DE:Pbftoosm

From OpenStreetMap Wiki
Jump to navigation Jump to search
Logo.png
Diese Seite handelt von historischen Inhalten der Geschichte von OpenStreetMap. Es geht dabei nicht um Gegenwärtiges, sondern um frühere Konzepte, Probleme oder Ideen.
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:

(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:

  1. bayern.osm.lzo (584 MB) (ultra schnelle Kompression and Dekompression, kann von der Geschwindigkeit der Festplatte abhängen)
  2. bayern.osm.bz2 (287 MB) (sehr langsame Kompression)
  3. 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.