Probleme mit Changefiles der Geofabrik

Hey,

falls hier jemand mit Linux unterwegs ist, kann er jenes bitte verifizieren?
https://github.com/osmcode/osmium-tool/issues/24

LG
Tobias

Oha, der Bug scheint auch in anderen Tools vorhanden zu sein! Habe ein Tool geschrieben, welches OSC-Dateien analysiert. Werde die Ergebnisse mal nachher im Wiki niederschreiben.

Nachtrag: Dieses Problem hat nicht direkt etwas mit dem obigen zu tun!

Sorry, noch ein Update: Habe wohl etwas Größeres gefunden, was unerfreuliche Gründe und Nebenwirkungen hat. Betroffen sind mehrere Changefiles … Ursache hat es wohl in einer unsachgemäßen Bedienung oder Fehler in Editoren.

Nachdem mir ein paar komische Dinge in Changefiles aufgefallen sind (Änderungen gingen in der Datenbank verloren), habe ich ein Script geschrieben, welches die Änderungen von Objekten auf Changefile-Ebene verfolgt. Also wann sie in welchem Changefile in welcher Version erzeugt/geändert/gelöscht wurden. Dabei wurden mir mehrere hundert Fehler an nur drei Tagen ausgeworfen. Hier mal ein Beispiel (das sind die Europa-Extracts der Geofabrik):


OSM-ID;timestamp;version;action;changeset-filename
1800937801      2016-04-30T23:57:53Z    1           d          europe.s000001144.osc
1800937801      2016-04-30T20:46:00Z    3           c          europe.s000001145.osc

Mit anderen Worten: Zeitreisen scheinen doch möglich zu sein - das Vulkanische Oberkommando lag falsch!

Schaut man sich die History dazu an, wird Einem ganz komisch:
http://www.openstreetmap.org/api/0.6/node/1800937801/history

Da lag wohl ein Konflikt zwischen beiden Nutzern vor: User A und B haben an dem Ausschnitt gearbeitet. Nutzer A löscht den Node und überträgt den Fehler. Ein wenig später (mit alten lokalen Daten), verschickt User B den Node. Als User B den Node commiten wollte, bekommt er einen Konflikt, aber übermittelt ihn trotzdem… BANG!
Die Nutzer haben übrigens iD 1.9.3 (Nutzer A) und JOSM/1.5 (Nutzer B) verwendet.

Das kann natürlich unerwartete Folgen für die Changefiles haben und könnte erklären, was ich für Probleme in den letzten Tagen damit hatte. Ich halte euch mal auf dem Laufenden.

Es gab letztens ein paar Unregelmäßigkeiten in der Diff-Erzeugung. Such mal auf osm-dev nach einem Thread “Re: [OSM-dev] Osmosis RuntimeException: Pipeline entities are not sorted”

Ansonsten sind zumindest die Daily diffs auf planet.openstreetmap.org für dein Beispiel sauber, d.h. deine Analyse ist dort nicht im 327.osc.gz nachvollziehbar.


  <delete>
    <node id="1800937801" version="2" timestamp="2016-04-30T13:49:17Z" uid="3899604" user="AxelRosch" changeset="38999663" lat="54.398121" lon="10.231277"/>
  </delete>
  <modify>
    <node id="1800937801" version="3" timestamp="2016-04-30T20:46:00Z" uid="40397" user="Zartbitter" changeset="39006345" lat="54.3981759" lon="10.2301252">
      <tag k="amenity" v="recycling"/>
      <tag k="recycling:clothes" v="yes"/>
      <tag k="recycling:glass" v="yes"/>
      <tag k="recycling_type" v="container"/>
    </node>
    <node id="1800997247" version="2" timestamp="2016-04-30T05:43:54Z" uid="1887547" user="3JIblgEHb" changeset="38993650" lat="55.7036561" lon="36.199675"/>
  </modify>



Edit: ich sehe gerade, dass Jan auf osm-dev aktuell immer noch Probleme mit den daily diffs hat. Häng dich am besten mal dort in den Thread mit rein.

Danke! Trotzdem gab’s da einen Konflikt in der DB, der so eigentlich nicht hätte passieren dürfen :slight_smile:

Kann es sein, dass die Daily-Changefiles nachträglich noch korrigiert wurden? Ich müsste mal die Minutely-Diffs ziehen und das dann prüfen.

Bei http://www.openstreetmap.org/api/0.6/node/1800937801/history ist überhaupt nichts besonderes. Ein node wurde angelegt, von einem anderen User gelöscht und von einem dritten User wieder angelegt. Das geht und das ist okay. Man sollte das nicht machen, wenn der Node was ganz anderes darstellt nachdem er wieder aufersteht, aber manchmal ist das sinnvoll, z.B. bei einem revert. In diesem Fall scheint der dritte User den delete des zweiten Users quasi revertiert zu haben und dabei die Tags korrigiert und die Position verändert. Kann man sich drüber streiten, ob das sinnvoll war, aber es ist kein Datenbankproblem oder dergl.

Habe es kurz zuvor im IRC diskutiert und dort wurde mir gesagt, dass der Node eben nicht revidiert wurde (ich bin ursprünglich auch davon ausgegangen). Woran siehst du, dass die Entfernung rückgängig gemacht wurde?

Tom Hughes schrieb im genannten Thread auf osm-dev: "I’ve emptied the failed hourly now, as I believe everything in it is also in the following one, and rebuilt the daily. "

Also, wenn ich mir die Zeitstempel dort so ansehe, müsste das nur das File "325.osc.gz 2016-04-29 21:26 " betreffen. Alle anderen daily diffs werden immer brav um 00:06 erzeugt.

Habe es kurz zuvor im IRC diskutiert und dort wurde mir gesagt, dass der Node eben nicht revidiert wurde (ich bin ursprünglich auch davon ausgegangen). Woran siehst du, dass die Entfernung rückgängig gemacht wurde?

Version 2 hat visible=“false”, also wurde die gelöscht. Version 3 hat visible=“true”, also wiederhergestellt.

Das habe ich auch vermutet. Im IRC wurde mir dann aber mitgeteilt, dass hier wohl zwei Nutzer überschneidend gearbeitet haben (siehe oben). Die Wiederherstellung nur eines Nodes ist schon … schwierig. Selbst mit JOSM-Plugins. Außer man hätte recherchiert, ob dort ein Node existiert hat und dann mithilfe der ID das Objekt wiederhergestellt… Das macht doch eigentlich keiner.

Edit: Will aber jetzt keinen Streit deswegen anfangen. Schade, dass die Changefiles der Geofabrik hier Probleme machen.

Also die Changefile-Extracts der Geofabrik sind definitiv fehlerhaft :frowning:

osmium getid -f osc europe.s000001144.osc.gz n1800937801
<?xml version='1.0' encoding='UTF-8'?>
<osmChange version="0.6" generator="osmium/1.3.0">
  <delete>
    <node id="1800937801" version="1" timestamp="2016-04-30T23:57:53Z" uid="190869" user="elbatrop" changeset="12003838" lat="54.398121" lon="10.231277">
      <tag k="name" v="Schwanenweg"/>
      <tag k="amenity" v="recycling"/>
      <tag k="recycling:glass" v="yes"/>
    </node>
  </delete>
</osmChange>

und hier aus dem Planet:

osmium getid -f osc 327.osc.gz n1800937801
<?xml version='1.0' encoding='UTF-8'?>
<osmChange version="0.6" generator="osmium/1.3.0">
  <delete>
    <node id="1800937801" version="2" timestamp="2016-04-30T13:49:17Z" uid="3899604" user="AxelRosch" changeset="38999663" lat="54.398121" lon="10.231277"/>
  </delete>
</osmChange>

Keine Ahnung, wie das da rein kommt.

Da ich nur mit den minütlichen Diffs von planet.openstreetmap.org arbeite und diese mit osmosis+osm2pgsql in meine lokale DB lade, sieht “mein” Node derzeit so aus:

select tags from planet_osm_point
where osm_id=1800937801;
tags

“amenity”=>“recycling”, “recycling_type”=>“container”, “recycling:glass”=>“yes”, “recycling:clothes”=>“yes”
(1 Zeile)

Timestamp, version, uid und user stehen mir nicht zur Verfügung, da ich die nicht mit importiere.

Der Inhalt deckt sich auch mit dem der UK-Api-Db: https://www.openstreetmap.org/node/1800937801
Das verstärkt eure Vermutung, dass bei der Datafabrik mit dem Export was schief gelaufen sein könnte.

Insofern bin ich ziemlich beruhigt. :wink:

Gruss
walter

Nachtrag: Oder der Full planet in UK? Hat sich den mal wer angesehen?

Das ist ein sehr altes und, wie ich angenommen hatte, bekanntes Problem.

Wenn ich ein Deutschland-Diff ausrechne, dann tue ich das, indem ich vermittels Osmosis den Unterschied zwischen dem Deutschlandfile von heute und dem von gestern bestimme. Wenn ein Node gestern noch da war und heute nicht mehr, dann kann Osmosis nicht feststellen, in welcher Version er gelöscht wurde - sie muss höher sein als die von gestern, das ist klar, aber welche, kann man höchstens erraten. Osmosis verzichtet auf dieses Raten und verwendet die gleiche Versionsnummer wie vom bekannten Objekt.

Für osm2pgsql spielt das keine Rolle, weil das eh nicht auf Versionsnummern guckt.

Man kann sich jetzt drüber streiten, ob das “fehlerhaft” ist, aber auf jeden Fall ist es normal :wink:

Bye
Frederik

Frederik, das Problem ist: es werden Uhrzeiten erfunden, die es gar nicht gibt. Werden die bei deinem Abgleichprozess nicht mitgenommen? Einfacher Workaround für die Versionsnummern, wie Jochen schon sagte: beim Löschen die Version um 1 erhöhen, so macht es die API auch. Die API sollte Maß aller Dinge sein.

Hautproblem ist aber, dass das Mergen von daily-diffs mit den drei bekannten Tools osmium, osmconvert und osmosis zu falschen Ergebnissen führt. Ich denke nicht, dass es sich hierbei um ungewöhnliche Tools handelt, die ich hier einsetze. Ich sehe es als fehlerhaft an, da die besagten Probleme mit den Original-Planet-Files nicht auftritt.

Naja, mehr als informieren und warnen kann man nicht.

osmosis setzt dort einfach den aktuellen Zeitstempel an:

Link.

Oh okay - danke! Ich dachte, das wird irgendwie mitgeführt… Das erklärt echt, wieso die Scripte hunderte logische Fehler auswirft und die ganzen Tools beim Mergen durchdrehen. Gut, dann kann ich die jetzt nicht mehr verwenden, danke!

Ich habe allerdings noch ein Problem, welches derzeit NICHT auf den Timestamp zurückverfolgbar ist. Schreibe nachher noch was dazu.

+1

Naja… auch die API kann mal falsch liegen. Und wenn Informationen fehlen - wie in dem von Frederik beschriebenen Szenario - muss man sich eben anders behelfen. Ich bin mir nicht sicher, aber ich meine, osmconvert arbeitet sogar noch primitiver: die Versionsnummern werden ignoriert, es entscheidet die Reihenfolge der Dateinamen in der Parameterübergabe. Bin mir aber jetzt nicht sicher, müsste in den Code schauen.

Deswegen finde ich die Lösung, für das Löschen eine um 1 erhöhte Versionsnummer zu erzeugen, eine gute Idee.

Klar, “it’s a fake!”, aber es ist ein guter und sinnvoller Fake. Wichtig ist im Prinzip nur, dass der Zeitstempel neuer ist als der der letzten vorherigen Änderung. Und da man selten Changefiles verarbeitet, die in der Zukunft erzeugt wurden, ist das ja normalerweise der Fall. :wink:

Nicht durcheinanderbringen, das war das “Vulcan Science Directorate”. :wink:

Das könnte den Schluckauf erklären, den ich momentan mit den Daten habe.

Ach verflucht, stimmt… die einen sind durchtriebener und die anderen sind einfach nur sturr :smiley:

Speziell zu den Diffs der Geofabrik mit gelöschten Objekten: Der Timestamp sollte eigentlich auf Datum/Uhrzeit der Erstellung des jeweiligen Diffs gesetzt sein, der wahre Zeitpunkt lässt sich ja nicht mehr ermitteln. Bekannt ist nur, welches Element “gestern noch drin war” und “heute nicht mehr drin ist”. Wird ein Element am gleichen Tag revertet, werden die Meta-Daten anhand des Unterschieds “gestern/heute” korrekt aktualisiert. Wenn sich aber der Revert in einem anderen Diff befindet, benötigt man Kenntnis von der Wirkungsweise und möglichen Schaltern der Programme. Bei Osmosis weiß ich aus eigener Erfahrung, dass der Standardaufruf zu Fehlern in den Daten führt.

Osmosis hat den Schalter “conflictResolutionMethod”. Benutzt man ihn nicht, muss man --rxc in umgekehrter Reihenfolge anwenden (es sei denn, man arbeitet mit “inPipe.x” und gibt so die Reihenfolge vor). Grund ist der verwendete Stack für zu mergende Einzelelemente - was zuerst zwischengespeichert wird, wird zuletzt abgeholt und gilt als aktuell, also:
–rxc heute --rxc gestern → Stack: heute, gestern → Daten: erst gestern, dann heute.

Ansonsten bietet der Schalter “conflictResolutionMethod” speziellere Möglichkeiten:
http://wiki.openstreetmap.org/wiki/Osmosis/Detailed_Usage_0.44#–merge-change_.28–mc.29

Wobei auch zu sehen ist, dass ein Erhöhen der Version um 1 beim Löschen aufgrund des Defaults keine gute Idee ist. (Ist sie beim Revert höher als vorher?)
version: Macht trotzdem die Reihenfolge wichtig, falls die Version gleich ist.
lastSource: Reihenfolge zu beachten
timestamp: scheint geeignet zu sein, aber Vorsicht: ein Revert nach Erstellung der osm.pbf, aber vor der Laufzeit der Diff-Erstellung bringt den Fehler, weil der Timestamp in der aktuellen Diff dann neuer ist als der Revert in der nächsten Diff. Dagegen hilft, als Timestamp den neuesten in der osm.pbf zu nehmen statt der aktuellen Uhrzeit.

Fazit: Mit der richtigen Zeihenfolge der Input-Quellen ist man auf der sicheren Seite, weil die Version “schlimmstenfalls” gleich sein kann.

Ja, siehe weiter oben (wenn es denn wirklich ein Revert ist).