Verzeiflung beim .osc-Datei filtern (osmconvert/osmfilter/osmosis)

Herzliches Hallo an alle!

Eigentlich ist es ja keine große Sache (dachte ich), aber nach etlichen Stunden verzweifeltem probieren und Forumssuche/googlen wende ich mich an euch (und parallel die [Talk-de]) und hoffe auf Unterstützung:

Ausgangspunkt: .osc-Datei vom osm-Server. Filtern möchte ich zu folgendem Ergebnis:

• keine Relationen mehr

• alle Ways zu Nodes konvertiert

• nur Nodes behalten, die einige bestimmte keys haben.

Hintergrund ist folgender:

Ich möchte eine eigene MySQL-Datenbank (die Informationen über Poi vorhält) aktualisieren. Ways (also typischerweise Gebäude) sind darin durch ihren Mittelpunkt repräsentiert. Bisher habe ich dazu (testweise in kleineren Gebieten) den csv-export von overpass genutzt (DB-Inhalte vorher gelöscht und dann neu eingespielt), aber nun möchte ich das Gebiet ausweiten und die DB entsprechend aktualisieren statt täglich komplett neu zu füllen.

Um dabei nicht jeden einzelnen Änderungseintrag (Straßen und -wegpunkte, Wiesen, Gewässer, Stromleitungen usw) durch meine eigene DB-Updateroutine jagen zu müssen und dort zu prüfen, ob er überhaupt in die DB soll möchte ich das vorher schon filtern, was wesentlich performanter ist.

mein Erster Ansatz:

• erst mit osmconvert alle Relationen rauswerfen und alle Ways in Nodes umwandeln:

  osmconvert Ausgangsdatei.osc --drop-relations --all-to-nodes --out-osc >Zwischendatei.osc
  

  → klappt einwandfrei

• dann mit osmfilter alle Nodes rausschmeißen, die die Kriterien nicht erfüllen:

  osmfilter Zwischendatei.osc --parameter-file=parameter.txt >Ergebnis.osc
  

  → meckert bei einigen Nodes ‘wrong sequence’; diese werden ignoriert, obwohl sie ins Profil passen.
  Das dürfte wohl am Offset des ‘all-to-nodes’ liegen, den brauche ich aber für spätere Zwecke…
  => zu viel ausgefiltert

Spontaner Gedanke zur Lösung

• Erst filtern, dann Ways umwandeln
  → Problem: Alles was zuvor ein Way war ist jetzt komplett weg, vermutlich weil ja der filter alle tag-losen Wegpunkte rauschmeisst und osmconvert sie entsprechend nicht mehr finden kann - also schmeisst er alle Ways weg zu denen er keine Lageberechnung vornehmen kann…=> VIEEEL zu viel ausgefiltert

Also wieder zum ersten Ansatz, und osmosis dazwischensetzen um die Daten vorm filtern zu sortieren

osmosis --read-xml-change file="Zwischendatei.osc" --simc --sc --write-xml-change file="vorbereitetZumFiltern.osc"

→ Bricht mit einer NullPointerException während FloatingDecimal.parseDouble() ab - immer mal bei einem anderen Node… ?!warum - ich kann an denen nichts ungewöhnliches entdecken. Ich hab die ganze Datei durchgesehen, sie ist völlig in Ordnung, abgesehen davon, dass einige nodes eben sehr hohe Ids haben und somit nicht die richtige Reihenfolge für osmfilter vorliegt… Warum interessiert sich osmfilter überhaupt für die Reihenfolge? Und (BTW): Warum meckert osmfilter bei JEDER osc-Datei über ein ‘unerwartetes Ende der Datei’, wo es dieses Format doch unterstützt (nicht laut Wiki, aber laut Hilfstext des Programms.)

Probiert habe ich alle Varianten (und einige mehr) mit verschiedenen Programmversionen der 3 Kandidaten - ohne Erfolg.

Ich hoffe mir kann jemand die Fragen beantworten, aufklären was ich falsch mache oder einen Tipp geben. Ich dreh mich nurnoch im Kreis.

Vielen Dank und LG

Jochen hat dir doch schon auf talk-de geantwortet, dass dein Vorhaben so mit .osc Files so nicht funktioniert.

Sorry, cross posting geht gar nicht. Bitte diskutiere das Thema auf talk-de weiter.

Das habe ich gemacht, weil nicht alle talk-de Leser auch hier im Forum sind und umgekehrt. Und vor allem kam mir erst nach dem talk-de post der Gedanke, das ich womöglich (auch in Zukunft)nicht der einzige mit diesem Problem bin (insbesondere die Fragen am Schluss). Im Forum konnte ich bisher noch nicht viel dazu finden, aber dort wird es später sicher eher wiedergefunden, als in archivierten Mailings.

Wenn cross-posting hier allgemein nicht gern gesehen wird respektiere ich das natürlich.

Ja, eben gesehen und bedankt. In seinen Vorschlag bzgl. augmented_diffs arbeite ich mich ein… Die Lösung dahinter habe ich leider noch nicht verstanden.

Moin,

ich habe früher mal folgendes gemacht:

• ein leeres osm-File erzeugt (nicht .osc)
• mit osmosis das leere osm-File mit dem osc-File verarbeitet.
• das Resultat - ein osm-File! - weiter verwendet.

Danach wieder ein osc-File zu erzeugen, wäre der nächste logischen Schritt.

sehr geholfen hat mir dabei die Osmosis GUI OSMembrane

Gruss
walter

Wandel doch zunächst mal alles in Nodes um. Anschließend kannst du eine (eigene) Filterapplikation darüber laufen lassen. Die Daten sind ja jetzt sehr einfach aufgebaut und einheitlich.

Gruß Klaus

Genau das beschreibt mein obiger Vorschlag:

“leeres” osm + osc → osmosis → “gefülltes” osm.

Gruss
walter

Die ML ist ganz normal über Browser zu erreichen und auch genauso indiziert wie das Forum hier. Siehe auch die neuerliche Antwort von Jochen unter https://lists.openstreetmap.org/pipermail/talk-de/2017-August/114183.html

Es wird eigentlich nirgendwo gerne gesehen. Lass es zukünftig einfach, oder verweise wenigstens auf alle anderen Posts. Es gibt Künstler, die ihre Frage für so wichtig halten, dass sie es auf Help OSM, hier im Question & Answer Unterforum, auf Stack Overflow und noch auf GIS SE posten. Dass das wenig zielführend ist, brauche ich glaube ich nicht weiter auszuführen.

Zunächst kurz zur Info: den cross-post auf talk-de habe ich mit Verweis aufs Forum aufgelöst, bzw. gebeten Tipps hier im Forum weiterzugeben.

Kurze Zusammenfassung von dort: Jochen hat mir im Verständnis super weitergeholfen, warum mein Ansatz nicht funktioniert wie erwartet: Zitat: “In den .osc-Dateien sind nur geänderte Objekte drin, nicht ungeänderte Objekte, die mit den geänderten zusammenhängen, wie es bei Nodes in Ways oder Ways in Relationen der Fall ist.” Heißt also mit anderen Worten, wenn an einem Way zB ausschließlich tags geändert wurden, sind im .osc die zugehörigen Wegpunkte nicht enthalten, nur Id-Referenzen darauf. Das hatte ich noch garnicht aufm Schirm.

Lösen liese sich das mit den augmented diffs (dort sind alle Infos im vorher/nachher-Stil drin). Einen Filter müsste man sich dafür aber selbst bauen. Konsens: Wenns nicht um mega viele Daten geht, könnte man dann auch fast besser gleich einen täglichen Neuimport aller Daten machen. (Die Option fällt bei mir wahrscheinlich weg, weil ich vorm einpflegen in die Datenbank noch Berechnungen mache…)

Fallen mir in dem Moment nicht alle delete-Anweisungen raus? leer + delete = leer
Oder habe ich grad einen Denkfehler?

Du meinst also wie von mir beschrieben erst mit osmconvert --all-to-nodes und dann aber statt mit osmfilter mit einem eigenen Filter (zB in meiner eigenen DB-Update-Engine) drüber, der sich nicht an der Reihenfolge stört? Ich dachte nur, nachdem es mit osmfilter einen Spezialisten für sowas gibt kann ich mir das sparen.

Bleibt die Frage: Warum stört sich osmfilter eigentlich daran, dass zwischendrin mal eine ID höher ist als die nachfolgenden? Wurde das absichtlich aus irgend einem logischen/technischen Grund implementiert, oder ist das ein Bug?

Und seltsam finde ich nach wie vor das ‘unerwartete Ende der Datei’. Ein ums lässt die Meldung verschwinden, der Output ist erstem Anschein nach identisch…

jo, die hatte ich net gesehen.

Du versuchst ja eigentlich, den Job von “osm2pgsql -a” für deine mysql-DB mit unzureichenden Mitteln nachzuvollziehen.

Da hab ich nur einen Tip: Wechsel auf PostgreSQL/PostGIS. Da ist alles für vorhanden und du bewegst dich in einem etablierten, bekannten OSM-Universium.

Gruss
walter

Über welche Datenmenge reden wir eigentlich? Und wie lange dauert ein vollständiger Import?

Gruß Klaus

Guter Punkt.

Was bedeutet “ausweiten”? Weltweit? Europa? Deutschland?

Hier mal ein Beispiel: http://overpass-turbo.eu/s/qOh

Es liefert Änderungen an amenity=* Nodes und Ways in einer Bounding Box zwischen dem 31.7. und 1.8.2017.

Deutschlandweit. Ob sich das später ändert weiss ich nicht, kommt natürlich darauf an ob sich die fertige Applikation später als nützlich erweist und angenommen wird. Derzeit ist es aber einfach ein Lernprojekt von mir.

Das wird auf Dauer natürlich die beste Lösung sein, das ist mir klar. Dennoch bin ich jemand, der gern die einzelnen Schritte genau versteht und selbst ausprobiert, bevor ich zu einer ‘fertigen’ Lösung greife (denn wenn sonst später im Produktivbetrieb etwas beim Update unerwartet falsch läuft, hab ich ja gar keinen Plan mehr warum)

Was genau meinst du mit ‘unzureichend’? Das mein Weg bisher umständlicher ist, als nötig? Ist klar. Aber osmfilter weiss ja garnicht, was ich für eine DB habe - oder generell mit den Daten vorhabe… Könnte ja sein, dass ich eine vollständige PostGIS-DB habe und (aus welchen Gründen auch immer) nur einen Teil aktualisieren will, was mit gefilterten osc/osm-Dateien technisch möglich wäre!

Nochmals: Warum also ist es mit osmfilter nicht möglich eine osc (oder auch osm) zu filtern, nur weil zwischendrin Id’s höher sind als Nachfolgende. DAS ist meine Frage; die Hinweise, dass es eine einfachere/schnellere/bessere Lösungen für mein konkretes Vorhaben gibt sind richtig und auch gut und nett von euch, dass ihr darauf hinweist; aber das wusste ich vorher und ist nicht mein Verständnisproblem…

osmfilter ist dafür wirklich das falsche Tool, da es .osc Dateien als Eingabeformat überhaupt nicht unterstützt:

Wenn ich in meine Shell nur ‘osmfilter’ eingebe kommt folgendes:

osmfilter 1.2S+
Filters .o5m, .o5c, .osm, .osc and .osh files. ...

In Version 1.4.2 ebenso

PS: bei .osm meckert es ausserdem auch ‘wrong sequence’.

Also, unabhängig davon dass die Wiki-Seite offenbar veraltet ist, klappt das vom Ansatz her trotzdem nicht mit Filtern von .osc Files.

Nehmen wir mal ein Beispiel. Ich filtere nach [building=residential] und will ein .osc verarbeiten, in dem ein solcher Way gelöscht wird:
http://www.openstreetmap.org/way/421675769/history

Im entsprechenden .osc File steht allerdings nur:

  <delete>
    <way id="421675769" version="2" timestamp="2016-09-24T19:49:30Z" uid="2042836" user="1kcp" changeset="42410781"/>
  </delete>

Wie soll ich denn ausschließlich auf dieser Information mit osmfilter ermitteln, dass ich in meiner DB das Gebäude löschen soll?

Du hast Recht, bei delete-, und ich denke auch bei modify-Anweisungen - hat ein Filter allein (ohne Vergleich der Vorher-Situation) keine Chance herauszufinden, ob ein solcher Eintrag in die Teilmenge gehört oder nicht. Ergo müssen diese Anweisungen alle bleiben. Bei create-Anweisungen gibt es aber kein Problem…

Ich gehe davon aus, das das berücksichtigt wurde - getestet habe ich es noch nicht. Falls nicht wirkt die osc-Verarbeitung von osmfilter auf mich insgesamt tatsächlich nach alpha-Stadium…

Ganz einfach - für mich: unzureichend sind deine Mittel, da du sie beim Einsatz von osm2pgsql garnicht benötigst.

Ich nehme mal an, du hast nicht alle Daten mit allen Objekten und Tags von DEU in deiner MySQL-DB und möchtest diese jetzt updaten. Dabei möchtest du natürlich keinen “Schrott” (Daten, die du nicht drinhaben willst) übernehmen. Dafür versuchst du diese vor deinem geplante Update zu filtern.

Richtig verstanden?

Bei osm2pgsql ist so ein Filter bereits eingebaut, da in einem von dir einstellbaren Style-File definiert ist, was in die DB übernommen werden soll. Dazu braucht es keinerlei “osmconverts”, “osmfilter” oder ähnlicher Hilfsprogramme.

Das meine ich mit “unzureichenden Mitteln”.

Ich weiss nicht, wie du deine MySQL-DB updaten willst, wenn das alles hier klappen würde - ich würde aber genau an dieser Stelle ansetzen.

Gruss
walter

Völlig korrekt. Auch alles andere wurde schon geschrieben. Es gibt aber Fälle, in denen ein Filtern vorab sinnvoll ist, weil die Filterfunktion in osm2pgsql nicht immer die schnellste ist bzw. nicht immer alle gewünschten Filteroptionen bietet und der Import dadurch recht lange dauern kann. Manche Projekte filtern daher vorab.

Das geht – wie schon mehrfach geschrieben – nicht mit regulären .osc-Dateien, wohl aber mit kompletten OSM-Dateien. Der Trick ist, dass man komplette Daten filtert und sich die .osc-Datei fürs Datenbank-Update selbst erstellt. Die ÖV-Karte openptmap.org beispielsweise geht diesen Weg.

Schematische Übersicht: https://wiki.openstreetmap.org/wiki/Openptmap/Installation#Schematic_Diagram

Ein Datenbank-Update mit gefiltertem Planetfile braucht dadurch weniger als eine Stunde (einschließlich Download und Vorfiltern).