Erstmal Danke. Danke, dafür, dass du mir das Schreiben abgenommen hast. ;-)
Denn ich hatte auch schon sehr ähnliche Gedanken, ich bin nur nicht dazu
gekommen, sie niederzuschreiben.
2010/12/17 Heiko Jacobs <heiko.jac...@gmx.de>
> Ersteres Tool ist nötig wegen des Teilens und Vereinigens von Wegen.
> Beim Teilen entsteht ein way mit "frischer" Historie und "neuem"
> Benutzer, auch wenn der außer der Teilung gar nix zu diesem way
> beigetragen hat.
> Beim Vereinigen geht dagegen die Historie eines ways verloren.
>
> ... beides zumind. aus Sicht normaler Nutzer.
> Eine komplette Verfolgung der Historie ist bisher nur äußerst
> mühsam möglich über die beteiligten nodes, weil die beim Teilen
> und Vereinigen meist bestehen bleiben, beim potlatch live Modus
> ganz sicher, bei allen anderen Editoren kann auch mit den nodes
> zwischendrin genug passieren, dass man es durchaus nicht so recht
> nachvollziehen kann ...
>
> Nützlich wäre ein solches Tools aber schon bei ganz allgemeinen
> Fragestellungen, bspw. wann bestimmte Änderungen eingefügt wurden
> und von wem, also für eine bessere Versionskontrolle.
> Von daher wäre es sinnvoll, ein solches Tool
> - unabhängig vom Lizenzwechsel zu entwickeln,
> - dieses nicht nur für's Aufarbeiten vergangener Edits zu verwenden,
> - sondern möglichst dauerhaft einzusetzen auch für künftige Edits.
>
So was wäre allgemein ein gutes Feature für die nächste API Version.
Beim Neuerstellen eines Weges wird dann mitgespeichert, ob der Weg echt neu
oder aus der Teilung eines anderen Weges entstanden ist (welcher?) und beim
Löschen wird dann mitgespeichert, ob der Weg eventuell aufgrund einer
Vereinigung gelöscht wurde.
Für letztere ist die neue Lizenz nach allem, was mir bisher begegnete,
> vermutlich klar besser. Und auch dem Mapper bietet sie vermutlich mehr
> Sicherheit (Unter "Lizenz" verstehe ich jetzt mal zur Vereinfachung
> die Gesamtheit aus Daten- und Datenbanklizenz und CT.)
> So dass es vermutlich insgesamt betrachtet besser wäre,
> die Lizenz zu wechseln. Und je schneller, desto besser.
>
Ja, ein schneller Lizenzwechsel wäre alles in allem eigentlich auf jedem
Fall begrüßenswert - aber es muss alles getan werden, dass der Datenverlust
so gering wie möglich gehalten wird!
Die Daten sind einfach wesentlich wichtiger als die Lizenz!!
> Da stellt sich für mich schon lange die Frage, ob diese Nebenwirkungen
> nicht vermeidbar sind.
>
Wenn man will, auf jeden Fall. Nur leider erwecken einige Akteure den
Eindruck, dass sie garnicht gewillt sind, diese Nebenwirkungen so weit wie
es irgend geht zu vermeiden...
> Ein Tool haben wir ja noch zu diskutieren:
> Die Klärung, welches Element unter welcher Lizenz steht.
> Da gibt's einen ganzen Rattenschwanz zu klären:
> - Wie gewichtig ist das Urheberrecht an einer einzelnen Koordinate eines
> nodes
> - Wenn von 100 nodes eines ways 99 ok sind, was macht man mit dem 100.?
> - ab wann sind edits trivial, Frage nach bots etc.
> - ab wieviel tags unter neuer Lizenz ist ein Element sauber
> - ...
>
Ja, das ist mit die dringendste Frage, die für den Lizenzwechsel endlich mal
geklärt werden sollte. Bis das nicht geklärt ist, hängen wir nämlich
wirklich in der Luft.
> Da will ich mir gar nicht groß den Kopf drüber zerbrechen, weil
> - Diplomarbeit unterwegs, die da vielleicht Antworten liefert?
> - nicht so wirklich relevant für meine Überlegung.
> Es geht um das Ergebnis, das kann sein:
> - Element sauber OdBL, 100%
> - Element nicht sauber ODbL
> oder auch
> - Element sauber ODbL, 100%
> - Element fast sauber ODbL, 90%
> - ...
> - Element rein CC, 100%
> oder auch
> - Element 100% PD, das kann man ja auch ankreuzen
>
Ich verstehe nicht ganz, wie das mit den 90% etc. funktionieren soll. Ich
würde eher sagen, der kleinste gemeinsame Nenner zählt.
- Nur PD-Edits -> PD
- PD + OdBL-Edits -> OdBL
- PD + OdBL + CC-Edits -> CC
Ein Schritt weiter wäre dann noch die Betrachtung der Versionen:
"Bis Version 2 PD, bis Version 5 OdBL und ab da CC."
> Dann sind wir nahe dran, den einmal ermittelten Zustand irgendwo
> in den Daten festzuhalten. Dann kriegt ein <way id=...> <node id=...>
> <tag k=... v=...>, oder was auch immer man alles beurteilen wird,
> noch ein l=... (licence=...) dazu
> l=o, l=c, l=p oder auch in Variationen l=o50 für 50% ODbL ...
> vielleicht auch noch Zusätze, die aussagen, warum etwas noch nicht
> 100% ODbL ist ...
>
Wie oben schon gesagt, die Sache mit den Prozenten finde ich nicht so toll,
es reicht eigentlich schon das 'l=o, l=c, l=p'.
> Sichten!
>
> (Ich nenne es mal so in genau dieser Anlehnung an die Wikipedia)
>
> Wie mappt Otto-Normal-Mapper heute?
> Er mappt, was fehlt.
> - fehlende nodes, wenn die runde Straße noch eckig erscheint ...
> - fehlende ways komplett
> - fehlende tags
> Kaum ein Mapper käme auf die Idee, schon vorhandenes neu zu machen,
> - außer, das Objekt liegt geometrisch daneben, dann wird's zurechtgerückt
> - oder die tags sind falsch oder suboptimal
>
> Auch vorhandenes neu zu mappen, die Idee kam ja erst im Zuge des
> Lizenzwechsels auf, um Daten ODbL-sauber zu machen.
> Das ist aber einfach nur Quark ...
>
> Aber im Prinzip haben wir noch ein Problem, dass wir in diesem Zuge
> lösen könnten: Ein einmal angelegtes Objekt hat den Zeitstempel des
> Anlegezeitpunktes. 5 Jahre später, wenn seitdem niemand anderes was
> dran getan hat, stehen wir vor der Frage
> - ist das Objekt wirklich unverändert
> - oder ist der Stand veraltet?
>
> Im Moment gibt es keine Möglichkeit, ein Objekt als noch existent zu
> bestätigen.
>
> Wenn wir eine Sichtung einführen in OSM, die Lizenzstatus und
> Alter des Objekts anzeigt, könnten wir mit einem Klick auf "sichten"
> - bestätigen, dass ich das Objekt unter neuer Lizenz neu hätte mappen
> können
> und/oder
> - bestätigen, dass das Objekt immer noch genau so existiert.
>
Genau!
Bei meinen Überlegungen hatte ich dieses Lizenz-Sichten als Bürgen
bezeichnet. Denn dieses Sichten mit der Übernahme des Weges in die OdBL
würde eigentlich folgender Aussage entsprechen:
"Ich bürge, dass dieses Objekt mit all seinen Eigenschaften genau so
existiert. Ich bestätige hiermit, dass ich alle Möglichkeiten hätte, dieses
Objekt in seiner Lage und mit all seinen Eigenschaften genau so wieder zu
erfassen. Dieser Vorgang [des Lizenz-Sichtens] stellt in diesem Sinne nur
eine Abkürzung des erneuten Mappens dar."
Das würde in meinen Augen bedeuten, dass ein Verstoß gegen die originale
Lizenzsierung nur dann besteht, wenn sich dieses Lizenz-Sichten auf die
CC-Daten stützt, was dann der Fall ist wenn der sichtende Mapper eben nicht
alle Möglichkeiten hat, dieses Objekt in seiner Lage und mit all seinen
Eigenschaften genau so wieder zu erfassen (z.B. weil er hunderte Kilometer
weit weg wohnt und auch noch nie in der gesichteten Gegend war).
Eine eventuelle Verletzung der CC-Lizenz muss dann übrigens auch gegen den
sichtenden Mapper vorgebracht werden. Und dann muss ihn auch erstmal
nachgewiesen werden, dass er eben nicht alle genannten Möglichkeiten
hatte...
Und noch eine Frage an unsere (Hobby-)Lizenzrechtler: Wer darf eigentlich
sein Lizenzrecht geltend machen, wenn ein Objekt mehrere Bearbeiter hat?
> Vermutlich müsste man noch unterscheiden, ob man
> - die Geometrie
> - die Eigenschaften
> bestätigen kann. Ersteres aus eigenen GPS-Tracks oder Luftbilder,
> letzteres einfach durch in Augenscheinname.
> Vielleicht auch noch detaillierter unterschieden (ich kann surface
> bestätigen, aber nicht name, ...)
>
Bei einem alleinigem Bestätigen der Geometrie müsste man dann alle Tags
entfernen und nur den Weg in OdBL übernehmen (eventuell kann man ja bei
Straßen/Wegen wenigstens ein highway=road mit übernehmen)
Bei den Eigenschaften müsste man das dann so machen, dass man einfach die
Eigenschaften abhacken kann, die man bestätigen kann und nur diese werden
dann in das OdBL-Objekt übernommen.
Eigentlich kann man doch die Eigenschaften nur bestätigen, wenn man auch die
Geometrie bestätigen kann, oder?
Die Idee mit der Sichtung finde ich eine wunderbare Erweiterung dieser
Lizenz-Sichtungs-Idee.
Man muss dan natürlich auch, anders als bei Wikipedia,
Sichtungsaktualisierungen möglich machen. Also eine erneute Sichtung nach
einiger Zeit ohne das es eine neue Objektversion gibt.
Und schön wäre dann noch eine Karte die farblich das Alter der letzten
Sichtung darstellt.
> Inwieweit der laufende Betrieb ein Flaschenhals sein kann,
> muss noch ein Fachmann bzgl. API beurteilen.
> Sprich ob das Einarbeiten des Lizenzstatus und der Version aus den
> Changesets mit und ohne Sichtung, mit Splits/Joins, ... mit oder
> ohne Tipps durch den Editor ("habe Weg x geesplittet in ...")
> kontinuierlich beim Hochladen erfolgen kann oder ob da ein Prozess
> nachgeschaltet werden muss (ähnlich wie das neurendern von
> Mapnik-Kacheln ja auch abgetrennt vom Hochladen läuft)
> und ob das lizenzgenaue Abrufen möglich ist und wenn ja,
> in welcher Detailliertheit bzgl. der Lizenz und evtl. Graduierungen.
>
Also die Erfassung des Splits/Joins sollte idealerweise in den Editoren
geschehen, das dürfte der geringste Aufwand sein, denen das beizubringen.
Damit die API damit auch umgehen kann, braucht es aber wohl eine neue
API-Version.
_______________________________________________
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de
