Ich möchte eine vier Tage alte planet-Datei aktualisieren. Ich würde dafür am Liebsten –append-change verwenden, weil man dort scheinbar mehrere Input-Dateien auf einmal angeben kann. Aber dort steht auch als Anmerkung, dass
ich also lieber –merge-change verwenden soll. Damit kann man aber immer nur zwei osc-Dateien verbinden (mergen).
Außerdem soll man vorher noch sortieren. Das steht aber nur bei --merge-change dabei, nicht bei --append-change, was auch gegen die Verwendung von --merge-change spricht.
Weiß hier jemand was dazu? Oder wo frage ich das besser?
Merge-change nehme ich, um die Daily Changes zu mergen weil sie nicht täglich in die zu aktualisierende Datei kommen - letztendlich wie bei minütlichen Changes (Replication Task), welche nicht jede Minute “abgeholt” werden, lückenlos müssen die Daten dennoch sein.
Der Merge funktioniert ohne Sort bis jetzt korrekt:
osmosis --rxc $oldchange.osc.gz --rxc $change.osc.gz --mc --wxc $newchange.osc.gz
Bei apply-change (nicht “append-change”) verwende ich statt “sort” ein “simplify-change”:
osmosis --rxc $range.osc.gz --simc --rb area-$olddate.osm.pbf --ac --bb top=55.3 left=5.6 bottom=45.7 right=18.9 --wb omitmetadata=true area-$lastdate.osm.pbf
Die Verwendung der Variablen ist für den täglichen Gebrauch in Scripts gedacht, die Variablen sind aus den Dateinamen gewonnen die je nach Stand der Aktualisierung innerhalb der Changes sowie beim Planet-Ausschnitt angepasst werden.
Gut, wenn man das täglich macht ist das praktisch. Aber wenn man eben mal mehrere Änderungen vereinen will, muss man sich mit einem Bash-Skript helfen, oder? Etwa so:
cd $VERZEICHNIS_MIT_CHANGESETS
j="null"
for i in *.osc.gz; do
if [ ! blub$j = "blubnull" ]; then
osmosis --rxc $j --rxc $i --mc --wxc merged.osc.gz
fi
if [ blub$j = "blubnull" ]; then
j=$i
else
j=old.osc.gz
mv merged.osc.gz old.osc.gz
fi
done
Ein recht längliches Skript, was man vielleicht mittels --append-change verkürzen könnte – hoffte ich jedenfalls.
Wahrscheinlich sind die auf planet.osm.org veröffentlichten changesets schon sortiert.
Ja, aber ich will ja eben gerade was über die Verwendung von –append-change erfahren, weil das so schön viele Eingabedateien akzeptiert. Bleibt wohl nichts als ausprobieren, denn die Dokumentation im Wiki sagt mir nichs genaueres darüber, was denn nun der Unterschied zwischen --merge-change und --append-change ist.
Oh, vielen Dank für diesen Tipp. Zwar weiß ich jetzt noch nicht, wozu dieses ominöse --append-change da ist, aber mit osmchange scheint’s ja noch viel einfacher zu gehen. Danke sehr.
PS: Ich sehe gerade, dass es doch gar nicht so günstig ist, wenn alle Dateien nur gepackt vorliegen (was bei solch riesigen XML-Dateien sinnvoll ist). Denn Osmosis entpackt gz- und bz2-Dateien (leider keine lzop-Dateien) im Betrieb und erzeugt auch wieder gepackte Dateien. Mit osmchange ist das scheinbar nicht möglich.
Ja, es ist viiiel einfacher, aber sei bitte vorsichtig. Falls deine Existenz von diesen Daten abhängt, ist Osmosis vielleicht die bessere Wahl, da es sich seit Jahren bewährt. osmchange ist recht neu. Es erledigt zwar die Updates von www.openptmap.de und www.opengastromap.de seit ein paar Wochen zuverlässig (und viel schneller), aber eine Garantie gibts natürlich nicht.
Welches Betriebssystem verwendest du? Die .osm-Dateien können gepackt oder ungepackt vorliegen und auf Wunsch auch gepackt werden. Das erledigen die externen Programme recht zuverlässig und - soweit ich mich an osm2pgsql erinnere - nicht selten auch schneller als die eingebauten Funktionen. Linux-Beispiel von der osmchange-Wiki-Seite:
Bei Windows gehts auch, hab ich aber grad nicht im Kopf.
Allerdings ist eine Einschränkung richtig: die .osc-Dateien, also die Changefiles, müssen ungepackt vorliegen. Aber die sind in der Regel ja auch nicht so groß. Falls jemand mitliest und weiß, wie man unter Linux das Entpacken auch der .osc in einem Aufwasch mit dem osmchange-Kommando hinbekommt (eigene Pipes), bitte melden.
Ich entpacke die .osc-Dateien übrigens immer gleich beim Runterladen, dann brauch nicht nicht die Dateien hin- und herzuschaufeln:
Sie werden groß, wenn man mehrere solcher Dateien zu einer zusammenfasst.
Ah, „named pipes", davon habe ich schonmal gehört. Vielleicht ließe es sich damit lösen. Das wäre genial, denn dann hätte ich Platz gespart, könnte das viel schnellere aber immernoch gut packende LZOP verwenden und würde nicht viel Festplattenplatz brauchen, denn der ist sehr begrenzt.
Wie viele .osc-Dateien willst du denn auf einmal in eine .osm-Datei einarbeiten? Typische Größe für ein Daily Changefile (gesamte Erde): 50 MB, entpackt ca. 0,5 GB.
“Named Pipe” klingt irgendwie gut. Ich muss mir das mal angucken.
Zu den Pack-Formaten: Ich hab experimentiert mit bz2, zip und gzip. Am schnellsten beim Entpacken war gzip (wie zip) und beim Packen “gzip -1”. Mit der Option “-1” komprimiert es nicht sonderlich gut, ist aber recht schnell. Hier steht zu dem Thema auch ein Satz: http://wiki.openstreetmap.org/wiki/Daily_update_an_OSM_XML_file#Get_the_OSM_XML_File
Bis zu sieben auf einen Streich. Jaja, geht schon alles, aber das sind dann entpackt schon mehrere Gigabyte (so vier oder fünf).
• Dass xz (= lzma) viel besser packt als bzip2, ist klar
• dass bzip2 viel besser packt als gzip, ist klar
• dass gzip viel besser packt als lzop, ist recht unbekannt, weil lzop noch neu ist.
Aber: Die Zeit zum „besseren Packen" steigt überproportional stark an. lzop hat das beste Pack/Zeit-Verhältnis. Dazu gibt es umfangreiche Tests.
Also: Wenn’s zeitkritisch (beim Packen!) ist, aber dennoch möglichst viel Platz in der kurzen Zeit gespart werden soll: lzop
Wenn’s möglichst gut gepackt sein soll: xz (= lzma).
Entpackt werden beide sehr schnell.
PS: osmchange ist tatsächlich etwas mehr als doppelt so schnell. Super!
Nochmals vielen Dank für die Tipps. Dank osmchange und den named pipes (mit lzop) läuft das ganze jetzt sau schnell und braucht kaum Festplattenplatz. Genau das richtige, denn die Anforderungen sind, möglichst wenig CPU-Zeit zu verbrauchen, da diese für andere „wichtigere" Dinge gebraucht wird, und die fast volle Festplatte möglichst wenig füllen/verwenden.
Aber gern. Falls es Probleme gibt, bitte sag Bescheid, das interessiert mich!
Ich hab inzwischen Experimente mit lzop gemacht. Echt genial. Zwar komprimiert “gzip -1” um ca. 20% kleiner, aber “lzop” ist doppelt so schnell. Das gilt aber - wie du schon sagst - nur fürs Komprimieren und nicht fürs Dekomprimieren. Alles in allem ist der Vorteil nicht so groß, dass ich die Notwendigkeit sehe, die Scripte meiner Karten umzubauen; im Moment hab ich genügend CPU-Leistung zur Verfügung. Aber wenn ich das Zeug neu schreiben würde, würd ich sicher lzop verwenden.
Ich hab Berichte von einem User, dass die Methode mit dem Programm “osmchange” unter Windows unheimlich langsam sein soll. Gibts dazu weitere Erfahrungen?
Unter Linux läuft das Ganze ja wirklich sehr schnell… deswegen wundert mich das schon…
Weiter zu höheren Geschwindigkeiten: Habe gerade gelesen, dass die XML-Daten von OSM noch besser im speziell dafür entwickelten PBF-Format gespeichert werden sollten, weil das beim Schreiben noch 5 mal schneller als eine gzippte (also mit gzip gepackte) OSM-(XML)-Datei sein soll. Also auch noch 2 mal schneller als lzop und das Ergebnis sogar nur halb so groß wie eine gzippte OSM-Datei. Und gzip macht schon etwas kleinere Dateien als lzop.
Wer entwickelt osmchange? Wo erfährt man was darüber? Wird noch weiter entwickelt? Wird PBF eingebaut werden? Wann?
Als Standard gilt bis jetzt noch XML. PBF ist arg spezialisiert und irgendwie clusterweise gepackt. Ich hab die Doku noch nicht ganz verstanden. Bin auch nicht sicher, ob sich PBF wirklich durchsetzen wird. Kompressionsfaktor ist nun wirklich nicht alles…
Nur so kommt man zu den krassen Vorteilen dieses Formats.
Genau, sondern auch noch extrem erhöhte Schreibgeschwindigkeit (Lesegeschwindigkeit sowieso).
Außerdem bedeutet Kompression, dass die Daten schneller oder häufiger (oder beides!) aktualisiert werden könnten.
Inwiefern? Von mir? Oder von den PBF-Entwicklern? Oder von den osmchange-Entwicklern?
Wäre halt schön, wenn’s dieses PBF irgendwie als lib (Bibliothek) zum Einbinden gäbe. Aber wenn das jeder selbst implementieren muss, verstehe ich, dass es noch nicht so verbreitet ist.
Edit: Achso, schon kapiert, wer osmchange geschrieben hat.
Im Abschnitt “The code” wird ausgeführt, dass es einen Teil unabhängig von Anwendungen gibt. Vermutlich betrifft dies das Lesen/Schreiben des Formats. Dafür gibt es Programm-Code in Java.
Weiter gibt es einen Teil der spezifisch für einzelne Anwendung ist. Dies ist erforderlich, da die interne Struktur für die OSM-Daten von Anwendung zu Anwendung unterschiedlich ist. Ob man etwas aus den bestehenden Anwendungen für OSMchange verwenden könnte, vermag ich nicht einmal zu vermuten.
PS:
Eigentlich ist das Protocolbuffer Binary Format (PBF) ein sehr allgemeines Format um strukturierte Informationen effizient in unabhängig decodierbaren Blöcken zu speichern. Jede Art solcher strukturierte Informationen ist dann natürlich eine spezielle Ausprägung des PBF. So etwas wie die DTD bei XML gibt es allerdings noch nicht.
Und ich habe gerade von Skinkie erfahren, dass er das Gegenprogramm zu pbf2osm schreibt. Dieses osm2pbf soll in Kürze fertig sein. Und wenn osmchange so schlank bleiben soll, wie bisher, kann man ja per Pipes alles an das Programm weitergeben und entgegen nehmen. Lieber nicht zu sehr überfrachten. Jedes Programm soll nur eine Sache können, dafür aber perfekt. Für den Rest gibt’s (named) Pipes. Edit: Wahrscheinlich dürfte osmchange doch schneller sein, wenn es zumindest XML und PBF lesen und schreiben könnte. Denn dann müsste es beim Ausschneiden von Polygonen nicht erst die ganze Datei durchsuchen, sondern nur den Teil der PBF-Datei, die auch diesen Bereich enthält ⇒ extreme Geschwindigkeitserhöhung. Dagegen dürfte die Integration von bz2, gz, lzo und xz keinen Geschwindigkeitsvorteil bringen – kann also weiterhin per Pipes angegliedert werden.
Wenn dieses osm2pbf fertig ist, wird’s wohl auch die planet-Dateien als PBF geben. Also nur abwarten und Skinkie ein paar Schokostückchen und Kekse schicken.
Mir erscheint das PBF-Format immer noch zu komplex. Vor allem stört mich die Tatsache, dass eine Datei dann aus vielen einzeln komprimierten Blöcken besteht. Für osmchange-Aufgaben muss dann jeder Block einzeln entpackt und wieder verpackt werden.
Die Grundidee, nämlich eine binäre Struktur vorzugeben, ist ja absolut nicht schlecht: also, dass man zum Beispiel für Koordinaten int32-Festkommazahlen verwendet (osmchange macht das intern ja auch). Aber die Einzeln-Packerei vergrößert den Aufwand m.E. dann schon.
Das dezentrale Packen wäre sinnvoll, wenn man direkt auf Dateibereiche zugreifen wollte. Aber wer macht das schon? Immer dann, wenn man drauf angewiesen ist, schnell an die Daten ranzukommen, entpackt man die Datei vorher ganz. Oder man schiebt sie in eine PostgreSQL-Datenbank.
Ich würd mir eine binäre Struktur wünschen (z.B. wie intern bei PBF definiert), aber dann komplett mit einem handelsüblichen Packer gepackt - z.B. mit lzop. Dadurch wäre die gesamte PBF-Datei unter Umständen sogar kleiner als sie jetzt ist. Und sie ließe sich leichter seriell verarbeiten.
Aber - das alles ist Geschmacksache. Und wahrscheinlich hab ich das bis jetzt definierte PBF-Format auch noch nicht ganz verstanden. Mir fehlen dazu noch Beispiele, wie das im Hexcode aussieht. Vielleicht… werden wir dann doch noch Freunde - das Format und ich. Aber nur vielleicht.
