Hi zusammen,
ich würde gern auf das tägliche Holen eines PBF von der Geofabrik verzichten. Ich kriege aber mit Osmosis aus den gestrigen Daten und den Changes bisher nie genau die heutige Datei (inclusive Reihenfolge der Angaben) raus. Kennt einer von Euch einen Parametersatz für Osmosis mit dem das funktioniert?
Weide
Hallo,
die Changes ab den gestrigen Daten sind noch nicht da.
Die Daten reichen immer bis zum aktuellen Tag ca. 21:00 Uhr - osm.pbf bzw. osm.gz sind dann ab 02:00 Uhr nach Mitternacht fertig.
Download nicht der europe-latest.osm.pbf ist bei lokaler Aktualisierung empfehlenswert, sondern der europe-YYMMDD… Da hat man erstmal das Datum (ungefähre Uhrzeit ist ja bekannt) und kann sich sicher sein, die richtige Datei zum Anknüpfen erwischt zu haben (keine Überschneidung während des Downloads und Vorhandensein einer inzwischen neueren Datei). Für die Changefiles zählt dann der genaue Zeitstempel der state.txt im Europe-Updates-Verzeichnis - wenn paar Tage vergangen sind, dann im entsprechenden Unterverzeichnis.
Struktur: SequenceNumber=123 entspricht Unterverzeichnis 000/000, Dateien 123… oder später 123456789 entspricht Pfad /123/456, Dateien 789 (xxx-state.txt und xxx-osc.gz), Zeitstempel ist ein extra Wert in der state.txt.
Für die korrekte Aktualisierung braucht man also immer die zur aktuell gedownloadeten Datei passende state.txt. Da ich es etwas anders mache aber das “Zeugs” auch auswerte, kenne ich die nötigen Parameter für Osmosis nicht. Zumindest ist eine “Initialisierung” nötig, an welcher die zukünftigen Updates anknüpfen können.
Grüße
Mario
Sorry, ich meinte vorgestern und gestern statt gestern und heute. Das Problem liegt also nicht in unpassenden Changes.
Hintergrund: Ich lasse über die letzte und die vorletzte pbf dasselbe Programm laufen. Es produziert jedesmal eine Liste von Fehlermeldungen. Wenn die PBFs jetzt leicht unterschiedliche Ausschnitte des Datenbestandes enthalten und auch nur denselben Datenbestand in leicht unterschiedlicher Reihenfolge, dann bringt ein simples diff über die outputs nicht mehr viel.
Weide
Jetzt verstehe ich - die eigene Aktualisierung gleicht nie der frisch gedownloadeten Datei gleicher Aktualität.
Ich würde für Vergleiche nicht mit unterschiedlichen Programmen (Osmosis vs. Osmupdate) und unterschiedlichen Changefile-Quellen (Geofabrik vs. planet.openstreetmap.org) hantieren, immer nur eine Schiene fahren. Erstens ist der Output trotz jeweils korrekten Inhaltes leicht unterschiedlich und zweitens gibt es beim Aktualisieren ein größeres Ding: Osmupdate kann wohl auch stunden- und minutengetreu updaten, das haut dann mit dem Stand der täglichen Updates der Geofabrik nicht mehr hin.
Ich fahre beide Schienen, aber nicht gemischt sondern parallel:
-Osmconvert mit den täglich gesammelten Changefiles in größeren Abständen (deswegen kein Osmupdate, letzteres ruft ersteres auch nur auf) für die Bounds (europe im o5m-Format mit --drop-author)
-Osmosis mit den täglich an anderes Ziel gemergten Changefiles (–merge --merge --merge… in Osmosis ist doof) für den Ausschnitt in kleineren Abständen (ein bis zweimal die Woche, nur DACH/CZ+0.5xPL als osm.pbf mit omitmetadata=true)
Quelldaten: alles von der Geofabrik - kein Polygon zum Ausschneiden von Europa nach merge-change nötig, Änderungen am Polygon bei der Geofabrik sollten sich im nächsten Changefile widerspiegeln und entdeckte Fehler im Toolset und deren Korrektur (z.B. neuer/sauberer Extrakt) dürften ebenfalls über das nächste Changefile korrigiert sein…
Seit Monaten/Jahren habe ich keinerlei Probleme mit dem Vorgehen - ein frischer Download mit Vergleich ergab nur ein paar wenige kB Unterschied bei den beiden 4 und 21 GB großen Dateien, also meiner Meinung nach nichts was sich aufsummiert haben könnte. (Einen Fehler bei mir habe ich mal gefunden: Der Merge der Changefiles mit Osmosis muss wegen des Stacks im FILO-Prinzip in der richtigen Reihenfolge stattfinden, weil die Changefiles aus den täglich generierten Extrakten erzeugt werden und es dadurch nur “gefakte” Metadaten für gelöschte Objekte geben kann - kein echtes Changeset, Dummy-User eingesetzt, Version hat den letzten Stand statt version=version+1, Timestamp ist ebenfalls nicht mehr ermittelbar und wird daher auf den Zeitpunkt der Erstellung des Changefiles also in die Zukunft verlegt etc.) -Vielleicht ist das auch ein Grund für die Unterschiede in Deinen Daten. Beim Einspielen der/des Changefiles muss erst das Changefile angegeben werden, dann erst die osm(.pbf)-Datei, die Change-Elemente gehen erst in den Stack, dann die OSM-Elemente und dort abgeholt werden sie in umgekehrter Reihenfolge - also erst das OSM-Element, dann das Change-Element, welches das OSM-Element vorm Abspeichern ändert. Und der Parameter --simc hat auch noch einen Einfluss. Auch wenn alles korrekt abläuft, wird man nie vergleichbare Daten bekommen, binär schon gar nicht, da hilft nur ein konvertieren ins OSM-Format und der Vergleich der vorhandenen OSM-Elemente (Anzahl Punkte, Linien, Polygone). Die Sortierung ist nur für die Reihenfolge Punkte-Linien-Polygone wichtig, nicht für die IDs in der jeweiligen Kategorie - die sind ja referenziert wenn zugehörig.
Danke, jetzt verstehe ich die Vorgänge etwas besser und kann vielleicht eine Lösung finden.
Das ist bei mir anders. Der Hauptzweck des Programms ist die Erzeugung von transformierten OSM-Daten für die Erzeugung von ÖPNV-Overlays und für die stimmt das mit der Sortierung auch so. Dabei werden die Ways z.B. um die nutzenden ÖPNV-Linien ergänzt mit der Angabe der Nutzungsrichtung. Der zweite Zweck (und im Moment der Hauptzweck) ist die Erzeugung von Fehlermeldungen wie “Buslinie 4711 fährt in der Straße xy gegen die Einbahnrichtung”. Diese Meldungen werden bei einem Durchgang durch diese modifizierten Ways erzeugt und kommen daher in der Reihenfolge der Ways. Wenn ich dann die Veränderungen im Fehleroutput an aufeinanderfolgenden Tagen mit einem einfachen “diff” vergleichen will, ist eine andere Reihenfolge der Wege fatal. Dasselbe gilt für die Punkte. Genauso problematisch ist das Auftreten zusätzlicher Punkte oder Ways am Rand des Gebiets. Das spielt bei meinen relativ kleinen Gebieten wie Regierungsbezirken sicherlich eine größere Rolle als bei ganz Europa.
Mal sehen…
Erstmal danke … das hat mir ein paar Einsichten gebracht.
Weide
osmosis hat eine Option “–sort”. Vielleicht hilft es, die Datei nach jedem Update zu sortieren…
Grüße, Max
Ganz bestimmt, da auch nach Id sortiert wird. Vielleicht muss ich dann nochmal clippen, aber spätestens dann müsste es gehen.
Danke
Weide
Richtig froh wird man über eine Sortierung über alle IDs nicht. Die IDs der Members von Relationen sind jetzt schon ziemlich gemischt. Zukünftig stört auch, wenn irgend ein vorhandener Member im Zuge einer Korrektur gelöscht und neu angelegt oder ein Weg geteilt wird, die eine ID liegt dann “sonstwo”, aber die Referenzierung entspricht ja der richtigen Reihenfolge (wiederum nur, wenn die Relation in sich sortiert wird, was JOSM zumindest für den geladenen Bereich und nach bewusster Betätigung kann). Das wiederum betrifft dann aber die Reihenfolge der Mitglieder nach “geografischer Aneinanderreihung”, nicht die Sortierung nach ID.
Grüße
Mario
Die Sortierung von Mitgliedern in einer Relation ist eine etwas wackelige Geschichte. Die Miglieder einer Relation sind nach Datenmodell zunächst eine simple, ungeordnete Menge. Abgelegt werden sie natürlich in irgend einer Reihenfolge, zunächst nach Zeitpunkt des Eintrags.
Der Relationseditor in JOSM kann das für die Anzeige sortieren (äußerst hilfreich bei der Frage, ob geschlossen) und speichert das dann auch so zurück (nach Sortieren wird die Relation als “dirty” geführt).
Jede neue Änderung (Split, way geändert) zerstört die Reihenfolge in der DB aber wieder, insbesondere wenn die Mitglieder nicht vollständig geladen wurden. Nach einer Sortierung ist die Relation bei einem Neuladen kurz darauf weiterhin sortiert, nach ein paar Wochen oder Monaten geht die Chance dafür deutlich zurück.
Osmosis sortiert bei –sort die Objekte der Datenfiles aber nicht die Eigenschaften. Daher bleibt die Reihenfolge der Member einer Relation bei einem Sort unverändert.
Der Sort ist notwendig, damit ein Merge mehrerer Files (Diffs) relativ einfach möglich ist.
Gruss
walter
Richtig. Deswegen hilft auch die Sort-Option nicht, sie ordnet nur alle Punkte vor die Wege und alle Relationen nach ganz hinten, damit etwaige Members schon verarbeitet sind wenn dann die Objekte verarbeitet werden, die Members haben. Der Kontext meiner Ausführungen war aber ein anderer: Erfolglosigkeit eines Sortierens nach ID, wenn dies für Erkennen von Änderungen verwendet werden können soll, falls ich Weide überhaupt richtig verstand.
Grüße
Mario
Ich rätsel auch ein wenig rum, was da ausgewertet werden soll, muß aber größte Bedenken anmelden ob ein Vergleich verschiedenener PBF-Files der richtige Weg ist.
Die OSM-Rohdaten sind nun wirklich nicht für sowas gedacht.
Gruss
walter
Das waren sie im letzten API, im jetzigen API ist es nicht so. Dadurch wurden Routen wie in PTv2 möglich, in denen die Reihenfolge der Member die Reihenfolge in der Realität angibt.
Wenn im JOSM beim Splitten von Wegen Relationen beschädigt werden, dann ist das ein Editierfehler. Vor jedem “p” muss man im JOSM den Weg und beide Endpunkte anwählen und die “Mamas” mit Ctrl-Alt-D laden – dann passiert nichts Böses.
Weide
OK. Ich vergleiche keine PBF-Files.
Anhand eines PBF-Files wird von einem Programm eine Fehlermeldungs-Datei erzeugt. Anhand dieser Fehlermeldungsdateien repariere ich dann ÖPNV-Kram.
Um aber als erstes schnell zu sehen, welche Fehler ich selbst gestern eingebaut habe oder welche Fehler erst durch das gestrige Eintragen sichtbar wurden, sehe mit mir die Veränderungen zwischen dem gestrigen und dem heutigen Fehlerprotokoll zuerst an. Dazu nehme ich ein einfaches Diff über die Fehlermeldungsdateien.
Letzteres geht aber in die Hose, wenn die Objekte in der ursprünglichen PBF-Datei ihre Reihenfolge gewechselt haben, denn dann werden auch die Fehlermeldungen entsprechend durcheinandergewürfelt und das Diff zeigt Unterschiede, die sich nicht aus dem Wegfallen oder Hinzukommen von Fehlern ergeben.
Mit den PBFs von der Geofabrik geht das sehr gut. Wenn ich aber das neue PBF aus den Changes und dem alten PBF selbst erzeuge, dann bekomme ich ein anderes PBF als das neue von der Geofabrik und viele unechte Fehlerdateidifferenzen.
Alle Klarheiten beseitigt?
Weide
ist für mich das selbe in Grün. Du nimmst zwei PBF, wertest beide aus und vergleichst die Auswertungen (hab ich übrigens auch beim 1. mal schon verstanden).
Ein 2. Mal: Dann sortiere die Rohdaten!
Wobei ein Sortieren der Member mit osmosis selbstverständlich nicht möglich ist. Sie stehen in den Daten so drin, wie sie aus der OSM-DB kommen: genau in der Reihenfolge, wie sie vorher abgespeichert wurden.
Eine Möglichkeit wäre es, die Ergebnisse der Auswertungen in so einem Format zu speichern, dass ein Vergleich der Auswertungen auch möglich ist. Das ist bei dir anscheinend nicht gegeben.
Gruss
walter
Dann verstehe ich nicht, wo deine Bedenken gegen das diff liegen. Du hattest damit argumentiert, dass die OSM-Daten für so etwas ungeeignet sind und ich habe dir zugestimmt und erklärt, was mir das diff auf den outputs bringt.
Ich mach mal ein Beispiel:
Ich lege bei einer größeren Haltestelle eine stop_area an. Am nächsten Tag taucht eine zusätzliche Fehlmeldung auf: “Bus 4711 (PTv2) verwendet verwendet ein Objekt mit highway=bus-stop mit der Rolle ‘stop’ und in der stop_area wird es mit der Rolle ‘platform’ verwendet.” Das diff zeigt mir diese Fehlermeldung und ich sehe nach, ob ich einen Fehler beim Anlegen der stop_area gemacht habe oder ob der Fehler in der Route liegt. Das diff ist also nur dazu da, dass ich erstmal meine eigenen Fehler von gestern korrigiere bevor ich mich an die große Liste mit jetzt nur noch 6000 Fehlern im Reg.-bez. Düsseldorf begebe.
Ich weiss. Mein Problem ist gelöst. Das hab ich doch hier sofort geschrieben. Der Fall war für mich schon erledigt.
Das ist mir total klar. Immerhin ist meine Hauptbeschäftigung der Umgang mit PTv2-Routen. Deren Besonderheit im Gegensatz zu anderen Relationen besteht nun einmal darin, dass Sortieren Informationen vernichten würde.
Ja das hab ich auch schon mal erwogen. Die Fehler-Outputs sind aber eigentlich zum direkten Lesen durch Menschen gedacht und der Diff-Kram ist nur ein Zusatz.
Weide
naja, dann machen wir hier mal schluß
Gruss
walter