Hallo zusammen,
nachdem jetzt fast 1/4 Jahr ins Land gegangen ist, bin ich neulich beim Aufräumen auf meinem Rechner über meine angefangenen Untersuchungen zu dem Thema gestolpert. Hatte ich fast schon vergessen. 
Habe daher noch einmal ganz bei Null angefangen und dabei die nachstehenden Probleme nochmals aufbereitet, die alle in irgendeiner Art und Weise bereits weiter oben in diesem Thread angesprochen wurden. Ich habe noch einmal versucht die Ursachen für die bisher diskutierten Punkte zu finden und eine abschließende Zusammenfassung zu erstellen.
Untersucht habe ich CGIAR Dateien vom italienischen FTP Server (ftp://xftp.jrc.it) und HGT Dateien vom FTP Server der NASA (ftp://e0srp01u.ecs.nasa.gov). Die untersuchte CGIAR Kachel srtm_40_04.tif wurde aus dem Verzeichnis /pub/srtmv4/tiff des FTP Servers heruntergeladen und trägt das Datum 01.10.2008. Es handelt sich also um Daten der Version 4.1. Die HGT Dateien der Version 2 stammen aus dem Verzeichnis /srtm/version2/SRTM3/Eurasia des NASA Servers.
Zum Überprüfen bzw. Vergleichen der Höhenwerte habe ich sowohl die entsprechenden Original HGT Daten der NASA, die CGIAR GeoTiff Daten und die aus den GeoTiff Dateien abgeleiteten HGT Dateien mit Global Mapper in das ASCII XYZ Format exportiert. MICRODEM hat beim Exportieren leider einen Fehler (s.u.) Außerdem habe ich die Grafiken optisch verglichen (Pixelfärbung, Höhenlinienvergleich, ...) und Zahlenwerte beim Überfahren mit dem Mauszeiger überprüft.
Bei den GeoTiff Kacheln gehe ich davon aus, dass der Mittelpunkt eines 3"x3" (0.05'x0.05') Pixels als repräsentativ für den jeweiligen Pixel anzusetzen ist, da gemäß Header für die CGIAR GeoTiff Kacheln die PixelIsArea Definition verwendet wird (vgl. dazu die Spezifikation zu Abs. 2.5.2.2 Raster Space bei remotesensing.org).
Der Vergleich der Ergebnisse sollte immer dieselben Werte liefern, da in den untersuchten Bereich keine Löcher in den NASA Daten vorhanden sind!
1. Problem, Versatz zw. Original HGT der NASA und den CGIAR GeoTiff Dateien
Dieser generelle Versatz der Daten fällt sofort auf, wenn Höhenlinien direkt aus den GeoTiff Daten und zum Vergleich aus den Original NASA HGT Daten erzeugt werden. Um einen Fehler bei der Höhenliniengenerierung in Global Mapper auszuschließen, habe ich zum Vergleich auch noch Höhenlinien aus den Original HGT Dateien und den GeoTiff Dateien mit DEM2TOPO generiert.
In den nachstehenden beiden Abbildungen sind die Höhenlinien der GeoTiff Datei (Magenta) transparent über die Höhenlinien der HGT Datei (Braun) gelegt.
Zunächst die mit Global Mapper erzeugten Höhenlinien
und derselben Bereich mit den mit DEM2TOPO generierten Höhenlinien
Die Höhenlinien zwischen den beiden Programmen sind nicht identisch, da die internen Algorithmen unterschiedlich sind. In beiden Fällen ist jedoch derselbe Versatz nach Nordosten zu erkennen.
Ein genauerer Vergleich der Zahlenwerte in der ASCII XYZ Datei zeigt dann, dass sämtliche Höhenwerte in der GeoTiff Kachel um exakt 1.5" = 0.025' nach Norden und Osten gegenüber den Original HGT Daten versetzt sind. Im folgenden Bild z.B. ein Vergleich der Höhenwerte der GEOTIFF Datei srtm_40_04.tif mit denjenigen der südöstlichen Ecke der Datei N44E019.HGT. Dieser Versatz kann in beliebigen anderen Kacheln ebenfalls nachvollzogen werden. Er tritt konstant überall auf. Zumindest gilt er für alle von mir untersuchten Kacheln die mit den NxxEyyy.HGT verglichen wurden. Ob das bei den NxxWyyy.HGT, SxxEyyy.HGT und SxxWyyy. HGT Dateien genauso ist, oder ob diese einen Versatz in eine andere Richtung aufweisen, habe ich nicht untersucht.
Meiner Ansicht nach, ist der Versatz der Höhenwerte zwischen den NASA HGT Kacheln und den GeoTiff Kacheln dadurch begründet, dass die 6001*6001 Punkte (4*(1201 -1) + 1201) der jeweils überlappenden und über die Ränder (40° N - 45° N / 15° E - 20° E) überstehenden 5x5 HGT Kacheln, die den Bereich der GeoTiff Kachel srtm_40_04.tif abdecken, auf 6000*6000 Punkte der „seamless“ (nahtlos) GeoTiff Kachel umgerechnet werden müssen. Die Koordinaten der Punkte in den HGT Dateien und der GeoTiff DAtei sind dabei nicht identisch, sondern um exakt die 1.5" gegeneinander versetzt. Die CGIAR Daten wurden jedoch nicht aus den benachbarten Punkten der HGT Daten interpoliert sondern der Einfachheit halber wurden wohl lediglich die Werte der HGT Dateien um 1.5“ nach Norden und Osten verschoben. Ich kann mir zwar vorstellen, dass die Werte an den um 1.5" versetzten Punkten zufällig auch bei einer Interpolation der Werte mal identisch sein können (z.B. bei sehr kleinen Unterschieden zwischen den benachbarten Punkten), dass dieses jedoch an allen Punkten, völlig unabhängig von der Geländeoberfläche (Gebirge, Flachland, ...) so ist, kann ich mir jedenfalls nicht vorstellen!
Ich habe mich etwas über diesen Versatz gewundert, da ja als Anmerkung zu den CGIAR Daten der Version 4 extra der Satz steht, dass der Versatz um 1/2 Pixel jetzt endgültig behoben sei. Vgl.
Zitat
Version 4 differs from Version 3 with a ½ grid pixel shift which definitively solves this confusion.
bei http://srtm.csi.cgiar.org/SRTMdataProcessingMethodology.asp
Bei der Suche im Internet habe ich auch nur eine einzige weitere Quelle gefunden, die diesen Versatz anspricht, vgl. folgende Diskussion im Forum von[URL='http://www.sim-outhouse.com/sohforums/showpost.php?p=95453&postcount=14' sim.outhouse.com[/URL], wo es um die Geländeerzeugung für Flugsimulatoren geht.
Martin, hast Du damals - wie von Jörn vorgeschlagen, s. Beitrag [URL='http://www.naviboard.de/vb/showpost.php?p=257088&postcount=19']#19 - mit CGIAR Kontakt aufgenommen?
2. Problem, Beim Abspeichern einer GeoTiff Kachel im BIL Format in MICRODEM werden die Werte aus der GeoTiff Kachel nach Norden und Westen versetzt
Dieser Versatz tritt in MICRODEM sowohl beim Speichern der GeoTiff Datei im BIL als auch im ASCII XYZ Format auf. Nachvollziehen kann man den Versatz dadurch, dass die mit MICRODEM exportierten Dateien im Anschluss in Global Mapper geöffnet werden, in eine ASCII XYZ Datei exportiert werden und anschließend mit den Originalwerten der GeoTiff Kachel und der Original HGT Datei verglichen werden. Alternativ fällt ein Versatz auch immer dadurch auf, dass sich die Pixelfärbungen beim Ein- und Ausblenden der einzelnen Kartenlayer in Global Mapper leicht gegeneinander verschieben.
Wie man aus der vorstehenden Abbildung erkennt, sind die Werte der mit MICRODEM erzeugten BIL Datei gegenüber den Werten der Original NASA HGT Datei um 3" = 0.05' nach Norden verschoben (violette Pfeile). Gegenüber der GeoTiff Datei (rote Pfeile) sind sie um 1.5" nach Norden und Westen verschoben.
Speichert man die GeoTiff Daten in MICRODEM hingegen im proprietären MICRODEM DEM Format, tritt übrigens kein Versatz auf. Sobald diese MICRODEM DEM Datei jedoch wieder im BIL Format exportiert wird, ist wieder eine Verschiebung gegenüber den Werten in der GeoTiff Datei feststellbar.
3. Problem, Beim Zerlegen der BIL Datei in HGT Dateien fehlen am östlichen und südlichen Rand des betrachteten Bereiches Werte
Dieses Problem tritt immer dann auf wenn keine weiteren Kacheln in dieser Richtung angrenzen. Außerdem fehlen im Inneren einer Kachel immer dann - wenn hinter einem gerade betrachtenen Punkt keine weiteren Höhenwerte in östlicher und/oder südlicher Richtung vorhanden sind (z.B. bei den Meeresflächen in der GeoTiff Datei) - Punkte in der neuen HGT Datei. (Die GeoTiff Dateien enthalten anders als die Original NASA HGT Dateien keinen Wert 0 für den Meeresspiegel)
Beim Aufspalten einer mit MICRODEM aus einer einzelnen GeoTiff Kachel erzeugten BIL Datei (6000x6000 Punkte) in HGT Dateien mit BILxSRTM werden die in der BIL Datei vorhandenen Werte direkt übernommen. Diese sind dann jedoch gegenüber der Original Datei der NASA um die oben beschriebenen 3" nach Norden versetzt. Am östlichen Rand der BIL Datei fehlen allen entsprechenden HGT Dateien zwei Spalten mit Werten. Bei den HGT Kacheln am südlichen Rand der BIL Datei fehlt jeweils eine Reihe von Werten.
Selbst wenn eine BIL Datei mit 6001x6001 Punkten erzeugt wird, fehlt bei den HGT Kacheln am südlichen und östlichen Rand jeweils eine Reihe bzw. Spalte mit Werten.
Das ist auch das Problem, dass Martin in den Beiträgen #37 und #38 beschrieben hat. Wird jeweils eine einzelne GeoTiff Kachel (6000x6000 Punkte) betrachtet fehlt am südlichen Rand eine Reihe mit Werten am östlichen Rand fehlen zwei Reihen. Auf Martins screenshots gut erkennbar! Werden die Kacheln vorher verschmolzen ("gemerged"), so fehlen bei Martins Screenshot die Werte am südlichen Rand und am nicht dargestellten östlichen Rand der anschließenden Kachel srtm_41_04.tif.
Das vorstehende Problem lässt sich dadurch umgehen, dass man eine einzelne BIL Kachel am östlichen und südlichen Rand um zwei Reihen mit Werten überstehen lässt. Dazu muss die gewünschte Kachel mit den angrenzenden Kacheln verschmolzen werden. Die Datei beinhaltet dann 6002x6002 Werte. Wird diese 6002x6002 Punkte BIL Datei in HGT Dateien zerlegt, so entstehen am südlichen und östlichen Rand zwar überflüssige Kacheln. Diese können gelöscht werden.
Beim Überprüfen der Ergebnisse ist mir an den Küstenstreifen dann noch aufgefallen, dass der direkt aus der BIL bzw. GeoTiff Datei erzeugte Küstenverlauf nicht mit dem Küstenverlauf übereinstimmt, der aus den aus der BIL Datei abgeleiteten HGT Dateien erzeugt wird. Sehr deutlich erkennbar wird der Unterschied wenn man den Küstenverlauf einer aus einer BIL Datei abgeleiteten HGT Datei über denjenigen der zugehörigen BIL Datei legt. Dazu wurde in der folgenden Abbildung für den Verlauf aus der HGT Datei ein anderer "Shader" als für den Verlauf aus der BIL Datei eingestellt und dann transparent über den Küstenverlauf aus der BIL Datei gelegt. Rot und Violett ist der Verlauf, der sich aus der HGT Datei ergibt, blau derjenige aus der BIL (bzw. GeoTiff) Datei.
Das ist hier wieder dasselbe Problem wie an den Kachelrändern. BILxSRTM scheint immer hinter dem aktuell geschriebenen Wert noch einen weiteren Wert östlich bzw. südlich zu erwarten. Ist dieser nicht vorhanden, so wird der Punkt gar nicht geschrieben. Da in der GeoTiff und der abgeleiteten BIL Datei - übrigens im Gegensatz zu den Original HGT Dateien der NASA – ohne vorherigen manuellen Eingriff die Werte für den Meeresspiegel fehlen, fehlen dann oftmals einzelne ost- bzw. südwärts liegende Pixel. Diese fehlen ebenso wenn nur ein einzelner Pixel vorhanden ist, wie z.B. bei schmalen Landzungen, Molen, … Dieses Problem lässt sich dadurch beheben, dass den Punkten mit Meereshöhe in der GeoTiff bzw. BIL Datei - analog zu den HGT Dateien der NASA - ein Wert von 0 zugewiesen wird!
Gefundene Lösungen
Mit MICRODEM und BILxSRTM bin ich folgenden Weg gegangen:
1. Vereinigen ("mergen") der GeoTiff Daten zu einer großen, neuen Datei (vgl. Martins Beitrag #26). Diese wird von MICRODEM automatisch im proprietären MICRODEM DEM Format gespeichert. Um hier z.B. nur die 25 HGT Dateien für die von mit immer untersuchte GeoTiff Datei srtm_40_04.tif zu erzeugen, müssen dazu die nördlich, östlich und südlich anschließenden Dateien srtm_40_03.tif, srtm_41_03.tif, srtm_41_04.tif, srtm_41_05.tif und srtm_40_05.tif mit dazu geladen werden. Die Ergebnisdatei kann ich dann mit Global MApper schon nicht mehr öffnen. Wenn keine HGT Dateien am südlichen und östlichen Rand der betrachteten GeoTiff Kachel erzeugt werden sollen, kann auf das Vereinigen in einer großen DEM Datei verzichtet werden .
Zum Vereinigen der GeoTiff Kacheln in MICRODEM mit FILE | DATA MANIPULATION | MERGE | DEMS | DEMS-.- PICK MULTIPLE zunächst die gewünschten GeoTiff Dateien auswählen und unter einem neuen Namen abspeichern.
2. Da die Daten der GeoTiff Dateien bei einem Export in eine BIL Datei verschoben werden und die Ausgangsdaten einen generellen Versatz von 1.5" nach Norden und Osten gegenüber den Original NASA Daten im HGT Format aufweisen, wird der Header der DEM Datei modifiziert und die Datei neu gespeichert. Vgl. Klaus' Beitrag #27.
Mit FILE | DATA MANIPULATION | EDIT | DEM HEADER die zuvor vereinigte DEM Datei auswählen. Auf die Schaltfläche mit der Weltkugel im Bereich SW CORNER klicken und im anschließenden Unterdialog die angezeigten Koordinaten um exakt 3“ nach Süden versetzen. Sinnvollerweise dazu den Radio-Button bei SEC aktivieren, da die Werte dann direkt in Bogensekunden eingetragen werden können.
Nach Bestätigung des Unterdialoges die bei x und y angezeigten Werte auf die im grauen Bereich angezeigten Werte in Dezimalgrad abändern, da dieses nicht automatisch aktualisiert werden und den Dialog mit OK schließen.
Die abschließende Frage nach dem neuen Schreiben der DEM Datei (REWRITE DEM?) bestätigen.
3. Öffnen dieser großen, neuen Datei im proprietären MICRODEM DEM Format in MICRODEM und zuweisen von Werten für die Bereiche der GeoTiff Datei ohne Werte (Meeresspiegel) da anderenfalls Probleme beim Zerlegen der BIL Datei in HGT Dateien mit BILxSRTM auftreten (s.o.). Dazu mit EDIT| DEM HOLES | MISSING DATA TO SEA LEVEL den Bereichen ohne Höhenwert den Wert 0 (Meereshöhe) zuweisen.
4. Export der modifizierten Daten in die endgültige BIL Datei (File | Save DEM | BIL)
5. BIL Datei mit BILxSRTM in HGT Kacheln zerlegt.
Alternativ dazu habe ich dann noch mit Global Mapper und BILxSRTM folgenden Lösungsweg verfolgt:
1. Versatz von 1.5" nach Norden und Osten zwischen GeoTiff und HGT zurückgesetzt. Dadurch steht die Kachel gegenüber der Ausgangskachel jetzt am südlichen und westlichen Rand um 1.5" über. Am Nord- und Ostrand fehlen jeweils 1.5". Die Manipulation des GeoTiff Headers erfolgt mit dem Programm ListGEOg (GeoTiff Tools GUI, Download bei remotesensing.org).
2. Da in einer einzelnen, zurückgeschobenen "seamless" Datei nur 6000x6000 Punkte vorhanden sind, können daraus keine HGT Dateien erstellt werden. 5x5 HGT Kacheln erfordern 6001x6001 Punkte. Genauer gesagt sind es sogar 6002x6002 Punkte (s.o.), da anderenfalls bei den mit BILxSRTM erzeugten HGT Kacheln am östlichen und südlichen Rand Punkte fehlen!
Die GeoTiff Kachel in welcher die gewünschten HGT Dateien liegen, wird daher gemeinsam mit den benachbarten Kacheln geöffnet.
Wenn keine HGT Dateien am südlichen und östlichen Rand der betrachteten GeoTiff Kachel erzeugt werden sollen, kann auf das Öffnen der benachbarten Kacheln verzichtet werden.
3. Speichern einer "vergrößerten" GeoTiff Kachel, die jetzt nicht mehr "seamless" ist. Das Speichern der "vergrößerten" GeoTiff Kachel kann auch entfallen und stattdessen sofort eine „vergrößerte“ BIL Datei aus den gemeinsam geladenen, verschobenen GeoTiff Kacheln exportiert werden.
4. Zuweisen von Werten für die Bereiche der GeoTiff Datei ohne Werte (Meeresspiegel) da anderenfalls Probleme beim Zerlegen der BIL Datei in HGT Dateien mit BILxSRTM auftreten (s.o.).
5. Export in eine BIL Datei.
6. BIL Datei mit BILxSRTM in HGT Kacheln zerlegt.
Alternativ zu den Schritten 5 und 6 habe ich dann noch ein Lösung nur mit Global Mapper (außer der Headermanipulation) untersucht. Dazu habe ich ein Global Mapper Skript geschrieben und direkt 1°x1° große HGT Dateien erzeugt. Dabei wird die "vergrößerte" GeoTiff Datei in 1°x1° große BIL Dateien exportiert, denen im Skript sofort den Namen der entsprechenden HGT Datei zugewiesen wird. Dieses ist möglich, da sich die BIL Dateien und die HGT Dateien von der internen Datenstruktur her nicht unterscheiden.
Als Ergebnis fallen in allen drei von mir vorstehend beschriebenen Fällen (MICRODEM ==> BILxSRTM, Global Mapper ==> BILxSRTM, Global Mapper direkt) die Höhenlinien aus den Original NASA HGT Dateien mit denjenigen zusammen, die aus den HGT Dateien erzeugt wurden, die aus den CGIAR SRTM GeoTiff Dateien abgeleitet wurden (in Bereichen ohne Löcher in den Originaldaten). Dieses gilt sowohl für die mit Global Mapper erzeugten Höhenlinien als auch für die Höhenlinien aus DEM2TOPO.
Hier der oben dargestellet Bereich mit den neuen Höhenlinien in Global Mapper generierten Höhenlinien
und derselbe Bereich mit den DEM2TOPO erzeugten Höhenlinien
Ebenso stimmen die Zahlenwerte in den ASCII XYZ Dateien an den untersuchten Punkten überein. Im Folgenden der Vergleich der süddöstliche Ecke der aus der srtm_40_04.tif erzeugten N40E019.HGT und der Original N40E019.HGT.
Bis auf die Tatsache, dass ich mich evtl. noch einmal dirket an die CGIAR (wg. des Versatzes von 1.5" gegenüber den Original HGT Daten) wenden werde, ist meine Eingangsfrage dieser Diskussion damit endgültig geklärt und ich danke allen für die rege Diskussion.
Grüße
weoli
