Korrekt! Beides. 
Ich wollte mögliche Kompatibilitätsprobleme von vornherein ausschließen. Die, die das Letzte rauskitzeln wollen, werden das Programm sowieso selber übersetzen.
Genau das Problem hatte ich am Anfang auch. PA94 hat mir mit einem Tipp weitergeholfen:
http://forum.openstreetmap.org/viewtopic.php?pid=162140#p162140
Das MinGW-Paket, das du dort findest, hat alle möglichen Bibliotheken schon an Bord.
Du hast Recht, das schaut doof aus, aber praktisch alle anderen Programme machen es genauso. Ich wollte vom Syntax her nicht zu sehr abweichen, weil sich möglicherweise manche Software drauf verlässt. Probleme gabs zum Beispiel schon mal mit den FOSM-Downloads; die verwenden durchgehend das einfache Hochkomma: ’
Mit -v oder -v=2 verrät osmconvert zwar den Präfix für die Namen der temporären Dateien, aber beim reinen Umwandeln von .osm nach .pbf wird keine benötigt und deswegen auch keine angelegt. Der gesamte Speicherplatzbedarf dürfte etwas unter einem halben GB liegen und damit für die meisten Systeme unkritisch sein.
Und ja, in osmconvert läuft nur ein einziger Thread. Das ist meist praktisch, weil die Maschine dann nebenher noch anderes erledigen kann, aber wenns um Geschwindigkeitswettbewerbe geht, natürlich noch verbesserungsfähig. Die Frage ist, ob es den Aufwand lohnt, die Programmstruktur auf parallele Verarbeitung umzubauen.
Zur Dateigröße:
Am Anfang hab ich mich auch gewundert, dass die von osmconvert erzeugten .pbf-Dateien kleiner sind als die von Geofabrik. Insbesondre deswegen, weil osmconvert nicht alle Optimierungsmöglichkeiten nutzt. Es werden zum Beispiel die Strings nicht nach Häufigkeit sortiert. Erklären kann ich mir den Unterschied nur mit der Blockgröße. Das PBF-Format speichert die Daten blockweise und erlaubt Blöcke bis zu einer Größe von 32 MiB. osmconvert schöpft diese Größe zur Sicherheit nicht ganz aus, packt aber immer ca. 31 MB in einen Block. Osmosis packt meines Wissens immer genau 8000 Objekte (nodes, ways oder relations) in einen Block, dadurch wird die Blockgröße nicht ausgenutzt.
Größere Blöcke lassen sich besser komprimieren (das PBF-Format sieht blockweise Komprimierung mit dem zlib-Algorithmus vor).
Leerstring-Fehler:
Letzte Nacht habe ich noch einen Fehler entdeckt. Er tritt auf, wenn in den XML-Daten ein Leerstring enthalten ist. Wenn also irgendwo nicht “xyz”=“yes” sondern “”=“yes” steht. Einen solchen Fall gibts in Westengland. Keine Ahnung, wie der Tag dort reingekommen ist, denn eigentlich sollte sowas durch die Editoren abgewiesen werden. In der Folge konnte europe.osm nicht korrekt in eine PBF-Datei umgewandelt werden, die Tags bei manchen Knoten wurden falsch zugeordnet. Eine neue Version (0.3V) lade ich hoch, sobald der Vergleich durchgelaufen ist.
Womit wir beim Thema “Vergleich” wären:
Unter Linux kann man mit dem Befehl “diff” zwei Dateien zeilenweise vergleichen (unter Windows mit “fc” soweit ich mich noch erinnere). Leider geht “diff” mit dem Speicherplatz verschwenderisch um, so dass es nicht möglich ist, Dateien zu vergleichen, die mehrere GB groß sind - schon gar nicht die 128 GB der europe.osm. Für solche Zwecke gibt es aber den Befehl “cmp”. Er ist im Vergleich zu “diff” weit weniger komfortabel, erlaubt aber byteweise Vergleiche von beliebig großen Dateien. Mit dem Parameter “-i” lassen sich die ersten paar Bytes überspringen, so dass man auch Dateien vergleichen kann, die mit unterschiedlichen Programmversionen geschrieben wurden. Beispiel:
cmp -i 100 europe1.osm europe2.osm
So, ich hoffe, ich hab keinen vergessen.
Melde mich wieder, sobald die Version 0.3V online ist.
EDIT:
Version 0.3V ist online: m.m.i24.cc/osmconvert_pbf.c bzw. m.m.i24.cc/osmconvert_pbf.exe
Meinen nächsten Test mache ich mit dem Planet-File. Kann allerdings sein, dass die .osm-Datei dann nicht auf meine Platte passt. Also, Mittester immer willkommen.
