Probleme mit Changefiles der Geofabrik

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

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

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.

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

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.

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

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

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).

Sorry, war bei einem Kunden. Hier die Auswertung. Ich empfinde das als Fehler:

# Changefiles runterladen
# Geofabrik 142.osc.gz hat die Daten vom 2016-04-28 (plus ein paar Zeiteinheiten)
# Geofabrik 146.osc.gz hat die Daten vom 2016-05-03 (plus ein paar Zeiteinheiten)
wget http://download.geofabrik.de/europe-updates/000/001/14{2..6}.osc.gz
mkdir europe && mv *.osc.gz upd_europe/

# Planet 325 hat die Daten von 2016-04-28 (plus ein paar Zeiteinheiten)
# Planet 329 hat die Daten von 2016-05-03 (plus ein paar Zeiteinheiten)
wget http://planet.openstreetmap.org/replication/day/000/001/32{5..9}.osc.gz
mkdir planet && mv *.osc.gz upd_planet/

# Analyse am Beispiel von Weg 414256828
zgrep 414256828 upd_europe/143.osc.gz
zgrep 414256828 upd_europe/146.osc.gz
zgrep 414256828 upd_planet/325.osc.gz
zgrep 414256828 upd_planet/329.osc.gz

# Ergebnis (von oben nach unten) als CSV
osm_id;timestamp;version;filename
414256828;2016-04-28T20:44:16Z;1;europe/143.osc.gz
414256828;2016-05-03T00:18:16Z;1;europe/146.osc.gz
414256828;2016-04-28T20:44:16Z;1;planet/325.osc.gz
414256828;2016-05-02T08:11:34Z;2;planet/329.osc.gz

Wie deutlich wird, weichen die Timestamps extrem ab - und dabei handelt es sich um die Rohdaten. Ich habe das noch nicht mit einem Tool bearbeitet.

Offenbar schreibt Osmosis, wenn man zum Zeitpunkt X ein Diff aus A und B erzeugt, und etwas in A drin war, was in B nicht mehr drin ist, den Zeitpunkt X in das Objekt statt dem Originalzeitpunkt.

Also ich muss ich da ein bisschen stur stellen. Da sehr viele Leute völlig unproblematisch die Geofabrik-Diffs einsetzen, scheinen es nur Nischen-Anwendungsfälle zu sein, die hier ein Problem haben. Ich setze derzeit Osmosis “von der Stange” ein, um diese Diffs zu erzeugen. Es gibt keine “eindeutig richtige” Lösung, was Osmosis ins Changefile schreiben soll, wenn es feststellt, dass ein Objekt gelöscht wurde. Ich sehe nicht, was ich ändern sollte, und wenn ich es sähe, hätte ich nicht das Programm dazu, um es zu machen. Nur sehr ungern würde ich ein gepatchtes Osmosis einsetzen, das andere Resultate erzeugt, als sie jemand bei sich reproduzieren könnte. Die beste Lösung wäre, ein Original-Tagesdiff von OSM zu nehmen und dieses nach Ländern und Regionen aufzudröseln. Das ist aber aus verschiedenen Gründen eine teure Operation. Augmented Diffs von Overpass wären eine Alternative. Aber es fehlt mir die Zeit, hier zu forschen, was man am besten machen sollte, besonders, wenn es nur für einen Nischen-Anwendungsfall ist.

Also, langer Rede kurzer Sinn, wem das nicht passt, der soll sich dafür einsetzen, dass Osmosis geeignet geändert wird, dann installiere ich bei mir auch gern eine neue Osmosis-Version. In der Zwischenzeit sollte ich vielleicht einfach die Dokumentation zu den Diffs dahingehend verbessern, dass dieses Problem klar erklärt wird.

Bye
Frederik

Wer zwingt dich denn osmosis zu verwenden? Im Vergleich zu allen anderen Lösungen “auf dem Markt” ist osmosis mit Abstand die langsamste Variante.

Nochmal kurz: Ich mache dir keinen Vorwurf, wollte nur den Leuten helfen, die ähnliche Probleme wie ich haben. Mag sein, das Verfolgen von Änderungen eine Nischenanwendung ist, aber OpenStreetMap ist mehr als eine Karte, die man aus osm2pgsql-Daten rechnet.

Mein Tool hat übrigens über 300 Abweichungen in den oben genannten Changefiles gefunden. Ein tolles Beispiel, welches auch auf osm2pgsql Einfluss hat, ist z.B. Way 6525983. Das ist aber augenscheinlich ein osmium-Problem, was in Verbindung mit den Geofabrik-Daten auftritt (da hier die Version nicht erhöht wird).

Mit den Dateien von oben...
# Arrays erstellen (numerisch sortiert)
files_europe=(upd_europe/14{2..6}.osc.gz)
files_planet=(upd_planet/32{5..9}.osc.gz)

# Merge mit osmium v1.3.0 (57715b1)
osmium merge-changes --simplify --output=osmium_europe.osc "${files_europe[@]}"
osmium merge-changes --simplify --output=osmium_planet.osc "${files_planet[@]}"

# Merge mit osmconvert v0.8.5
osmconvert --merge-versions -o=osmconvert_europe.osc "${files_europe[@]}"
osmconvert --merge-versions -o=osmconvert_planet.osc "${files_planet[@]}"

# Analyse der Dateien anhand von Weg 6525983
grep 'way id="6525983"' -B1000 osmium_europe.osc | grep -E 'delete|modify|create' | tail -n 1 # Ergebnis: <modify>
grep 'way id="6525983"' -B1000 osmium_planet.osc | grep -E 'delete|modify|create' | tail -n 1 # Ergebnis: <delete>
grep 'way id="6525983"' -B1000 osmconvert_europe.osc | grep -E 'delete|modify|create' | tail -n 1 # Ergebnis: <delete>
grep 'way id="6525983"' -B1000 osmconvert_planet.osc | grep -E 'delete|modify|create' | tail -n 1 # Ergebnis: <delete>

Jochen hat inzwischen osmium überarbeitet. Ich prüfe die Ergebnisse gleich nochmal mit der neuen Version.
Edit: Das Problem mit den Versionen wurde behoben (in diesem Post genannter Fehler). Die falschen Timestamps bleiben vorhanden, sind aber für das Rendering egal.

Danke an alle Beteiligten.