DE:Pbftoosm
- Inhalt
- Pbftoosm war ein Programm, um .osm.pbf-Dateien in das OSM-XML-Format zu konvertieren.
- Gründe für die Überlebtheit
- Es wurde im Jahr 2011 entwickelt. Seine Funktionalität ist heutzutage in Osmconvert enthalten.
- Archivierungszeitpunkt
- 2011
Das Programm pbftoosm wandelt .pbf Dateien in .osm files um. Der gewünschte geographische Bereich kann mit einem Rechteck (so genannte bounding box) oder einem Bounding-Polygon begrenzt werden. Geschrieben wurde das Programm in C, es ist relativ schnell.
- Dieses Programm wird zurzeit nicht aktiv gewartet. Bitte soweit möglich osmconvert verwenden (größerer Funktionsumfang).
Download
These Downloads are available:
- Programmdatei für Linux 32 bit
- Programmdatei für Linux 64 bit
- Programmdatei für Windows
- Quellcode (neueste Version, möglicherweise Beta-Version)
(Wie üblich: Gewährleistung ausgeschlossen, so weit wie gesetzlich zulässig.)
Programmbeschreibung
Das Programm bietet zwei Funktionen: Umwandeln einer PBF-Datei in eine OSM-XML-Datei sowie das Begrenzen des Kartenausschnitts auf einen bestimmten geografischen Bereich.
Decodieren von .pbf-Dateien
Das Umwandeln von .pbf-Dateien in (menschenlesbare) .osm-XML-Dateien kann mit diesem Programm durchgeführt werden. Beispiel:
./pbftoosm < norway.osm.pbf > norway.osm
Die Ausgabedatei kann auch komprimiert werden. Zum Beispiel:
./pbftoosm < norway.osm.pbf | gzip -1 > norway.osm.gz
Die meisten Anwendungen (z.B. Renderer) benötigen keine History-Tags. Um Versions-, Changeset-, User- und Timestamp-Informationen auszuschließen, kann der Kommandozeilenparameter --drop-history verwendet werden. Beispiel:
./pbftoosm --drop-history < a.pbf > a.osm
Falls nicht nur Knoten ausgeschlossen werden sollen, die außerhalb vorgegebener geografischer Grenzen liegen, sondern auch die Referenzen auf solche Knoten, kann das mit dieser Option erreicht werden (notwendig für den Datenimport in den OSM Map Composer):
--drop-brokenrefs
In ähnlicher Weise können ganze Abschnitte ausgeschlossen werden:
--drop-nodes --drop-ways --drop-relations
Anwenden von geografischen Grenzen
Falls die Kartendaten auf eine bestimmte geografische Region begrenzt werden sollen, kann eine so genannte Bounding-Box als begrenzendes "Rechteck" definiert werden. Dazu müssen die Koordinaten der südwestlichen und der nordöstlichen Ecke angegeben werden. Zum Beispiel:
./pbftoosm < germany.osm.pbf -b=10.5,49,11.5,50 > nuernberg.osm
An Stelle einer einfachen Bounding-Box kann auch ein Bounding-Polygon als Begrenzung definiert werden. Dadurch kann man eine politische Grenze genau vorgeben. Zum Beispiel:
./pbftoosm < germany.osm.pbf -B=hamburg.poly > hamburg.osm
Unter Ubuntu in das Verzeichnis wechseln und der Befehl ist im Terminal:
./pbftoosm32 < europe.osm.pbf -B=hamburg.poly > hamburg.osm
Das Format der Border-Polygon-Datei ist hier beschrieben. Die Formatbeschreibung muss nicht strikt eingehalten werden; wichtig ist jedoch, dass jede Koordinatenzeile mit einem oder mehreren Leerzeichen beginnt.
Normalerweise wird die Zieldatei einige Relationen beinhalten, deren Knoten nicht innerhalb der vorgegebenen Grenzen liegen. Das lässt sich verhindern, indem man den Parameter -i verwendet und dem Programm damit Direktzugriff auf die Eingabedatei erlaubt. Die Verarbeitungszeit erhöht sich allerdings ein bisschen. Zum Beispiel:
./pbftoosm -i=germany.osm.pbf -b=10.5,49,11.5,50 > nuernberg.osm ./pbftoosm -i=germany.osm.pbf -B=hamburg.poly > hamburg.osm
Plausibilitäts-Prüfung
Der Parameter -t unterdrückt die Standardausgabe des Programms. Das ist nützlich, wenn man nur die Eingabedateien prüfen lassen und keine Ausgabedatei schreiben will. Es werden dann nur Fehler- und Warnungsmeldungen ausgegeben.
Weitere Hilfe
Mit der Option -h kann die Hilfeseite des Programms aufgerufen werden.
Ressourcen
Das Programm selbst belegt nur wenige MB Hauptspeicher. Falls mehrere .osc-Dateien gleichzeitig verwendet werden, ist je Datei mit ca. 20 MB Platzbedarf zu rechnen. Falls geografische Grenzen angewendet werden sollen (Parameter -b oder -B), benötigt das Programm weitere 400 MB für einen Hash-Speicher. Diese Hash-Speichergröße kann mit dem Parameter -h... verändert werden, zum Beispiel: -h=1000.
Benchmarks
Vergleich mit Osmosis
Obwohl Osmosis zweifellos das bekannteste und universellste Tool für die Umwandlung von OSM-Daten ist, erledigt pbftoosm bestimmte spezielle Aufgaben deutlich schneller.
Mit diesem Benchmark wird die Umwandlung einer .pbf-Datei in eine .osm-Datei bei gleichzeitiger Anwendung eines Border-Polygons getestet. Im Detail:
- .pbf Input-Datei: germany.osm.pbf (2011-04-16)
- Border-Polygon: bayern.poly von Cloudmade (2011-04-16)
- Software: Osmosis-0.39 und pbftoosm 0.2A
- Betriebssystem: Ubuntu 10.04
- CPU: Intel Atom 330 (2 Kerne, 1,6 GHz)
Osmosis
$ time ../osmosis/bin/osmosis --read-pbf file="germany.osm.pbf" --bounding-polygon file="bayern.poly" cascadingRelations --write-xml file="bayern_os.osm" 16.04.2011 14:00:10 org.openstreetmap.osmosis.core.Osmosis run INFO: Osmosis Version 0.39 16.04.2011 14:00:11 org.openstreetmap.osmosis.core.Osmosis run INFO: Preparing pipeline. 16.04.2011 14:00:12 org.openstreetmap.osmosis.core.Osmosis run INFO: Launching pipeline execution. 16.04.2011 14:00:12 org.openstreetmap.osmosis.core.Osmosis run INFO: Pipeline executing, waiting for completion. 16.04.2011 15:07:29 org.openstreetmap.osmosis.core.Osmosis run INFO: Pipeline complete. 16.04.2011 15:07:29 org.openstreetmap.osmosis.core.Osmosis run INFO: Total execution time: 4039003 milliseconds. real 67m20.922s user 67m6.656s sys 1m18.453s
- Ergebnis: etwa 67 Minuten
pbftoosm
$ time ./pbftoosm -i=germany.osm.pbf -B=bayern.poly > bayern_po.osm real 4m29.005s user 3m40.514s sys 0m22.029s
- Ergebnis: weniger als 5 Minuten
pbftoosm, ohne History-Information
$ time ./pbftoosm -i=germany.osm.pbf -B=bayern.poly --drop-history > bayern_po_h.osm real 3m10.160s user 2m38.766s sys 0m12.269s
- Ergebnis: etwa 3 Minuten
Dateigrößen
- bayern.poly - 100,1 KB (102506 Bytes)
- germany.osm.pbf - 871,1 MB (913428341 Bytes)
- bayern_os.osm - 3,1 GB (3303447197 Bytes)
- bayern_po.osm - 3,0 GB (3239098681 Bytes)
- bayern_po_h.osm - 1,5 GB (1654126217 Bytes)
Osmosis vs. pbf2osm vs. pbftoosm
Vergleich des Ausschneidens eines Polygons aus drei verschiedenen Dateien:
- bayern.osm.lzo (584 MB) (ultra schnelle Kompression and Dekompression, kann von der Geschwindigkeit der Festplatte abhängen)
- bayern.osm.bz2 (287 MB) (sehr langsame Kompression)
- bayern.osm.pbf (181 MB) (schnelle Dekompression)
time osmosis --rx file=bayern.osm.bz2 --bp file=regensburg.poly --wx file=e.osm real 10m7.058s
time lzop -d < bayern.osm.lzo | osmosis --rx file=- --bp file=regensburg.poly --wx file=c.osm real 2m23.741s
time bzcat bayern.osm.bz2 | osmosis --rx file=- --bp file=regensburg.poly --wx file=g.osm real 2m22.601s
time bzcat bayern.osm.bz2 | osmchange -B=regensburg.poly > f.osm real 2m0.632s
time pbf2osm bayern.osm.pbf | osmchange -B=regensburg.poly > d.osm real 1m45.854s
time lzop -d < bayern.osm.lzo | osmchange -B=regensburg.poly > b.osm real 0m46.488s
time osmosis --rb file=bayern.osm.pbf --bp file=regensburg.poly --wx file=a.osm real 0m40.421s
time pbftoosm -B=regensburg.poly -i=bayern.osm.pbf > h.osm real 0m6.658s
Ergebnis
Beim Ausschneiden eines Polygons ist pbftoosm fast 20 mal schneller als pbf2osm mit osmchange. Und immernoch mehr als 6 mal schneller als osmosis (mit pbf).
Weitere Benchmarks
Bitte selbst ergänzen.