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

Martin,

habe gerade nicht sehr viel Zeit mich mit der Materie zu befassen. Gestern abend habe ich mal angefangen den Grund für den fehlenden Pixel an der östlichen Kachelgrenze zu suchen. Da es schon spät war, bin ich nicht sehr weit gekommen. So weit aber schon mal vorweg, der Fehler beginnt bereits beim Abspeichern der *.BIL Datei. Da bekommt man schon einen Pixelshift mit MICRODEM rein. Bei Global Mapper übrigens nicht. Wenn man dann daraus *.hgt Dateien macht, pflanzt sich das fort und wird bei den aus der MICRODEM *.BIL erzeugten *.hgts noch größer. Ich hoffe, dass ich am Wochenende dazu komme das fortzuführen und kurz zusammenzufassen.

Grüße

weoli

PS "srtm_40_04_ARINFO_ASCII..." war der Name unter dem ich die Datei abgespeichert hatte, damit ich sie im Verzeichnis besser unterscheiden kann. Das ist die normale srtm_40_04.asc Datei. Die Adresse des italienischen FTP Servers hats Du ja zwischenzeitlich gefunden und die des CGIAR Servers steht im Eingangspost. Habe übrigens jetzt festgestellt, dass die Daten auf beiden Servern identisch sind. Meine Kachel vom CGIAR Server hatte ich am 18.09. runtergeladen. Das war in der Zeit der Umstellung von Version 4.0 auf 4.1. Jetzt liegen auf dem CGIAR Server dieselben Dateien vom 19.09. Bei denen ist dann auch der GeoTiff Header in Ordnung und es kommt keine Fehlermeldung beim Öffnen mehr. Damit entfällt das Anpassen des Headers wie weiter oben beschrieben.

PS

Martin,

Freitagnachmittag bei der Arbeit

mit fehlender Pixelreihe meinte ich nicht eine Pixelspalte oder -zeile in der "seamless" GeoTiff Kachel, sondern in der *.Bil oder den abgeleiteten *.hgts. Sobald ich Zeit habe, schreibe ich das mit ein paar Screenshots zusammen.

Ich nehme immer die 40_04 Kachel und sehe mir da die nordöstliche Ecke (N 45° E 20°) an. An den übrigen Ecken ist dann der Versatz gleich. Die 40_04er Kachel nehme ich deshalb, weil das die Kachel ist, deren Höhendaten ich für meine private Karte vom Gargano (Stifelsporn Italien) brauche.

Und nur ganz kurz zu den bisherigen Erkenntnissen:

Geotiff ==> Global Mapper ==> *.BIL kein Versatz (neue Kachel schließt oben rechts bei N 45° E 20° ab) ==> *.hgt mit BILxSTRM ergibt Versatz (1/2 Pixel nach Süden und Westen wenn ich es recht in Erinnerung habe, N 44° 59' 58.5" E 19° 19' 58.5")

Geotiff ==> MICRODEM ==> *.BIL ergibt Versatz (wenn ich es recht in Erinnerung habe 1/2 Pixel nach Norden und Westen N 45° 00' 1.5" E 19° 19' 58.5") ==> *.hgt mit BILxSTRM ergibt weiteren Versatz (1 ganzer Pixel [3'] nach Westen N 45° 00' 1.5" E 19° 19' 55.5")

Das liegt wahrscheinlich daran, dass die GeoTiff 6000 Pixel hat und exakt bei N 45° E 15° angebunden ist. Eine *.BIL oder *.hgt steht ja normalerweise um 1/2 Pixel über den Anhängepunkt hinaus. Das kann man sehr gut sehen, wenn man eine hgt in Global Mapper öffnet und das Gitternetz einblendet. Daher hat eine solche Kachel auch immer 1201 oder 3601 Pixel. Wenn man jetzt den Mittelpunkt des obersten linken Pixels der *.hgt betrachtet, liegt der z.B. exakt auf N 45° und E 15°. Bei der GeoTiff liegt der Mittelpunkt des obersten linken Pixels aber bei N 44° 59' 58.5" E 15° 00' 1.5". D.h. Du hast hier schon einen Versatz drin. (Bilder und genauere Auswertung folgen)

Grüße

weoli

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

Hallo Martin,

habe eben eine Mail an Dr. Jarvis rausgeschickt mit der Frage nach dem generellen Versatz von 1.5" nord- und ostwärts zwischen den CGIAR GeoTiff und den NASA HGT Daten. Wenn ich mich richtig erinnere ist dieser Versatz auch in ArcASCII Daten vorhanden. Kann ich zurzeit nicht nachsehen, da in der Arbeit.

Mal sehen, ob ich eine Antwort bekomme.

Grüße

weoli

Martin,

ich habe mir jetzt auch noch einmal die ArcASCII Dateien angesehen und bin dabei auf folgende Punkte gestoßen.

Du schreibst:

Zitat

Wegen der Lage des südwestlichen Pixels der GeoTiff Dateien hatte ich leider keine Antwort von CGIAR erhalten.

Ich denke, dass die Lage des südwestlichen Pixels einer ArcASCII Datei eigentlich direkt aus der Datei selbst zu entnehmen ist. Wenn ich mir die Beschreibung (die sich so ähnlich auch an anderne Stellen findet) und das zugehörige Bild bei ESRI_grid ansehe, ist das doch eigentlich recht klar erkennbar. Der linke untere Punkt wird hier durch die beiden Einträge xllcorner und yllcorner eindeutig festgelegt. Somit liegt dieser bei der von mit untersuchten Kachel srtm_40_04.asc exakt bei 40° N und 15° E. Sehr gute Erklärungen zu den Rasterformaten im Allgemeinen findest Du übrigens unter What_is_raster_data und zum ArcASCII Format unter esri_ascii_raster_format in der Online Hilfe zu ESRI ArcGIS 9.3

Das bestätigst Du ja eigentlich auch durch deinen Anmerkung:

Zitat

Wenn man in MicroDEM eine ArcASCII Datei von CGIAR öffnet (auch *.zip Dateien kann MicroDEM direkt öfftnen) und dann den Data Header anschaut, dann sieht man, dass die südwestliche Ecke genau auf dem Längen- bzw. Breitengrad liegt.

Damit dürfte der südwestliche Punkt der Kachel also eindeutig fest liegen. Wenn ich die beiden Dateien in Global Mapper lade, kann ich übrigens auch bei der GeoTiff, keinen Versatz erkennen. Die Kacheln liegen beide exakt zwischen 40° N - 45° N und 15° E - 20° E. Deinen Satz

Zitat

bei den ArcASCII Daten gibt es keinen Versatz, wie er bei den GeoTiff Daten in MicroDEM angezeigt wird.

kann ich also so für Global Mapper nicht bestätigen. Ich habe übrigens keine so schöne Darstellung der Ecken in MICRODEM hinbekommen, wie in Global Mapper. Wenn man in MICRODEM extrem reinzommt, fehlen mir da immer Pixelwerte. Ich habe es nicht geschafft so weit rein zu zoomen, dass ich exakt die Ecke der Kachel anzeigen kann.

Wenn man dann noch folgendes liest (z.B. bei http://www.climatesource.com/format/arc_asciigrid.html)

Zitat

xllcorner and yllcorner are given as the EDGES of the grid, NOT the centers of the edge cells. ARC/INFO supports other header strings that allow the centers of the edge cells to be given using xllcenter and yllcenter instead. The origin of the grid is the upper left and terminus at the lower right.

und sich das Bild auf der o.g. Wikipedia Seite ansieht, erkennt man, dass die in der ArcASCII Datei angegebenen Werte wieder - wie die Werte der GeoTiff Kachel - den Höhenwert für den Mittelpunkt eines Rasterpunktes definieren. Im Folgenden mal das Bild von der o.g. Wikipedia Seite mit ein paar Ergänzungen meinerseits (grüne Punkte und Markierung der Mittelpunktskoordinaten, gelbe Markierung des Rasterursprungs)

Wenn ich mir dann die srtm_40_04.asc Kachel in einem beliebigen (naja, er muss die großen Dateien öffnen können) Texteditor ansehe, erkenne ich da wieder dieselben Werte wie in der GeoTiff Datei. Vgl. z.B. die obere linke Ecke der ArcASCII Datei

mit den Werte in der GeoTiff und der Original NASA HGT Datei

Und wenn ich dann aus der ArcASCII Datei Höhenlinien in Global Mapper erzeuge, so liegen diese exakt über den Höhenlinien, die ich in Global Mapper aus der GeoTiff Kachel erzeugt habe (in der folgenden Abbildung magenta, braun die Höhenlinien aus den NASA HGT Kacheln). D.H. die Höhenlinien sind wieder nach Nordosten versetzt.

Sehr überraschend finde ich es daher, wenn ich die Höhenlinien, so wie Du es auch gemacht hast über den Weg MICRODEM ==> BIL ==> BILxSRTM ==> HGT generiere. Da bekomme ich dann Höhenlinien, die wieder deckungsgleich mit denjenigen liegen, die aus den Original HGT Dateien erzeugt wurden. In der folgenden Abbildung z.B. die Höhenlinien der Original NASA HGT Datei, der über den Weg MICRODEM ==> BIL ==> BILxSRTM erzeugten HGT Datei und der manipulierten CGIAR GeoTiff Datei (von mir um 1.5" nach Südwesten versetzt, s.o. #45).

Das halte ich aber eher für ein zufälliges Ergebnis, das mit einem Versetzen der Daten beim Exportieren der Arc ASCII Datei in eine BIL Datei mit MICRODEM zusammenhängt. Schön das es so funktioniert, aber aus meiner Sicht darf der einfache Export von Daten in ein anderes Format nicht dazu führen, dass sich das ganze Raster verschiebt. MICRODEM hat da beim Exportieren ziemliche Probleme. Oder es übernimmt einfach die Daten aus dem Ursprungsheader und überlässt es einfach dem Anwender die Dateiheader wieder richtig zu stellen. Ist ja aus meiner Sicht auch im Gegensatz zu Global Mapper eher ein Programm für Leute, die genau wissen was sie tun In Global Mapper habe ich solche Verschiebungen beim Exportieren in ein anderes Format bisher nicht feststellen können. Zum Vergleich noch mal die mit MICRODEM exportierte BIL Datei in Global Mapper halbtransparent über die originale ArcASCII Datei gelegt. Hier für die untere rechte Ecke, da unten links in der srtm_40_04.asc keine Werte vorhanden sind (Meeresfläche). Da sieht man sehr schön den Versatz um 1.5" nach Süden und Westen.

Grüße weoli