[Talk-de] Neuigkeiten vom OSMI Lizenzwechsel-View, und odbl=clean

[Frederik Ramm]

Hallo,

    ich habe den Lizenzwechsel-View so angepasst, dass man jetzt fuer 
ein ausgewaehltes Objekt auch direkt zum "Deep History"-Dienst von Ian 
Dees springen kann, da sieht man dann schoen aufgelistet, wer wann was 
hinzugefuegt hat. Das ist dieses "Uhr"-Icon. Ausserdem wird jetzt 
angezeigt, welcher Benutzer fuer die Faerbung eines Objekts 
verantwortlich ist - in Form der Benutzer-ID oder, wenn bekannt, des 
Benutzernamens. (In einigen Faellen koennten es mehrere verschiedene 
User sein, dann wird nur der erstbeste gelistet, aber im Deep 
History-Dienst sieht man das dann genauer.)

Es kam ja hier auch schon im Thread "Remappen NACH dem Lizenzwechsel" 
die Frage hoch, was man in Situationen machen soll, in denen ein Objekt 
durch einen an sich harmlosen Beitrag unnoetigerweise eingefaerbt wird.

Ganz klare "sinnlose" Beitraege - z.B. Aenderungen, die spaeter 
revertiert wurden, oder Nicht-Aenderungen - filtere ich fuer den 
OSMI-View bereits heraus. Das ist allerdings aufwendig, weil man dazu 
die Geschichte aller Objekte betrachten muss, und das passiert daher 
nicht automatisch. Viele "korinthenkacker"-Edits sollten auf diese Weise 
schon von mir herausgefiltert worden sein, oder die allfaelligen 
"created_by"-Loeschungen usw.

Oft ist es aber komplizierter - ein Mensch kann die Historie ansehen und 
sagen "ja, von der Aenderung, die der Nichtzustimmer X 2009 gemacht hat, 
ist hier eigentlich nichts mehr uebrig, dieses Objekt kann so 
freigegeben werden", doch einem Algorithmus faellt das schwer.

Wenn es eine Moeglichkeit gaebe, das anzugeben - "dieses Objekt is OK 
so, dafuer stehe ich, Mapper X" - dann waere das nicht nur fuer das 
Aufraeumen des OSMI-Views, sondern auch fuer den tatsaechlichen 
Lizenzwechsel hilfreich.

Auf Benutzer-Ebene ("alles, was dieser Benutzer gemacht hat, ist OK, 
obwohl er nicht zugestimmt hat") und auf Changeset-Ebene ("dieser 
Benutzer hat nicht zugestimmt, aber die Changesets X, Y, und Z sind 
automatisierte Importe/Aenderungen und koennen daher uebernommen 
werden") gibt es bereits solche "Uebersteuerungen" (siehe 
wiki.openstreetmap.org/wiki/WTFE). Bloss auf der Ebene einzelner Objekte 
noch nicht.

Man koennte so auch selbst aufraeumen und z.B. ein von einem 
Nichtzustimmer hinzugefuegtes Tag direkt loeschen und danach das "jetzt 
ist das Objekt sauber"-Flag setzen. Das wuerde es uns erlauben, mithilfe 
des OSMI-Views systematisch die Gegend abzugrasen und fuer den 
Lizenzwechsel vorzubereiten.

Einige haben hier im blinden Vertrauen auf "OSMF wird das schon richtig 
machen" gesagt "da warte ich doch lieber, bis die dann beim 
Lizenzwechsel alles sauber geloescht haben, und dann schau ich...". 
Ehrlich gesagt, weiss ich nicht, ob und wie "die das schon richtig 
machen" werden, und es waere mir lieber, wenn wir (Mapper vor Ort) das 
vorher taeten. Selbst wenn wir alle Objekte in einen Zustand bringen, in 
dem wir sagen: So koennen die jetzt uebernommen werden, dann muss die 
OSMF immer noch rausfinden, wie sie mit der History umgeht und so 
weiter, das ist alles nicht ganz trivial.

Ich koennte mir vorstellen, dass wir dafuer einen Tag "odbl=clean" 
einfuehren. Dieses Tag duerfte man nur setzen, nachdem man sich 
gruendlich ueberzeugt hat, das das Objekt in diesem Zustand 
lizenzmaessig "sauber" ist und uebernommen werden kann - es waere 
praktisch gleichzusetzen mit einer Loeschung und Neuerstellung des 
Objekts, aber es haette den Vorteil, dass die History erhalten bleibt 
und dass es eine bessere Nachvollziehbarkeit bietet. Ich koennte damit 
genau sehen, dass das Objekt X weiter in der Datenbank bleibt, weil User 
Y zum Zeitpunkt Z dafuer das OK gegeben hat; wenn der User Y hingegen 
das Objekt loescht und neu anlegt, ist die "Datenspur" weniger deutlich.

Ich habe vor, das mit dem OSMI-View mal auszuprobieren (wenn nicht 
irgendjemand jetzt ganz laut schreit); ich wuerde dann alle Objekte, die 
"odbl=clean" gesetzt haben, nicht mehr rot/orange, sondern leicht gruen 
einfaerben auf der Karte, und die Lizenzwechsel-Views im JOSM und 
Potlatch muessten natuerlich auch entsprechend eingefaerbt werden.

Zwar steht hinter dem ganzen keine Garantie der OSMF, dass die auch 
mitziehen und am Stichtag dann alles, was odbl=clean ist, uebernehmen - 
aber eigentlich rechne ich schon damit. Da jeder Mapper jederzeit eben 
auch ein Objekt loeschen und neu erstellen kann, gibt es keinen Grund, 
dem odbl=clean nicht zu vertrauen.

Bye
Frederik

-- 
Frederik Ramm  ##  eMail frederik at remote.org  ##  N49°00'09" E008°23'33"