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

Garmin fenix 7X und epix Gen 2 im Test

Der Schwerpunkt dieses Tests und Vergleichs der Garmin Fenix 7X Solar und Garmin Epix Gen 2 liegt auf den Sensoren wie Höhenmesser, Positionsbestimmung und Herzfrequenz. Was unterscheidet die beiden GPS-Outdoor-Smartwatches? Und wie gut ist die Taschenlampe der Fenix 7X für den Outdoorbereich? Hier geht es zum Test der Outdoor-Smartwatches ...

    Martin,


    die Daten der VErsion 4.1 findest Du auch direkt auf dem FTP Server der CGIAR unter folgender Adresse ftp://srtm.csi.cgiar.org/SRTM_v41/SRTM_Data_GeoTIFF/. Denke, dass Du mit den Kachelbezeichnungen klar kommst.


    Joern, weißt Du um welche Daten es sich beim Herunterladen über die grafische Oberfläche der CGIAR handelt? Sind das die Daten der Version 4.1? Oder sind das noch Daten der Version 4.0? Ich hatte damals als die Daten von der 4.0 auf dei 4.1 umgestellt wurden durch Zufall gerade versucht Dateien vom FTP Server runterzuladen. Und da sind dann nach und nach die Daten im FTP Verzeichnis der Version 4.0 verschwunden. Die der Version 4.1 waren erst ein paar Tage unvollständig und wurden dann nach und nach vervollständigt. Jetzt sind die Verzeichnisse der Version 4.0 alle leer und direkt finde ich nur die Daten der Version 4.1 im GeoTiff Format.


    Grüße


    weoli

    Martin,


    noch etwas ist mir gerade eingefallen. Du schreibst


    Zitat

    Nun die Probleme auf die ich gestoßen bin:
    Problem 1: MICRODEM liest die *.ASC Dateien von CGIAR ebenso versetzt ein wie 3DEM die *.tif Dateien. Im Beispiel von Beitrag 13 wird die nördliche westliche Ecke eben nicht mit 45.000, 15.000 sondern mit 44.9995836, 14.9995837 eingelesen. Dadurch werden natürlich alle Höhendaten verschoben dargestellt, und bei der Erzeugung der *.hgt Dateien werden am westlichen und südlichen Rand der *.ASC Dateien zusätzliche *.hgt Dateien erzeugt; anstelle von 5 mal 5 werden 6 mal 6 *.hgt Dateien erzeugt.


    Muss das nicht sogar so sein. Die Geotiffs überlappen sich um jeweils eine Pixelreihe/-spalte am Anfang der Kachel . Deshalb auch 1201 bzw. 3601 Pixel. Jedes Pixel stellt 3"x3" dar (0,000833°x0,000833°). Die Pixel tragen die Information GTRasterTypeGeokey=RasterIsPixel. D.h. der angegebene Höhenwert bezieht sich auf den Mittelpunkt des Pixels. Bei 1 Pixel Überlappung ergeben sich so genau die angegebenen Koordinaten 44,9995836 = 45 - 0,000833/2 bzw. 14,9995837 = 15 - 0,000833/2.


    Siehe folgenden Abschnitt aus dem Dokument ftp://e0srp01u.ecs.nasa.gov/sr…umentation/Quickstart.pdf


    Zitat

    SRTM3 files contain 1201 lines and 1201 samples. The rows at the north and south ecges as well as the columns at the east and west edges of each cell overlap and are identical to the edge rows and columns in the adjacent cell. SRTM1 files contain 3601 lines and 3601 samples, with similar overlap.


    Ich bin bisher davon ausgegangen, dass dieser eine Pixel am Anfang der Kachel automatisch von den lesenden Programmen richtig berücksichtigt wird.


    Grüße


    weoli


    Edit: Text aus pdf der NASA zur Erläuterung

    Hallo Weoli,


    Zitat von weoli


    Joern, weißt Du um welche Daten es sich beim Herunterladen über die grafische Oberfläche der CGIAR handelt? Sind das die Daten der Version 4.1? Oder sind das noch Daten der Version 4.0? Ich hatte damals als die Daten von der 4.0 auf dei 4.1 umgestellt wurden durch Zufall gerade versucht Dateien vom FTP Server runterzuladen. Und da sind dann nach und nach die Daten im FTP Verzeichnis der Version 4.0 verschwunden. Die der Version 4.1 waren erst ein paar Tage unvollständig und wurden dann nach und nach vervollständigt. Jetzt sind die Verzeichnisse der Version 4.0 alle leer und direkt finde ich nur die Daten der Version 4.1 im GeoTiff Format.


    Ich weiß nur das CIGAR im Moment noch an der Umstellung von 4.0 auf 4.1 arbeitet. Deshalb gehe ich davon aus, dass an der GUI noch die Version 4.0 anliegt.


    Gruss Joern Weber

  • Datenschutz ist uns & Euch wichtig, daher verzichten wir auf Bannerwerbung & Web-Analysetools! Um das Forum zu unterstützen bitten wir Euch über diesen Link: bei Amazon zu bestellen....
    Für Euch ist das nur ein Klick, uns hilft es das Forum langfristig und werbefrei für Euch zu betreiben! Vielen vielen Dank...

    Hallo Martin,


    Zitat von Martin K


    Ich fühlte mich als "Freizeit-Ausprobierer" nicht ausreichend qualifiziert, mich direkt an CGIAR zu wenden.


    Sorry, ich habe aber auch nur begrenzte Kapazitäten.


    CIGAR ist ein gemeinnütziges Projekt. Die Leute die dort mitmachen, haben auch mal klein angefangen. Ich kann dir im Moment nicht sagen, wie weit CIGAR mit der Korrektur der Daten ist. Fakt ist aber das sie ein Problem mit der Kalibrierung hatten. Derjenige der dir helfen kann ist: a.jarvis (at) cgiar.org.



    Gruss Joern Weber

    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

    Er spannt den Norden aus über der Leere und hängt die Erde über dem Nichts auf.

    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.

  • Datenschutz ist uns & Euch wichtig, daher verzichten wir auf Bannerwerbung & Web-Analysetools! Um das Forum zu unterstützen bitten wir Euch über diesen Link: bei Amazon zu bestellen....
    Für Euch ist das nur ein Klick, uns hilft es das Forum langfristig und werbefrei für Euch zu betreiben! Vielen vielen Dank...

    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 Martin,


    bist ja gerade mächtig am probieren ;), War leider am WE krank und jetzt ruft die Arbeit wieder.


    Mir ist noch etwas eingefallen, was ich schon länger ausprobieren wollte, aber keine Zeit dafür gefunden habe.


    Im Dokument ftp://e0srp01u.ecs.nasa.gov/sr…tes_for_ARCInfo_users.pdf findet sich folgender Satz:


    Zitat

    Users of ARC/INFO or ArcView can display the DEM data directly after renaming the file extension from .HGT to .BIL.


    Dazu muss dann noch eine Header Datei erzeugt werden. Vgl. die Datei, die beim Abspeichern des GeoTiffs im *.BIL Format angelegt wird.


    Dann müsste ja eigentlich auch der umgekehrte Weg gehen. Und ein bisschen Suchen führt dann zu diversen Beschreibungen wie z.B. der folgenden


    Zitat

    So theoretically what you could do is :

    1. Download from Seamless in BIL format.
    2. Change the extension from .bil file to .hgt
    3. Rename the file so that it conforms to the hgt file name format.


    Die *.hgt Datei hat ja keine Header Datei. Da ergibt sich der "Header" sozusagen implizit aus dem Dateinamen, der die Lage des DEMs festlegt. Durch die vorstehende Vorgehensweise müsstest Du eigentlich auch *.hgt ohne den Umweg über BILxSTRM erzeugen können. Die 5°x5°-Kacheln dürften nur für viele Programm etwas groß sein. MapEdit++ ist mir vor längerem immer beim Laden mehrerer *.hgt Dateien abgestürzt, die ich aus einem GeoTiff erzeugt hatte.


    Die vorstehende Umwandlung ist übrigens auch im folgenden Thread http://forum.ttqv.com/viewtopi…0cdca7ed9d54f38f2c1f41b2c im TTQV Forum angesprochen. Jedoch hat der Schreiber seine Ergebnisse nicht mehr mitgeteilt.


    Grüße


    weoli


    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.

  • Datenschutz ist uns & Euch wichtig, daher verzichten wir auf Bannerwerbung & Web-Analysetools! Um das Forum zu unterstützen bitten wir Euch über diesen Link: bei Amazon zu bestellen....
    Für Euch ist das nur ein Klick, uns hilft es das Forum langfristig und werbefrei für Euch zu betreiben! Vielen vielen Dank...

    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 Martin,


    Zitat von Martin K


    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.


    Gratulation! tup


    Mit MicroDEM hatte ich vor vielen Jahren meine ersten DEM's gebaut. Das war noch in der Zeit vor CIGAR, als man die Löcher in den DEM noch selber stopfen musste.


    Noch ein Hinweiß für den Lernprozess in dem Du dich gerade befindest. Als nächstes solltest Du dich mit den Grundlagen der Erdmodellen und Ihre Unzulänglichkeiten befassen. Andernfalls läufst Du dich im Lernprozess zu den DEM's fest. Und wunder dich nicht, wenn Du feststellst, das selbst die amtlichen Höhenmodelle Deutschlands technisch auf den Müllhaufen der Geschichte gehören. Das ist historisch bedingt und nicht weiter schlimm, da wir in einem Umbruchprozess bei der Ansicht zu den Höhenmodellen stecken. Manch einer hat schon begriffen, das da von Einsteins Lehre einiges drin steckt. Viele hängen aber noch der alten "heilen" Welt der ortometrischen Höhen nach.


    Im Forum habe ich dazu schon einige Beiträge geschrieben, welche versuchen das Thema leicht verständlich abzuhandeln. Einige andere findest Du in http://www.kowoma.de/gpsforum/


    Gruss Joern Weber

    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

    Er spannt den Norden aus über der Leere und hängt die Erde über dem Nichts auf.

  • Datenschutz ist uns & Euch wichtig, daher verzichten wir auf Bannerwerbung & Web-Analysetools! Um das Forum zu unterstützen bitten wir Euch über diesen Link: bei Amazon zu bestellen....
    Für Euch ist das nur ein Klick, uns hilft es das Forum langfristig und werbefrei für Euch zu betreiben! Vielen vielen Dank...
    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 Martin K


    Ich habe ein paar Berechnungen angestellt zum Pixelabstand.


    Damit hast Du schon den Laien-Status hinter dich gelassen. Das ist nicht übertrieben. Die Profis der digitalen Kartographie rechnen alle mit Pixel pro Meter und nicht mit dem Maßstab. Das Du noch mit Meter pro Pixel rechnest ist dabei nur ein Schönheitsfehler. Viel wichtiger ist, dass Du das Prinzip verstanden hast.


    Zitat


    Wäre schön, wenn Du kurz überprüfen könntest, ob ich mich da nicht verrechnet habe:

    Da ich davon ausgehe, das einen Taschenrechner betätigen kannst, nur noch der Hinweis: Verwende eine grössere Anzahl von Stellen hinter dem Komma und runde genauer. Bei deinem ersten Zwischenergebnis wäre statt 57,8 mit 57,9 oder besser noch mit 57,883333 weiter zu rechnen gewesen. Irgendwann rächen sich die kleinen Schlampereien mal.

    Zitat


    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.

    Korrekt. Und genau des wegen werden einige Firmen jetzt die Höhendaten Ihrer Produkte austauschen müssen. Es ist ist halt der Lauf der Dinge. Vor Jahren waren wir hoch erfreut überhaupt Höhendaten zu haben, heute sollen sich schon genau sein.;) Die SRTM-Daten der Version 3 hatten übrigens noch einen Fehler von 12 Meter.


    Zitat


    Deine Ausführungen zu den Höhenmodellen sind im Moment zuviel für mich. Zu gegebener Zeit, werde ich aber dankbar darauf zurückkommen.

    Ja, mache das. Stelle die Fragen am besten öffentlich, dann haben alle was davon. Bis dahin reicht es, wenn Du im Hinterkopf behältst, dass sich die absolute Genauigkeit von Höhendaten nicht unter 50 cm drücken lässt. Alle genaueren Systeme verwenden relative Höhen bezogen auf einen willkürlich festgelegten Bezugspunkt.


    Zitat


    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.

    Korrekt. Im Kalten Krieg hat der Osten dem Westen verheimlicht, dass das im Westen genutzte Kartenbezugssystem einen Fehler besitzt. Das war möglich, weil der Fundamentalpunkt für das Kartenbezugssystem (Helmertturm) im Osten lag. Damit sass die Nato bis 1984 auf einem Kartenfehler von bis zu 2 Meter fest. Nach der wende flog der Schwindel auf. Die Karten mit Kartenfehler kammen im Osten in den Schredder, da as MfS dort noch einige andere Fallstricke eingebaut hatte. Die ordenlichen Karten der DDR (Staatsausgabe) wurde weiter verwendet und passten jetzt nicht mehr exakt zu den Karten des Westens. Dieses Probelm versuchte man dann noch auf unterschiedliche Art un Weise zu lösen. So kommt es, das heute im Harz die Karten mit dreierlei Kartenbezugsystemen aufeinander trefen. (Potsdam, PD83 und RD83). Das ist aber nur ein grober Abriss, die komplette Geschichte der Kartographie ist spannender als der beste Krimi und tragischer als die beste Komödie. Und die Geschichte schreibt weiter spannende Geschichten. Die SRTM-Daten sind aus einer Idee italienischer Wissenschaftler entsprungen, die mit deutscher Ingenieurkunst umgesetzt wurde und für die die USA das Transportfahrzeug lieferten. Die Ideen und die Arbeit eines Amateurs haben dann aus den halbgaren SRTM-Daten die jetzigen CIGAR-Daten gemacht. Ohne die Arbeit des britischen Hobby-Kartografen Jonathan de Ferranti hätten die SRTM-Daten immer noch mehr Löcher als ein alter Strumpf. De Ferranti schlachte dabei in Handarbeit die Höhendaten der Militärkarten der untergegangenen UdSSR aus. So ist das Zeugs aus dem Kalten Krieg wenigsten heute noch zu etwas gut. Außerdem hat er effektive Verfahren zum stopfen der Löcher in Höhendaten entwickelt.



    Gruss Joern Weber

    Papaluna,


    hab' Dank für den Hinweis. Gerade gestern hab ich im Installationsverzeichnis von MICRODEM die readme.txt gefunden. Und da steht es ja auch! Ich sag nur RTFM ;) Und dann steht es auch noch groß auf der Downloadseite. Lesen müsste man können.


    Grüße


    weoli

  • Datenschutz ist uns & Euch wichtig, daher verzichten wir auf Bannerwerbung & Web-Analysetools! Um das Forum zu unterstützen bitten wir Euch über diesen Link: bei Amazon zu bestellen....
    Für Euch ist das nur ein Klick, uns hilft es das Forum langfristig und werbefrei für Euch zu betreiben! Vielen vielen Dank...

    @martin


    Danke für den Hinweis auf den italienischen FTP Server :D Wenn man den direkt über einen FTP client öffnet, ist das ja eine richtige Fundgrube. Da liegen ja viel mehr Daten rum als auf dem CGIAR Server direkt:jubel: Der Pfad zum Server wird angezeigt, wenn man oben bei den Radio Buttons den italienischen Server wählt, im Webinterface irgendeine Datei auswählt und dann auf die zweite Seite des Webinterfaces wechselt. Entweder mit der Maus über die zum Download angebotene Datei fahren und den Pfad in der Statuszeiile des Browsers ablesen oder per Rechtsklick den Pfad speichern. Password ist keines erforderlich.


    Habe eben mal die verschiedenen Dateien in Global Mapper geöffnet. Da kommen ja selbst wenn man Daten derselben Version (?) direkt vom FTP Server oder über das Webinterface herunterlädt unterschiedliche Ergebnisse raus. Scheinbar sind die Daten je nach Server unterschiedlich.


    Aber eines habe ich zumindest in Global Mapper rein optisch schon mal festgetellt. 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.


    Bei den Daten vom CGIAR Server kann man dafür in Global Mapper sehr gut sehen, dass sie um jeweils einen halben Pixel gegenüber dem Gitter versetzt sind, was dann ja zu dem von Dir beschrieben Problem bei der Erzeugung der hgt Dateien mit BILxSTRM führt.


    Noch ein Hinweis. Bei den italienischen GeoTiff Daten ist ein *.twf Worldfile und eine *.hdr Headerdatei dabei, so dass beim Öffnen der Datei auch keine Fehlermeldung oder Abfrage nach der Projektion, ... kommen. ERGÄNZUNG: auch die GeoKeys im Datei-Header der GeoTiff Datei sind richtig eingetragen!


    Grüße


    weoli


    PS in dieser PDF Datei (geotiffs.pdf) sieht man die Ergebnisse für die verschiedenen Dateien

    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.

  • Datenschutz ist uns & Euch wichtig, daher verzichten wir auf Bannerwerbung & Web-Analysetools! Um das Forum zu unterstützen bitten wir Euch über diesen Link: bei Amazon zu bestellen....
    Für Euch ist das nur ein Klick, uns hilft es das Forum langfristig und werbefrei für Euch zu betreiben! Vielen vielen Dank...

    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.

    Er spannt den Norden aus über der Leere und hängt die Erde über dem Nichts auf.