klar, die beiden Zeilen lassen sich zusammenfassen.
Also die Option complex-ways war eine schöne Falle, ohne diese Option geht es jetzt.
Morgen werde ich mal das komplette Script durchlaufen lassen und dabei stufenweise ausschneiden.
Bei den letzten Cuts kann ich dann complex-ways auch wieder verwenden, denn dann bin ich ja weit unter 2GB.
Rückblickend betrachtet bin ich nun froh, dass ich mich mit osmosis in den letzen Jahren nicht tiefer beschäftigt habe, und nun gleich OsmConvert, OsmFilter und OsmUpdate verwenden darf. Für mich kommen diese Tools daher wie gerufen.
Nochmals einen großen Dank an Markus für diese tollen Tools, damit geht vieles nun bedeutend leichter (und auch schneller).
OsmUpdate und OsmConvert laufen wie erwartet problemlos, auch die Garmin-Maps lassen sich mit dem Output generieren.
Die optimale Lösung war doch nicht, Update auf planet + crop auf Ausschnitte,
sondern (eigentlich eh klar) Update auf alle benötigten Ausschnitte,
da dann immer nur die Diff-Daten gecropt werden müssen.
Bei OsmUpdate kann man als Parameter angeben, ob man als Intervall daily, hourly, minutely haben möchte.
Ich hätte mir erwartet, dass bei hourly alle daily update + die letzten hourly updates durchgeführt werden.
Das scheint nicht so zu sein, die SW macht in diesem Fall nur hourly updates, auch über die letzten Tage.
Das ist zwar kein Problem, war halt nur unerwartet - vielleicht habe ich ja auch noch irgendwo einen Fehler im Aufruf.
Noch etwas zur Filegröße.
planet.o5m: 28 GB
europe.o5m: 13 GB
Updatelauf (auf ca. 5 Jahre altem PC): 0,5 GB / min
Das ergibt somit eine deutliche Einsparung gebenüber einem regelmäßigen Download.
Die pbf-Files sind zwar nur 1/2 so groß wie die o5m-Files, ein Update dauert damit trotzdem ca. doppelt so lange.
Selbst die anschl. Umwandlung von o5m nach pbf ist unterm Strich immer noch eine Zeitersparnis.
da ich mich selbst bald damit beschäftigen möchte - wenn auch in kleinerem Maßstab -, erstmal Danke für Deine Infos.
Macht es daher bei größeren Update-Abständen evtl. Sinn, im Script ständig
erst ein Daily-Update
danach das Hourly-Update
aufzurufen?
Inklusive Download?
Das würde bedeuten >66 Mbit/s-Anbindung - Respekt!
Was erwartet mich dann bei meiner ländlichen 1,3 Mbit-Anbindung … Rein rechnerisch schaffe ich Europa wohl nicht mehr täglich - zum Glück will ich ja erstmal wesentlich kleinere Karten backen.
— Edit: Blödsinn, das World-Diff ist doch hoffentlich wesentlich kleiner - oder … Aber für grenzüberschreitenden Verkehr (Deutschland/Skandinavien) kommt man um Europa wohl nicht herum, oder?
— Edit: Diff ist ja sowieso weltweit - und muss anschließend gecropt werden
Wenn man osmupdate aufruft ohne auf Daily oder hourly einzuschränken, dann holt sich osmupdate erst die Daily danach die hourly und zum schluss die minutley updates. Damit hat man dann den zu diesem Zeitpunkt aktuellsten Planet oder ebend Ausschnitt.
Außerdem:
For updates every few hours, you usually would not need minutely changefiles. So please consider applying this option:
--hourly --daily
ich dachte mir, dass ich einen Fehler bei den Parametern hatte.
Also mit --hourly --daily macht es genau das, was ich erwartet habe.
Danke für den Hinweis.
Hallo Georg,
die Tages-Diffs sind 30-60 MB
die Stunden-Diffs bis zu 4 MB
und die Minuten-Diffs 20-80 kB
Hallo,
also das Programm osmupdate ist ne tolle Sache, hab bis jetzt immer manuell mit osmosis das File aktuell gehalten.
Osmupdate macht das durch den selbstständigen Download natürlich noch einfacher ==> aber wieso fehlt immer der letzte Tag
verwende folgenden Aufruf
.\osmup.exe --daily --emulate-osmosis --keep-tempfiles -v -b=%box% %osm% lausitz.pbf
wenn ich den Heute 18.01. starte werden nur die daily bis 16.01. geholt also der 17.01. fehlt noch, WISO?
wenn ich
.\osmup.exe --hourly --daily --emulate-osmosis --keep-tempfiles -v -b=%box% %osm% lausitz.pbf
das nehme werden dann für den 17.01. und den 18.01. alle Stunden Files gezogen.
Gibt es den Tag vorher noch nicht als daily oder warum ist das so?
Vorher habe ich mir hier immer die Updates geholt http://planet.openstreetmap.org/daily/ damit hatte ich auch immer den vorherigen Tag mit drin.
@aighes
Also bei mir läuft die so entstandene *.pbf problemlos durch den Splitter und auch durch mkgmap
Ich habe das nicht getestet, aber den Quellcode gelesen und hoffentlich richtig interpretiert.
edit:
Das geht aber nur bei --minutely und --hourly.
Bei --daily (und evtl. ohne Angabe) nicht, da history/* unter redaction-period/ nicht zur Verfügung steht, diese Dateien werden anscheinend zurzeit nicht erstellt.
history/* hat eine andere Benennung der Dateien, somit ist day-replicate/* wahrscheinlich ohne Anpassungen kein Ersatz.
versucht, das funktioniert solange man als timestamp < 31.3.2012 mitgibt,
die update-Datein werden brav heruntergeladen.
Ich vermute das es eher daran liegt das unter /history die Timestamp.txt folgendes enthält:
2012-03-31T00:00:00Z !!
und somit gibt es bei korrekten Timestamp = 2012-04-08T23:30:00Z meiner europe.osm.pbf
die Meldung von osmupdate:
D:\maps\OSM_Data>update_europe.bat
D:\maps\OSM_Data\europe.osm.pbf.old konnte nicht gefunden werden
osmupdate Parameter: --daily
osmupdate Parameter: -B=euro.poly
osmupdate Parameter: --planet-url=http://planet.openstreetmap.org/
osmupdate Parameter: europe.osm.pbf
osmupdate Parameter: 2012-04-08T23:30:00Z
osmupdate Parameter: europe2.osm.pbf
osmupdate: newest daily timestamp: 2012-03-31T00:00:00Z
osmupdate: Your OSM file is already up-to-date.
Das System kann die angegebene Datei nicht finden.
Drücken Sie eine beliebige Taste . . .
@echo off
del europe.osm.pbf.old
osmupdate -v --daily -B=euro.poly --planet-url=http://planet.openstreetmap.org/ europe.osm.pbf 2012-04-08T23:30:00Z europe2.osm.pbf
if exist europe2.osm.pbf rename europe.osm.pbf europe.osm.pbf.old
rename europe2.osm.pbf europe.osm.pbf
pause
Im /day-replicate sind sowohl die state als auch die Updates selbst auf neuesten Stand.
Ist das ein Fehler, und wenn ja wen kann man das näher bringen?
Selbst wenn man die man Programmtechnisch auf die letzte state.txt umprogrammiert wird versucht ein anderes osc.gz zu laden (keine lußt mir das auch noch Programmtechnisch umzubiegen um dann vielleicht in 2Tagen endlich die Lizenzumstellung zu erleben)
Ich selbst mache mommentan das update “manuell” mit osmconvert
Weis zwar nicht ob das so Richtig ist aber um die Daten aktuell zu halten scheint das so zu gehen (und nein ich nehme nicht OSMOSIS !!! und werde es auch nicht!)
Da dort nur die Daten bis zum 31.3.2012 zu finden sind, ist auch nichts anderes zu erwarten.
Es gibt unter “/history” nur alte Daten bis zum 31.3.2012 und genau das ist auch so beabsichtigt.
Auf dem Server ist alles in Ordnung.
Ja, aber für was sollte das gut sein?
Neue Daten gibt es unter “/history” trotzdem nicht.
Ich habe auf meine abgelaufene Milch das Datum von übermorgen geschrieben, trotzdem schmeckt diese immer noch so seltsam.
Was kann ich da machen?
Jei nun, Osmupdate greift aber scheinbar auf genau dieses File auf dem Server zu
um den VersionsStand abzugleichen.
Wie auch immer, kennst Du eine Möglichkeit Osmupdate wieder zum Laufen zu bringen,
bis jetzt war das eine feine Methode bei limitierter Datenquote die europe.osm auf Stand
zu halten.
Ich mache mir öfter eine Garmin-Karte mit Deutschland + ca. 50 km + Island und habe dazu bisher immer die europe.osm.pbf von der Geofabrik benutzt und mit osmconvert und Polygon-File entsprechend ausgeschnitten. Jetzt update ich nur noch meinen bereits vorhandenen .osm.pbf-Datensatz unter Benutzung des Polygon-Files. Ich spare jede Menge Traffic!
Gerne doch, meine Batchdatei “update.bat” sieht wie folgt aus:
@echo off
set http_proxy=http://localhost:8888
osmupdate --daily --planet-url=http://planet.openstreetmap.org/redaction-period/ OSM-Data\germany+iceland.osm.pbf OSM-Data\germany+iceland-new.osm.pbf -B=germany+iceland.poly -v
Wobei die 2. Zeile nur bei mir nötig ist, da ich einen lokalen Proxy auf Port 8888 habe, über den wget ins Internet gelangt. Dazu muß die aktuelle Version von osmupdate UND osmconvert sowie wget im Pfad verfügbar sein. Die erste Datei (germany+iceland.osm.pbf) ist der vorhandene Datenbestand, die zweite Datei (germany+iceland-new.osm.pbf) ist dann die upgedatete Version.
Edit:
Ich vergaß: Ich habe noch eine Polygondatei (germany+iceland.poly), die den gewünschten Kartenausschnitt beschreibt.
Wo spare ich dabei den Traffic?
Es wird doch immer die komplette daily(s) meist so 40MB pro Tag) geladen
Einzig die einzupfelgenden daten werden doch dadurch reduziert!
Nun, für mich ist es schon ein gewaltiger Unterschied, ob ich die 40 MB Planet-Change-File oder die 7,9 GB des kompletten europe-Abzug TÄGLICH herunterlade, oder etwa nicht?
- damit auch Andere in den genuß kommen ! Jede Menge Traffic zu sparen!