Hallo,
lang hat es gedauert, aber seit heute kann osmconvert auch PBF-Dateien schreiben.
Ich trau dem Programm noch nicht ganz über den Weg, deswegen hab ich die Testversion noch nicht regulär hochgeladen. Will erstmal ein paar ausführlichere Versuche durchlaufen lassen. Der erste Versuch mit bremen.osm hat geklappt, aber das heißt nicht viel. 
Mag jemand mittesten?
Grüße
Markus
icke!
Oha, aus Preußen? 
Habs grad die Beta als Version 0.3P hochgeladen:
m.m.i24.cc/osmconvert_pbf.c
Übersetzen wie üblich mit
cc osmconvert_pbf.c -lz -o osmconvert
Bitte noch nicht in einer produktiven Umgebung einsetzen. Zwar waren meine Tests erfolgreich (bremen.osm und germany.osm), aber die Version ist noch seeehr neu.
Ach ja, neue Option: --out-pbf
Kurze Frage, wie kann man die Intigrität der erzeugten PBF testen? Ich meine nur lesen und schreiben ist ja das eine. Die Frage ist wie man Fehler entdeckt. Ich würde dann unter Windows auch ein paar Durchläufe machen. Schickst mir die Version am Besten übersetzt und dann jage ich das mal durch.
Hallo auch!
Hab eine Windows-Testversion grad hochgeladen: m.m.i24.cc/osmconvert_pbf.exe
Wie man die Integrität testen kann, weiß ich nicht genau. Ich hab bei meinen Tests einfach umgewandelt:
Zuerst das Original-PBF besorgt (z.B. bremen.osm.pbf von Geofabrik), dann per osmconvert in .osm umgewandelt.
Dieses .osm dann in .pbf umgewandelt und wieder zurück in (ein anderes) .osm.
Anschließend hab ich das erste und das zweite .osm verglichen.
Hoffentlich war das jetzt nicht zu wirr… 
Also es scheint zu funktionieren unter Windows7 mit Sachsen erfolgreich getestet. Allerdings ist mir beim Umwandeln aufgefallen, dass der 4 Kern Prozessor nur zu 25% ausgelastet ist. Eventuell gibt es hier Optimierungsmöglichkeiten für die Geschwindigkeit. Wichtig ist vielleicht dabei, dass kein Prozessorkern um die 100% rennt und auch die Festplattenlampe flackert immer wieder. Eventuell kann man in einem Prozess in Den arbeitsspeicher lesen und mit einem weiteren Prozess im Speicher umwandeln während der erste Prozess einen weiteren Bereich liest und dann schreibt er die Daten des ersten Schrittes weg, während der zweite Teil im Speicher bearbeitet wird.
Klingt total kompliziert und ich weiß nicht ob es was bringen könnte.
M:\>osmconvert_pbf -v europe.osm.pbf >europe1.osm
osmconvert: Verbose mode.
osmfilter Parameter: europe.osm.pbf
osmconvert: Last processed: relation 1769936.
M:\>osmconvert_pbf -v europe1.osm --out-pbf >europe1.osm
osmconvert: Verbose mode.
osmfilter Parameter: europe1.osm
osmfilter Parameter: --out-pbf
osmconvert Error: file empty: europe1.osm
osmconvert Exit: 5
Das Europe file war nicht ganz aktuell. Es ist noch vom 30.9.11
Wäre es nicht sinnvoll zu schauen, ob bspw. osmosis mit dem erstellten pbf klar kommt?
Bspw. osm laden, dann zu pbf dann mit osmosis zu osm und schauen, ob es dann noch geht.
Das Problem ist, dass OSmosis einen anderen OSM Dialekt spricht. das heißt die Dateien am Ende sind nicht identisch. Daher ist es dann auch nicht einfach festzustellen ob es einen Fehler gab.
Du lädst dir ein osm von der Geofabrik (von osmosis erstellt=Referenz), dann mit osmconvert nach pbf und das dann mit osmosis wieder zu osm. Dann hast du den gleichen “Dialekt” zum vergleichen.
Nein, nicht kompliziert, sondern sicher eine gute Idee. Ob es den Programmieraufwand lohnt, weiß ich noch nicht. Mal schauen, zuerst muss der Programm korrekt arbeiten, das ist viel wichtiger als Geschwindigkeitsoptimierungen.
“osmfilter Parameter:” - das ist noch ein Bug. Natürlich müsste da “osmconvert” stehen.
“file empty: europe1.osm” - ist die Datei wirklich leer? Nein, oder? Wie ist die genaue Größe? Vielleicht gibts ein Problem mit der 2-GB-Grenze. Oder ist es gepackt? Eine ungepackte .osm-Datei ist ja riesengroß…
Ja, ganz sicher sinnvoll! Mit germany.osm hab ich es schon probiert. Die von Osmosis erzeugte .pbf-Datei kann man aber nicht direkt mit der von osmconvert erzeugten vergleichen. Osmosis beherrscht zwar mehr Optionen (z.B. mit und ohne Kompression, Densenodes oder nicht), nutzt das .pbf-Format aber nicht vollständig aus. Das heißt, es gibt schon Unterschiede in der Dateigröße.
Jetzt könnte man natürlich die Osmosis-PBF und die osmconvert-PBF jeweils wieder in eine .osm-Datei umwandeln und die beiden .osm-Dateien vergleichen. Leider packt “diff” so große Dateien nicht. Ach ja, ein Unterschied ist mir trotzdem aufgefallen: In der .osm-Datei, die aus der Osmosis-PBF erzeugt wurde, ist immer wieder mal uid=“0” und user=“” zu finden. Aus meiner Sicht ist das nicht korrekt, bin mir noch nicht sicher, ob das ein Bug in Osmosis ist.
Also es sollte solche uid=“0” geben. Das sind anonyme Einträge…war irgendwann mal möglich.
Guter Plan, klappt so leider nicht ganz:
$ bzcat bremen.osm.bz2 |head
<?xml version='1.0' encoding='UTF-8'?>
<osm version="0.6" generator="pbf2osm">
<node id="125799" lat="53.0749415" lon="8.7868047" version="6" changeset="7711393" user="UScha" uid="45445" timestamp="2011-03-29T21:43:10Z"/>
Anscheinend werden die .osm-Dateien bei Geofabrik mit pbf2osm erstellt.
Ja, das Editieren war mal anonym möglich. Aber in dem Fall darf die XML weder uid noch user enthalten. Jedenfalls hab ich bisher uid=“0” noch nie woanders gesehen. Aber von einem echten Standard kann man ja nicht reden, insofern ist es wohl auch kein Bug.
Ähm doch natürlich sie hat exakt 0kb. Auf NTFS Laufwerken gibt es doch keine 2GB Grenze. Oder wo steckt die? Ich hatte einfach die Idee Europa auszupacken und dann wieder einzupacken und schon die PBF Datei ist ja 6Gb groß. OsmConvert hat sich redlich gemüht. Ergebnis war aber ohne Fehlermeldung 0kb.
Also ich habe den Osmosis test auch mal gemacht. Dafür habe ich mir die Sachsen.osm.pbf geladen und mit Osmosis --rb sachsen.osm.pbf --rx sachsen1.osm erzeugt.
Dann habe ich mit Osmconvert das in ein Pbf gesteckt und mit Osmosis daraus wieder ein xml gemacht. Die beiden Datein verglichen und sie sind anders! wenn man sich aber die ersten Zeilen anschaut, dann sind dort sinnlose Dinge verschieden. Welche gar nicht die Daten betreffen.
Also nochmal die zweite Osm Version in Pbf gepackt und mit Osmosis wieder ausgepackt und jetzt sind die Dateien identisch. Ob jetzt allerdings beim ersten konvertieren Daten verloren gegangen sind und wie man das gegebenfalls prüft weiß ich nicht. Aber das Pbf von Osmconvert versteht osmosis und übersetzt es wieder auf die gleiche Art.
Hallo viw,
das mit dem europe.pbf werd ich heute Abend auch mal testen.
Bezüglich des Formats: vielleicht hilft beim Erzeugen einer XML-Datei mit osmconvert die Option --emulate-osmosis ein wenig. Sie ist zwar nicht perfekt, aber vielleicht werden die Unterschiede dann weniger.
Spontane Vermutung: Mit einer Pipe die zu lesende Datei zu schreiben, funktioniert nicht. Dann ist klar, dass sie leer ist, denn sobald die Pipe angelegt wird, sollte die Datei eigentlich im write-Modus geöffnet sein.
Oder habe ich da irgendwas verpasst?
Äh ja - das hab ich gar nicht gesehen!
Die zu lesende Datei und die zu schreibende sind identisch. Das kann natürlich nicht klappen…
]
These formats can be written:
.osm (default) .osc .osh .o5m .o5c
das ist noch ein Bug. Natürlich müsste da
.osm (default) .osc .osh .o5m .o5c .pbf
stehen.
Du hast mich überzeugt. Ich werde jetzt also nochmals das Europa durch jagen.
@marqs mir fällt auf das er sehr sparsam mit Hauptspeicher umgeht. Aber wenn es das Programm irgendwie beschleunigt und der Speicher da steht, kann man den auch nutzen. Vielleicht wie bei osm2pgsql mittels Parameter.