[Talk-de] Geofabrik-Downloads jetzt als Binaerformat

[Carsten Moeller]

Am 22.09.2010 23:48, schrieb Frederik Ramm:
> Hallo,
>
> Robert S. wrote:
>> Und was ist zu machen, wenn man z.B. mit Maperitive[1] eine Karte rendern
>> will, der braucht ja .osm-XML-Dateien. Bisher reichte es ja, die
>> .bz2-Datei
>> mit 7.Zip oder WinRar zu entpacken. Und nun...?
>
> osmosis --read-bin file.osm.bpf --write-xml file.osm
>
> Oder warten, bis Maperitive das .osm.bpf selber auch unterstuetzt. Es
> wird bald eine einfache C-Implementierung fuer die Umsetzung pbf->osm
> geben, die kann dann jeder (z.B. der Maperitive-Entwickler) einfach in
> sein Programm einbauen.
>
> Aber die alten .bz2s gibt es ja noch, und die verschwinden auch nicht
> morgen. Fruehestens uebermorgen ;)
>
> Bye
> Frederik
>

Na ja, wenn man da mal - wenn auch etwas verspätet zwischengrätschen darf...

Ich halte bpf für eine Alternative, nicht jedoch für eine wirklich gute 
Lösung. Die Annahme, dass alles da draußen auf osmosis aufsetzen wolle 
oder mal eben ganze Importstrukturen umkippen wird, um sich dem doch 
eher gruseligen Binärgefriggel-Format anzuschließen, halte ich für 
gewagt. Eine 30%ige Reduzierung der Transportmengen wäre durchaus auch 
anders zu erreichen. Nicht jeder benötigt immer alles. Als gutes 
Beispiel sehe ich hier die Cloudmade-Philosophie Extrakte für 
verschiedene Anwendungsfälle bereitzustellen. Da ist ein 
europa-highways.osm plötzlich nur noch ein Drittel so groß wie das 
Original. Analog wäre z.B. auch denkbar, die ganzen Meta-Infos wie 
Autor, TimeStamp, etc. aus den Tags rauszulassen und nur reine Nutzdaten 
zu komprimieren. Wette, das geht dann auch auf 30% runter!
Aber der wichtigste Aspekt zum Schluss:
Ich weiß nicht wie viele XMLs ich bereits analysiert habe und so ganz 
schnell auf kleine aber nicht unwichtige Dinge und Fehlerchen aufmerksam 
geworden bin. Diese Option wird es dann ja in Zukunft nicht mehr geben.

Schade.