SRTM Höhenlinien für Garmin-Karten erstellen

Communities Deutschland (Germany)
1

Wer hat Erfahrung mit der Erstellung von Garmin-Karten mit Höhenlinien?

Ich kann derzeit mit mkgmap problemlos meine Karten erstellen, aber bei den Höhenlinien erhalte ich kein brauchbares Ergebnis.
Ich versuche mal aufzulisten, welche Parameter ich alle setze. Falls sich jemand auskennt, wäre ich für Hinweise dankbar.

Schritt 1.

groundtruth contours -b=“48.0,16.0,48.5,16.5” -interval=10

Dieser Schritt funktioniert noch, im Ordner \Cache\Dem\Srtm3 landen die NASA dem3-Daten und im akt. Ordner das File output.ibf

Schritt 1b kann ich hier überspringen, ich überschreibe die NASA Daten noch durch korrigierte Daten von ViewFinderPanoramas.org und rufe Schritt 1 nochmals auf.

“C:\Program Files\7-Zip\7z” e -r -aoa ViewFinderPanoramas\download*.zip N47E016.hgt -oCache\Dem\Srtm3\

Schritt 2.

groundtruth ibf2osm -cat=“100,20”

Auch dieser Schritt geht gut, im Ordner \Output landen die Files Contours1.osm.bz2 bis Contours4.osm.bz2 (Es ist ja nur ein kleines Gebiet)

Schritt 3. - Beim Aufruf von Splitter vermute ich meinen Fehler

“C:\Program Files\Java\jre7\bin\java” -Xmx6144m -jar splitter.jar Output\Contours*.osm.bz2 --mapid=60110001 “–description=Hoehenlinien Wienerwald” --max-areas=512 --max-nodes=800000 --resolution=14 --keep-complete=false --mixed --output=o5m

Schritt 4. - Würde vermutlich gut gehen, wenn Schritt 3 funktioniert.

“C:\Program Files\Java\jre7\bin\java” -Xmx6144m -ea -jar mkgmap.jar “–description=Hoehenlinien Wienerwald” -c Map_Options.txt -c SRTM_Options.txt -c Common_Options.txt --mapname=60110001 --overview-mapname=60110000 --family-id=60 --product-id=11 --gmapsupp 6011*.o5m Styles.txt

Ich habe bei den Parametern hier aus Gründen der Übersichtlichkeit die vollen Ordner-Pfade weggelassen, also bitte nicht wundern, ich hab nicht alles in einem Ordner liegen.
Die Parameter im Schritt 4 sind die gleichen wie für den osm-Plan, daher etwas umfangreicher als für reine Höhenlinien.
Die Parameter im Schritt 3 sind beim srtm Einsatz gegenüber dem osm Einsatz leicht verändert.

Splitter Parameter für osm-Plan: --keep-complete=true

Splitter Parameter für srtm: --keep-complete=false --mixed (bei obigen Parametern bekomme ich eine Fehlermeldung, vermutlich ist der GroundTruth-Output mixed)

Wenn ich die Höhenlinien für den Wienerwald erstelle, wie in diesem Beispiel, dann funktionieren alle Schritte bis zum Ende, die erstellten Höhenlinien sehen gut aus.

Wenn ich das Gebiet doppelt so groß wähle, wird das erstellte img-File exakt gleich groß.

Ich vermute, dass der Splitter beim Aufruf mit Contours* nicht alle Contours Files verarbeitet, sondern nur das erste.
Meine Frage nun an die Experten: Wie sieht eure Erstellung von Höhenlinien aus, was macht ihr anders, so dass es funktioniert?

Walter

2

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:Garmin-User#H.C3.B6henlinien

Grüße
Mario

3

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?

4

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

5

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-america-terrain-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

6

Ü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. :slight_smile:

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

bye, Nop

7

“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

8

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

9

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

10

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

11

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/OpenTopoMap/tree/master/garmin

12

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

13

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. :frowning:

14

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/files/NumPy/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

15

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

16

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

17

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.)

18

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

19

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

20

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