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 ...

    Angeregt durch die folgende Bemerkung von Jörn Weber in http://www.naviboard.de/vb/sho…php?p=247418&postcount=16


    Zitat

    Genau das was ich schrieb. Ordentlich korrigierte SRTM-Daten liefern bessere Höhenwerte, als die GPS-Empfänger selber. Deswegen ist mit den SRTM 1" Daten immer noch mehr zu erreichen, als mit dem Austausch der 10°x10° Matrix gegen das EGM2008.


    in einer der gerade laufenden interessanten Diskussionen über die Höhenmodell, Berechnung der Höhenmeter, … (z.B. http://www.naviboard.de/vb/showthread.php?t=31895 oder http://www.naviboard.de/vb/showthread.php?t=31850) habe ich mir die Frage gestellt, ob es lohnenswert ist aus den mittlerweile in Version 4 bei http://srtm.csi.cgiar.org vorliegenden SRTM-3 Höhendaten im GeoTiff Format SRTM-3 oder sogar SRTM-1 Höhendaten im HGT Format zu erstellen. Diese können dann z.B. in TTQV oder GTA.NET zur Ermittlung der Höhen aus dem DEM oder in GPSMapEdit (michus addons) zur Berechnung von Höhenlinien verwendet werden.


    Dabei stellt sich mir die erste Frage, was bedeutet "Ordentlich korrigierte Höhendaten"? Jörn meinst Du damit die korrigierten SRTM Daten der Version 2, die bei ftp://e0srp01u.ecs.nasa.gov/srtm/version2 heruntergeladen werden können?


    Beim weiteren Nachdenken habe ich mir dann die Frage gestellt wie genau Daten im HGT-Format sind, die aus den mittlerweile in Version 4 vorliegenden GeoTiff SRTM-3 Daten bei ftp://srtm.csi.cgiar.org abgeleitet werden.


    Grund dafür ist die Tatsache, dass ich vor kurzem einen Weg gefunden habe, wie ich die GeoTiff SRTM-3 Daten ins HGT Format wandeln kann.


    Dabei gehe ich wie folgt vor:


      Höhendaten der Version 4 im GeoTiff Format herunterladen




    Und jetzt meine generellen Fragen dazu an die Experten: Lohnt es sich HGT Daten im 3'' oder 1'' Raster aus den 3'' Rasterdaten im GeoTiff Format zu erzeugen? Sind die besser als die Daten der Version 2, die direkt im HGT Format heruntergeladen werden können? Werden dadurch die Ergebnisse besser?


    Die Frage ergibt sich bei mir deshalb, weil bei http://seamless.usgs.gov/faq/srtm_faq.php folgendes zu finden ist:


    Zitat

    SRTM data were processed from raw radar echoes into digital elevation models at the Jet Propulsion Laboratory (JPL) in Pasadena, CA. These original data files had samples spaced ("posted") at intervals of 1 arc-second of latitude and longitude (about 30 meters at the equator) […]


    Daraus schließe ich, dass die Originaldaten eine Genauigkeit von 1'' hatten. Weiter geht es dann mit:


    Zitat

    The editing, also referred to as finishing, consisted of delineating and flattening water bodies, better defining coastlines, removing "spikes" and "wells", and filling small voids. This set is publicly available at two postings: 1 arc-second for the United States and its territories and possessions, and 3 arc-seconds for regions between 60 degrees N and 56 degrees S latitude.


    The method NGA used to produce 3 arc-second data from the 1 arc-second set is "subsampling", namely selecting the center value from the set of nine centered on a particular posting location. This is the method that has been used to produce the 3 arc-second "finished" data that are available through The National Map Seamless Server.


    Der erste Abschnitt beschreibt die Aufbereitung der Originaldaten SRTM Höhendaten der Version 1 zum Erhalten der Daten der Version 2. Für die USA stehen diese als 1'' zur Verfügung, für den Rest der Welt zwischen 60° Nord und 56° Süd als 3'' Daten. Interessanter finde ich dann den zweiten Absatz, denn da ist beschrieben, wie aus den 1'' Daten die 3'' Daten abgeleitet wurden. Wenn ich es richtig verstanden habe (auch aus dem Dokument SRTM_Topo.pdf bei ftp://e0srp01u.ecs.nasa.gov/srtm/version2/Documentation) wurde dabei der Höhenwert für einen Punkt im 3’’ Raster durch Mittelwertbildung der Werte der 9 umliegenden Punkte im 1’’ Raster gemittelt.


    Ist es dabei wirklich so wie in SRTM_Topo.pdf beschrieben, dass die SRTM-3 Daten nach Meinung der Experten besser (''a superior product'') sind als die 1’’ Daten?


    Zitat

    It is felt by most analysts that the averaging method produces a superior product by decreasing the high frequency ‘noise’ that is characteristic of radar-derived elevation data. This is similar to the conventional technique of ‘taking looks’, or averaging pixels in radar images to decrease the effects of speckle and increase radiometric accuracy, although at the cost of horizontal resolution.


    Aus den nicht aufbereiteten 3'' Daten der Version 1 wurden die bei ftp://srtm.csi.cgiar.org zu findenden Daten im GeoTiff Format abgeleitet:


    Zitat

    What is the source of this data, and why is it different from the NASA data?


    The current dataset (Version 4) has been produced based on the finished-grade 3 arc-second SRTM data released by NASA and distributed by the USGS through ftp access (ftp://edcsgs9.cr.usgs.gov/pub/data/srtm/version1/). The original data came with data voids, where insufficient contrast was available in the radar data to extract the elevation. These data voids tend to occur over water bodies (lakes and rivers), areas with snow cover and in mountainous regions (for example, the Himalayas has the greatest concentration of no data voids in the original data). The CGIAR-CSI SRTM dataset has undergone post-processing of the NASA data to “fill in” the no data voids through interpolation techniques (see the Data Processing and Methodology page for detailed description). The result is seamless, complete coverage of elevation for the globe.


    In die aufbereiteten SRTM-3 Daten der Version 4 sind mittlerweile eine Vielzahl von zusätzlichen DEMs (u.a. auch Jonathan de Ferrantis Höhendaten) zum Verbessern fehlerhafter Daten eingeflossen.


    Wenn ich daraus 3'' Daten ableite gehe ich davon aus, dass durch die Umwandlung der GeoTiff Daten ins BIL Format die Genauigkeit erhalten bleibt, da lediglich die Koordinatenpaare und Höhenwerte vom einem Binärformat in ein anderes Binärformat umgewandelt werden. Wenn ich dann aus den 5°x5° großen Kacheln 6000x6000 Pixeln (1 Pixel = 0,000833°) mit BILxSRTM 1°x1° STRM-3 Kacheln bleibt die Genauigkeit genauso erhalten, da jede Kachel 1201x1201 Pixel groß ist. 1201 = 6000/5 + 1 Pixel Überlappung der Daten. Jeder Pixel hat dann immer noch dieselbe Höheninformation.


    Lohnt sich jetzt der Aufwand aus den SRTM-3 Daten SRTM-1 Daten zu machen. Die 1°x1° SRTM-1 ist immerhin auch 9mal so groß wie die SRTM-3 Kacheln. GPSMapEdit (michus addons) macht dann nach dem Laden von 5 Kacheln schlapp. Oder sollte man hier die Interpolation für die Punkt innerhalb des 3“ Rasters besser dem auswertenden Programm (z.B. TTQV, GTA.NET, …) überlassen.


    Leider gibt der Autor von BILxSRTM keine Angaben, wie er die Werte für die 1’’ HGT Daten berechnet.


    Grüße

    Hallo,


    Zitat von weoli

    A habe ich mir die Frage gestellt, ob es lohnenswert ist aus den mittlerweile in Version 4 bei http://srtm.csi.cgiar.org vorliegenden SRTM-3 Höhendaten im GeoTiff Format SRTM-3 oder sogar SRTM-1 Höhendaten im HGT Format zu erstellen. Diese können dann z.B. in TTQV oder GTA.NET zur Ermittlung der Höhen aus dem DEM oder in GPSMapEdit (michus addons) zur Berechnung von Höhenlinien verwendet werden.


    Du bist nicht der erste der sich diese Frage stellt. Jonathan de Ferrati BA. betreibt dieses Geschäft seit ein paar Jahren. Wenn Du möchtest kannst Du Ihn gerne unterstützen.


    http://www.viewfinderpanoramas.org/dem3.html


    Es ist aber sinnfrei den Job doppelt zu machen.


    Zitat


    Dabei stellt sich mir die erste Frage, was bedeutet "Ordentlich korrigierte Höhendaten"? Jörn meinst Du damit die korrigierten SRTM Daten der Version 2, die bei ftp://e0srp01u.ecs.nasa.gov/srtm/version2 heruntergeladen werden können?

    Die version 2 der SRTM-Daten sind in der Höhe schon vom US-Militär mit
    dem EGM96 korrigiert. Die haben die notwendigen Supercomputer dafür. Das EGM96 hat eine Auflösung von 30x30 Minuten. Das entspricht ca. 50x50 km. Damit konnte nicht alle lokalen Höhenanomalien erfasst werden. Desweitern gab es kein Umrechnung dieser in Meterwerte. Hinzu kommt das die Polarregionen fehlten. deshalb wurde aus diesen Daten kein MSL-Model wie das EGM2008 abgeleitet.


    Zitat


    Beim weiteren Nachdenken habe ich mir dann die Frage gestellt wie genau Daten im HGT-Format sind, die aus den mittlerweile in Version 4 vorliegenden GeoTiff SRTM-3 Daten bei ftp://srtm.csi.cgiar.org abgeleitet werden.

    Das kann ich nur grob abschätzen. Die SRTM-3" in der koorigierten Fassung der CIGAR sind basser als die Globe30 und SRTM-30" in der Genauigkeit, besitzen aber mehr Löcher. CIGAR stopft nun die Löcher der SRTM-3" mit den Globe-30" Daten. Hinzu kommt das diese daten nur bis ca. 80° nördlicher Breit zur verfügung stehen.


    Jonathan de Ferranti hat nun eine Möglichkeit gefunden, den russischen Militärkarten Ihr Höhenmodell zu entziehen und die damit die CIGAR-Daten noch mals zu verbessern. Dieses Höhenmodell erfordert aber massiven manuellen Aufwand, da Jonathan jede Kachel manuell nachbearbeitet.


    Zitat


    Grund dafür ist die Tatsache, dass ich vor kurzem einen Weg gefunden Und jetzt meine generellen Fragen dazu an die Experten: Lohnt es sich HGT Daten im 3'' oder 1'' Raster aus den 3'' Rasterdaten im GeoTiff Format zu erzeugen? Sind die besser als die Daten der Version 2, die direkt im HGT Format heruntergeladen werden können? Werden dadurch die Ergebnisse besser?

    Bevor CIGAR den Job gemacht hat, haben wir unsere SRTM-Daten mit 3DEM und Blackart selber aufbereitet.


    Zitat


    Daraus schließe ich, dass die Originaldaten eine Genauigkeit von 1'' hatten.

    Jain. Die SRTM Daten mit 3 Sekunden genauigkeit gehören den USA und sind Public-Domain entsprechend dem Act of freedom for Information. Die SRTM-Daten mit 1 Sekunde Genauigkeit gehören der Bundesrepublik Deutschland und werden von der DLR für viel Geld verkauft. Nur für die USA sind die sind die SRTM Daten mit 1 Sekunde Genauigkeit offen gelegt. Das war der Fuhrlohn den Deutschland an die USA für das Space Shuttle zur errichten hatte. Die Italien haben ebenfalls Ihre SRTM-Daten erhalten, weil die sich mit Know How beteillgt hatten. Es war schon kurios, das die SRTM-Mission 3 verschiedene Radars an Bord hatt. 2 gehörten den USA und das ein gehörte Deutschland.


    Zitat


    Weiter geht es dann mit:

    Inzwischen ist Deutschland nicht mehr auf die USA angewiesen. Die Bundeswehr besitzt 5 und die DLR einen Satelliten SAR Satteliten. Die Auflösung des DLR-Satelliten Beträgt 15 cm und die der Militärsatelliten ist gehaim. Sicherlich aber deutlich besser als die des DLR-Satelliten. Diese Satelliten wurden übrigens mit einer russischen Träger-Rakete in Umlauf gebracht. So das die USA außen vor sind. Deutschland tauscht die Daten aber gelegenlich schon mal gegen französiche Satellitenbilder ein.

    Was man mit diesen Daten anfangen kann, zeigt das Proof of Konzept hier:


    http://www.realitymaps.de/



    Zitat


    Ist es dabei wirklich so wie in SRTM_Topo.pdf beschrieben, dass die SRTM-3 Daten nach Meinung der Experten besser (''a superior product'') sind als die 1’’ Daten?

    Was ist gut und was ist schlecht. Um so hochauflösender die Daten umso mehr wirken sich die Schatten des Seitenradar-Prinzips aus. Wenn ich die extrapoliere wird die Zuverlässigkeit besser. Wenn ich Daten interpolier, wird sie schlechter. Momentan ist die einhällige Meinung, das die Daten von Jonathan de Ferranti die besten Daten sind. Selbst CIGAR verweist auf diese Daten. Die deutschen 1" SRTM sind zwar theoretisch genauer aber besitzen sehr viele Löcher. Gleiches gilt für Höhendaten aus den Laser-Scannern. Diese müssen massiv nachgearbeitet werden.



    Zitat


    Wenn ich daraus 3'' Daten ableite gehe ich davon aus, dass durch die Umwandlung der GeoTiff Daten ins BIL Format die Genauigkeit erhalten bleibt, da lediglich die Koordinatenpaare und Höhenwerte vom einem Binärformat in ein anderes Binärformat umgewandelt werden. Wenn ich dann aus den 5°x5° großen Kacheln 6000x6000 Pixeln (1 Pixel = 0,000833°) mit BILxSRTM 1°x1° STRM-3 Kacheln bleibt die Genauigkeit genauso erhalten, da jede Kachel 1201x1201 Pixel groß ist. 1201 = 6000/5 + 1 Pixel Überlappung der Daten. Jeder Pixel hat dann immer noch dieselbe Höheninformation.

    Wenn du Jonathan's 1" Daten zu 3"-Daten extrapolierst bleibt die Genauigkeit in der Höhe erhalten, aber du verschlechterst das Raster. Was willst Du damit erreichen?


    Zitat


    Die 1°x1° SRTM-1 ist immerhin auch 9mal so groß wie die SRTM-3 Kacheln. GPSMapEdit (michus addons) macht dann nach dem Laden von 5 Kacheln schlapp.

    Globalmapper kann auch Höhenlinien aus STRM oder GEOTiff generieren. Es ist nur eine Frage der CPU-Leistung. Es gab auch schon mal einen Dienstleiter, der diese besorgt hat. Leider habe ich die Adresse verbummelt.



    Gruss Joern Weber

    Jörn,


    besten Dank für deine ausführlichen Antworten. :danke: Wo nimmst Du nur die viele Zeit her? :???:


    Zitat

    Es ist aber sinnfrei den Job doppelt zu machen.


    Meine Frage betrifft ja eigentlich nicht das Patchen der Löcher in den SRTM-3 Daten, wie es Jonathan de Ferranti auf seiner Seite so schön verständlich beschreibt (bin ihm sehr dankbar für die so mühsam erstellten 1'' DEMs der Alpen), sondern ob es lohnenswert ist, aus den bei CGIAR-CSI vorliegenden Daten SRTM-3 Daten im GeoTiff Format eigene DEMs im HGT Format abzuleiten.


    Vielleicht habe ich mich da auch missverständlich ausgedrückt, oder manches, was ich die letzten Tage gelesen habe, in meinem ersten Post weggelassen. Z.B. das folgende Zitat vom CGIAR-CSI Konsortium:


    Zitat

    UPDATE - VERSION 4: THE SRTM DATA NOW AVAILABLE FROM THIS SITE HAS BEEN UPGRADED TO VERSION 4. THIS LATEST VERSION REPRESENTS A SIGNIFICANT IMPROVEMENT FROM PREVIOUS VERSIONS, USING NEW INTERPOLATION ALGORITHMS AND BETTER AUXILIARY DEMs. WE ARE CONFIDENT THIS IS NOW THE HIGHEST QUALITY SRTM DATASET AVAILABLE


    Und zu den Unterschieden der Versionen



    Das hatte mich eigentlich dazu veranlasst meine Frage zu stellen. Denn die CGIAR-CSI hat - so wie ich es jetzt verstanden habe - zum Patchen der als „finished“ bezeichneten SRTM-Daten der Version 2 der USGS bzw. NASA verschiedene Hilfs-DEMs, u.A. auch die Daten von John de Ferranti, und Methoden (siehe Abschnitte Auxiliary DEMs und Methodology auf http://srtm.csi.cgiar.org/SRTMdataProcessingMethodology.asp benutzt.


    Auf der zuvor genannten Seite und in dem dort verlinkten Dokument Reuter H.I, A. Nelson, A. Jarvis, 2007, An evaluation of void filling interpolation methods for SRTM data, International Journal of Geographic Information Science, 21:9, 983-1008 findet sich dazu folgender Abschnitt:


    Zitat

    The “finished” version of the SRTM data (described more fully in section 2.1) provided by USGS (United States Geological Survey) and NASA (National Aeronautics and Space Administration) still contains 3,399,913 voids accounting for 803,166 km² (an area comparable to Pakistan or somewhat larger than Texas), and in extreme cases, such as Nepal, they constitute 9.6% of the country area with some 32,688 voids totalling an area of 13,740 km².


    Wenn ich nun diese Daten mit den weiter gepatchten Fehlstellen (voids) im GeoTiff Format auf die im ersten Post beschriebene Weise ins HGT Format wandele, müsste ich dann ja eigentlich weiter verbesserte SRTM-3 Daten im HGT Format haben, als wenn ich die Daten der SRTM Version 2 direkt von der USGS oder der NASA nehme.


    Und für die USA nehme ich dann gleich die 1'' SRTM Daten von der USGS, für die Alpen die 1'' Daten von Johathan, …


    Zitat

    Wenn du Jonathan's 1" Daten zu 3"-Daten extrapolierst bleibt die Genauigkeit in der Höhe erhalten, aber du verschlechterst das Raster. Was willst Du damit erreichen?


    Da hast Du mich wohl falsch verstanden, ich wollte mit der im ersten Post beschriebenen Methode über MICRODEM und BILxSTRM aus den 3'' GeoTiff Daten auch 1'' Daten im HGT Format erzeugen. Das war eigentlich nur eine zusätzliche Anmerkung.


    Nachdem ich mit eben noch mal die Seiten von Jonathan de Ferranti und auch den oben genannten Aufsatz von Reuter et al. durchgelesen gehe ich auf jeden Fall davon aus, dass ich die Bestimmung der Höhenwerte zwischen den 3'' Rasterpunkten wohl getrost den verschiedenen Programmen überlassen kann, die ich mit den aus den GeoTiff Daten abgeleiteten 3'' DEMs füttere. Da muss ich mir nicht die Festplatte mit 1'' DEMs vollbunkern, die wahrscheinlich lediglich durch Interpolation in BILxSRTM zwischen den Rasterpunkten der 3'' Daten erzeigt werden.


    Zitat

    Globalmapper kann auch Höhenlinien aus STRM oder GEOTiff generieren. Es ist nur eine Frage der CPU-Leistung. Es gab auch schon mal einen Dienstleiter, der diese besorgt hat.


    Das weiß ich. Der Hinweis auf das schlappmachen von GPSMapEdit sollte eigentlich nur ein Hinweis darauf sein, dass die großen 1'' DEM Dateien in manchen Programmen zu Problemen führen können. In GlobalMapper geht es ja sogar viel komfortabler (mehr Einstellmöglichkeiten) und schneller als mit GPSMapEdit (michus addons). Es kostet aber Geld, weil ich Höhenlinien im Vektorformat nur mit der registrierten Version exportieren kann. Am Anfang habe ich statt GlobalMapper immer DEM2TOPO genommen, was ja auch die GeoTiff oder SRTM Daten einlesen kann.



    Grüße

  • 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


    Wo nimmst Du nur die viele Zeit her? :???:


    Jeder hat halt sein Hobby. Einiges ist dann bei meinem Buch http://www.kompass.at/produkte…osse-gps-handbuch-mit-cd/ auch nebenbei angefallen.


    Zitat von weoli


    Meine Frage betrifft ja eigentlich nicht das Patchen der Löcher in den SRTM-3 Daten, wie es Jonathan de Ferranti auf seiner Seite so schön verständlich beschreibt (bin ihm sehr dankbar für die so mühsam erstellten 1'' DEMs der Alpen), sondern ob es lohnenswert ist, aus den bei CGIAR-CSI vorliegenden Daten SRTM-3 Daten im GeoTiff Format eigene DEMs im HGT Format abzuleiten.


    Die Daten von CIGAR sind deutlich besser als die Version 2 der NASA-Daten, das hatte ich als selbstverständlich vorausgesetzt. Sie liegen aber in der Qualität unter denen von Jonathan, denn Daten-Substanz lässt sich nicht durch Interpolation ersetzten. Ich bin der Meinung das es sich nur lohnt die CIGAR-Daten noch weiter zu verbessern, wenn man zusätzliche Substanz hineinbringt. Jonathan tut das, in dem er das DEM der ehemaligen UdSSR in die SRTM-Daten einbringt. Gerade im Himalaja ist die russische Substanz an Höhendaten extrem wichtig, da hier das Seitenradar an seine Grenzen kommt. Wenn Du jetzt die 3" SRTM-Daten von CIGAR verbessern willst, dann solltest Du schauen ob Jonathan schon die betreffende Kacheln überarbeitet hat, wenn ja dann macht es nur Sinn diese zu interpolieren, da sie die Daten der UdSSR bereits enthalten. Sollte Jonathan da noch nicht an den kacheln dran gewesen sein, müsstest Du selber die Daten der UdSSR mit denen von CIGAR verheiraten und diese verheirateten Daten dann interpolieren. Das hieße dann aber gleichzeitig sich mit Jonathan abzustimmen, um doppelte Arbeit zu vermeiden.



    Gruss Joern Weber

    Hallo Jörn,

    sieht cool aus das Buch. Werde es sobald als möglich mal bestellen,
    obohl ich das Geröt, Navigieren verstehe (so denke ich mal).
    Ich auch gut wenn Bekannte sich mit dem Thema befassen wollen, so hab ich was um ihnen für's erste mal in die Hände zu drücken:p


    Wenn ich euch so nachlese komme ich mir immer so "klein" vor.
    Mir fehlt einfach die Zeit mich mit der ERstellung der Karten so fest zu vertiefen und wenn ich dann immer so "Schubeise" dazukomme fehlt immer wieder was. Das wäre für mich schon sehr viel hilfreicher, einen roten Faden zum nachlesen wie das so funktioniert.

    Gruss und Danke für deine aktive Hilfe hier im Forum
    Stefano

    Hallo stefano,


    Zitat von Stefano


    obohl ich das Geröt, Navigieren verstehe (so denke ich mal).



    Freud mich, das Buch ist aber keine Bedinungsanleitung, sondern soll ein Überblick über den Dinge geben und bei der Auswahl von Karten und gerät helfen. Die FAQ's halt, die hier immer wieder aufschlagen.


    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...


    Hi, Weoli,


    Also ich habe dies mal versucht nachzuvollziehen.
    Leider ist mir dies mit den Daten im GeoTiff-Format nicht gelungen.
    In MICRODEM 10.0, Build 2008.11.2 fehlte bei mir die Möglichkeit ins BIL-Format zu exportieren.
    Habe ich da etwas übersehen.???
    Wie dem auch sei bin ich dann auf die Idee gekommen es noch einmal zu probieren und habe die Daten nochmals im ArcInfo ASCII-Format heruntergeladen.
    Und siehe da, nach dem Import als DEM hatte ich nun die Möglichkeit als BIL zu speichern.
    Ich wollte das nur kundtun falls noch jemand das gleiche Problem hatte.



    Gruss Papaluna

    Inzwischen schaetze ich mal, dass die einfachste Moeglichkeit ohne Zahlen von Lizenzgebuehren fuer Programme ist, die .hgt Datein von Jonathan de Ferranti mit SRTM2OSM in OSM Dateien zu wandeln, und dann mit Mkgmap zu Garmin .img Datein. Mann muss sich nur eine kleine Batch Datei schreiben, und dann den PC rechnen lassen. Nur funktioniert das ganze eher schlecht mit SRTM 1" Daten von Jonathan, die Datenmengen sind dann einfach riesig - etwa 10x so groß - (obwohl das daraus resultierende .img ein gleich großes Raster hat - sprich alle 10m eine Hoeenlinie), ich weiß nicht wirklich woran das liegt (ob dies ein Fehler ist, bzw ob dies prinzipiell bedingt ist).

    Zitat von extemecarver

    Inzwischen schaetze ich mal, dass die einfachste Moeglichkeit ohne Zahlen von Lizenzgebuehren fuer Programme ist, die .hgt Datein von Jonathan de Ferranti mit SRTM2OSM in OSM Dateien zu wandeln, und dann mit Mkgmap zu Garmin .img Datein.


    Und was ist mit der Michus-Version von GPSMapEdit?


    http://michus.narod.ru/projects/gpsmapedit/addons.html


    Zitat


    Mann muss sich nur eine kleine Batch Datei schreiben, und dann den PC rechnen lassen. Nur funktioniert das ganze eher schlecht mit SRTM 1" Daten von Jonathan, die Datenmengen sind dann einfach riesig - etwa 10x so groß - (obwohl das daraus resultierende .img ein gleich großes Raster hat - sprich alle 10m eine Hoeenlinie), ich weiß nicht wirklich woran das liegt (ob dies ein Fehler ist, bzw ob dies prinzipiell bedingt ist).


    Die Datenmenge ist tatsächlich eher etwas für Mainframes, der Algorithmus dahinter nicht trivial, und es ist noch nicht das Ende der Fahnenstange (Siehe öffentliche Höhendaten von Südtirol). Eigentlich ist es Wahnsinn aus den den SRTM 1" Daten vorneweg schon zu Höhenlinien zu plotten. Ein geeigneter Kartenplotter würde das auch in Echtzeit für den jeweiligen Kartenausschnitt erledigen können. Garmin unterstützt zwar digitale Höhendaten, aber nicht deren plotten in Echtzeit.


    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...

    Da brauche ich aber weiterhin cgpsmapper, oder?


    Ausserdem Crashed die 1.040 Version von Michus wenn ich damit versuche ein Jonathan de Ferranti SRTM 1" zu oeffnen.


    Ich glaube SRTM2OSM ist der deutlich einfachere Weg. Ganz Oestereich mit SRTM3 von Jonathan de Ferranti, sowie fuer Gegenden wo es diese nicht gibt normale SRTM Dateien benoetigen bei mir etwa 1 Stunde bis alles fertig ist. Wenn das Batch gut geschrieben ist, ein Klick und dann rechnen lassen bis die Karte fertig ist (etwa 2 Stunden auf meinem Laptop). Das schwerste ist festzulegen, wie groß die Kacheln sein sollen, und die Koordinaten rauszusuchen.


    Mit SRTM2OSM kann ich wenigstens die SRTM1" Dateien noch verarbeiten ohne Crash, nur muss ich halt die Kachelgroeße so auf 0.1*0.1 setzen damit es hinhaut. SRTM3" fuer Oesterreich hat bei mir dann 128MB Groeße, Hohenlinien alle 10m.

    Zitat von extemecarver

    Da brauche ich aber weiterhin cgpsmapper, oder?


    Du kannst auch die Compiler von Mapdekode oder JürgenD verwenden.


    Zitat

    Ausserdem Crashed die 1.040 Version von Michus wenn ich damit versuche ein Jonathan de Ferranti SRTM 1" zu oeffnen.


    Schreib einen Bugreport in englisch an Michus.


    Zitat


    Ich glaube SRTM2OSM ist der deutlich einfachere Weg.


    Ok, das mag dann sein. Übrigens GlobalMapper kann auch Höhendaten zu Höhenlinien ausplotten.


    Gruss Joern Weber

    Zitat von Joern_Weber


    .....
    Übrigens GlobalMapper kann auch Höhendaten zu Höhenlinien ausplotten.


    Gruss Joern Weber



    Hi, das klappt sogar hervorragend.
    So sieht meine Top10 NRW in TTQV jetzt aus:
    (Höhenlinien 10m aus dem DGM5 der Top10-NRW erzeugt und als Overlay über die Top10 gelegt):
    Kartenmaterial + Höhendaten (c) LVMA-NRW, Screenshot TTQV 4.0 (c) Touratech GmbH


    [Blockierte Grafik: http://up.picr.de/1511541.jpg]

  • 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 Papaluna,


    habe mal versucht die folgende Problematik


    Zitat

    In MICRODEM 10.0, Build 2008.11.2 fehlte bei mir die Möglichkeit ins BIL-Format zu exportieren.
    Habe ich da etwas übersehen.???


    nachzuvollziehen und weiß jetzt woran es liegt.


    Wenn Du die CGIAR Daten im GeoTiff Format runterlädst und versuchst die in irgendeinem Programm, das die Höhendaten anzeigen oder verwenden kann (GlobalMapper, DEM2TOPO, 3DEM, TTQV und auch MICRODEM), zu öffnen, kommt es zu Warnungen bzw. Fehlermeldungen, dass die Einträge (GeoKeys) im Datei-Header nicht vollständig sind. Es fehlen u.A. Informationen zum Kartenbezugssystem, … (z.B. Fehlermeldung von DEM2TOPO welche die fehlenden tags GTModelTypeGeoKey, GTRasterTypeGeoKey und GeographicTypeGeoKey anmahnt).


    Lädt man hingegen die SRTM3 Daten der NASA Version 2 bei http://seamless.usgs.gov/ im Geotiff Format runter und öffnet diese in einem der vorgenannten Programme so kommt keine Meldung. Man kann die Header der Dateien dann z.B. mit ListGEOg (GeoTIFF Tools GUI) analysieren.


    Vgl. den folgenden Header der Kachel srtm_40_04.tif von CGIAR, da müssten die vorgenannten GeoKeys hinter Keyed Information: folgen und normalerweise auch ein Block zur Definition des Kartenbezugsdatum, ...


    Geotiff_Information:
    Version: 1
    Key_Revision: 1.0
    Tagged_Information:
    ModelTiepointTag (2,3):
    0 0 0
    14.9995837 44.9995836 0
    ModelPixelScaleTag (1,3):
    0.000833333333 0.000833333333 0
    End_Of_Tags.
    Keyed_Information:
    End_Of_Keys.
    End_Of_Geotiff.



    Corner Coordinates:
    Upper Left ( 15.000, 45.000)
    Lower Left ( 15.000, 40.000)
    Upper Right ( 20.000, 45.000)
    Lower Right ( 20.000, 40.000)
    Center ( 17.500, 42.500)


    Im Vergleich dazu ein Header einer GeoTiff Datei von seamless.usgs.gov (Kachel deckt einen kleineren Bereich ab, als die vorgenannte)


    Geotiff_Information:
    Version: 1
    Key_Revision: 1.0
    Tagged_Information:
    ModelTiepointTag (2,3):
    0 0 0
    15.30625 42.1120833 0
    ModelPixelScaleTag (1,3):
    0.000833333333 0.000833333333 0
    End_Of_Tags.
    Keyed_Information:
    GTModelTypeGeoKey (Short,1): ModelTypeGeographic
    GTRasterTypeGeoKey (Short,1): RasterPixelIsArea
    GTCitationGeoKey (Ascii,219): "IMAGINE GeoTIFF Support\nCopyright 1991 - 2001 by ERDAS, Inc. All Rights Reserved\n@(#)$RCSfile: egtf.c $ $Revision: 1.11.2.3 $ $Date: 2004/11/24 09:12:56EST $\nProjection Name = GCS_WGS_1984\nUnits = dd\nGeoTIFF Units = dd"
    GeographicTypeGeoKey (Short,1): GCS_WGS_84
    GeogAngularUnitsGeoKey (Short,1): Angular_Degree
    End_Of_Keys.
    End_Of_Geotiff.


    GCS: 4326/WGS 84
    Datum: 6326/World Geodetic System 1984
    Ellipsoid: 7030/WGS 84 (6378137.00,6356752.31)
    Prime Meridian: 8901/Greenwich (0.000000/ 0d 0' 0.00"E)


    Corner Coordinates:
    Upper Left ( 15d18'22.50"E, 42d 6'43.50"N)
    Lower Left ( 15d18'22.50"E, 41d34'34.50"N)
    Upper Right ( 16d12'19.50"E, 42d 6'43.50"N)
    Lower Right ( 16d12'19.50"E, 41d34'34.50"N)
    Center ( 15d45'21.00"E, 41d50'39.00"N)

    Wenn man nun die fehlenden tags (den tag GTCitationGeoKey hab ich nicht eingetragen) und den Block zwischen Enf_Of_Geotiff. ..... Corner Coordinates: in den CGIAR Daten analog zu den vorstehenden Einträgen ergänzt, lässt sich die CGIAR Datei ohne Meldungen in allen Programmen öffnen und in MICRODEM steht auf einmal auch wieder die Option zum Speichern als BIL zur Verfügung. Die Daten im ArcInfo ASCII-Format hingegen sind von Anfang an wahrscheinlich richtig referenziert und bringen alle nötigen Informationen mit. Daher kannst du die dann wohl auch immer im BIL Format exportieren. Scheint wohl eine Eigenart von MICRODEM zu sein. Allein mit dem Programm könnte man Tage verbringen um die ganzen Möglichkieten auszuloten.


    Grüße


    weoli

    Hallo,


    Zitat von weoli


    Wenn man nun die fehlenden tags (den tag GTCitationGeoKey hab ich nicht eingetragen) und den Block zwischen Enf_Of_Geotiff. ..... Corner Coordinates: in den CGIAR Daten analog zu den vorstehenden Einträgen ergänzt, lässt sich die CGIAR Datei ohne Meldungen in allen Programmen öffnen und in MICRODEM steht auf einmal auch wieder die Option zum Speichern als BIL zur Verfügung. Die Daten im ArcInfo ASCII-Format hingegen sind von Anfang an wahrscheinlich richtig referenziert und bringen alle nötigen Informationen mit. Daher kannst du die dann wohl auch immer im BIL Format exportieren. Scheint wohl eine Eigenart von MICRODEM zu sein. Allein mit dem Programm könnte man Tage verbringen um die ganzen Möglichkieten auszuloten.


    Deine Lösung wird provisorisch funktionieren, aber trotzdem einige Anmerkungen zum Hintergrund, falls jemand mit Unstimmigkeiten konfrontiert wird.


    Wenn Du das Map Datum WGS84 in die CIGAR-Daten rein schreibst machst Du praktisch ein Shift des Map Datum von Mean Sea Level (MSL) auf WGS84 ohne die Daten umzurechnen. Das kann böse Nebenwirkungen verursachen, da WGS84 auch ein vertikales Map Datum ist und sich bis zu 100 Meter in der Höhe von WGS84 unterscheidet. Des Weiteren unterscheiden sich WGS84 und MSL auf Grund der Welligkeit des Geoiden leicht in der Lage. Leider ist MSL momentan noch nicht wirklich als Map Datum eigenständig definiert, sondern nur über Höhenkorektursysteme vom WGS84 abgeleitet. Dabei steht noch nicht einmal fest welches System zur Ableitung verwendet wird? EGM97 oder EGM2008? Oder die alte 10°x10° Matrix?


    Das gesamte Thema ist halt noch eine Spielwiese für die Forschung.


    Gruss Joern Weber

    Joern,


    hab Dank für die interessante Anmerkung. Jede deiner kurzen Einlassungen wirft für mich meistens wieder eine Menge Fragen auf. :???:


    Z.B. schreibt ja sowohl die NASA als auch die CGIAR, so wie Du es oben angemerkt hast, dass für die herunterladbaren Höhendaten das 'horizontal datum' WGS84 und das 'vertical datum' EGM96 gültig ist. Gibt's da übrigens einen Unterschied zwischen EGM96 (CGIAR) und WGS84/EGM96 (NASA)? Auf beiden Seiten wird das 'vertical datum' unterschiedlich bezeichnet.


    Daher gehe ich davon aus (auch wenn ich Deinen post richtig verstehe), dass bei den heruntergeladenen Daten der Shift nicht eingerechnet ist. Die Korrektur des Shifts müsste ich mit einem Programm vornehmen und bekäme daraus die Werte für WGS84. Diese so korrigierten Werte wären dann die richtigen? Nur welches der 'consumer'-Programme (Global Mapper, TTQV, ...) berücksichtigt diesen Shift zwischen WGS84 und EGM96? Ich kann doch immer nur ein Datum angeben und das ist das Horizontaldatum. Woher sollten die Programme wissen, dass sie die Höhenwerte (seien es nun *.hgt Dateien der NASA, GeoTiffs der CGIAR oder USGS), die sie bekommen umrechnen müssten. Die Angabe des 'vertical datum' habe ich noch in keinem Headerfile oder GeoTiff-Header gesehen. Woher sollten die Programme die Information bekommen? Soweit ich das auf der Seite von remotesensing.org zu den GeoTiff Spezifikationen sehe, gibt es da zwar schon diverse 'Vertical ..' Keys zur Beschreibung des verwendeten Vertikaldatums, EGM96 fehlt aber. Man könnte es also gar nicht in den GeoTiff Header eintragen.


    Dieselbe Unstimmigkeit, wie bei den von mir im Header ergänzten GeoTiff Daten der CGIAR, tritt doch auch auf, wenn ich eine Original USGS GeoTiff Datei nehme. Auch da ist als Datum lediglich das Horizontaldatum eingetragen (siehe CGS ...). Auch die haben als Vertikaldatum aber EGM96. Daher muss man doch im Augenblick wahrscheinlich immer mit dieser Unstimmigkeit leben, oder? Außer man würde nach dem Herunterladen die Daten enstprechend aufbereiten. Für meine Anwendungsfälle zur Abschätzung der zurückgelegten oder vor mir liegenden Höhenmeter, kleine eigene Karten, ... wäre das wohl doch zuviel Aufwand.


    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...
    Zitat von weoli


    Z.B. schreibt ja sowohl die NASA als auch die CGIAR, so wie Du es oben angemerkt hast, dass für die herunterladbaren Höhendaten das 'horizontal datum' WGS84 und das 'vertical datum' EGM96 gültig ist. Gibt's da übrigens einen Unterschied zwischen EGM96 (CGIAR) und WGS84/EGM96 (NASA)? Auf beiden Seiten wird das 'vertical datum' unterschiedlich bezeichnet.


    EGM96 eigentlich kein vertikales Datum, sondern ein Korrektursystem zu WGS84. Dieses Korrektursystem ist aber seit Juli diesen Jahres technisch veraltet, da wir dank des US-Militärs jetzt EGM2008 besitzen. Diese ist auch ein Korrektursystem. Zur Definition eines echten vertikalen Map Datum muss man noch den Umgang mit der verbliebene Restungenauigkeit diskutieren. Diese ergiebt sich aus permanten Höhenschwankungen der Erdoberlfläche um rund 50 cm. Ja du liest richtig, zu jeder Sekunde ändert sich die Höhe unter deinen Füssen. Die Ursache hierfür sind die von Mond und Sonne verursachten Gezeiten. Momentan diskutieren die Geodäten und Geophysiker darüber, wie man damit umgehen will und muss. Wollen wir ein zero- mean- oder full- tide level basiertes System? Oder vielleicht doch gleich ein dynamischen zeitabhängiges Erdmodell.


    Zitat


    Daher gehe ich davon aus (auch wenn ich Deinen post richtig verstehe), dass bei den heruntergeladenen Daten der Shift nicht eingerechnet ist. Die Korrektur des Shifts müsste ich mit einem Programm vornehmen und bekäme daraus die Werte für WGS84. Diese so korrigierten Werte wären dann die richtigen? Nur welches der 'consumer'-Programme (Global Mapper, TTQV, ...) berücksichtigt diesen Shift zwischen WGS84 und EGM96? Ich kann doch immer nur ein Datum angeben und das ist das Horizontaldatum.


    Vergiss das vorerst. Du bist gerade an die Grenzen des technisch und wissenschaftlich machbaren gestossen. Lese die Unterlagen der European Geosciences Union General Assembly 2008 Vienna, Austria, 13 – 18 April 2008:


    http://meetings.copernicus.org/egu2008/index.html


    Ein Shift von EGM96 auf WGS84 mean ist nichtlinerar über die gesamte Kartenfläche und unter Berücksichtigung der Erdkrümmung und Gravitation zu realisieren. Statt das technisch veraltete EGM96 zu verwenden, ist es erstmal sinnvoll bei den SRTM-Daten das EGM96 gegen das EGM2008 auszuwechseln. Der nächste Schritt ist dann, WGS84 auf den Müllhaufen der Geschichte zu schaffen und durch ein unverselles Modell der Erde zu ersetzen, das sowohl die horizontale als auch die vertikale Komponente enthält. Erst danach ist über die Realisierung eines Shifts zwischen WGS84 und dem neuen System nachzudenken. Aber bis wir ein neues System besitzen, wird noch einige Zeit vergehen. Eventuell werden sogar noch leistungsfähigere Computer notwendig, als diejenigen die US-Militärs bisher besitzen oanders machbar.der wir uns momentan vorstellen können.


    btw. Sorry, wenn ich jetzt nicht alles tiefgreifend erläutert habe, aber das ist momentan nicht. Ich habe momentan nicht die Zeit das Thema populär aufzuarbeiten.


    Gruss Joern Weber

    Zitat von Klaus_K

    Hi, das klappt sogar hervorragend.
    So sieht meine Top10 NRW in TTQV jetzt aus:
    (Höhenlinien 10m aus dem DGM5 der Top10-NRW erzeugt und als Overlay über die Top10 gelegt):
    Kartenmaterial + Höhendaten (c) LVMA-NRW, Screenshot TTQV 4.0 (c) Touratech GmbH

    [Blockierte Grafik: http://up.picr.de/1511541.jpg]



    Das ist ja klasse!
    Leider durchschaue ich noch nicht, wie man das macht, sonst würde ich das Overlay für meine TOP10NRW auch gerne erstellen.

    Gruß
    Eli

    weoli: Danke für den Hinweis auf die Programme MICRODEM und BILxSRTM.
    Papaluna: Danke für den Hinweis mit dem ArcInfo ASCII Format
    @Joern_Weber: Danke für die Hinweise zu den Höhen- und Korrekturmodellen


    An einen Beitrag zum Thema GTA + SRTM-Daten hatte ich bereits zwei Bilder mit einem Ausschnitt des Karwendelgebirges angehängt, wo man den Unterschied von Version2 und Version4 der SRTM3 Daten sieht.

    Nun füge ich im Anhang noch ein Bild einer mit MICRODEM und BILxSRTM erstellten *.hgt Datei hinzu, es zeigt denselben Höhenwert an wie das Bild der Geotiff Datei.


    Das Erzeugen der *.hgt Dateien geht wirklich fix. Und weil eine Datei von CGIAR den Bereich von 25 *.hgt Dateien abdeckt, spart man sich außerdem noch die Zeit, die *.hgt Dateien einzeln herunterzuladen.


    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.
    Problem 2: Die Dateien von CGIAR enthalten am nördlichen und östlichen Rand keine Daten. Diese Daten fehlen entsprechend in den erzeugten *.hgt Dateien.


    Anmerkung: GPS-Track-Analyse.NET kann die mit MICRODEM und BILxSRTM erzeugten *.hgt Dateien verwenden, um Trackpunkten die Höhendaten zuzuweisen. Allerdings gibt es einzelne Fehler in der Zuweisung (ich denke das ist wegen fehlender Daten am Rand in den CGIAR Daten). Weil nach dem Zuordnen der Höhendaten die Trackpunkte in der Spalte Waypoints um den Eintrag " : (srtm)" ergänzt werden, kann man diese Stellen einfach finden, markieren und mit der Funktion "Trackpoints bearbeiten / Markierte Höhen angleichen" korrigieren. Genial, wie umfassend und anwenderfreundlich blackwilli das alles programmiert hat. (Habe jetzt erst gemerkt, daß man auch Routen einlesen kann. Da konnte ich mir den Umweg über WinGDB3 für eine Testroute von Helsingborg nach Vaduz sparen).
    weoli: Wenn ich im Programm BILxSRTM die Einstellung 3 arcsecond (entsprechend zu SRTM3) wähle, liefert GPS-Track-Analyse.NET ein "schönes" Höhenprofil. Wenn ich die Einstellung 1 arcsecond auf die SRTM3 Dateien anwende, sieht das Höhenprofil "sehr, sehr zackig" aus (außer der 10 fachen Dateigröße).


    Das Programm DEM2TOPO (in Verbindung mit IDL VM) liest die Geotiff Dateien korrekt ein, trotz der von weoli beschriebenen Fehlermeldungen (einfach mit Klick auf OK bestätigen). Dies kann man an den erzeugten *.mp Datein erkennen.
    Wer schon immer einmal seinen neuen schnellen Computerprozessor ausreizen wollte und eine Enttäuschung nicht scheut, sollte sich einmal Höhenlinien mit 10 m Äquidistanz erzeugen lassen. Das kann schon mal über 20 Minuten dauern und für srtm_38_03.tif geht es bei mir (wegen der Arbeitsspeicherbegrenzung von DEM2TOPO unter Windows) nur mit Linux (die erzeugte *.mp Datei ist dann auch 1,286 GB groß). Wenigstens kann man bei einem Mehrkernprozessor mit den anderen Kernen ganz normal in anderen Programmen weiterarbeiten. (Werde wohl auch mal den Jumper auf der Northbridge auf enable overvoltage umstecken.)


    Schließlich noch zwei Bilder im Anhang aus GPSMapEdit mit Höhenlinien (500m bis 670m) vom Wüstegarten (Kellerwald, Nordhessen):
    einmal original mit DEM2TOPO errechnet und einmal die roten Höhenlinien in GPSMapEdit "per Hand wieder zurückverschoben" (48 m nach Norden und 28 m nach Osten)
    - schwarze Höhenlinien (von den braunen überdeckt) aus: N51E009.hgt SRTM3 Version2 vom NASA Server
    - braune Höhenlinien aus: srtm_38_02.tif SRTM3 Version4 von CGIAR
    - rote Höhenlinien aus: N51E009.hgt mit MICRODEM und BILxSRTM erzeugt aus srtm_38_02.ASC SRTM3 Version4 von CGIAR


    Gruß, Martin

  • 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


    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.


    Problem 2: Die Dateien von CGIAR enthalten am nördlichen und östlichen Rand keine Daten. Diese Daten fehlen entsprechend in den erzeugten *.hgt Dateien.


    Das Problem scheint bei CIGAR zu liegen. Schreib CIGAR(Andy) deswegen am besten an. Du benötigst die CIGAR Daten in der Version 4.1.


    Gruss Joern Weber

    Zitat von Joern_Weber

    Schreib CIGAR(Andy) deswegen am besten an. Du benötigst die CIGAR Daten in der Version 4.1.


    Hallo Joern,


    wenn Du mit Deinem umfangreichen Fachwissen mir das schon empfiehlst, dann werde ich das auch tun. Danke für die Ermutigung. Über die Antwort werde ich dann hier berichten.


    Ich fühlte mich als "Freizeit-Ausprobierer" nicht ausreichend qualifiziert, mich direkt an CGIAR zu wenden. Im Forum zu MICRODEM habe ich auf die Schnelle auch nichts gefunden, wie man die Dateien von CGIAR richtig einlesen oder verschieben kann.


    Gruß, Martin

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