Hallo,
wie stelle ich es am geschicktesten an, alle Grenzen aus einer pbf-Datei mit osmfilter zu extrahieren.
Schritt 1 wäre mit pbftoosm ein osm-xml-File zu erzeugen
Im 2. Schritt wollte ich dann mit osmfilter filtern. Als Ergebnis brauche ich alle Relationen mit boundary=administrative und alle ways mit selbigem Tag in einer osm-xml oder pbf-Datei.
Oder wäre es effektiver das pbf in ein o5m zu wandeln und mit 05mfilter zu bearbeiten und dann wieder nach osm-xml zu konvertieren?
Wenn es DIr wichtig ist, pbftoosm, o5mfilter, osmfilter oder andere moderne Digne zu nutzen, habe ich keine Antwort. Aber mit einem halbwegs aktuellen Osmosis geht das direkt vom PBF so:
osmosis --read-pbf quelldatei.osm.pbf --tf accept-relations boundary=administrative --used-way --used-node --wx relation-boundaries.osm
osmosis --read-pbf quelldatei.osm.pbf --tf accept-ways boundary=administrative --used-node --wx relation-ways.osm
Damit hast Du zwei Dateien, eine mit den Relationen (und allem, was dazugehoert) und eine mit den Ways. Du kannst auch beides in einem Schritt erzeugen lassen (Stichwort --tee). Viele Ways werden in beiden Dateien enthalten sein; Du kannst beide Dateien wieder zu einer zusammensetzen lassen und dabei Dubletten entfernen (Stichwort --merge). Das allerdings muss tatsaechlich in einem separaten Schritt erzeugen, denn das Wiederzusammenfuegen von zwei mit --tee gesplitteten Streams sorgt bei Osmosis fuer ein Problem, da haengt es sich auf.
Bye
Frederik
Hallo Frederik,
ich wollte mal einen Vergleich machen, ob es mit osmosis oder mit obigen Tools schneller geht. Der Weg über osmosis ist mir bekannt und läuft auch, dauert halt nur etwas.
Hallo!
Der Standardweg wär mit dem Alleskönner Osmosis, da hat Frederik völlig recht. Über die Alternative könnte es schneller gehen, verglichen hab ich das allerdings noch nicht.
Das Einzige, wozu o5mfilter zu doof ist, ist eine PBF-Datei zu schreiben. Alles andere sollte ohne Probleme gehen. Als Eingabeformat für o5mfilter ist .osm (XML) zwar möglich, aber .o5m lässt sich viel schneller verarbeiten (auch schneller als .pbf). Mein Vorschlag wäre dieses:
osmconvert germany.osm.pbf --out-o5m >germany.o5m
o5mfilter germany.o5m --keep="boundary=administrative" >grenzen.osm
Wenn du das Filtern auf bestimmte Admin-Levels beschränken willst (ist eventuell sinnvoll), dann könnte das Filterkommando so aussehen:
o5mfilter germany.o5m --keep="all boundary=administrative admin_level=2 =3 =4" >grenzen.osm
Ich hoffe, das klappt so. Vielleicht probier ich es gleich mal selber…
Hallo Marqqs!
Behält o5mfilter mit --keep=“boundary=administrative” auch die Grenzen, die nur als Relation in den Daten schlummern und die zu den Relationen gehörenden Weg? Dann werde ich das gleich mal versuchen.
Ja, tut es. Auch die Nodes, die zu diesen Wegen gehören, sind dann im Ergebnis.
Streng genommen wären im Ergebnis sogar andere Nodes, die diesen Tag selber besitzen, aber da dürfte es kaum welche geben. Wenn du aber solche Nodes ausschließen willst, kannst du die Filter für die Objekttypen gezielt vorgeben. Für Nodes also einen leeren Filter, dann sind sie nur dann im Ergebnis, wenn sie zu einem betroffenen Weg gehören.
--keep-nodes= --keep-ways-relations="boundary=administrative"
Meine alte Mühle hat eine ganze Weile gerechnet. Fairerweise müsstest du bei der Alternative mit o5mfilter die Zeit für die Datenumwandlung von .pbf nach .o5m hinzurechnen, denn .o5m ist bis jetzt noch ein eher wenig verwendetes Format. Außer, du willst die Basis mehrfach verwenden und nach unterschiedlichen Kriterien filtern. Hier die Ergebnisse (Ubuntu 10.04, 32 Bit, Intel Atom).
$ time ./osmconvert germany.osm.pbf --out-o5m >germany.o5m
real 4m8.948s
user 3m56.455s
sys 0m10.353s
$ time ./o5mfilter germany.o5m --keep-nodes= --keep-ways-relations="boundary=administrative" >grenzen.osm
real 2m43.116s
user 2m17.365s
sys 0m7.792s
Die Ergebnisdatei “grenzen.osm” ist bei mir 270.262.836 Bytes groß. Sie lässt sich mit JOSM öffnen, dauert halt ein bisschen.
Bei mir waren beide Programme nach 2min durch. Danke für deine Hilfe!
Uff, verdammt schnell. Zeigt deutlich, dass meine alte EeeBox nicht grad ideal für solche Datenkonvertierungen geeignet ist. 
Und wie sieht Osmosis im Vergleich dazu aus? Und sind die Daten vollständig? Das wären jetzt Entscheidungshilfen für andere Nutzer. Ich habe ja bereits positive Erfahrungen damit gemacht.
Würde mich auch interessieren. Vollständigkeit ist letztlich ja wichtiger als Geschwindigkeit. Zwei Problempunkte:
Osmosis: Die Option cascadingRelations=yes ist wichtig, weil sonst Unterrelationsn fehlen können.
o5mfilter: Das Programm ist recht neu, so dass ich da lieber zweimal hinschauen würde. Bugs sind wahrscheinlicher als bei Osmosis.
Vielleicht könnte man o5mfilter mit der Option –emulate-osmosis laufen lassen und das Ergebnis dann per diff vergleichen. Mit dieser Option schreibt o5mfilter die Daten in dem Format, das auch Osmosis verwendet (Leerzeichen statt Tabs, XML-Reihenfolge innerhalb der Header-Tags usw.). Sollte es jedenfalls.
Wenn ich den osmconverter auf europe.osm.pbf loslasse bekomme ich den Fehler: decompression failed: -5
Win7 64bit
Hast du eine Erklärung dafür?
Schau mal hier ganz unten: http://forum.openstreetmap.org/viewtopic.php?id=12419&p=6
Hallo Henning,
die Fehlermeldung kommt aus zlib. Der Ausgabepuffer ist angeblich zu klein. Da er mit 32 MB dimensioniert ist, hält sich das gelesene PBF nicht an die Spezifikationen. Oder – was viel wahrscheinlicher ist: da ist ein Bug im Programm. Oder… es gibt wieder ein Problem mit der Windowsversion und der 2-GB-Grenze für Dateien. Sollte aber gefixt sein.
Kannst du bitte sagen, welche Programmversion du benutzt? Und, ist es die europe.osm.pbf-Version von heute? Ich geh der Sache dann auf den Grund.
Markus
Hallo Markus,
ich hab Version 0.1C für Windows genutzt. Das Problem hatte ich mit der europe.osm.pbf von der GeoFabrik von gestern (-5) und heute (-3).
Hallo - hab das Problem immer noch nicht erwischt.
Mit Version 0.0E unter Ubuntu (32 Bit) läuft alles glatt. Gleiches gilt für die Windows-Version unter Wine.
Ich bereite grad einen Test für 32-Bit-Windows vor. 64-Bit-Windows hab ich im Moment nicht greifbar.
Hast du eigentlich die osmconvert.exe runtergeladen oder selber mit MinGW übersetzt?
Ich hab mir die fertige exe geladen. Kann ich die 0.0E irgendwo herunterladen, dann probiere ich die nochmal aus.
EDIT: Mit der 0.1F gibts das gleiche Problem.
Wenns dir möglich ist, übersetz bitte mal neu mit MinGW unter Win64.
Ich hab grad unter Win32 (XP Pro) getestet, da läufts einwandfrei. Bin jetzt auf der Suche nach einer Win64-Installation. Sobald mir eine unter die Finger kommt, werd ich testen.
Ich hab eben 0.1H selber compiliert (wie hier beschrieben), der Fehler besteht weiterhin. Kann ich sonst noch etwas testen bzw. dir behilflich sein?
DANKE!
Aber ich wüsste jetzt nicht wie. 
Außer, du willst dich wirklich in den Quellcode reinwühlen.
Vielleicht hab ich übermorgen die Gelegenheit, mit Win64 zu testen.
Interessant wäre noch zu erfahren, ob es bei pbftoosm zur gleichen Fehlermeldung kommt. Oder ob die Meldung bei ca. 2 oder 4 GB Dateiposition auftritt. Aber das ist dann schon wieder Forschungsarbeit. Ich kümmer mich am besten mal um eine 64-Bit-Version.