Beiträge von Martin K

Hallo weoli,

schön, dass schreibst und mitliest.

Zitat

Gestern Abend habe ich mal angefangen, den Grund für den fehlenden Pixel an der östlichen Kachelgrenze zu suchen.

Die v4.1 Daten sind doch "seamless" also ohne Überlappung. Also wenn die westlichste Pixelspalte von srtm_40_04 genau auf der Linie von N40.000000° liegt, dann liegt die östlichste Pixelspalte auf (N45.000000 - 0,000833 =) N44.999167. Und auf N45.000000 liegen dann schon die Pixel der ersten Spalte von srtm_41_04.

Zitat

... der Fehler beginnt bereits beim Abspeichern der *.BIL Datei. Da bekommt man schon einen Pixelshift mit MICRODEM rein.

Das könnte gut sein, vielleicht auch schon beim Einlesen und vielleicht auch nur um einen halben Pixelabstand. Und vielleicht ist das auch bei DEM2TOPO so. Man müsste mal selbst eine Datei mit Höhendaten schreiben, um das genau überprüfen zu können. Aber da ist zurzeit auch meine Kapazitätsgrenze (zeitlich und vom Wissen her).

Zitat

Bei Global Mapper übrigens nicht.

Das wäre schön, wenn Du das einmal überprüfen könntest, wenn Du wieder mehr Zeit hast.

Zitat

Wenn man dann daraus *.hgt Dateien macht, pflanzt sich das fort und wird bei den aus MICRODEM *.BIL erzeugten *.hgts noch größer.

Das denke ich allerdings nicht und glaubte es mit Beitrag#38 ausgeschlossen zu haben. Und wie ich in Beitrag#39 gezeigt habe, liegen die Pixel der mit MicroDEM und BILxSRTM aus CGIAR v4.1 erzeugten *.hgt Dateien genau an derselben Position wie die aus den *.hgt Dateien der Version2 und zwar unabhängig davon, ob die *.hgt Dateien aus einzelnen *.ASC Dateien oder aus zusammengefügten (Funktion Merge) erzeugt wurden.

Gruß, Martin

Jetzt noch einmal das Karwendelgebirge aus Beitrag#18:

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.

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

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.

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

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

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

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.

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

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.

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

neue GPSMapEdit Version 1.0.53.0 vom 07. Nov. 2008

Homepage(englisch) Download(zip)

Gruß, Martin

neue MapEdit++ Version 1.0.53.295 vom 17. Nov 2008

Homepage(englisch) Download bei SourceForge.net

Michael Sotin bietet das Programm als 32-bit(i386) und 64-bit(AMD64) Version an. Die Datei kann mit dem Programm 7-Zip entpackt werden.

Unter Windows Vista 64-bit erhielt ich beim Programmstart eine Fehlermeldung, daß die Datei VCOMP90.dll nicht gefunden wird. Nach der Installation von "Visual C++ 2008 SP1 Redistributable Package (x64)" läßt sich das Programm starten.
Für 32-bit Betriebssysteme gegebenenfalls nach "Visual C++ 2008 SP1 Redistributable Package (x86)" suchen.

Gruß, Martin

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

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

Zitat von Romby

... Problematisch wirds schon für Leute, die mit dem GPS Track Viewer die Tracks nur mal ansehen wollen, weil sie da nur bis 2 MB Größe und 2000 Trackpunkten angezeigt werden. ...

Hallo Romby,

die Entscheidung, auf wieviele Trackpunkte Du die einzelnen Tracks reduzieren / filtern willst, musst Du schon selbst treffen. Als Benutzer wären mir persönlich Tracks mit vielen Trackpunkten lieber als solche mit wenigen, denn reduzieren / filtern kann ich dann noch selbst, wenn meine Software oder mein GPS Empfänger diesbezüglich Einschränkungen haben. Und bei der Ansicht in Google Earth sieht ein detailreicherer Trackverlauf auch besser aus. Aber vielleicht entscheidest Du Dich auch einfach, die Tracks einmal mit vielen Trackpunkten und einmal gefiltert mit wenigen Trackpunkten anzubieten.

Ein Track mit 4.000 Trackpunkten hat als *.gpx Datei in etwa eine Dateigröße von 0,2 MB. Selbst die über 100.000 Trackpunkte der 6.000 km langen North-Sea-Cycle-Route erzeugen gerade einmal eine *.gpx Dateigröße von 6,6 MB (hier als gezippte *.gdb Datei im Anhang) und stellen kein Problem für MapSource oder Google Earth dar. (Das Laden dauert eben nur ein paar Sekunden länger.)

... und wenn Du Dir schon die Mühe machst, eine schön gestaltete *.kmz Datei wäre auch nicht schlecht. Die Geländeansicht von Google Earth finde ich persönlich einfach sehr anschaulich, insbesondere für Ortsfremde.
Schließlich kann man sich auch noch auf Google Maps html Code erzeugen lassen, mit dem man sich die *.kmz Datei in einem Fenster auf der eigenen Webseite anzeigen lassen kann.

... Wegpunkte mit schöner Landschaftsicht, Verpflegungsmöglichkeiten, kulturellen oder religiösen Sehensürdigkeiten oder ähnliches wäre natürlich auch schön für einen Benutzer aber sicher sehr viel Arbeit für den Ersteller.

Zitat von Romby

... dass ich ungern mit Routen arbeite, dann hätte man weniger Wegpunkte. ...

Dazu wurde in den vorangegangenen Beiträgen schon alles gesagt: Für Deinen Zweck unbrauchbar.

Weiterhin viel Freude beim Basteln

Gruß, Martin

Kellerwaldsteig Wanderwege Jesberg

Hallo Kareem

Polar Equine Wearlink W.I.N.D.
Polar Equine RS800g3 mit Sirf III Empänger

Ich habe keine Ahnung von Pferden und auch nicht vom Reiten. Trotzdem möchte ich gerne meinen Kommentar abgeben: Ich denke einmal, daß bei einem Ausritt das Pferd eine höhere relative Pulsfrequenz erreicht als der Reiter, und deshalb die Pulsüberwachung des Pferdes interessanter und wichtiger ist. Für einen Tipp bezüglich der Auswahl der passenden Pulsuhr und der Anforderungen an den GPS Empfänger wären genauere Anforderungen und Budget hilfreich.

Mein persönlicher Tipp als Freizeitsportler: Von Polar den WearLink Gurt für das Pferd und die FS1 Uhr für gute Ablesbarkeit (Händler fragen, ob die Uhr wirklich die Signale des W.I.N.D. empfangen kann). Und für die Orientierung und Streckenaufzeichnung von Garmin das eTrexVistaHCX oder GPSMap 60CSx wegen guter Lesbarkeit, langer Batterielaufzeit und Speicherung der Wegaufzeichnung auf MicroSD Karte mit Platz für viele 100.000 Trackpunkte. Als Karte je nach Bedarf und Wissen: Karten von Garmin kaufen, nach kostenlosen und freien Karte von OpenStreetmap suchen oder eigene Karten oder Tracks erstellen oder danach suchen.

Schöne Fotos waren ja schon in diesem Beitrag.

Oder eben versuchen, wie man den Brustgurt von Garmin um das Pferd bekommt und dann zwischen zwischen Edge, Colorado oder Oregon auswählen.

Trainingsratgeber für Pferde (PDF in englisch)

Gruß, Martin

Hallo Torsten,

die Strecken werden ja auch als *.kmz Datei angeboten. Die würde ich in Google Earth öffnen und gleich wieder als *.kml Datei speichern. Anschließend mit GPSBabel in eine *.gpx Datei konvertieren.

Das ist mal ein tolles Angebot von Wanderstrecken im Internet. Danke für den Hinweis. Ich wünschte, daß es einmal alle Wanderstrecken, die in den topographischen Freizeitkarten verzeichnet sind - und oft eine sehr lange und interessante Geschichte haben - ebenfalls so angeboten würden. Lassen sich ja oft auch gut mit dem MTB fahren;).

Gruß, Martin

Hallo click,

zur Basiskarte kann ich leider auch nicht mehr sagen. Tatsächlich habe ich die Basiskarte auf meinem ehemaligen Nüvi oder Streetpilot noch nie benötigt, deshalb kann ich den Nutzen nicht beurteilen. Andere Quellen dazu kenne ich nicht.

Im letzten Jahr war ich selbst in der Situation, daß ich die neue CityNavigator auf meinem PC haben wollte. Ich hatte mich schließlich anstelle eines Kartenupdates für den Streetpilot für den Kauf eines Nüvi 350 entschieden. Wegen des Kaufdatums bekam ich das Kartenupdate kostenlos. So hatte ich die Karte auf meinem PC und in MapSource, und das Gerät habe ich in der Verwandschaft verschenkt. Als die im Sommer mit dem Auto nach Rügen gefahren sind, war der neue Rügendamm schon im Nüvi.

Wo sich nun die Kartenpolitik von Garmin geändert hat, überlege ich mir eben auch, ob ich mir was Neues kaufen kann und will, oder wie oder was. NüMaps Garantie und "lebenslange" Kartenupdates finde ich jedenfalls tolle Angebote.

In diesem Markt, wo es immer wieder neue Produktentwicklungen gibt, kann man immer nur eine beste Wahl treffen mit einer begrenzten Laufzeit. Aber beim Tanken ist ja die Laufzeit der Wahl des besten Zeitpunkts noch viel geringer, aber das ist nun wirklich zu weit weg von Deiner Frage.

Gruß, Martin

Hallo click,

beim günstigsten Internetanbieter (laut http://www.Idealo.de) hat sich der Preis des Geräts binnen Jahresfrist mehr als halbiert. Gleichwohl würde ich mir ein nüvi aus der 7*5er Serie kaufen, wenn es auf den Markt kommt - insbesondere des Routenspeichers, des Tracklogs und des Spurassistenten wegen. Letzteren stelle ich mir beispielsweise auf der Autobahn von Frankfurt/Main nach Wiesbaden hilfreich vor, oder ganz allgemein bei Autobahnabfahrten oder in fremden Großstädten. Da würde ich dann vielleicht auch noch gleich die 119€ für "lebenslange" Kartenupdates drauflegen. (Für transatlantische Geräte muß man entsprechend 119€ für Europa und noch einmal 119€ für Nordamerika zahlen, wenn das im nächsten Jahr so kommt, wie es hier und im NaviBoard erzählt und diskutiert wird.)

Laut der neuen, seit 15. Oktober 2008 gültigen nüMaps Garantie sind Kartenupdates innerhalb von 60 Tagen nach der ersten Nutzung (erster Satellitenfix) kostenlos. (siehe dazu auch hier im Naviboard). Das ist natürlich bei dem nüvi 670 insofern genial, weil auf dem Gerät mit höchster Wahrscheinlichkeit noch die CN 2008 Karten drauf sein werden und man durch das Update die Karten der CN 2009 (Europa und Nordamerika) auch gleich auf seinen PC, sprich in MapSource, bekommt.

Zur Basiskarte kannst Du bei Garmin in der Produktbeschreibung lesen: ja.

Viel Spaß bei der Entscheidungsfindung

Gruß, Martin