ODbL Zustimmung /ODbL Agreement rate

Wobei man sagen muss, dass der Anstieg bei den Zustimmern / der Rückgang bei den ‘schlechten’ Daten rein logisch gesehen mit der Zeit langsamer werden muss. Und dass nach Plan ja schon am 1.4. alles vorbei sein soll, also die 2-6 Monate nicht zur Verfügung stehen.

In vielen Gebieten sieht es ja schon ziemlich gut aus. Allerdings gibt es auch Bereiche, wo ich ziemlich schockiert über die Konsequenzen bin, z.B. bei Uelzen: http://cleanmap.poole.ch/?zoom=12&lat=52.97778&lon=10.57158&layers=00B0 Da fehlt dann der halbe Landkreis und dabei ist es bislang sehr detailliert dort.

Bleibt nur zu hoffen, dass wir anschließend Ruhe haben. Zumindest meine Intention war es bei OSM immer, Daten für jeden unter keiner Bedinung zur Verfügung zu stellen. Schade, dass sich dagegen einige wehren.

Ja, das erklärt die Funktion und Arbeitsweise des OOM Killers.
Ich vermute mal, dass dabei OOM Out Of Memory bedeuten soll.

Edbert (EvanE)

Korrekt.
Das ist so ziemlich die letzte Waffe, die Linux einsetzen kann, wenn es eng wird. Bevor der Rechner hängen bleibt und überhaupt nix mehr geht, werden einige Anwendungen gekillt. Dann sind deren Daten zwar weg, aber das wären sie auch, wenn neu gebootet werden müsste. Der Rest hat dann noch ne Chance.

Gruss
Walter

Eine “Weiche Umstellung” wäre genial. Es werden, sagen wir mal 100 Punkte weltweit verteilt. Von diesen Punkte aus zieht dann ein BOT eine ODBL-Grenzlinie, welche immer um ODBL-Konforme Bereiche ausgeweitet wird.

Am Ende haben wir eine schöne Karte und können so perfekt sehen, wo viel zu tun ist. Wenn nur mit Kantenlängen von 100 bis 200 Metern gearbeitet wird, hält sich alles auch halbwegs in Grenzen.

Erst sind es dann 100 ODBL-Inseln. Diese Inseln wachsen irgendwann zusammen, bis es viele NON-ODBL-Inseln gibt, die dann verkleinert werden können.

Und was macht das besser? Letztlich läuft es darauf hinaus, dass ein Bot alles, was nicht schon durch das Remapping aus der Welt (naja, ‘Datenbank’) geschafft worden ist, löscht bzw. ersetzt. Ob das nun mit einem Mal überall oder über längeren Zeitraum lokal begrenzt passiert, was macht es für einen Unterschied?

Wenn es sich so “Virusartig” oder “Blubberartig” ausbreitet ohne daß der Bot gleich löscht, ist das ein großer Ansporn, weiter zu machen. Und das zieht. Wenn Du siehst, daß zwei Dörfer weiter ein “Loch” ist, machste das, auch wenn Du sonst nie nachgeschaut hättest dort…

Dennis, das ist nun wirklich kein Argument. Denn wenn die zwei Dörfer dann gelöscht sind, dann müssen die sowieso neu gemappt werden. Egal ob sie “sanft” gelöscht wurden oder “hart”. Wer sich bisher nicht um sein Revier gekümmert hat, wird auch in den nächsten 1-2 Monaten nicht dort remappen.

Wenn einmal gelöscht ist, weiß hinterher wenigstens jeder woran er ist und was alles neu gemacht werden muss. Derzeit geht mit Sicherheit auch viel Energie in Sachen, die nicht unbedingt komplett ersetzt werden müssen.

Was mir an halbwegs sinnvollen Szenarien einfallen würde:
Szenario 1:
Wir einigen uns auf eine Reihenfolge nach Objektarten: z.B. zuerst werden die nötigen landuses gelöscht, zuletzt highways und places
Vorteil: Man erkennt auf den Übersichtskarten besser wo noch kritische Infrastruktur verloren geht
Alternative: ->bisher: in JOSM größere Gegend laden, filtern, Lizenzprüfung starten → unnötig hohe Serverlast
->todo: z.B. im OSMI License Change View mehrere Layer (nach Objektarten) anbieten

Szenario 2:
Es werden zuerst Objekte gelöscht die nur von Nicht-Zustimmern bearbeitet wurden, zuletzt Objekte an die Zustimmer Tags wie name/maxspeed/… ergänzt haben
Vorteil: Man erkennt wo noch Informationen von Zustimmen zu retten sind die sonst nur aufwendig vor Ort neu erfasst werden könnten
Alternative: ->bisher: jede einzelne Objektgeschichte prüfen → sehr Zeitaufwendig
->todo: Tools schaffen die Objekte mit Tags von Zustimmen hervorheben

Gruß
BBO

Nach Art dürfte nicht gehen, da diese massenhaft miteinander gekoppelt (gemeinsame Nodes) sind. Wobei, könnte man sicher auch dann erstmal die Nodes drin lassen.
Ich sehe darin aber keinen sinnvollen Ausweg. Denn jeder Remapper hat andere Präferenzen. Bei dir mögen es die Straßen sein, bei mir der landuse bei noch einem anderen die POIs und wieder ein anderer die Schienen. Wo also anfangen???

Mit Szenario2 hätte ich kein Problem, wäre froh, wenn alles “rote” erstmal weg ist. Allerdings kann man dann immer noch nicht unbeschwert loslegen und muss dennoch bei jeder Verknüpfung mit bestehenden Daten aufpassen, dass man nicht für die Katz mappt.

Ja, aber da sehe ich den ‘continous changeover’ nicht. Ich meine, das ist ja mit zwei diskreten Schritten abzuhandeln: 1. Man lösche alles, was eh nur von Ablehnern bearbeitet wurde, weil’s eh weg muss und 2. bearbeite man den Rest eben etwas später. Aber das hat ja nichts mit einem System zu tun, das in sehr kleinen Dosen arbeitet.

Natürlich kann man das kontinuierlich machen. Kontinuierlich bedeutet für mich nur, dass man nicht die DB sperrt, alles durchlaufen lässt und dann das Resultat wieder frei gibt, sondern dass man ganz normal einen Bot laufen lässt, der dann 3-4 Tage beschäftigt ist mit dem Löschen.

Unter ‘continous changeover’ verstehe ich dass, was ich bereits im Post #1211 angesprochen habe: Wenn wir so weiter remappen und zustimmen, wird in einigen Monaten Zahl der “schlechten” Daten auf 0 sinken. Und damit haben wir dann automatisch eine ODbL konforme Datenbank. Dass man den Prozess noch technisch unterstützt und am Ende eventuell den Rest einfach rausputzt (löscht), ist durchaus möglich. Aber ich beobachte heute schon Regionen wo Mapper jede auch noch so kleine Abweichung beseitigen. Die Licensechange Karte von OSMI und der entsprechende Overlay als JOSM Hintergrund sind dort nicht nur Hilfreich, sondern auch ein Ansporn.

Ich denke mir auch ohne zusätzliche Massnahmen würden wir die Umstellung schaffen - warscheinlich nicht in den nächsten 3 Wochen, aber warscheinlich bis zur Jahresmitte.

mdk

das gefällt mir aus drei Gründen nicht.

  1. Das Drama muss auch mal ein Ende haben
  2. Ist es technisch wesentlich einfacher nach der Löschung fehlende Objekte neu zu erstellen
  3. ist es menschlich angenehmer etwas neues zu erfassen als zu ersetzen, wo man viel Arbeit hat aber hinterher nichts auf der Karte sieht.

Ich garantiere dir: Das wird nie der Fall sein, wenn man nicht “schlechte” Daten in größeren Mengen löscht. Als Beispiel sein nur mal der Mapper Mirco Küster genannt. In seiner Kernregion um Artern rum hat sich seit Monaten nichts getan. Gut ein wenig Landuse hab ich remappt, das macht weder Spaß noch ist es sonderlich effektiv. Ebenso in der Dominikanoschen Republik, wo er die Hauptstadt aus dem Boden gestampft hat.

Von anderen Daten in Ländern ohne nennenswerte Mapper/ohne Community möchte ich nicht reden.

Auf die 0 kommt man nur mit aktivem Löschen.

Volle Zustimmung.
Ein ähnliches Problem gibt es in USA:
Dort sind fast alle Straßen drin, weil sie durch den Tiger-Import geladen wurden. Allerdings sind diese Daten grottenschlecht, falsch positioniert, veraltet.
Auf dem ersten Blick sieht das ja ganz gut aus und niemand von der lokalen Community hält es für notwendig, dort aktiv zu werden und diesen “Schrott” zu korrigieren.
Allein die massive Existenz von unkorrekten Daten bremst die Leute dort aus. “Es sieht ja alles prima aus - was soll ICH denn da tun?”
Hier erschlägt die Masse die Qualität.

Gruss
Walter

@aighes: Natürlich kann man. Aber ich sehe den Nutzen davon nicht.

@mdk: Das verstehen aber die LWG und die Rebuild-Mailingliste anders - nämlich wie oben besprochen.

ich habe soeben die “Specials” auf odbl.de angestossen. Mit Eintritt in den Read-Only Mode werde ich alle Statistiken letztmalig duchlaufen lassen und die Berechnung dann anhalten.

Dann sei dir jetzt schonmal ein großes Dankeschön gesagt!!! Die Statistik war immer eine gute Hilfe und etwas Motivation hat sie auch geliefert, sich mal in der weiten Welt umzumappen.

gern geschehen. Den größten Teil hat allerdings Wicking gemacht. Er hat die Skripte den Wünschen hier angepasst und automatisiert.