Allerdings phyghtmap gepatched um von vornherein etwas weniger Tiles zu produzieren (1 pro Input – einfach nach 100.000 suchen im Sourcecode und 3 Nullen anhängen).
Dann mergen und sort per Skript
Anschließend mit osmconvert das osm file in ein osm.pbf umformatieren. Osmosis produziert allerdings auch mit obigem Skript sortierten File nur Fehlermeldungen…
Muss sagen - ist schon ziemlich umständlich das ganze ohne srtm2osm.
Außerdem spuckt osmconvert einige Fehlermedungen von wegen wrong sequence aus - scheint derzeit aber zu funktionieren und braucht viel weniger Speicher wie bei Benutzung von vielen Einzelfiles. Muss noch überprüfen ob der pbf output auch verwendbar ist.
20m…
(benutze ich für europaweit, außer Benelux).
BTW osmconvert für osm nach pbf ist extrem langsam. Etwa 1/4 der Geschwindigkeit die phyghtmap braucht - für Alpen wird mein Rechner also etwa 4 Stunden brauchen zum konvertierne - vs 1 Stunde die phyghtmap braucht. An einem Perl-Skript was zuverlässiger ist wäre ich auch interessiert - wobei schlauer wäre wohl phyghtmap entsprechend zu patchen, so dass dieser Schritt entfällt (dann bräuchte man nicht mal den mgkmap-splitter, da man die max-nodes ja im Sourcecode vorm kompilieren entsprechend anpassen kann), am besten wäre ja pbf support für phyghtmap.
ups zu früh gefreut… osm.pbf ist grad mal 420MB groß, da wird wohl ein Fehler vorliegen (Originaldatei 17GB). Mal schauen - lasse gerade mal splitter/und mkgmap drüberlaufen.
Das ist jetzt mal der Output von osmconvert:
openSUSE-114-64-minimal:/home/contourlines # ./osmconvert alps3.osm -o=alps3.osm.pbf
osmconvert Warning: wrong sequence at node 61343367
osmconvert Warning: next object is node 42707657
osmconvert Warning: wrong sequence at way 61343368
osmconvert Warning: next object is way 42707669
Allerdings unterschlägt osmconvert diese Warnings soweit ich sehen konnte sehr gerne nachdes es ein paar gemeldet hat…
Jip, und osmconvert hat auch irgendeinen Schrott gebaut. Die Daten lassen sich zwar splitten - aber mkgmap akzeptiert sie nicht:
Error parsing file
Error at line 1, col 1
Bad file format: 75280000.osm.pbf
usw…
Das ganze passiert auch schon mit dem ungesplitteten osmconvert Output:
Error parsing file
Error at line 1, col 1
Bad file format: alps3.osm.pbf
Error parsing file
Exception in thread “main” java.lang.NullPointerException
at uk.me.parabola.mkgmap.combiners.FileInfo.getFileInfo(FileInfo.java:139)
at uk.me.parabola.mkgmap.main.Main.endOptions(Main.java:413)
at uk.me.parabola.mkgmap.CommandArgsReader.readArgs(CommandArgsReader.java:126)
at uk.me.parabola.mkgmap.main.Main.main(Main.java:112)
Das Problem scheint nicht osmconvert zu sein, sondern der Konvertierskript. Weil auch die 17GB osm Datei die daraus entstanden ist - funktioniert nicht mehr mit mkgmap.
Kannst du dein perl Skript mal irgendwo hochladen?
(die Grunddaten sind okay, weil die kann ich ungesplittet mkgmap vorlegen ohne Probleme)
Das (ich glaube, von meinem abgewandelte) Script auf http://osm.thkukuk.de/srtm.html sortiert die Daten nicht so wie ich es mache. Vielleicht ist das der Grund und osmconvert braucht unbedingt sortierte Daten - erst die Nodes nach ID, dann die Ways nach ID. Zumindest sollte aber der Tile-Splitter mit dem Schalter “–mixed” mit den Daten klarkommen.
@Mario – genau Dein Skript hatte ich aber sogar genommen. Werde es nochmal mit dem vom Kukuk versuchen - aber mir sah es vom Prinzip her gleich aus, bis darauf dass der Content nicht compressed ist. Schneller als das perl Skript ist es auf jeden Fall…
Aber so groß ist der Unterschied auch nicht. Bin grad am converten des outputs vom perl skript mit osmconvert - allerdings auch da schon wieder Errors.
Sollte der splitter eigentlich bei korrekt sortierten Daten auch ohne --mixed klarkommen?
Bei Bedarf kann ich ja eine Erläuterung zu meinem Script geben, vielleicht kann man dabei Denkfehler wegen der Datenstruktur aufdecken. Das müsste aber bis morgen warten.
Und ja, bei meinem Script kommt der Splitter auch ohne --mixed aus.
Muss jetzt los.
PS: Für sowas würde sich auch die Diskussionsseite anbieten.
Bummer - das Perl Skript von toc-rox funktioniert genauso wenig… Selber Fehler.
So werde jetzt erstmal aufgeben. Scheinbar funktioniert keines der drei Skripte fehlerfrei, bzw kommt mit den Daten zurecht. Wenn ich die Daten allerdings direkt verarbeite mit mkgmap gibt es keine Probleme.
Probiere grad noch das Skript von kukuk aus - aber erwarte hier auch keine Besserung…
Mmh, hab’ mir das mal an einem Mini-Beispiel angeschaut:
$ phyghtmap -a 10.98:48.98:11.02:49.02 --osm-version=0.6
Wenn ich das richtig sehe, sind bei den 4 entstandenen osm-Dateien nur nodes & ways intermittierend, die Reihenfolge
der nodes (bzw. ways) selbst aber ok.
Somit jene gefiltert und die daraus 8 generierten Dateien wieder zusammengemanscht:
#!/bin/sh
for i in *.osm
do
osmconvert $i --drop-nodes --out-o5m > $i.w.o5m 2> /dev/null
osmconvert $i --drop-ways --out-o5m > $i.n.o5m 2> /dev/null
done
osmconvert *.o5m --out-pbf > all.osm.pbf
all.osm.pbf resp. all.osm sollten komplett richtig sortiert sein.
Keine Ahnung, ob das auch bei den Alpen klappt
Edit:
Hab’ mir mal auch im wiki das skript von Marco “Kleiner Einschub - Sort und Merge der Höhendaten” angeschaut.
Die Stelle
ls -t -r lonlat.osm
ist IMHO nicht ganz korrekt, es wird zwar zwischen Nodes und Ways unterschieden, aber jene nicht in richtiger Reihenfolge.
Bei meinem
lon10.98_11.00lat48.98_49.00_srtm3.osm (1)
lon10.98_11.00lat49.00_49.02_srtm3.osm (2)
lon11.00_11.02lat48.98_49.00_srtm3.osm (3)
lon11.00_11.02lat49.00_49.02_srtm3.osm (4)
gilt eben nicht die ID-Reihenfolge (4) - (3) - (2) - (1),
sondern (4) - (2) - (3) - (1), nur so als Beispiel.
bei mir wird die Reihenfolge der IDs korrekt eingehalten. Vor paar Tagen erst habe ich “filelist=$(ls -t -r lonlat.osm)” eingefügt (vorher hatte ich einfach eine Datei nach der anderen eingelesen, was dann alphabetisch nach Dateiname war). Die Option “-t -r” bewirkt ja erst das Auflisten der Dateien in die Variable in der Reihenfolge nach Erstellungszeit (-t = time und -r = reverse = älteste zuerst). Dies korreliert mit dem Aufsteigen der IDs aufgrund des (sowieso nötigen) Schalters --jobs=1 in Phyhtmap.
Aber nach meiner Erfahrung ist die Reihenfolge unwichtig, zumindest dem Mkgmap-Splitter. Die Splits, ob mit sortierten oder unsortierten Daten haben die gleiche Größe. Beim Schreiben des Scripts habe ich sogar mit einem umständlichen Osmosis-Merge verglichen - ist identisch bis auf den Umstand, dass Osmosis alle Tags in Langform umschreibt - aber nach Splitten wieder absolut gleiches Ergebnis.
Du machst Dir ein neues Verzechnis (mkdir test; cd test), kopierst die HGT-Dateien rein (cp -r …/hgt .) und legst los mit
$ phyghtmap -a 10.98:48.98:11.02:49.02 --osm-version=0.6
Und jetzt lässt Du Dir die Änderungszeiten aller Dateien anzeigen:
Die 4 osm-Dateien haben den gleichen (Modify)-Zeitstempel, so dass “ls -t -r” doch wieder alphabetisch sortieren muss
osmconvert braucht halt eine vollständig korrekt sortierte Datei, wenn es keine “wrong sequence …” ausgeben soll.
Beim o. g. mini-shell skript “choked” osmconvert noch (deshalb Unterdrückung mittels “2> /dev/null”, die entstehenden
“nodes-only”- bzw. “ways-only” sind aber bereits korrekt (hoffentlich ;), so dass das letzte “osmconvert *.o5m …” ohne
Schluckauf funktionokelt.
Ich stelle dann hier doch mal die Beta-Version des Perl-Utilities zur Verfügung.
Das Utility interessiert überhaupt nicht für die Timestamps der Dateien,
sondern baut eine Hashmap mit der jeweils ersten ID aus jeder Datei auf.
Diese Hashmap wird anschließend sortiert abgearbeitet.
Wichtig ist jedoch (wie auch schon von Marco erwähnt) bei phyghtmap die Option “–jobs=1” zu setzen.
Hierdurch wird sichergestellt, daß die IDs in allen erzeugten lon*-Dateien fortlaufend sind.
war.
Meinem armen, kleinen Netbook (1/12 RAM von extremecarvers Kiste) wollt’ ich die 18 GB (oder so) nicht antun und hab’ mich so auf die Hochalpen beschränkt:
Das Perl-Skript von Klaus bzw. das Shell-Skript von Mario generieren (gleichschnell aus den 103 osm-Dateien
jeweils ein ca. 6 GB große osm-file. Die Sortierung hab’ ich geprüft wie folgt:
osmconvert --out-statistics phyghtmap_result.osm
bzw.
osmconvert --out-statistics topo.osm
In beiden Fällen gab es keine “wrong order/wrong sequence”-Warnung. Dann für beide Fälle
problemlos jeweils ein pbf generiert ( 5.8 GB → 148 MB !) und aus jenen per “omsconvert -B=geneve.poly …”
Genf extrahiert ohne Fehlermeldung und dieses kurz in JOSM angeschaut.
splitter/mkgmap wurde nicht gestestet, da nicht der Garmin-Fraktion angehörend
Denke nicht, dass von 6 GB auf 18 GB sich etwas grundsätzlich ändert, so vermute ich den Fehler woanders.
Debian 6, phyghtmap 1.24 (ohne patches)
EDIT:
Nett wäre es, wenn phyghtmap einen Parameter “–single-file” hätte, bei welchem es eine Art “phyghtmap_result.osm”
generieren würde, indem es 2 temporäre Dateien mit nur ways resp. nur nodes benutzt und jene am Schluß konkateniert.
Dann bräuchte man keine “merge-scripte” mehr und osmconvert könnte das “singe-file” sehr platzsparend nach
pbf konvertieren, da sich in diesem Format die Höhendaten extrem gut packen lassen, besser als mit gzip.
aus den 103 osm-Dateien