[Talk-de] Lizenzwechsel ohne Datenverlust + bessere Versionskontrolle + Qualität durch Sichtung

Heiko Jacobs heiko.jacobs at gmx.de
Do Dez 16 23:14:06 UTC 2010


Moin

Ich möchte noch mal das Thema Lizenzwechsel + Datenverlust aufgreifen,
auch unter neuen Gesichtspunkten und verbunden mit dem Thema
Qualitätssicherung und Versionskontrolle, vielleicht auch
interessant im Zusammenhang mit einer laufenden bacchelor thesis
http://forum.openstreetmap.org/viewtopic.php?id=9817
oder dem groben Ansatz der kartographischen Darstellung des
Lizenzwechselstandes http://osm.informatik.uni-leipzig.de/map/?layers=B0

Zu dem Themenkreis braucht man
- Entscheidungen zur Vorgehensweise und
- Tools zur Umsetzung derselben.

Bei letzterem sind es vor allem zwei:
- Herstellung einer kompletten Objekthistorie und
- Entscheidung aus dieser heraus, welcher Lizenz ein Objekt aktuell hat.

Arbeitet schon jemand auf der Welt an solchen Tools?
Habe jedenfalls noch nicht von sowas gehört ...

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.

Für zweiteres würde ein standalone Tool reichen, dass 1x bei der
Umstellung der Lizenz durchläuft. Hätte den Haken, dass man keine
Zwischenstände erzeugen könnte ...
Letzteres hieße, dass man entweder der API das beibringt,
oder *alle* hochladenden Editoren zwingt, Infos einzubauen.
Oder beides. API-Einbau, der meistens (aber nicht immer) nix zu
tun hat, weil die großen Editoren es mundgerecht liefern, denn die
wissen ja am besten, wann split/join geklickt wurde ...

Soweit der erste Tool, nun erst mal zum Lizenzwechsel.

Wer braucht die neue Lizenz?

Der reine Mapper eigentlich nicht so dringend, weil der mappt ja
schon die ganze Zeit fröhlich mit der angeblich ungeeigneten Lizenz,
der würde wohl auch weiter fröhlich damit mappen ...

Die meisten Datenanwender auch nicht so dringend, denn für die div.
slippy maps online und auf Navis war die alte Lizenz bisher auch
brauchbar.

Es gibt aber einen Kreis, der ganz spezielle Anwendungen mit den
Daten aus OSM bestücken will, vielleicht auch Daten unterschiedlicher
Lizenzen miteinander kreuzen will, ohne dabei in juristische
Schwulitäten zu kommen, was bei der jetzigen Lizenz wohl pasieren kann.

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.

Großer Haken ist in meinen Augen aber die Behandlung der Altdaten,
die nach bisheriger Lesart zwangsläufig bei einer Umstellung
verschwinden müssten. Dabei verschwinden nicht nur Wege etc., sondern
weiterhin bestehende Objekte werden -- fast noch schlimmer -- durch
Wegfall von nodes oder tags teilweise grob verfälscht.
Besonders lästig ist, dass sich das unter keinen Umständen verhindern
lässt, selbst wenn man noch so große Werbemaßnahmen startet für
den Wechsel, weil es immer Leute geben wird, die nicht zustimmen können
oder wollen, weil sie tot, verschollen oder verärgert ausgestiegen
sind oder einfach, weil ihre verwendete Datengrundlage nicht kompatibel
mit der neuen Lizenz zu kriegen ist.

Für den Kreis der Spezialanwender ist eine Lizenzumstellung
existentiell wichtig, während für die große Masse die Umstellung
einen eher nur theoretischen Nutzen haben wird, aber rein praktisch
höchst ärgerlich werden wird, wenn sie erstmal (zu spät) merken,
was das für Nebenwirkungen haben wird.

Da stellt sich für mich schon lange die Frage, ob diese Nebenwirkungen
nicht vermeidbar sind. Bisherige Überlegungen stießen aber größtenteils
auf Ablehnung. Vielleicht habe ich mit den neuen ja mehr Glück ... ;-)

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
- ...

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
Was genau da rauskäme, muss noch diskutiert werden, gerade vorm
Hintergrund gemeinsam bearbeiteter Objekte, bisher völlig ungelöst.

Bisher ist vorgesehen, dass daraus dann EIN neuer Datensatz entsteht,
der nur noch ODbL-Daten enthält.

Warum aber nur so "binär" und einmalig?

Im Prinzip wird der Beurteilungsprozess sicher so gestaltet werden,
dass man ihn mehrmals laufen lassen kann, denn das Volk verlangt
nach Zwischenzuständen "bis heute haben 47110815 Mapper zugestimmt,
das führt zu dieser Karte http://... wenn es so bliebe"

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 ...
Was genau gespeichert werden könnte, kann man vermutlich erst im
laufenden Prozess beurteilen, wenn man sich genauer damit beschäftigt.
Vielleicht bringt die Diplomarbeit da Erkentnisse?

Damit könnte man dann zwei Sachen machen:

A.
Wir lassen einfach alle Daten auf Dauer in OSM drin, auch die CC-Daten.

Wer die Daten für Anwendungen braucht, bei denen es egal ist, ob sie
unter CC oder ODbL stehen, zieht sich einfach ALLE Daten.
Die slippy maps könnten weiterhin alle Daten ziehen, es sei denn,
es sind Spezialkarten, die künftig inniger mit Fremdlizenzdaten
kombinieren wollen als es die CC-Lizenz zulässt.

Wer die Daten sauber nach einer einzigen Lizenz braucht, greift
nicht auf den Original-Planeten zurück, sondern entweder bei großen
Gebieten auf in bestimmten Abständen generierten Auszüge, so wie
es sie ja schon regional ausgeschnitten, Deutschland etc. pp., gibt.
Dann gibt's halt nicht nur planet.osm, sondern auch noch planet-odbl.osm
und planet-pd.osm (!) oder planet-odbl50.osm.

Wer nur kleine Gebiete braucht, kann ja jetzt schon über die XAPI
bspw. highway=residential selektiv abfragen, da käme dann l=o o.ä. hinzu,
wer's lizenzrein braucht.

So gäbe es keine Datenverluste und die, die ODbL zwingend brauchen,
können im Prinzip ab sofort (sobald es diese Tools gibt) loslegen,
deutlich früher vermutlich, als wenn sie auf die 99%-Umstellung warten
müssten, die vielleicht auch gar nicht kommt, wenn nicht genug mitmachen
(können). Sie können schon bei 75% starten, besser als wenn's keine
ODbL-sauberen Daten gäbe.

Dass der Bestand an ODbL-Daten innerhalb dieser Mischdatenbank
anteilsmäßig wächst, dafür können zwei Effekte sorgen:
zum einen die wachsende Zahl neuer User, die nur noch ODbL-kompatibel
einsteigen, zum anderen die ohne Datenverlustgespenst stärker steigende
Zahl der Lizenzwechsler.
Wir können (und sollten auch) auch beim bisherigen Plan bleiben, dass ab
einem Zeitpunkt in 2011 nur noch Benutzer erlaubt sind, die zugestimmt haben.

Das ist aber noch nicht alles, kommen wir zu:

B:
Sobald man in den Daten ein l=o o.ä. drin hat, kann man das
natürlich auch anzeigen.
In Potlatch 2 bspw. über einen weiteren Kartenstil.
Darauf kann man was weiteres entwickeln, was sich neben einer besseren
Versionskontrolle im Prinzip auch an die Wikipedia anlehnt:

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.

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, ...)

Wir werden ja noch in das große Problem reinrutschen, dass die Daten
so aussehen, als wäre alles gemappt. Woran erkennt man denn heute,
dass es in einer Ecke veraltete Daten geben könnte? Gar nicht,
weil man denen ihr Alter absolut nicht ansieht.
Mit Sichtungstools und -anzeigen könnte man das Alter besser erfassen
und so Ecken erkennen, die mal kontrolliert werden sollten ...
Irgendwann wird's uns ja langweilig, wenn alle Blumenzwiebeln im
Garten dank 1-cm-Luftbilder erfasst sind ;-)

Im Prinzip könnte man auch das Gegenteil einführen: Sichtung aufheben,
um auszudrücken, dass Geometrie und/oder Eigenschaften angezweifelt
werden, das wäre sozusagen eine erweiterte Verknüpfung mit OpenStreetBugs
oder so ...
Sowas hätte ich mir die Tage gewünscht an einer Stele, von der ich
weiß, dass dort irgendwo irgendwie gerade ein neuens Bahnbetriebswerk
gebaut wurde.

Außerdem müsste auch das Tool, dass den Lizenzstatus erfasst, ob nun
einmalig oder mehrfach für Zwischenzustände, dauerhaft installieren, damit
- diese Sichtungen am l=... angebracht werden
- oder die ganz normalen Änderungen, die den Status ändern,
letzteres durch das ganz normale Verschieben von nodes oder ändern
von tags, die ja auch eine Sichtung mit anderen Mitteln ist ...

Damit hätte ich glaub alle Tools und Schritte beisammen ...


Vorteile:
- Datenverlust vermieden
- Lizenzübergang gleitend
- Problem gemeinsam bearbeiter Daten nicht mehr so schwerwiegend für viele
- schneller ODbL-Datensätze für Spezialanwender verfügbar
- aber auch schneller besserer Schutz, weil schneller von CC-only-DB weg
- eventuell migriert OSM so irgendwann auch langsam gleitend zu PD
- überhaupt ist es die einzige Möglichkeit für PD-Fans PD zu extrahieren?
Und:
- langfristig durch Sichtung und Versionskontrolle bessere Qualität

Nachteile:
- ODbL-only-Datenbank dauert länger
- mehr Aufwand im laufenden Betrieb

Mit Sichtung wird der Nachteil, dass noch CC-Daten da sind, aber vielleicht
schneller ausgeglichen, als wenn CC-Daten gelöscht und neu gemappt werden
müssten. Ich habe zwei große Waldgebiete bearbeitet, fehlende Wege erfasst
und ALLE Wege frisch klassifiziert.
ALLE nicht ODbL-sauberen tags, die schon vorher da waren, also
urheberrechtlich nicht von eingebracht sind, könnte ich in einem
Rutsch sichten, denn wären sie nicht da gewesen, hätte ich sie ja
drangehängt.
Bei den Geometrien müsste ich etwas genauer hinschauen, ob meine
GPS-Tracks auch eine Sichtung der Geometrie hergeben, weil ich meinen
alten Empfänger mit wenig Speicher oft abgeschaltet habe, wenn ich
über alte Wege fuhr. Aber aus Extrapolation meiner GPS-trcks und
Vergleich mit Luftbildern könnte ich wohl vieles doch geometrisch sichten.
Fehlendes wird irgendwann nachermittelt, Waldwege ändern sich ja
gelegentlich und irgendwann muss ich wieder raus, nachgucken, ob grade4
noch immer grade4 ist oder inzwischen impassable, grade5, grade3, grade2, ...

Im Prinzip läuft ja gerade ein riesengroßer "Sichtungsprozess" an:
Mit Freigabe der Bing-Luftbilder wird verstärkt abgemalt.
Aber nicht nur neues wie bei mir gleistreue Bahnanlagen, Wenn
die Geometrie nicht passt und es nicht am verschobenen Luftbild
liegt, dann rückt man ja auch die nähere Umgebung zurecht (ich jedenfalls),
damit die Bahnbrücke zur Straße drunter passt und nicht alles krumm
und schief aussieht.
Diese Daten sind damit zumindestens "geometrisch frisch gesichtet".
Aber mit der derzeitigen Technik eben nur, wenn der node dabei wenigstens
ein bisschen verschoben wurde. Passt das drumrum dagegen gut, dann
habe ich das für mich zwar festgestellt, konnte diese Erkenntnis an den
Daten aber nicht anbringen.

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.

Werde einen Crosspost über die div. Kommunikationskanäle machen:
talk-de, Forum und Wiki in meiner Sprache deutsch, mindestens
talk-legal und Wiki auch mit dem Versuch einer leicht gerupften
englischen Version. Möge es so die richtigen Leute erreichen,
ggfs. durch weiterreichen an die richtigen Stellen.

http://forum.openstreetmap.org/viewtopic.php?pid=127301 im Forum deutsch
http://forum.openstreetmap.org/viewtopic.php?pid=127300 im Forum englisch
Im Wiki:
http://wiki.openstreetmap.org/wiki/Talk:ODbL/Upcoming#licence_change_without_data_loss_.2B_better_version_control_.2B_flagged_revisions

Gruß Mueck





Mehr Informationen über die Mailingliste Talk-de