ODbL Zustimmung /ODbL Agreement rate

@SunCobalt

Hallo Thomas

Bei der Auswertung für Europa vom 4.3.2012 ist irgendetwas schief gelaufen.
Es kommt nur eine leere Seite. Nicht mal der Header ist vollständig.

Das muss jetzt nicht zwingend neu gerechnet werden.
Aber wenn die Ursache nicht temporär ist, solltet ihr euch drum kümmern.

PS:
Bei der Gelegenheit, will ich mich für die Mühe und den Aufwand, die ihr in diese Auswertungen steckt, bedanken.
Diese Auswertungen sind ein wertvolles Hilfsmittel, die Entwicklung der Zustimmung in den einzelnen Gebieten zu verfolgen.

Edbert (EvanE)

In Hannover hat er sehr präzise Knotenpunkte eingezeichnet.

Hat sich erledigt, jetzt ist alles da. Danke :slight_smile:

Edbert (EvanE)

Das war der OOM Killer, den ich mit meinen Postgres Spielereien auf den Plan gerufen hatte. Der hatte die Berechnung gleich mit abgebrochen. Ich hatte es zwar gleich nochmal angestossen, das dauerte aber eine Weile. Trotzdem Danke für die Info.

Danke für die Erklärung.
Aber was ist ein/der OOM Killer?

Edbert (EvanE)

http://linux-mm.org/OOM_Killer

HTH,
ajoessen

Was ist denn unter “continuous changeover” zu verstehen ?

“The Rebuild group held a conference call Sunday. Consensus exists that an in-place schema update of the existing database is the best approach. There is also a generally positive attitude to the idea of “continuous changeover”, though some more details need to be discussed.”

Quelle: https://docs.google.com/document/pub?id=1kYe21omyXeejc5S_8gPCzjXrWAcEV_RDGPF8uaO2Ve8

Ich habe das so verstanden, daß es keine abrupten Umschaltung zur ODbL, sondern einen langsamen Übergangsprozeß gibt. Es sollen nach und nach die Edits von Ablehnern, Nichtzustimmer und anonyme Edits in der Datenbank ‘unsichtbar’ gemacht werden. Ich hatte das auch so verstanden, daß das ganze schon VOR dem 01.04.12 beginnt, also bereits JETZT im März die ersten nicht ODbL-konformen Changesets rausfallen.

Christian

Möglicherweise ergibt sich das aus Diskussionen auf der Rebuild-Liste? Auf die Schnelle habe ich aber auch dort keine explizite Definition gefunden. Meine Vermutung wäre, daß ein “Lizenzputz im laufenden Betrieb” gemeint ist. D.h. es soll nicht die Datenbank offline genommen und gesäubert werden und dann unter ODbL wieder online gehen, sondern bei voller Verfügbarkeit der API beginnt ein Bot, die Daten zu kastrieren. Solange der Bot läuft, stehen die Daten unter CC-BY-SA. Wenn der Bot fertig ist, sind nur noch nominell ODbL/CT-kompatible Daten übrig und dann ändert man die Lizenz des Datenbestandes. Vorteile wären zum einen, daß man nicht Stunden bis Tage downtime hat, zum anderen, daß der Bot nicht im ersten Lauf alles perfekt erledigen muß, sondern im Prinzip beliebig viele Schritte zum Nacharbeiten möglich sind.

Ja, so oder so ähnlich ist das wohl angedacht. Ich würde allerdings trotzdem nach aktuellem Stand nicht damit rechnen, dass im März schon was passiert. Aber naja, wir werden sehen^^

Ich denke wir sind auf gutem Wege:

  • Die Anzahl der Zustimmer steigt seit einigen Monaten konstant um 60-80/Tag (zur Zeit 450 in den letzen 5 Tagen).
  • Die Anzahl der Ablehner bleibt konstant.
  • Remapping und Zustimmer verringern die Anzahl “schlechter” Daten kontinuierlich.

Eine sehr grobe Extrapolation zeigt:

  • 8M Knoten im letzen Monat, also ca 3 Monate bis auf 0.
  • 800k Wege im letzen Monat, also gut 2 Monate bis 0.
  • 5k Realtionen im letzen Monat, also gut 6 Monate bis 0.

Grüsse

mdk

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