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.
Grüße
Mario
@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…
Wie genau hast du denn die Höhendaten erzeugt ?
Welchen gcc verwendest Du? (gcc --version)
“-march=native” sollte schon lange (http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33115) unter Apple funktionokeln.
Dein Bugreport bezieht sich auf eine Lösung für Version 4.3.0 aus dem Jahr 2007.
Ich sollte meine Entwicklingsumgebung doch mal langsam aktualisieren. 
Edbert (EvanE)
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.
Hi,
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.
Grüße
Mario
Das Problem ist, dass es halt nicht ganz hinhaut
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:
$ stat *
File: „hgt"
Size: 4096 Blocks: 8 IO Block: 4096 Verzeichnis
Device: fe01h/65025d Inode: 6955390 Links: 3
Access: (0755/drwxr-xr-x) Uid: ( 1000/ user) Gid: ( 1000/ user)
Access: 2012-01-06 09:12:42.000000000 +0100
Modify: 2012-01-06 09:12:42.000000000 +0100
Change: 2012-01-06 09:12:42.000000000 +0100
File: „lon10.98_11.00lat48.98_49.00_srtm3.osm"
Size: 21953 Blocks: 48 IO Block: 4096 reguläre Datei
Device: fe01h/65025d Inode: 6955398 Links: 1
Access: (0644/-rw-r--r--) Uid: ( 1000/ user) Gid: ( 1000/ user)
Access: 2012-01-06 09:13:09.000000000 +0100
Modify: 2012-01-06 09:13:09.000000000 +0100
Change: 2012-01-06 09:13:09.000000000 +0100
File: „lon10.98_11.00lat49.00_49.02_srtm3.osm"
Size: 30566 Blocks: 64 IO Block: 4096 reguläre Datei
Device: fe01h/65025d Inode: 6955416 Links: 1
Access: (0644/-rw-r--r--) Uid: ( 1000/ user) Gid: ( 1000/ user)
Access: 2012-01-06 09:13:09.000000000 +0100
Modify: 2012-01-06 09:13:09.000000000 +0100
Change: 2012-01-06 09:13:09.000000000 +0100
File: „lon11.00_11.02lat48.98_49.00_srtm3.osm"
Size: 30963 Blocks: 64 IO Block: 4096 reguläre Datei
Device: fe01h/65025d Inode: 6955415 Links: 1
Access: (0644/-rw-r--r--) Uid: ( 1000/ user) Gid: ( 1000/ user)
Access: 2012-01-06 09:13:09.000000000 +0100
Modify: 2012-01-06 09:13:09.000000000 +0100
Change: 2012-01-06 09:13:09.000000000 +0100
File: „lon11.00_11.02lat49.00_49.02_srtm3.osm"
Size: 26553 Blocks: 56 IO Block: 4096 reguläre Datei
Device: fe01h/65025d Inode: 6955417 Links: 1
Access: (0644/-rw-r--r--) Uid: ( 1000/ user) Gid: ( 1000/ user)
Access: 2012-01-06 09:13:09.000000000 +0100
Modify: 2012-01-06 09:13:09.000000000 +0100
Change: 2012-01-06 09:13:09.000000000 +0100
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.
Link: http://dl.dropbox.com/u/1677057/process_phyghtmap_data.pl
Benutzung: process_phyghtmap_data.pl lon*
Man erhält eine Ergebnisdatei mit dem Namen “phyghtmap_result.osm”.
Klaus
Hallo Klaus,
sehr schön, geht ab wie eine Rakete 
Der Loop bei meinen skript war sehr “clever”, richtig reingeswappt.
Daher umgeschwenkt auf
osmconvert lon*.osm --drop-nodes --out-o5m > w.o5m 2> /dev/null
osmconvert lon*.osm --drop-ways --out-o5m > n.o5m 2> /dev/null
osmconvert n.o5m w.o5m > all.osm
Braucht aber immer noch 2x so lang wie Deine perl-Variante.
Tja, das hat er leider uns nicht mitgeteilt, der liebe, gute extremecarver 
Wir können aus seinen posts nur vermuten, dass es etwas in der Art
$ phyghtmap --area=5.5:45.2:16.7:48.7 --gzip --jobs=1 --max-nodes=250 --osm-version=0.6 --start-node-id=10000000 --step=20 --viewfinder-mask=1
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:
phyghtmap --area=6:44:9:47 --jobs=1 --osm-version=0.6 --step=20 --viewfinder-mask=1
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.
Über diese Aussage bin ich immer wieder gestolpert. Experimentieren ergab, wenn man unsortierte Daten verwendet,
braucht osmconvert 10x so lang beim pbf-Erstellen als mit richtig sortierten Dateien => stets sortierte Daten für osmconvert benutzen.
osmconvert kann aus unsortierten Daten Polygone schneiden und die unsortierten Daten auch in andere Formate konvertieren,
bei “mergen” geht’s jedoch schief:
Seien a.osm, b.osm, c.osm unsortiert, so ist
osmconvert a.osm b.osm c.osm > d.osm
fehlerhaft, denn es fehlen nodes.
=> stets sortierte Daten für osmconvert benutzen.
Ja, das sehe ich genauso und hatte letzte Woche (05.01.) den Programmautor diesbezüglich angeschrieben.
…
Wäre es möglich nur eine (große) Ergebnisdatei statt vieler kleiner zu erzeugen ?
Würde dies eine Qualitätssteigerung, z.B. an den Kachelgrenzen, darstellen?
…
Ich stelle das Ergebnis einer Rückantwort dann hier ein.
Klaus
PS: Dass das Perl-Skript genauso performant ist, wie Marios Shell-Skript wundert mich allerdings - aber gut.
$ phyghtmap --area=5.5:45.2:16.7:48.7 --gzip --jobs=1 --max-nodes=250 --osm-version=0.6 --start-node-id=20000000 --step=20 --viewfinder-mask=1
jip, ähnlich. Poste das Korrekte Morgen. Hab zusätzlich noch eine srtm3 Datei durch eine viewfinders3 ausgetauscht. Denke aber nicht dass es daran liegt. Meine phyghtmap hat die patches von kukuk - sowie eine Änderung wo ich die node Zahl von 100.000 auf 100.000.000 hochgesetzt - sonst ident. Poste Morgen nochmal meine komplette Toolchain inkl. Sources.
Der Wert für “–start-node-id=20000000” ist zu klein, es sei denn deine Patches modifizieren intern den Wert.
Besser (weil kollisionsfrei zu OSM-IDs) wäre das: --start-node-id=2000000000
Klaus
Mein vollständiger Aufruf:
phyghtmap --step=25 --osm-version=0.6 --jobs=1 --area=-19:27:-12:30 --line-cat=500,250 --viewfinder-mask=3 --start-node-id=2000000000
Ich habe nicht vor die Daten zu mergen - daher sollte die start-node-id ziemlich egal sein.
Hier ist mein phyghtmap Aufruf:
phyghtmap --jobs=1 --osm-version=0.6 --area=5.56214:45.24627:16.68790:48.65879 --step=20 --output-prefix=alps --line-cat=500,100 --viewfinder-mask=1 --max-nodes=250 --gzip
– Daten passen zum Alpenextrakt von Geofabrik. Platzbedarf ungepackt 17GB. RAM braucht man nicht so viel. osmconvert war nach umbearbeitung eigentlich recht schnell.
Hallo,
ab und an nutze ich in JOSM den Hill-Layer von Nop’s Reit- und Wanderkarte [1], kombiniert mit einem OSM Mapnik Hintergrund [2]. Wenn ich für das gleiche Gebiet Höhenlinien mit phyghtmap erzeuge, liegen diese etwa 50m Richtung NW versetzt. Die Umrisse der Höhenlinien sehen dagegen auf den ersten Blick gleich aus. Beide Höhenlinien stammen wohl aus der gleichen Quelle.
Wodurch entstehen diese Abweichungen?
Getestet mit phyghtmap 1.25 im Gebiet 6.7793889,49.3146251,6.7921776,49.3199614, Schrittweite 10.
Gruß,
mmd
[1] tms:http://www.wanderreitkarte.de/hills/{zoom}/{x}/{y}.png
[2] tms:http://tile.openstreetmap.org/{zoom}/{x}/{y}.png
In Version 1.25 ist ein neuer Parameter enthalten: --max-nodes
Allerdings nicht im Sinne von Thomas Patch fuer ways, sondern die Gesamtzahl der nodes pro tile.
Nicht verwirren lassen
