osmfilter: Nach ID filtern

Hallo,
Ich habe mich in letzter Zeit etwas in die ganze OSM-Thematik eingelesen und würde nun gerne versuchen selber etwas aus einer .o5m-Datei zu filtern.
Leider habe ich bisher nur herausgefunden, wie ich nach Tags filtern kann, konnte aber nirgends etwas zur Filterung nach spezifischen IDs finden. Ist dies mit “osmfilter” überhaupt möglich?

Ziel ist es, eine (oder mehrere) spezifische Relation inkl. der dazugehörigen Ways und Nodes zu extrahieren. Die IDs der Relations sind bekannt.

Mit Overpass-API geht das ja recht einfach, ist aber aufgrund der Daten- und Abfragemengen keine wirkliche Option. (Habe da schon öfter eine TooManyRequests-Exception bekommen)

Danke im Voraus

Maas

Hallo Maas,

nimm das Osmium-Tool, Befehl getid.

Nimm die libosmium-Bibliothek, wenn dir der Funktionsumfang nicht ausreicht.

Viele Grüße

Michael

Dir ist bekannt, dass man auch mehrere ids in einer Abfrage abrufen kann? Die Fehlermeldung hört sich eher so an, als ob du jede id einzeln abfragst. Frage wäre natürlich, was mit “Daten- und Abfragemengen” konkret gemeint ist. 100, 1000, 1 Million??

Beispiel:


node(id:1000,1001,1002,1003);
out meta;

Das ist mir bekannt, aber auch da gibt es Grenzen in der Größe des Requests. Da meine Daten etwas verschachtelt sind und ein Request einer kompletten “Gruppe” zu groß/zu viel für Overpass ist, müsste ich diese Verschachtelung aufsplitten, nach Request-Größe ordnen und sortieren (Optimierung) und später wieder zusammenfriemeln. Außerdem ist bei den Datenmengen die Sache mit dem Download etwas langwieriger. Dazu habe ich keine Lust. Dann lieber offline.
Soweit ich das mitbekommen habe, ist Overpass auch nicht für einen massenhaften Download ausgelegt (also könnte es zwar verkraften, ist aber nicht der Sinn dahinter). Korrigier mich bitte, wenn ich da falsch liege.

Maas

Edit: Es handelt sich um mehrer tausend Relations inkl. Ways und Nodes

Danke für den Tipp. Ich habe es jetzt selbst heraus gefunden. Stand sogar in der Doku (-> special tags). Ja, wer lesen kann ist im Vorteil. :slight_smile:
Als “Key” wird “@id” benutzt. Hatte es vorher nur mit “id” probiert, was natürlich nicht funktioniert hat.
Danke trotzdem!

Maas

Ok, dann frage ich mal konkreter: boundaries? zip codes?

Schick mir am besten mal eine Beispiel-Query per pm (mmd | OpenStreetMap), dann schauen wir mal, was die Dev-Instanz dazu sagt.

pm

ok, danke. Ich hab’s zum Spass gerade mal ausprobiert. Alle boundary=administrative grob mit DE BBOX: http://overpass-turbo.eu/s/rYU - ergibt ein 83MB PBF mit 65289 Relationen. Ist jetzt nicht unbedingt empfehlenswert, würde aber auf einer eigenen Instanz durchaus laufen. Übliche Vorgehensweise wäre schon über lokales Planet file oder passende Extrakte.

Beziehungen zwischen den boundaries ergeben übrigens sich aus der räumlichen Beziehung, daher gibt es keine weitere Modellierung per Relation ID zwischen den einzelnen Relationen.

Also wenn boundary=administrative abgefragt werden, darf man fragen, was du dann weiter damit machen möchtest bzw. vor hast? Nicht das dir z.B. auch ein entsprechendes exportierendes Format der boundaries map reicht :wink:

Die Seite kenne ich bereits und habe ich Anfangs auch genutzt. Allerdings ist mir dann auch relativ schnell klargeworden, wieso OSM so strukturiert ist, wie es ist. Bei der boundaries map werden bereits die konvertierten Polygone zurückgegeben. Das ist ganz gut für den Anfang oder wenn man nur ein paar Bereiche benötigt, aber rächt sich in der Masse, da man mit steigender Zahl der sich überlappenden Bereiche auch eine erhöhte Redundanz der Ways und Nodes hat.
Letztendlich habe ich mir von dieser Seite die hierarchische Struktur heruntergeladen, da OSM das ja so direkt nicht anbietet (siehe post #8).

Edit: Es geht auch darum, die Möglichkeit zu haben, die Polygone etwas zu glätten. Dafür müssen natürlich angrenzende Polygone auch geglättet werden, damit sie zusammenpassen und keine Lücken oder Überschneidungen entstehen. Das ist (fast) nur verlässlich möglich, wenn es keine Redundanzen gibt. Für gewisse Anwendungsbereiche sind die OSM Ways manchmal etwas “übertrieben” genau.

Maas

Jo, und genau das ist der Sinn dieser Seite: aus den “Ways und Nodes” vernünftige Polygone zu machen, die ohne weiter Verarbeitung genutzt werden können - und das nicht nur in der OSM-Welt.

Ja, das Glätten ist ein sehr schwieriges Problem, da es ja darum geht, Lücken und Überschneidungen zu verhindern. Das hast du richtig erkannt. Allerdings halte ich deinen Ansatz (“ich nehme die Rohdaten, erhalte dadurch keine doppelten Ways und danach wird es einfach”) für übermütig.

Es gibt Lösungen, die auf PostGIS Topologien beruhen, allerdings ist dabei die schiere Datenmenge das grösste Problem. Selbst bei einer theoretischen Datenreduzierung um 50% ist das Verfahren extrem langsam. Für einige Grenzen (z.b. alle AL4 von DEU) mag das gerade noch gehen, aber ansonsten sehe ich da kein Licht am Tunnelende. Ich hab es jedenfalls noch nicht geschafft - und du kannst mir glauben, dass ich mich sehr freuen würde, wenn es so einfach wäre. Dann gäb es die nämlich schon als Download bei mir.

Ich wünsche dir viel Spass und Erfolg dabei - wobei es mich schon stutzig stimmt, dass du dir noch nicht einmal darüber klar bist, woher du denn deine Daten bekommen willst. Overpass ist definitiv der falsche Weg, das geht nur über das Planet-File oder deren Extrakte bei der Datafabrik.

Gruss
walter

Na dann…

Das ist schön und gut und ich beglückwünsche dich zu diesem Projekt, hat aber für mich aktuell, wie gesagt, keinen Zweck in der Form. (siehe post #10)

Man darf sich doch wohl noch ausprobieren dürfen?

Verstehe ich nicht. ???
In post #1 und #4 wird doch ziemlich klar was ich will und in post #5 erkläre ich auch, wie ich das erreiche. Was macht dich da stutzig? Und wie kommst du darauf, dass ich Overpass nutzen möchte, wo ich doch explizit Overpass als Option ausgeschlossen habe?

Irgendwie verwirrt mich dieser Post.

Maas

Klar. Ich bin halt nur ein wenig skeptisch, ob das was bringt.

ich sehen in #5 nur, dass du die Basisdaten der Relation (tags) und deren Ways/Nodes benutzen willst.
Geht natürlich. Ansonsten hätten wir ja keine Software, die daraus Polygone macht. Ich überlasse diesen Knochenjob aber gerne osm2pgsql.

jo, das war ein Versehen.

Gruss
walter

Es bringt Erfahrung. Natürlich, wenn ich mich mit der ganzen Thematik seit 2009 beschäftigen würde, würde das nicht viel Sinn machen. Ich bin aber erst seit ein paar Wochen an dem Thema dran und am Anfang geht man halt manchmal Wege, die in eine Sackgasse führen. Das heißt aber nicht, dass diese Wege auch umsonst waren, wenn man etwas dabei lernt.

In den vorherigen Posts habe ich erwähnt, dass ich das Ganze über planet-file und osmfilter machen möchte. Overpass habe ich ausgeschlossen. Die Relation-IDs und Parent-Child-Abhängigkeiten sind, wie bereits erwähnt, bekannt. Woher sind diese bekannt? Post #10 gibt die Antwort: Dein Projekt. Dort habe ich mir die hierarchische Struktur heruntergeladen. Ich habe somit die Arbeit genutzt, die du mit osm2pgsql gemacht hast.
Danke ausdrücklich dafür!

Maas

osmfilter kann anscheinend nach @id filtern, siehe http://wiki.openstreetmap.org/wiki/Osmfilter#Special_Tags

Aber ob das auch bei der Menge von @id s geht ?

Ja, genau. Wie in #5 beschrieben.

Ich habe aktuell den Eindruck, dass nicht. Generell akzeptiert osmfilter wohl nur bis zu 999 oder 1000 Filterargumente. Das wäre zwar noch irgendwie OK, aber ich habe es bisher nicht geschafft mehrere IDs anzugeben.
Sowohl

--keep-relations="@id=123456 =098765"

als auch

--keep-relations="@id=123456 or @id=098765"

plus am Ende

--keep-ways= --keep-nodes=

ergeben Dateien, die definitiv zu groß für das erwartete Ergebnis sind.
Es sollte auch nicht an keep-ways und keep-nodes liegen, da osmfilter anscheinend bei leeren Argumenten die abhängigen Ways und Nodes behält. Wenn diese Parameter weggelassen werden, werden einfach alle Ways und Nodes übernommen.
Bei einer einzelnen ID funktioniert es.

Es sieht wohl so aus, als ob ich Osmium nutzen oder einen PostGIS Server aufsetzen werde.

Maas

Habe etwas mit einem kleinen lokalen osm File herumprobiert und auch Einiges dabei wiederholt:

osmfilter.exe xxx.osm --keep-relations="@id=6352295 or @id=6340036" --drop-nodes --drop-ways -o=test_relid.osm

liefert nur die 2 gesuchten Relationen ohne die dazugehörigen Wege/Punkte .

osmfilter.exe xxx.osm --keep-relations="@id=6352295 or @id=6340036"  -o=test_relid.osm

dagegen liefert die beiden Relationen und (aus der Größe der Datei geschlossen) wahrscheinlich alle Punkte und Wege.

Was Du wohl brauchst, ist

osmfilter.exe xxx.osm --keep= --keep-relations="@id=6352295 or @id=6340036"  -o=test_relid.osm 

Hier kommen genau die 2 gesuchten Relationen mit allen zugehörigen Punkten und Wegen.

Super. Danke!
Ich werde das bei Gelegenheit mal ausprobieren.

Macht es einen Unterschied, ob

--keep=

vor oder nach

--keep-relations="..."

steht?

Maas