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.
_______________________________________________
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de
