Hallo,
ich versuche zurzeit, mit Srtm2Osm Höhenlinien für meine Garmin-Karte zu erstellen. Gestern habe ich Srtm2Osm mit dem Befehl
mono Srtm2Osm.exe -bounds1 56 4 46 16 -i -step 10 -cat 400 100 -o …/srtm_germany.osm
gestartet. Jetzt habe ich überprüft, wie weit es über Nacht gekommen ist und habe gesehen, dass es immer noch bei negativen elevations ist!
Ist es normal, dass Srtm2Osm so lange braucht oder mache ich da was falsch?
Auf Anhieb würden mir folgende Vermutungen einfallen:
1.) Du nutzt “mono” zum Ausführen, dadurch vermute ich, dass Du mit Linux unterwegs bist. Könntest Du in diesem Fall nicht einfach die Perl-Script-Variante von SRTM2OSM unter Linux nutzen? Vielleicht bremst Dich also “Mono” aus?!
2.) Vielleicht ist Deine Internetverbindung zu langsam, je langsamer Deine Leitung, desto länger dauert das Herunterladen?!
3.) Ich glaube außerdem, dass -step 10 in der Befehlszeile relativ wenig Sinn macht, da die SRTM-Daten -so glaube ich mal gelesen zu haben- eh’ nicht genauer als 20 Meter sind. Bei Wikipedia steht etwas von ±6 m, ob damit aber die Daten für Europa oder die etwas genaueren Daten für die USA gemeint sind, ist mir auch nicht ganz klar.
4.) Deutschland ist ganz schön groß… Ich kann daher eigentlich gar nicht so recht mitreden, da ich mit meinem “Taschencomputer” ganz Deutschland gar nicht verarbeiten kann, z.B. benötigt die Verknüpfung der OSM- mit den SRTM-Daten per Osmosis einfach zu viel Arbeitsspeicher ;-(.
Aber vielleicht melden sich noch andere Nutzer zu Wort, die mit dieser Sache besser vertraut sind als ich.
Zu 1.) Das hab’ ich mir auch schon gedacht. Ich wusste aber nicht, dass es eine Perl-Script-Variante gibt. Die scheint mir aber nicht sehr geeignet, weil es bei dieser Variante z. B. die -cat Option nicht gibt. Aber das bekommt man ja vielleicht mit einem anderen Tool hin. Ich werde es aber trotzdem mal mit Windows probieren, ob es dort tatsächlich schneller geht.
Zu 2.) Das glaube ich nicht. Ich hatte schon Geschwindigkeiten von ca. 1,8 MBit/s, das sollte doch reicen, oder sind die SRTM-Daten so groß?
Zu 3.) So wie ich das verstanden habe ist die Genauigkeit der einzelnen Höhenlinien ±6m, nicht der Abstand. Vielleicht weiß hier aber jemand anders, was der Abstand zwischen den SRTM-Linien ist.
Zu 4.) Da würde die -large Option von SRTM helfen. Wie sich herausgestellt ist nämlich mein Arbeitsspeicher auch zu klein, um die ganzen Höhenlinien ohne Zwischenspeichern in die Datei zu verarbeiten. Ich dachte nur, mit dieser Option würde es noch langsamer gehen.
Könnte ein Nutzer, der schonmal DE-Höhenlinien generiert hat, vielleicht schnell schreiben, wie lange das bei ihm gedauert hat? Vielleicht ist das ja sogar normal??!
Ich nutze für D step=20 und das dauerte so 5-6h.
Upps, es gibt sowas wie die -cat Option doch.
Mit step=10 sollte es dann logischerweise doppelt so lang dauern. Also ist das bei mir nicht normal. Ich werde mal die Perl-Script-Variante ausprobieren.
Nun ja, eher viermal so lang (quadratisch). Wir bewegen uns ja auf einer Fläche.
Es kann aber durchaus sein, dass der Algorithmus exponentiell skaliert. Dann sieht es noch übler aus.
Zeiten kannst du nur bei vergleichbaren Bedingungen (Hardware/Software) direkt vergleichen.
Edbert (EvanE)
Nein, bei diesem Algorithmus stimmt das mit dem doppelt glaube ich schon. Er fängt mit Höhenlinie -220 an und sucht Punkte, die auf dieser Linie liegen, dann sucht er Punkte auf Höhenlinie -210, dann auf -200 usw. Mit -step 20 muss er nur halb so viele Linien auf Punkte prüfen, braucht also ungefähr halb so lange. So habe ich das zumindest verstanden.
Andere Frage:
Sind die .asc (ArcInfo ASCII)-Höhenlinien von http://srtm.csi.cgiar.org/SRT-ZIP/SRTM_v41/SRTM_Data_ArcASCII/*.zip eigentlich ungenauer als die .hgt-Höhenlinien von http://dds.cr.usgs.gov/srtm/version2_1/? Diese braucht man nämlich bei dem Perl-Script.
Damit ergibt sich noch ein Problem: Bei dem Perl-Script kann man nur eine .asc-Datei angeben. Für Deutschland bräuchte man aber 7. Kann man die irgendwie zusammenfügen?
Aus einer Halbierung der Abstaende erhaelt man aber mehr als doppelt so viele Linien, weil nun kleinere Gelaendeunebenheiten als neue Objekte auftauchen, die vorher komplett weggefallen sind.
Beispiel plattes Norddeutschland: Bei einem Abstand von 20m bekommt man (in etwa) die Kuestenlinien mit 0m und Hoehenlinien fuer alle Erhebungen die groesser als 20m sind. Aller sonstiger Kleinkram faellt weg. Bei einem Abstand von 10m erhaelt man bei den Erhebungen groesser 20m doppelt so viele Linien, zusaetzlich tauchen aber auch noch alle Erhebungen mit 10-20m Hoehe als neue Objekte auf.
Der Auswirkungen des Linienabstandes auf die Laufzeit und die erzeugte Datenmenge wird also nicht unerheblich von der Topographie der untersuchten Gegend abhaengen.
Das bringt mich zu meinem naechsten Punkt: Macht es eigentlich Sinn, die Hoehenlinien fuer ganz Deutschland in einem Schritt mit einheitlichem Abstand zu erzeugen? Fuer die Garmingeraete muss man die Daten ja sowieso in verschiedenen Kacheln einteilen. Deshalb habe ich mir gleich von SRTM2OSM die Kacheln einzeln berechnen lassen, an der Nordseekueste benutze ich 5m Abstand, in den Mittelgebirgen 10m und in den Alpen 20m (oder waren es 25m?).
Gruss
Torsten
Das führt dann aber an den Rändern zu hässlichen “Sackgassen”. Damit hab ich auch schon herum gespielt. Besser wäre da eine höhenabhängige Staffelung. Bspw. bis 100m 5m-Abstand, bis 1000m 10m-Abstand und darüber dann 20m.
Ja. Allerdings sind diese Randbereiche ja nur ein verschwindend kleiner Teil der Karte, der Rest der Flaeche profitiert dagegen ja von der angepassten Skalierung. In der Praxis habe ich das nie als Problem empfunden.
Das waere in der Tat schoener, nur kann das mit dem aktuellen SRTM2OSM wohl nicht hinbekommen. (So ganz genau weiss ich das allerdings nicht, da die von mir benutzte Version von SRTM2OSM schon ziemlich alt ist. Die Hoehendaten aendern sich ja nicht, so dass ich das nur aeusserst selten benutze, wenn ich den Kartenbereich mal wieder etwas anpassen muss.)
Um so eine Staffelung zu erreichen, waere es z.Z. wahrscheinlich am einfachsten, wenn man anschliessend die OSM-Hoehendaten nochmal nachbearbeitet. Dann dauert die Erzeugung natuerlich noch viel laenger, ist ja aber allerdings eine einmalige Sache.
Ausserdem funktioniert dieser Ansatz nur, wenn die ueblichen Hoehnunterschiede in etwa proportional zur absoluten Hoehe sind. In Deutschland kommt das auch ganz gut hin, bei ausgedehnten Hochebenen wird eine hoehenabhaengige Skalierung allerdinsg nur suboptimale Ergebnisse liefern.
Gruss
Torstem
Die Daten von CGIAR sind besser als die SRTM (Löcher geflickt/ergänzt), kommen aber mit einer NC-Lizenz. Die derzeitige OSM-Lizenz ist dazu inkompatibel.
bye
Nop
CIGAR kommt doch auch nur als geotiff, welches man nicht zu etwas verarbeitet bekommt, was mkgmap frisst, oder hat sich daran etwas geändert?
Nein, ich meinte vom Format her. Die Frage könnte man im Prinzip auch so stellen: Sind im GeoTIFF-Format mehr Höheninformationen gespeichert als im ArcInfo ASCII (z. B. von den Intervallen her)?
Als geotif bekommt man auch die Daten von OpenDEM: http://www.opendem.info/download_srtm.html
Habe neulich versucht die zu nutzen, da die sehr schön aufbereitet wirken. Mit gdal_contur bekomme ich bei 9m gut 2GB großes “Shapefile”, bei 10m 1,7GB großes “Shapefile”. Aber mit “nur” 5,5GB RAM konnte keines der shp2osm Programme die ich getestet habe die umwandeln in etwas das mkgmap fressen würde. Ideen werden gerne entgegen genommen.