Datum für Lizenzwechsel steht

Sorry, ich meinte nicht, dass Du irgend jemand etwas unterstellt. Für mich stellt sich alles recht stringent dar. In den LWG Minutes steht der 1.4. und in dieser Mail der LWG auch. Du hattest nur geschrieben, dass Dir andere Infos vorliegen. Daher habe ich mich gewundert, dass die LWG nach wie vor den 1.4. erwähnt.
Das einzige, aber das ist jetzt Kaffeesatzleserei, was ich mir vorstellen könnte, ist, dass das ein Test der Community ist ob der Termin akzeptiert wird. Recht vage ist das ja im englischen schon formuliert, sowohl in den Minutes als auch in der Mail.

Sehr schön :slight_smile:

Hallo alle

Gerade wurde ich auf http://blog.osmfoundation.org/2011/11/16/odbl-progress/ aufmerksam gemacht.
Damit dürfte die Diskussion um den 1.4.2012 als Umstellungstermin hoffentlich ein Ende haben.

Edbert (EvanE)

Was machen sie, wenn sie am Tag der Umstellung draufkommen, dass sie noch keine Regeln definiert haben?

Sie verschieben? Ich kann mir aber kaum vorstellen, dass man jetzt 4.5 Monate rumsitzt und das vergisst.

Ich kann mir egentlich kaum vorstellen, dass der Termin halten kann, da ich mir überhaupt nicht vorstellen kann wie jemand (und schon garnicht ein automatische Skript) die ganzen Splits und Vereinigungen von Wegen etc. lizenzmässig korrekt abarbeiten könnte.

IMHO wird man da höchstens die leicht zu identifizierenden Lizenzprobleme durch Löschen/Reverts automatisch beheben können, beim Rest wird man ums drumrumschummeln nicht herumkommen. So in der Art, da haben schon so viele Veränderungen und Edits nach dem Nichtzustimmer an einen Objekt stattgefunden, da ist die neue Lizenz schon angemessen dafür.

Aber auch für diesen vom Skriptaufwand minimierteren Fall sollte man baldestmöglich Testläufe haben um zu sehen wie stark die Lücken wären. Ich gehe davon aus, dass wir mehrere Monate Zeit brauchen werden um zum einen die Umstellungsskripte zu perfektionieren und zum anderen die zukünftig entstehenden Lücken schließen zu können.

Markus

Ich denke, dass man weder das eine noch das andere machen wird. Zumindest die Lücken werden bestimmt nicht mehr vor der Umstellung geschlossen (soweit das nicht wir Mapper mit Hilfe der dafür schon vorhandenen Tools machen. Und was die Skripte angeht: Ich denke, man wird etwas einfaches machen, es soweit testen, dass es keine allzugroßen Probleme macht und dann auf die Datenbank loslassen. Warum langwierig so perfektionieren, dass alles absolut perfekt passt? Fehler können hinterher noch von den einzelnen Mappern ausgeglichen werden, Splits und Merges wird man denke ich garnicht erst beachten.

Dass die Lücken vorher nicht wirklich geschlossen werden können, denke ich auch. Aber es sollte schon die Möglichkeit geben diese schließen zu können. Dazu sind aber die bisherigen Tools ungeeignet, dazu bräuchte man schon eine Vorstellung des Datenbankstandes nach der Umstellung. Zumindest müsste man dringendst mal festlegen nach welchen konkreten Regeln die Umstellung vollzogen werden soll. Leider tut sich an der Front bisher nichts konkret sichtbares.

Aus meiner Sicht wird es besser sein, wenn man bei der konkreten technischen Umstellung keine Schnellschüsse auf die Datenbank loslässt. Zu gross ist da die Gefahr, dass entweder unnötige Lücken in den Datenbestand gerissen werden, bzw. auf der anderen Seite die Umstellung im lizenzrechtlichen Sinne eventuell nicht halten könnte, wenn man beinahe alles drinnen lässt. Da ist eine verlängerter Umstellungsprozess das kleinere Übel!

Markus

Du scheinst ein relativ schwaches Vorstellungsvermögen zu besitzen :wink:

Genau DIESE Zeit haben wir ja jetzt - oder reichen dir 4.5 Monate nicht?

Gruss
Walter

Wenn jetzt schon die Umstellungsskripte stehen würden, bzw. bekannt wäre nach welchen konkreten Kriterien die Umstellungsskripte vorgehen werden, dann würden der Zeitraum schon in etwa passen. Aber eben erst gerechnet ab dann, wenn diese konkreten Kriterien stehen.

Markus

Ich kriege da irgendwie Bauchschmerzen.

Um sicher zu sein, dass die eigenen Edits nicht bei der Umstellung verschwinden, müsste ich den bisherigen Grundsatz - respektiere die Arbeit der anderen - ersetzen durch:
Wenn du etwas änderrst, zerstöre möglichst viel History:

  • Du willst die Form eines Gebäudes anpassen? Also löschen und schnell neu erstellen (ist meist sogar einfacher, als irgent ein krummes altes 4-Eck weiter zu verwenden).
  • Du willst den Verlauf einer Weges korrigieren? Sicherheitshalber löschen und neu erstellen (wobei man die Tags natürlich aus einer anderen legael Quelle als OSM nehmen muss)!
  • Die ersten 50 Meter ab der Quelle eines Flusses stammen noch von einem Ablehner/Unknown? Dann sollte man den gesammten Fluss (nach Luftbildern) bis zur Mündung neu erfassen!

Mir graut vor den nächsten Monaten.

mdk

der Termin am 1.4. hat einen großen Vorteil. Üblicherweise steigt die Aktivität im Frühling stark an. Daher werden die Dinge (hoffentlich) schneller ersetzt als wenn man einen Termin im November nimmt. Dass es jetzt langsam mal Zeit für die Details der Löschaktion wird, ist denen schon bewusst. Das bekommt die LWG fast jeden Tag gesagt. Ich bin mir sicher, dass da schon dran gearbeitet wird. Angesichts der Haltung “lieber kritisieren als mithelfen” verstehe ich aber, dass die LWG vielleicht erst dann mit den Details rauskommt, wenn sie ausgereifter sind

Ich bin auf jeden Fall happy, dass der Termin endgültig feststeht - es sei denn, der Mond fällt auf die Erde :wink:

Ein Teil unserer Mitstreiter wird sich wohl mit weiteren Diskussionen beschäftigen, ein andere Teil die Ärmel hochkrempeln und -wie auch immer - retten was zu retten ist und ein grosser Teil wird weiterhin nichts tun.

Von der dritten Gruppe erwarte ich das größte Geschrei ab 04/2012

Gruss
Walter

@mdk: Wie wäre es denn mit folgendem Grundsatz stattdessen:
Wenn du etwas änderst, erhalte soviel History wie möglich: Rausfinden, was von Ablehnern stammt (licensechange-Plugin und Versionshistorie), das ersetzen, den Rest erhalten

Stammt beispielsweise nur ein Knoten im Weg von einem Ablehner, lösch ihn und setz, wenn nötig, einen neuen Knoten in die Nähe (nach Luftbild/GPS-Track). Stammt der ganze Weg ursprünglich von einem Ablehner, musst du ihn natürlich komplett ersetzen, kannst aber alle von Zustimmern erzeugten Tags und Knoten übernehmen.

Kennst du die Regeln wie mit Splits und Joins umgegangen wird? Ich nicht!

Ich konzentriere mich zur Zeit auf anonyme Edits (ID=0), da diese Beiträge mit an Sicherheit grenzender Warscheinlichkeit verschwinden werden. Anonyme edits sind in der Regel sehr alt und beinhalten sehr wichtige Objekte wie Autobahnen, Hauptstrassen und grosse Flüsse, halt all das Zeugs was man als aller erstes mappen würde.

Wenn der Weg nun einen Knoten solch eines “Ablehners” enthält, ist es dann nicht sehr warscheinlich, dass auch der gesammte ursprüngliche Weg von ihm stammt? Wenn Splits bei der Umstellung berücksichtuigt werden, ist auch dieser Weg futsch! und zwar ohne dass mir licensechange-Plugin oder Versionshistorie auch nur den geringsten Hinweis darauf geben würde!!!

Ich würde gerne meinen alten Grundsätzen treu bleiben, aber …

mdk

Da gibt es ein klitzekleines Problem, nämlich den Zeitfaktor. Ein Vorgehen in der zitierten Weise ist in vielen Fällen extrem aufwändig und damit zeitraubend. Soviel Zeit werden die meisten aktiven Mapper kaum haben, ich jedenfalls nicht. Schließlich ist OSM-Tätigkeit nicht die Hauptarbeit. Es bleibt also nur, entweder vorsorglich alle fraglichen Objekte plattmachen oder die Finger davon lassen.

Entsprechend verfahre ich. Bei den Objekten, die ich kenne oder wo ich z.B. aus Bildern Eigenschaften erkennen kann, lösche ich das alte Objekt und ersetze es durch ein entsprechendes Neues mit jungfräulicher history. Schließlich will ich die Arbeit nicht noch ein weiteres Mal machen müssen. Bei allen anderen Objekten lasse ich die Finger von Reparaturen.

Du meinst den Fork? Denn eine Umgehung des Urheberrechts wirst du hoffentlich nicht meinen…

Genau so ist es. Man kann nicht etwas reparieren, bevor man weiß, was kaputt geht.

Und ich bin mir sicher, dass Barbarossa in einer Höhle sitzt und wartet, bis sein Bart 3x um den Tisch gewachsen ist.

Sie haben die letzten 2 Jahre auch schon drauf vergessen. Siehst du Anzeichen für eine Änderung?

Wenn in deiner Firma ein Mitarbeiter die letzten 2 Jahre nichts weitergebracht hat, wirst du ihn wahrscheinlich rausschmeißen und wen anderen mit der Aufgabe betrauen.

Nein, Walter meint Leute wie z. B. Walter aka wambacher: Leute, die die Ärmel hochkrempeln und schauen, wo die “größten potentiellen Lücken” sind und versuchen, diese vor dem 1. 4. zu reparieren.

errt zitiert an anderer Stelle:
http://checkout.yourweb.de/thesis/Jakob_Altenstein_Thesis.pdf

Schaut jetzt nicht nach einem Hexenwerk aus, muss halt (so oder in ähnlicher Form) gemacht werden :wink: