europe.osm.pbf File per täglichem Diff-Abgleich aktuell halten

Der regelmäßige Download des 7GB großen Europa Extrakts von GeoFabrik geht ganz schön ins Download-Volumen.
Gibt es eine einfache Möglichkeit, ohne Datenbank dieses File auf aktuellem Stand zu halten?

Ich könnte mir das so vorstellen, dass von täglichen Auszügen (wo sind diese eigentlich aktuell zu bekommen)
per OSMConvert ungefähr Europa ausgeschnitten wird und das Ergebnis mit dem letzten File zu mergen ist.

Falls jemand damit Erfahrung hat oder sogar ein Skript für Windows besitzt, bitte um Nachhilfe.
Ich suche auch noch eine gute Wiki-Seite, wo dieser Vorgang ev. auch bereits beschrieben ist.

Walter

Wenn ich das richtig sehe, dann muesste osmosis sowas im Prinzip koennen, zumindest im XML-Format ist es laut Wiki moeglich, eine Datei mit einer Diff-Datei zu aktualisieren, ohne dass man dafuer ueber eine extra Datenbank gehen muss.

Probiert habe ich das aber auch noch nicht, das steht bei mir jetzt gerade auf der Liste.

Gruss
Torsten

Marqs war so nett und hat dieses Problem mit OSMupdate bereits gelöst.
Für windows musst du aber noch wget verfügbar machen, damit das Tool dann auch Daten runterladen kann. Außerdem musst du unter Win7 die Datei umbennen, da sonst Windowsfür das Ausführen Adminrechte erfordert.
Desweiteren empfielt sich die Datenhaltung im Format o5m, als Kompromiss aus Kompaktheit und Schnelligkeit beim Zugriff.

http://wiki.openstreetmap.org/wiki/DE:Osmupdate

Probier erstmal aus, ob du es mit osmupdate hinbekommst. Bei mir kann splitter und/oder mkgmap nichts mehr mit dem resultierenden pbf anfangen. Daher bin ich noch mit osmosis am Aktualisieren. Kann dir dann mal den Befehl raussuchen.

Vielen Dank für diese raschen Rückmeldung, ich werde mir mal das vielversprechende Osmupdate genauer ansehen. Ein dickes Lob auf jeden Fall mal an den Programmierer.
Er hat ein sehr wichtiges Problem richtig erkannt und genau dafür eine Lösung entwickelt, auch wenn es scheinbar noch im Experimentierstadium ist.

Walter

Hi,
hier mein Script für Win-7-64:

@echo off

cd \osmdata\

del europe.o5m.old

osmup -v --daily --drop-author -B=euro.poly europe.o5m  europe2.o5m

rename europe.o5m europe.o5m.old
rename europe2.o5m europe.o5m

pause


euro.poly:


europe
1
    -9.28344726 36.785824981
    -6.14135742 35.927609967
    -5.625      35.940212068
    -5.10864257 36.060941508
    -2.06542968 36.444853188
     1.53808593 37.521344634
    10.85449218 37.869071591
    11.55761718 37.294448810
    11.96411132 35.059978064
    17.24853515 34.512591916
    25.26855468 34.295042872
    33.64013671 34.288991865
    37.08984375 36.315125147
    44.82421875 37.020098201
    41.30859375 49.724479188
    36.2109375  51.618016548
    33.3984375  53.435719206
    31.55273437 54.521081495
    30.234375   56.121060425
    28.30078125 57.231502991
    28.74023437 58.957562746
    30.5859375  59.363061605
    32.34375    59.675137313
    33.70605468 60.486095852
    32.95898437 61.571548112
    31.55273437 62.110735207
    32.12402343 62.961882634
    31.33300781 63.982387048
    31.06933593 65.299589613
    30.84960937 67.764941778
    30.45410156 69.105164639
    31.81640625 69.570339578
    32.60742187 70.471104649
    28.4765625  71.385142084
    25.3125     71.538829906
    22.98339843 71.371109418
    18.01757812 70.495573540
    15.55664062 69.748551129
    13.79882812 69.162557908
    12.43652343 68.334375941
    11.11816406 67.429986771
   -18.69873046 67.432797815
   -23.62060546 66.826520274
   -25.44433593 65.412588787
   -23.62060546 63.470144746
   -11.32690429 51.815406979
   -10.72265625 51.303145259
    -9.82177734 51.027576337
    -9.79980468 43.047481534
    -9.97558593 39.141422170
    -9.47021484 37.136964796
    -9.33013916 36.853984790
    -9.28344726 36.785824981
END
END

Laufzeit: ca. 30 Minuten

Hallo Chris,

vielen Dank für das Skript, das sieht ja überraschend einfach aus, war auch so auf der Homepage beschrieben.
Mit osmupdate --help 2>osmupdate_help.txt habe ich mir dann noch die Parameter ausgeben lassen, die auf der Homepage fehlen.

Jetzt steht somit einem Update-Lauf nichts mehr im Wege, außer dass mein letzter Europa Extrakt schon wieder 1 Monat alt ist.
Da ich demnächst auch noch Asien benötige, sollte ich dann gleich auf planet.osm umstellen.

Leider gibt es zur Zeit recht viele unterschiedliche Formate.

.osm ist wohl das Original-Fomat, das jede SW versteht.

.osm.pbf ist schön kompakt und wird auch von mkgmap inzwischen verstanden. Für JOSM soll es ein Plug-In dafür geben.
Wo kann man denn planet.osm.pbf herunterladen, oder muss man sich das selbst einmal konvertieren.

.o5m scheint neu zu sein und etwas größer als das pbf-Format. Was ist denn der Vorteil von o5m gegenüber pbf und welche Tools können damit umgehen?

Falls alle Formate den gleichen Inhalt haben, dann müsste man sie ja jeweils verlustlos umwandeln können, oder gehen bei manchen Formaten Daten verloren.

Hallo Henning,

wenn ich das richtig gelesen habe, dann kann Osmconvert mit allen bekannten Formaten umgehen.
Hast du schon mal versucht, mit Osmupdate im osm-Format zu aktualisieren und dieses Ergebnis weiter zu verwenden.
Ev. treten die Format-Probleme ja nur dann auf, wenn du direkt im pbf-Format aktualisierst.

Walter

Na ja, o5m ist das “Hausformat” von osmconvert/osmupdate. Mittlerweile können die aber auch .pbf soweit ich weiß.

Hallo Walter,
osm ist für mich keine Alternative. Zum einen ist der planet viel zu groß (passt nicht mehr auf die ssd) und zum anderen ist die Verarbeitung deutlich langsamer. Dann hätte ich zwar einen etwas schnellere Aktualisierung aber der Rest wäre deutlich langsamer. Der Fehler tritt immer auf, wenn ich den planet mit osmconvert als pbf schreiben lasse.

Den Planet kanst du dir auf planet.osm.org laden, wobei doch für Europa auch das Extrakt der Geofabrik ausreicht.

http://planet.openstreetmap.org/pbf/

Hallo woodpeck, vielen Dank für den Link, der Download läuft bereits - bis morgen vormittags sollte das planetfile hier sein.

Hallo Henning, ich kann den Fehler mit dem pbf-Format bei Osmconvert bestätigen. mkgmap liefert folgende Fehlermeldung:

Ich denke, da sollten wir den Programmierer kontaktieren.
Mir ist auch aufgefallen, dass das neue pbf-File ca. 1% kleiner war als das 1 Monat alte File. Das deutet ebenfalls auf eine Abweichung beim Format hin.
Ich habe gerade einen Update-Lauf mit osmupdate im osm-Format gestartet, aber die Performance ist um 10er Potenzen langsamer als beim pbf-Format.

Kannst du mir bitte deine Aufrufparameter für Osmosis schicken, damit ich die Aktualisierung mal damit versuchen kann.

Danke
Walter

Korrektur am 7.1.2012: Fehler lag woanders (siehe Posting #19)

Also welches Programm hier den Fehler hat müsst ihr erstmal belegen in dem ihr Euch die Daten anschaut. pbf ist nämlich eine umfangreiche Formatdefiniton, welche nicht von allen Programmen in vollem Umfang genutzt oder verstanden wird. Zum Beispiel die Blockgröße. Hier sind meines Wissens nach mehrer Dinge möglich. Schon hier können Abweichungen zu Fehlern führen.
Jedenfalls dann wenn der Autor bisher osmosis pbf Dateien verarbeitet hat. übrigens osmosis kann mit den pbfdateien von osmconvert umgehen.

Der Vorteil von o5m ist von Marqs auch mehrfach dokumentiert. Dieses Format hat beliebige Einsprungpunkte, so dass man bei gezielter Datensuche (sortieren updaten etc.) Geschwindigkeitsvorteile. Weiterverabeiten kann man das dann aber nur mit osmconvert. Der Patch für osm2pgsql fiel leider nicht auf fruchtbaren Boden und wird daher wohl nicht weiterentwickelt.

Hallo Walter,
bei mir geht es beim splitten schon los. Die Kacheln sollten um die 20mb sein, sind aber kleiner als 1mb. Wobei splitter allerdings die richtige Anzahl an Knoten und Wegen zählt am Anfang. Die Frage ist nur, woran liegt es: osmconvert, splitter oder gar Windows?

Die Dateigröße der aktualisierten Datei ist mit osmupdate etwas kleiner, da es etwas effektiver komprimiert wird.

Was ich bisher noch nicht versucht hab ist, Datei in o5m zu aktualisieren dann nach osm mit osmconvert und dann nach pbf mit osmosis. Aber ich vermute, dass dies auch nicht wirklich Zeit spart, dafür aber jede Menge temporären Speicherplatz benötigt.

Der Update-Vorgang mit osmosis ist hier recht gut erklärt. Alles mit entpacken kannst du weglassen und den read und write im osmosis-Aufruf an pbf anpassen.

Vielleicht nochmal für das Verständnis. OSMupdate ist nur ein Programm zum Download und zur Steuerung von OSMConvert. OSMupdate sammelt also die Updates auf dem Server ein und gibt sie osmconvert um sie dann mit der Ursprungsdatei zu updaten.
Osmconvert komprimiert pbfDateien nicht. Es wird lediglich eine andere Blockgöße verwendet und noch einige Sparmöglichkeiten die in der Definition des Dateiformates vorgesehen sind.

Ein Update von o5m Dateien um sie danach in osm und dann mit osmosis im pbf zu wandeln ist eher schwierig. Zumal die osm Datei sehr groß wird. Aber du kannst ja mal versuchen ein mit osmconvert erstelltes pbf mit osmosis in pbf schreiben.

Hallo!

Ein paar Gedanken von mir:

  1. Entfernen von Metainformationen
    Die Option --drop-author ist bei .pbf nicht vorgesehen. Insbesondre im Bereich “dense nodes” kann es dabei zu Problemen kommen, mit denen nachfolgende Programme nicht umgehen können. Bitte versucht es im Zweifel ohne diese Option - auch wenn dann die Dateien etwas größer werden.

  2. Abweichende Größe bei PBF-Dateien
    Die Definition des PBF-Format liefert einigen Spielraum. Etwa können die Strings je Block sortiert gespeichert werden oder nicht. Die maximale Blockgröße von 32 MiB kann ausgenutzt werden oder nicht. Je nach Schreibprogramm werden manche dieser Optimierungen genutzt oder nicht: Osmosis optimiert das Speichern der Strings indem es sie sortiert, osmconvert tut das nicht. Dafür nutzt osmconvert die Blockgröße fast komplett aus, Osmosis speichert je Block immer nur 8000 Knoten und verschenkt dadurch ein bisschen Platz.
    Natürlich kommt es dann zu unterschiedlichen Dateilängen (osmconvert schreibt minimal kürzere PBF-Dateien als Osmosis). Aber alle Programme halten sich an die Formatdefinition, wie sie im OSM-Wiki veröffentlicht ist.

  3. Java-Exeptions von mkgmap
    Eine “NullPointerExeption” sollte nicht passieren und deutet meiner Ansicht nach erst einmal auf einen Fehler in dem Programm hin, in dem sie auftritt. Falls das Programm mit einem unzulässigen Datenformat gefüttert wird, sollte es nicht abstürzen, sondern eine einigermaßen lesbare Fehlermeldung bringen. OK, so weit die Theorie, meine Programme halten sich auch nicht immer dran. :wink:
    Wenn ich jetzt trotzdem hellsehen müsste, würde ich vermuten, dass das Problem daran liegt, dass Knoten fehlen, zu denen aber weiterhin Referenzen in Weg-Objekten enthalten sind. Das passiert, wenn man ein Gebiet ausschneidet. Solche unbefriedigten Referenzen lassen sich mit der Option --drop-broken-refs rauswerfen.

Schönes Wochenende!
Markus

Also ich habe mit osmupdate und osmconvert keine Probleme!!!

Die Fehlermeldung “NullPointerExeption” bekomme ich auch wenn ich die extrakte von geofabrik verarbeite - bis jetzt hab ich aber bei den gesplittetetn Daten keine Fehler endeckt und ignoriere diese Meldung!

Was aber oft Fehlermeldungen bei mkgmap vermeidet ist --emulate-osmosis ich verwende das immer !

osmup --daily --emulate-osmosis G:\OSM\europe.osm.pbf G:\OSM\europe-new.osm.pbf

verwende ich schon seid es osmupdate gibt und hab keine Probleme:

osmconvert --emulate-osmosis --out-pbf -B=G:\BONDARYS\germany.poly G:\OSM\europe.osm.pbf > “G:\OSM\germany.osm.pbf”

Und die Weiterverarbeitung mittels

“C:\Program Files\Java\jre6\bin\java.exe” -Xmx8192M -jar G:\Splitter\splitter.jar --overlap=200 --output=xml --max-threads=4 --description=OSM --mapid=63840001 --cache=G:\TMP G:\OSM\germany.osm.pbf
“C:\Program Files\Java\jre6\bin\java.exe” -ea -Xmx8192M -jar mkgmap.jar --ignore-osm-bounds --max-jobs=4 --style-file=G:\Mkgmap\resources\styles\topo --gmapsupp --latin1 TOPO.TYP OSM\63*.*

Läuft mit Ausnahme der “NullPointerExeption” Meldungen - die ich aber auch wie schon geschireben bei geofabrik auch habe!

Die option --drop-broken-refs ist zwar schön aber es entfernt doch Inhalte die man ja haben will und somit eigentlich nur für Auschnitte die einen ungenutzten Rand geeignet - was ja eigentlich bei mgkmap nicht vorkommt wenn man z.B die BONDARYs-Polys verwendet…

In meiner Werkzeugkette geht es vom europe.o5m per osmconvert ins gute alte osm.gz Format, damit
gibt’s in den folgenden Schritten (spitter, mkgmap) überhaupt keine Probleme.

Hallo Markus, vielen Dank für die Infos.

Ich kann Entwarnung geben bezüglich der Fehlermeldung von mkgmap, es war ein Fehler im Styles-File, nicht im osm-File.
Das von osmconvert erzeugte pbf-Format kann von splitter und mkgmap verarbeitet werden.

Hallo quasilotte,

vielen Dank für den Tipp, emulate-osmosis werde ich mal ausprobieren.
Die Option complex-ways soll ja auch sehr brauchbar sein.

Hallo Henning,

der Osmosis Aufruf ist ja nicht gerade trivial, da lobe ich mir osmupdate.
Du solltest bei der gesamten Toolkette die jeweils neuesten Versionen noch einmal testen,
es hat sich ja auch beim Splitter und mkgmap viel getan in letzter Zeit.

Ich werde nun versuchen, folgenden Workflow aufzusetzen.

1.) OsmUpdate: Aktualisierung von planet.o5m auf planet_new.o5m (Option: --keep-tempfiles), +rename
2.) OsmConvert: Ausschneiden von europe.o5m aus planet.o5m (Option: --complex-ways)
3.) OsmConvert: Umwandlung von europe.o5m nach europe.osm.pbf (Option: --emulate-osmosis)
4.) splitter + mkgmap

Mal sehen, ob der Ablauf so funktioniert.
Gibt es noch weitere Optionen von OsmUpdate/Convert, die ich übersehen habe?

Walter

Ich weiß nicht genau. Aber wenn ich das richtig verstanden habe schleust osmupdate alle nicht selbstverstandenen Parameter gleich an osmconvert weiter. Außerdem spart die Zusammenfassung von Schritt zwei und drei auf jeden Fall sehr viel kostbare Zeit.