SRTM Höhenlinien für Garmin-Karten erstellen

Hallo Walter,

meine Höhenlinien mache ich mit Phyghtmap - das sollte aber egal sein, wenn die OSM-konvertierten Rohdaten aus beiden Programmen in Ordnung sind.

Auch bei meinem Vorgehen habe ich dann mehrere Quelldateien, allerdings im OSM-Format. Diese merge ich dann per Shellscript (dauert ca. 3 Minuten für DACH/CZ) und auf das eine Gesamtfile setze ich den Splitter an, allerdings ohne Optionen - der Default entspricht dann: Overlap=0, keep-complete=true, Resolution 13 (was Letzteres bewirkt habe ich all die Jahre nicht verstanden, lediglich die Ausrichtung der Kachelgrenzen an 1024/2048-er Garmin-Units wird beeinflusst, nicht die Genauigkeit der Daten).

Zum Nachlesen: http://wiki.openstreetmap.org/wiki/User … 6henlinien

Grüße
Mario

Bei Phyghtmap gibts eine Option, die die Daten bereits in mkgmap gerechte Stücke auswirft. --max-nodes-per-tile=10000000 So habe ich mir den Splitterschritt gespart.

Mein Fehler am Anfang war immer die lat/lon Reihenfolge. Für Balearen sieht das richtig so aus: -a 1:38.3:4.5:40.5
Bei deinem Programm scheint die Reihenfolge anders angegeben zu werden?

Ich erzeuge meine Höhenlininien selbst in MapComposer. Das hat zwei Vorteile gegenüber mkgmap: Verbessertes Höhenmodell von CGIAR und Abrundung der Linien mit Splines.

(Zwischen)ergebnis sind ebenfalls mehrere Files mit OSM Daten, die könnte man auch weiterverarbeiten wie von Garmin-User beschrieben.

bye, Nop

So, jetzt hab ich den Fehler bei meinem Skript gefunden und beseitigt.
Die Output Daten von GroundTruth sind bereits korrekt gesplittet.
Ich muss die osm.bz2 Files nur mehr entpacken, dann kann mkgmap sie direkt verarbeiten.

Phyghtmap wäre sicher eine interessante Alternative zu GroundTruth, da man damit auch die dem1 Daten mit 30m Auflösung verarbeiten kann.
Gerade jetzt, wo die genauen NASA Daten auch für Europa freigegeben werden, wäre das ein großer Vorteil.
Der Unterschied ist schon gewaltig.
https://www.mapbox.com/blog/south-ameri … in-update/

Selbst die verbesserten CGIAR Daten basieren auf der schlechten 90m Auflösung.
Wenn GroundTruth hier nicht nachzieht und von dem3 auf dem1 umsteigt werde ich die Installation von Phyton unter Windows mal wagen.

Der MapComposer ist sicher die eleganteste Art der Planerstellung, da alles unter einer grafischen Oberfläche zusammengefasst ist.
Leider war damals das Routing damit nicht möglich, und ich bin auf eigene Skripts umgestiegen.
Heute habe ich eine umfangreiche Skriptsammlung, die zwar grafisch nicht an den Composer heranreicht, aber für meine Anforderungen optimal ist.

Walter

Walter Schlögl wrote:

Selbst die verbesserten CGIAR Daten basieren auf der schlechten 90m Auflösung.
Wenn GroundTruth hier nicht nachzieht und von dem3 auf dem1 umsteigt werde ich die Installation von Phyton unter Windows mal wagen.

Über die Nachricht mit den 30m Daten hatte ich mich auch gefreut. Allerdings nur sehr kurz, dann habe ich mich erinnert wie lausig und lückenhaft die SRTM Daten im Gebirge waren. Daran ändert auch die Erhöhung der Auflösung nichts.

Bestes Beispiel war dieser abschüssige See mit mehr als 400m Gefälle in den SRTM Daten - das perfekte Wasserskigebiet. :-)

Von daher kann ich auf unkorrigierte SRTM Daten getrost verzichten, egal ob 90m oder 30m. :-)

bye, Nop

Walter Schlögl wrote:

Gerade jetzt, wo die genauen NASA Daten auch für Europa freigegeben werden, wäre das ein großer Vorteil. Der Unterschied ist schon gewaltig.

"Gewaltiger Unterschied" ... ja ... besonders im Flachland ... dort sind die Linien meist stark "verrauscht" und bedürfen einer Glättung. Also deine Euphorie kann ich nicht so recht teilen teilen.

Gruß Klaus

Hallo Nop und Klaus,

das ist richtig, wir müssen noch darauf warten, dass auch die jetzt freigegebenen dem1 Daten korrigiert werden.
ViewFinderPanoramas hat das bisher erst für Skandinavien und die Alpen erledigt.

Bei den dem3 Daten hat es mehrere Jahre gedauert, bis sie weltweit korrigiert waren.
Mal sehen, ob es bei den dem1 Daten jetzt länger dauert oder schneller geht.

Bis dahin gibt es vermutlich auch eine GroundTruth Version, die dem1 Daten verarbeiten kann.
Immerhin wurde der entsprechende Code bereits 2009 testhalber implementiert.

Walter

Walter Schlögl wrote:

... wir müssen noch darauf warten, dass auch die jetzt freigegebenen dem1 Daten korrigiert werden. ViewFinderPanoramas hat das bisher erst für Skandinavien und die Alpen erledigt.

Zwei Hinweise:
- Für den Großteil von Skandinavien (nördlich 60 Grad) gibt es keine SRTM-Daten.
- Auch die Daten für die Alpen sind nicht von den SRTM-Daten abgeleitet.

Gruß Klaus

Nach den Rückmeldungen hier über den Einsatz von phyghtmap habe ich mich nun aufgerafft und Python unter Windows installiert.
Es war nicht so aufwändig wie befürchtet und hat sich auf alle Fälle gelohnt.
http://wiki.openstreetmap.org/wiki/DE:Phyghtmap

GroundTruth kann nur die srtm3 Daten der NASA herunterladen, die korrigierten dem3 Daten von ViewFinderPanoramas muss man dann selbst darunterschummeln.
Mein Skript hat diese Daten zwar automatisch aus vorab heruntergeladenen zip-Files extrahiert, aber auch das Skript muss man ja erst mal erstellen.

phyghtmap kann zusätzlich srtm1 Daten der NASA und ViewFinderPanoramas dem3 und dem1 Daten automatisch herunterladen.
Wenn ich das gewusst hätte, wäre ich vermutlich schon früher umgestiegen.

--source=view1,srtm1,view3,srtm3 bevorzugt unkorrigierte dem1 Daten vor korrigierten dem3 Daten (im Gebirge empfehlenswert)
--source=view1,view3,srtm1,srtm3 bevorzugt die korrigierten Daten, selbst wenn sie gröber aufgelöst sind (an Küsten empfehlenswert)
--o5m erzeugt bereits gesplittete Files für mkgmap

GroundTruth erstellt zwar auch gesplittete Contours*.osm.bz2 Files, ohne diese noch zu entpacken kann mkgmap sie aber nicht verarbeiten.

Die letzte GroundTruth Version 1.9.0.0 ist 2 Jahre alt, die letzte phyghtmap Version 1.60 ca. 5 Wochen.

Das einzige, was ich bereue ist, dass ich nicht schon früher umgestiegen bin.

Walter

Für die OpenTopoMap Garmin-Edition verwenden wir auch phyghtmap und erzeugen daraus zu allererst eine große pbf-Datei. Diese wird im Vergleich zu .osm oder .osm.bz2 von mkgmap bzw. dem splitter schneller eingelesen, da es sich um ein performantes Binärformat handelt. Sehr praktisch ist außerdem die Option von phyghtmap, eine .poly-Datei als Umgrenzung des herunterzuladenden Gebietes anzugeben, z.B. von der Geofabrik.

Unser Aufruf:

phyghtmap␣--polygon=europe.poly␣-j␣2␣-s␣10␣-0␣--source=view3␣--max-nodes-per-tile=0␣--max-nodes-per-way=0␣--pbf

Alles Weitere (inkl. Howto) ist vollständig auf Github zu finden: https://github.com/der-stefan/OpenTopoM … ter/garmin

Hallo Stefan,

es würde mich interessieren, wie groß die pbf Datei bzw. die daraus resultierende img Datei wird, wenn man europe.poly mit diesen Parametern verarbeitet.
Ich möchte das gerne mal mit meinem Ergebnis vergleichen, denn derzeit werden meine srtm.img Files von nur ca. 1/4 Teil von Europa bereits fast 3GB.

Walter

Walter Schlögl wrote:

wie groß die pbf Datei bzw. die daraus resultierende img Datei wird

Die pbf-Datei wird mit dem Europa-Polygon 4,2 GB groß. Allerdings schneiden wir aus dieser wiederum die einzelnen Länder aus, sodass ich nichts über die Gesamtgröße der img-Datei sagen kann. Eine Garmin-Datei darf ja leider nicht größer als 4 GB werden, da die Gerät nur FAT Dateisysteme lesen. 🙁

Ich habe die 32-bit Version von Python installiert, da es unter Windows manche Modul-Installer nicht für 64-bit gibt (z.B. numpy)
http://sourceforge.net/projects/numpy/f … mPy/1.9.1/

Damit werde ich ganz Europa nicht in einem Stück berechnen können.
Ich werde daher weiterhin nur kleine Teile berechnen, auch wenn der Workflow mit der Gesamt-Berechnung Vorteile hätte.
Vielleicht gibt es ja bald auch 64-bit Installer für Windows, dann kann ich immer noch umsteigen.

Walter

Ich habe jetzt einige Länder von Europa erfolgreich berechnen können.

Bei manchen Gebieten bekomme ich aber immer wieder den gleichen Fehler mit einer 1000 Zeilen langen Traceback Errormeldung.

␣File␣"build\bdist.win-amd64\egg\phyghtmap\hgt.py",␣line␣469,␣in␣chopData
File␣"build\bdist.win-amd64\egg\phyghtmap\hgt.py",␣line␣494,␣in␣chopData
File␣"build\bdist.win-amd64\egg\phyghtmap\hgt.py",␣line␣520,␣in␣__init__
File␣"build\bdist.win-amd64\egg\phyghtmap\hgt.py",␣line␣535,␣in␣getElevRange
File␣"c:\Python27_64\lib\site-packages\numpy\ma\core.py",␣line␣2460,␣in␣__call__
result␣=␣getattr(data,␣methodname)(*args,␣**params).view(cls)
File␣"c:\Python27_64\lib\site-packages\numpy\ma\core.py",␣line␣2792,␣in␣__array_finalize__
self._update_from(obj)
File␣"c:\Python27_64\lib\site-packages\numpy\ma\core.py",␣line␣2774,␣in␣_update_from
if␣not␣isinstance(obj,␣MaskedArray):
RuntimeError:␣maximum␣recursion␣depth␣exceeded␣while␣calling␣a␣Python␣object

oder

␣File␣"build\bdist.win-amd64\egg\phyghtmap\hgt.py",␣line␣469,␣in␣chopData
File␣"build\bdist.win-amd64\egg\phyghtmap\hgt.py",␣line␣466,␣in␣chopData
File␣"build\bdist.win-amd64\egg\phyghtmap\hgt.py",␣line␣419,␣in␣tooManyNodes
File␣"build\bdist.win-amd64\egg\phyghtmap\hgt.py",␣line␣403,␣in␣estimNumOfNodes
File␣"c:\Python27_64\lib\site-packages\numpy\ma\core.py",␣line␣3685,␣in␣__eq__
check␣=␣check.view(type(self))
File␣"c:\Python27_64\lib\site-packages\numpy\ma\core.py",␣line␣2792,␣in␣__array_finalize__
self._update_from(obj)
File␣"c:\Python27_64\lib\site-packages\numpy\ma\core.py",␣line␣2774,␣in␣_update_from
if␣not␣isinstance(obj,␣MaskedArray):
RuntimeError:␣maximum␣recursion␣depth␣exceeded␣while␣calling␣a␣Python␣object

Kann es sein, dass die Rekursions-Tiefe von Python noch erhöht werden muss, bevor man alle Gebiete fehlerfrei berechnen kann?

Walter

Falls jemand den Fehler reproduzieren möchte, hier die exakten Parameter

phyghtmap.exe --area=6:43.75:7:44.25 --source=view1

Das ist ein Gebiet um Digne-les-Bains mit mittelhohen Bergen.

Der Fehler tritt nicht auf, wenn man den Parameter --source=srtm1 verwendet.
Kann es sich hier um einen Fehler in den Korrekturdaten von viewfinderpanoramas handeln?

Ich habe noch ein weiteres Gebiet gefunden, das den gleichen Fehler verursacht, in der Nähe von Ruzomberok: area=19:48.75:20:49.25

Ein weiterer Fehler ist sehr seltsam: --area=-25:63:-24:64 --source=view3,srtm3
Dieses Gebiet liegt SW von Island. Die view3 Daten liefern wieder einen Fehler, srtm3 Daten gibt es hier gar nicht, da es hier keine Insel gibt.

Walter

Versuche doch mal, keine "source"-Parameter mitzugeben. Dann lädt Phyghtmap nur SRTM3-Daten der Version 3.0. Ich denke, das sind neu ermittelte SRTM3-Daten, die keine korrigierten Daten von Viewfinderpanoramas benötigen. Bei mir gehen die 3 Gebiete ohne Versatz ineinander über (an der Grenze zum Alpengebiet war vorher einer zu sehen).

Es gibt noch den Parameter --srtm-version=VERSION. Der Ausschnitt aus der Hilfe dazu:
use this VERSION of SRTM data. Supported SRTM versions are 2.1 and 3. Version 2.1 has voids which were filled in version 3 using ASTER GDEM and other data. In version 2.1, only the US territory is included in the 1 arc second dataset. In version 3, nearly the whole world is covered. The default for this option is 3. If you want the old version, say --srtm-version=2.1 here

VIEW1-Daten dürften noch nicht vollständig erfasst sein (Übergänge zu VIEW3 und SRTMx sind sichtbar) und müssen nicht bessere Ergebnisse liefern (Beeinflussung durch Waldschneisen, Häuserumrisse etc.)

Hallo Garmin-User,

mir ist schon klar, dass der Fehler nur bei view1 bzw. view3 Daten auftritt, das habe ich ja auch so geschrieben.

Es gibt noch einen anderen Workaround, um den Fehler zu umgehen.
Man kann das entsprechende hgt-File, das die Probleme macht, im VIEW1 Ordner durch das gleichnamige File aus dem SRTM1 Ordner ersetzen.
phyghtmap bekommt diese Ersetzung natürlich nicht mit und liefert beim nächsten Lauf keinen Fehler mehr.

Viel wichtiger wäre mir aber, zu erfahren, ob andere auf genau den gleichen Fehler stoßen,
oder ob ich der einzige bin, bei dem dieser Fehler auftritt.

Walter

Hallo Walter,

ich habe die drei fehlerbehafteten Bereiche mit Phyghtmap unter Linux (Ubuntu 64 Bit) durchgespielt und keine Fehlermeldung mit Abbruch bekommen.
Lediglich "phyghtmap --area=19:48.75:20:49.25 --source=view1" meldet "N48E019: no file found on server." Der Bereich ist dann leer.

Gruß
Mario

Danke für's ausprobieren, Mario

Dann muss ich wohl irgendwo bei mir einen Fehler machen.

Ich habe die Files ein zweites mal heruntergeladen, und wieder den gleichen Fehler bekommen.
Möglicherweise gibt es auch einen Unterschied zwischen Linux und Windows.

N48E019 gibt es aber auch bei mir nicht, der Fehler lag im File N49E019.

Walter