Lohnt es sich aus GeoTiff SRTM-3 Daten SRTM-3 oder SRTM-1 HGT Daten abzuleiten?

Hallo weoli,

ich habe tatsächlich nicht soviel Ahnung von der Materie, deshalb kann ich nichts zur Lage der Pixel beitragen.

Genial ist an der Methode mit MICRODEM und BILxSRTM einfach, daß man aus lediglich sieben *.ASC Dateien von CGIAR mit wenigen Klicks in kurzer Zeit alle für Deutschland benötigten *.hgt Dateien erzeugen kann.

Wenn ich Höhenprofile von verschiedenen Tracks vergleichen möchte, dann finde ich diese Dateien hervorragend als gemeinsame Datenbasis geeignet. Und vor allen Dingen geht die Zuweisung der Höhendaten mit GPS-Track-Analyse.net sehr schnell und einfach.

Ich hatte ja schon im Beitrag gestern geschrieben, daß die mit DEM2TOPO erzeugten Höhenlinien aus den GeoTiffs(Version4) von CGIAR deckungsgleich mit denen aus den *.hgt Dateien der NASA sind. Nur die mit MICRODEM und BILxSRTM erzeugten sind um 48 m nach Süden und um 28 m nach Westen verschoben.

weoli: Großes Dankeschön für die Adresse der SRTM3 Version4.1 Dateien. Der Download geht im Moment sehr langsam. Mal sehen, wie weit ich komme,
Wie weit bist Du denn mit der Erzeugung von *.hgt Dateien gekommen?

@Joern_Weber: ich hatte schon überlegt, ob ich an Andy Jarvis oder Andy Nelson schreiben sollte. Wie auch immer ich voran komme, werde ich einmal eine Mail schreiben. Schließlich heißt es ja auf der Seite: "If you find this digital elevation data useful, please let us know at csi(at)cgiar.org

Gruß, Martin

Mit dem Einlesen der verschiedenen Dateien von CGIAR bin ich nicht recht weitergekommen. ASCII(Version4), GeoTiff(Version4) und GeoTiff(Version4.1), wenn ich sie in MICRODEM öffne, erhalte ich jeweils verschiedene Header Informationen. Bevor ich an Dr. Andy Jarvis oder an Prof. Peter Guth (MICRODEM Forum) schreibe, probiere ich aber erst noch ein bißchen die Möglichkeiten von MICRODEM aus, wenn ich wieder die Zeit finde.

Ich habe noch etwas Schönes herausgefunden, was ich gerne weitergeben möchte:
MICRODEM/File/Data Manipulation --> öffnet das Fenster Data Manipulation. Anschließend kann man mit Merge/DEMs/DEMs--pick multiple mehrere Dateien zu einer neuen zusammenfassen. Aus der auf diese Art erzeugten Datei kann man dann wie gehabt mit BILxSRTM die *.hgt Dateien erzeugen. Ich habe das für die ASCII(Version4) Dateien von srtm_38_01 bis srtm_40_04 gemacht. Mit Edit/DEM Holes/Missing Data to sea level habe ich die leeren Meerflächen mit Höhendaten gefüllt (siehe das Bild im Anhang). Ganze 15 Minuten hat das vom Extrahieren der CGIAR Dateien bis zum Erzeugen der letzten *.hgt Datei gedauert.

Mit GPS-Track-Analyse.net habe ich dann das Verzeichnis der neu erzeugten *.hgt Dateien angegeben und für eine Testroute von Oslo nach Mailand die 24.421 Höhendaten fehlerfrei zuweisen lassen (siehe Erfolgsmeldung im Anhang). Genial.

So, ich habe in der Hilfe von MICRODEM gefunden, wie man die DEMs verschieben kann:
Das Fenster "Data Manipulation" öffnen durch File/Data Manipulation oder die Schaltfläche IN<-->OUT. Im Fenster "Data Manipulation" --> Edit/DEM Header --> Datei auswählen. Der Header wird wird geöffnet und kann bearbeitet werden. Nach Klick auf die Schaltfläche OK kommt dann die Bestätigungsabfrage "Rewrite DEM?". Klick auf YES überschreibt dann den alten Header.
Im Beispiel habe ich die südwestliche Ecke auf N45E5 gesetzt.

Der nächste Schritt wird nun sein, zu untersuchen, ob überhaupt oder um welches Maß die DEMs verschoben werden müssen.

Ein weiterer Schritt könnte die Ergänzung des GPS-Wikis sein.

Gruß, Martin

Anbei noch zwei Bilder aus MapEdit++ von der Region um den Mont Blanc. Die Höhenlinien habe ich mit DEM2TOPO erstellt und die Datei N45E006.hgt mit MICRODEM und BILxSRTM. Ich habe die SRTM3 v4 Höhendaten von CGIAR verwendet. 4.783 Meter Höhe wird auch in Google Earth am höchsten Punkt angezeigt. In Wikipedia und im Meyers Taschenlexikon sind es 4.807 m.

Hallo weoli,

großes Dankeschön für das Thema und Deine Beiträge. Seit ich den Unterschied zwischen Version 2 und Version 4 der SRTM Daten am Beispiel des Karwendelgebirges gesehen hatte, dachte ich, es müsse doch irgendwie möglich sein die neuen Daten für GPS-Track-Analyse.net und das Erzeugen von Höhenlinien nutzbar zu machen.

Zitat von weoli

bekommst Du beim Starten von MICRODEM übrigens auch immer eine Fehlermeldung?

Zuerst ja, weil ich das Programm auch in einen anderen Ordner installiert hatte (schließlich wird diese Option ja auch angeboten). Dann habe ich das Programm komplett deinstalliert und wie vorgegeben direkt unter C:/ installiert (C:/microdem/ und C:/mapdata/). Damit gibt es beim Start keine Fehlermeldungen mehr, und die Schaltflächen stehen alle zur Verfügung.

Zitat von weoli

Vielleicht liegt es daran, dass ich weder MICRODEM in das vorgegebenen Verzeichnis installiert habe, noch die Daten im vorgeschlagenen Verzeichnis liegen.

Genau so ist es.

Ich habe jetzt auch nocheinmal den Pixelabstand nachgerechnet: 6.000 Zeilen (Spalten) für 5° Lon (5° Lat), das sind 1.200 Zeilen (Spalten) für 1°. Der Kehrwehrt daraus ergibt den Pixelabstand in °, nämlich 0,0008Periode3. Die Daten von CGIAR sind ja "seamless", also ohne Überlappung. Jetzt hoffe ich noch auf Antwort von Andy Jarvis, wo das südwestlichste Pixel liegt. Und dann kann man damit den Data Header einfach entsprechend ändern.

Durch die Funktion Merge DEMs ist auch das Problem der doppelten oder leeren *.hgt Dateien für den Bereich innerhalb des zusammengefügten DEMs gelöst und außerdem noch mein Problem 2 aus Beitrag#18.

Zitat von weoli

Dann müsste ja eigentlich auch der umgekehrte Weg gehen.

Von den 15 Minuten für die Erzeugung von 256 *.hgt Dateien sind vielleicht 3 Minuten für BILxSRTM. Da spare ich mir die Zeit, andere Methoden auszuprobieren. Allerdings kommen jetzt vielleicht noch 2 Minuten für die Korrektur der Data Header dazu, aber das kann man wohl vernachlässigen.

Zitat von weoli

MapEdit++ ist mir vor längerem immer beim Laden mehrerer *.hgt Dateien abgestürzt

Mein Tipp: Immer nur fünf *.hgt Dateien auf einmal hinzufügen und die Auslastung des Arbeitspeichers im Blick behalten.

Gruß, Martin

Hallo Joern,

danke für die Blumen, ich bin einfach Deiner Ermutigung gefolgt und habe die Programme ausprobiert, die weoli erwähnt hatte. Ich habe ein paar Berechnungen angestellt zum Pixelabstand. Wäre schön, wenn Du kurz überprüfen könntest, ob ich mich da nicht verrechnet habe:

Ich habe einmal mit GPSMapEdit zwei Polylines erzeugt mit Kassel in der Mitte, eine Polyline in Nord-Süd Richtung und eine in Ost-West Richtung, jeweils mit einer Distanz von 5 Grad. Mit rechte Maustaste/Properties habe ich die Länge abgelesen und erhalte für die SRTM3 Daten folgende Werte:
347.300 Meter Distanz Ost-West / 6.000 Pixel -->57,8 Meter Pixelabstand in Ost-West Richtung
255.600 Meter Distanz Nord-Süd / 6.000 Pixel -->42,6 Meter Pixelabstand in Nord-Süd Richtung
347.300 Meter Distanz Ost-West / 5 Grad -->69.460 Meter Gradabstand in Ost-West Richtung
255.600 Meter Distanz Nord-Süd / 5 Grad -->51.120 Meter Gradabstand in Nord-Süd Richtung

Wenn ich die SRTM3 v4 Daten von CGIAR in MICRODEM einlese (Data Manipulation/Edit/DEM Header), zeigt der Data Header einen Pixelabstand von jeweils 0,000 833 354 000 ° Länge und Breite an. Daraus ergibt sich, daß die eingelesene Datei um 8,61 Meter (Längengrad) bzw. 6,34 Meter (Breitengrad) über die Größe von 5° mal 5° hinausragt.
Wenn ich die SRTM3 v4.1 Daten einlese, zeigt der Data Header einen Pixelabstand von jeweils 0,000 833 333 354 ° an. Daraus ergibt sich, daß die eingelesene Datei um 0,86 Zentimeter (Längengrad) bzw. 0,63 Zentimeter (Breitengrad) über die Größe von 5° mal 5° hinausragt.
Wenn ich nun den Pixelabstand über die Funktion Data Manipulation/Edit/DEM Header auf jeweils 0,000 833 333 333 ° ändere, dann erhalte ich 0,14 Millimeter (Längengrad) bzw. 0,10 Millimeter (Breitengrad) weniger als 5° mal 5°.

5 Grad / 6.000 Pixel = 0,000 833 333 333 333 ... Grad/Pixel

0,000 833 354 000 Grad/Pixel * 6.000 Pixel = 5,000 124 000 Grad --> 0,000 124 000 Grad zuviel
0,000 833 333 354 Grad/Pixel * 6.000 Pixel = 5,000 000 124 Grad --> 0,000 000 124 Grad zuviel
0,000 833 333 333 Grad/Pixel * 6.000 Pixel = 4,999 999 998 Grad --> 0,000 000 002 Grad zuwenig

0,000 124 000 Grad * 69.460 Meter / 1 Grad = 8,613 040 m
0,000 124 000 Grad * 51.120 Meter / 1 Grad = 6,338 880 m
0,000 000 124 Grad * 69.460 Meter / 1 Grad = 0,861 304 cm
0,000 000 124 Grad * 51.120 Meter / 1 Grad = 0,633 888 cm
-0,000 000 002 Grad * 69.460 Meter / 1 Grad = -0,138 920 mm
-0,000 000 002 Grad * 51.120 Meter / 1 Grad = -0,102 240 mm

Wenn ich die v4.1 Daten nun so nehme, wie sie sind (und ohne den Pixelabstand im Data Header zu ändern), dann weist das nordöstlichste Pixel in der Matrix einen Fehler von weniger als einem Zentimeter auf. (Bei den v4 Daten sind es immerhin mehr als 5 Meter und hier kommt noch die Problematik des südwestlichsten Pixels dazu).

Ergebnis: mit den v4.1 Daten bekomme ich jetzt genau 25 (1°mal1°) *.hgt Dateien aus 1 (5°mal5°) *.ASC Datei, wobei die südwestliche Ecke jeweils genau auf N*.000E*.000 liegt.

Ich wiederhole mich nur, wenn ich schreibe, daß mein vorrangiges Ziel war, auf schnelle und einfache Weise die v4 Daten von CGIAR für GPS-Track-Analyse.net verfügbar zu machen, um eine einheitliche Datenbasis für den Vergleich verschiedener Tracks zu haben.
Deine Ausführungen zu den Höhenmodellen sind im Moment zuviel für mich. Zu gegebener Zeit, werde ich aber dankbar darauf zurückkommen. Ich erinnere mich noch, mal aufgeschnappt zu haben, daß im Harz die Landkarten nicht richtig zusammenpaßten, als aus zwei deutschen Staaten wieder einer wurde. Und das wiederum erinnert mich an die verschiedenen Auffassungen und Unstimmigkeiten zur Datierung der Ägyptischen Geschichte. Und wenn man möchte, kann man dann auch noch über die kategorische Ablehnung/Ignoranz einiger Wissenschaftler gegenüber den "biochemische[n] Einwände[n] gegen die Evolutionstheorie" von Michael Behe den Kopf schütteln, aber das ist nun wirklich abseits des Themas.
Ich habe oft mit Kopfschütteln die zahlreichen Forderungen hier im Forum nach absolut genauen Höhendaten gelesen. Und Du hast da schon einige Beiträge zu geschrieben, wenn ich es recht überblicke.

Tipp: die v4.1 Daten im ArcInfoASCII Format gibt es vom FTP Server des JRC (Italien). Verknüpfung zur Internetseite von CGIAR-CSI. Die 872 Dateien haben eine Gesamtgröße von 14,1GB. Zur Beachtung: die Datein sind nur für den nichtkommerziellen Gebrauch. Wer die Daten kommerziell nutzen möchte, muss sich an Dr. Andy Jarvis (A.Jarvis(at)cgiar.org) wenden.

Gruß, Martin

Zitat von weoli

Hallo Martin,
PS bekommst Du beim Starten von MICRODEM übrigens auch immer eine Fehlermeldung? Ich muss die wegklicken und danach in den Optionen die Menus für MICRODEM wählen. Mir fehlem ansonsten immer die ganzen bunten Icons in der Menuleiste. Die werden nicht gespeichert. Adminrechte habe ich. Vielleicht liegt es daran, dass ich weder MICRODEM in das vorgegebenen Verzeichnis installiert habe, noch die Daten im vorgeschlagenen Verzeichnis liegen.

weoli +@ Martin

Soweit ich das ausprobiert habe und anderweitig nachgelesen habe, liegt es nur an dem "mapdata"-Verzeichnis, welches explizit als Root-Verzeichnis angelegt werden muss z.B. c:\mapdata. Es kann aber auch ein anderes Laufwerk sein. Das Programm Microdem selbst kann beliebig installiert werden.
Es reicht das mapdata Verzeichnis entsprechend umzukopieren und die Fehlermeldungen beim Programmstart sind weg und das Menu ist voll da.

Gruss Papaluna

Zitat von weoli

Aber eines habe ich zumindest in Global Mapper rein optisch schon mal festgestellt. Die ARC ASCII Daten und die GeoTiff Daten vom italienischen Server passen mit meinem Beispiel (das ist die Datei 40_04) exakt in das Gitter zwischen N 40.00° E 15.00° und N 45.00° E 20.00°. Mit den Daten müsste man also ohne jegliche Probleme die *.hgt Dateien erzeugen können.

Genau das hatte ich im Beitrag#32 bereits geschrieben. Hast Du mal *.hgt Dateien aus srtm_40_04 erzeugt und separat dazu aus srtm_41_04 (ich meine ohne die Funktion Merge/DEMs)? Dann würde mich nämlich interessieren, wie bei Dir der Übergang von N40E019 zu N40E020 am südlichen Rand aussieht. Füge doch bitte einmal ein Bild aus dem Programm GlobalMapper bei. Mit Deiner *.pdf Datei kann ich leider nichts anfangen. Ohne genaue Angabe der ftp Server oder http Adressen kann ich da nichts von nachvollziehen. Den Dateinamen "srtm_40_04_ARINFO_ASCII..." habe ich auch noch nirgends gesehen. Tut mir leid.

Die Bilder aus MapEdit++, die ich diesem Beitrag beifüge, zeigen den Unterschied, ob ich die *.hgt Dateien einzeln aus srtm_40_04 und srtm_41_04 erzeuge, oder die beiden *.ASC Dateien vorher mit Merge/DEMs zusammengefügt habe. Ich werde wohl doch ein bisschen mit dem Pixelabstand probieren, wenn ich Zeit dazu finde.

Gruß, Martin

Im Anhang ist nocheinmal das Bild des Übergangs von N40E019.hgt zu N40E020.hgt aus v4.1 Daten (ohne Veränderung des Data Headers) aus Beitrag 37. Man erkennt genau, dass durch das Zusammenfügen der Dateien srtm_40_04.ASC und srtm_41_04.ASC mit dem Programm MicroDEM die Position der Pixel mit den Höheninformationen nicht verändert wird. Nach dem Zusammenfügen der beiden Dateien kann aber nun auch der Bereich am östlichen Rand von N40E019.hgt und am westlichen Rand von N40E020.hgt berechnet werden.

Ich habe noch einmal verschiedene *.hgt Dateien aus den v4.1 Dateien von GGIAR erzeugt und mir in MapEdit++ die Lage der Pixel am Rand angesehen. Habe gezählt, gemessen und verschoben. Doch ohne genaue Information, wo genau das südwestliche Pixel liegt, ob direkt in der Ecke oder um einen halben oder ganzen Pixel vom Rand verschoben, das habe ich noch nicht in Erfahrung bringen können.

Dann habe ich noch einmal, wie in Beitrag#26 beschrieben, ein zusammengefügtes DEM aus den Dateien srtm_38_01.ASC bis srtm_40_03.ASC der v4.1 Daten erzeugt und daraus die 225 *.hgt Dateien von N45E005 bis N59E019. Dass am nördlichen Rand der N59E***.hgt Dateien, dem südlichen der N45E***.hgt sowie dem östlichen der N**E019.hgt jeweils eine Datenreihe bzw. -spalte fehlt, liegt daran, dass die srtm_**_**.ASC keine Überlappung haben. Siehe dazu auch den Beitrag#38.

So, und nun habe ich mir als Nordhesse die N51.E009.hgt herausgewählt. Genauer gesagt habe ich die südwestliche und die südöstliche Ecke betrachtet und die Datei aus Version2 der SRTM3 Daten vom NASA Server mit der mit MicroDEM und BILxSRTM erzeugten Datei aus den Version4.1 Daten von CGIAR gegenübergestellt. Die Bilder habe ich beigefügt. Für meinen Zweck ist die Übereinstimmung hinreichend. (Weil in dem betrachteten Bereich die Höhendaten von Version 2 und 4.1 gleich sind, kann man schön die Lage der einzelnen Pixel vergleichen.)

Ich möchte noch auf die SRTM Seiten des Joint Research Centers der Europäischen Union hinweisen. Die Seiten sind auf englisch. Hier findet man Informationen zu den Methoden und auch einen Online Viewer. Auf der Seite zum Download wird auch die Adresse ftp://xftp.jrc.it/pub/srtmV4/ angegeben, welche die Daten der Version 4.1 im arcascii und tiff Format in den Unterverzeichnissen enthält. Wie weoli bereits in Beitrag#36 geschrieben hatte, ist der Datendownload komfortabler, wenn man diese ftp Adresse direkt in die Adressleiste des Windows Explorers (nicht des Internet Browsers!) eingibt, weil man auf diese Weise gleich mehrere Dateien auf einmal kopieren kann.

Dass die aus den ASCII Dateien erzeugten *.hgt Dateien deckungsgleich zu den *.hgt Dateien der Version 2 sind, hatte ich bereits geschrieben.
Nun habe ich mit DEM2TOPO aus den Version 4.1 GeoTiff Dateien Höhenlinien erzeugt, erhalte aber dieselbe Verschiebung wie in Beitrag 18 beschrieben. Das hatte mich zunächst enttäuscht. Weil aber die Höhenlinien an zwei Seiten sowieso nicht bis zum Rand berechnet werden können, hätte ich dafür sowieso auf die *.hgt Dateien zurückgreifen müssen.

Nun habe ich mit DEM2TOPO aus den aus v4.1 erzeugten *.hgt Dateien Höhenlinien erzeugt. Und die sind genau deckungsgleich zu denen der v2. In GPSMapEdit (oder MapEdit++) sieht man, dass es am Übergang von Höhenlinien aus verschiedenen Dateien keine Überlappungen und auch keine Lücken gibt. Genial. Man kann mit DEM2TOPO auch gleichzeitig mehrere *.hgt Dateien auf einmal öffnen und daraus in einem Programmlauf mehrere Höhenliniendateien erzeugen.

Mit dem Programm MicroDEM gespeicherte *.DEM oder *.tif Dateien konnte ich mit DEM2TOPO nicht öffnen.