GTA.NET - Entwicklungsstadium, Fragen an die User

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 ...
  • Hi,


    also ich bin erdgebunden unterwegs und verwende dein Programm zur Nachbetrachtung von Roadstertouren.
    Die graphische Aufbereitung mit Hohenmodell und die Statistik sorgen da immer für Überraschungen im nachhinein.


    Dank und Gruß
    Geko

  • Hallöchen,
    die Anforderungsliste für die neue Version ist komplett und die Programmoberfläche sowie der Datenimport stehen.
    Jetzt müssen "nur" noch die Analyse, die Grafiken und die restlichen Tools mit Leben gefüllt werden. :huh:

    Die besonders gute Nachricht: Es konnten fast alle Wünsche aus den beiden Threads hier im Forum erfüllt werden.

    Bevor es jetzt richtig ans Eingemachte geht, will ich noch die Übernahme von Waypointnamen als Kommentare in die Trackliste abschließen.
    Nach dem Durchsuchen aller mir von Euch vorliegenden Trackdateien, konnte ich User Waypoints nur in folgenden Dateien finden:

    - GPX-Dateien generell,
    - TXT-Dateien aus MapSource,
    - NMEA-Dateien werden von mir gerade näher untersucht.

    Habt Ihr noch andere ASCII-Trackfiles, die schon von GTA unterstützt werden und die User Waypoints enthalten können?
    Voraussetzung ist eine Kennzeichnung als User Waypoint, ein enthaltener Name des Waypoints und natürlich die Position.
    Es geht ausschließlich um die so gekennzeichneten User Waypoints. Nur diese enthalten sinnvolle Namen, die es lohnt zuzuordnen.

    Gruß
    blackwilli

  • Hallöchen,

    ich habe gerade den Import von NMEA-0183 Dateien programmiert und dabei ein kleines Problem festgestellt:

    In den mir vorliegenden Dateien ist immer wieder mal zwischendrin die Höhenangabe im Datensatz $GPGGA (das 9. Datenfeld) auf 0.0 gesetzt, obwohl das Prüfflag "Empfängerwarnung" (2. Datenfeld im Datensatz $GPRMC) auf A=Daten Ok gesetzt ist.

    Kommt das häufiger vor, dass die Höhe einfach mal so auf 0.0 gesetzt wird, obwohl sie nicht 0.0 sein kann und der Empfang eigentlich ok ist?


    Das Problem dabei ist, dass das Höhenprofil mit diesen 0.0-Daten "zerhackt" wird.
    Ok, man kann diese Datensätze nach dem Import suchen und löschen, ist aber recht aufwendig.

    Ich kann anbieten, dass bei NMEA-Dateien Datensätze mit einer Höhe von 0.0 m grundsätzlich nicht eingelesen werden.
    Wäre das eine akzeptable Methode?

    Gruß
    blackwilli

  • 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!
    Alternativ sehr gerne auch per Paypal spenden.
    Vielen, vielen Dank ...
  • Hallo,


    Hallöchen,
    Kommt das häufiger vor, dass die Höhe einfach mal so auf 0.0 gesetzt wird, obwohl sie nicht 0.0 sein kann und der Empfang eigentlich ok ist?



    Das kommt exakt dann vor, wenn der Empfänger nur einen 2D und keinen 3D fix hat. Die Position ist dann immer noch korrekt.


    [duck] Ich träum immer noch davon, das man mit einem Freeware-Tool die fehlenden Höhendaten mit SRTM-Daten auffüllen kann. [/duck]


    Gruss Joern Weber




  • Den erklär mir mal genauer, Deinen Traum. :mellow:

    Am besten vielleicht direkt per Mail

    Gruß
    blackwilli

  • [duck] Ich träum immer noch davon, das man mit einem Freeware-Tool die fehlenden Höhendaten mit SRTM-Daten auffüllen kann. [/duck]

    Ich fände das auch eine tolle Sache: Ich erstelle oft einen Track(?) am PC um diesen danach mit dem Mountainbike oder zu Fuß per Track-Back abzufahren (-gehen). Z.B. in MapSource geht das seit ein paar Monaten ganz prima. Dieser am PC erstellte Track hat dabei übrigens ähnlich viele Punkte, wie ein vom GPS aufgezeichneter Track.


    Das einzige Problem dabei ist, dass der so erstellte Track keine Höhendaten enthält. :( Die zurückzulegenden Höhenmeter sind aber bei Radtouren oder Wanderungen in den Bergen sehr wesentlich und es wäre gut, sie vorher zu kennen.


    Wenn man jetzt diese Höhendaten für den am PC erstellten Track aus den SRTM-Daten extrahieren und zum Track hinzufügen könnte, um dann in GTA sehen zu können, wie das Profil und die zurückzulegenden Höhenmeter sind, wäre man sehr viel schlauer. ;)


    An dieser Stelle möchte ich mich bei dir blackwilli, bedanken! Ich bin sehr froh, dass es dein Tool gibt und freue mich schon sehr auf die neue Version!

  • 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!
    Alternativ sehr gerne auch per Paypal spenden.
    Vielen, vielen Dank ...
  • ...Wenn man jetzt diese Höhendaten für den am PC erstellten Track aus den SRTM-Daten extrahieren und zum Track hinzufügen könnte, um dann in GTA sehen zu können, wie das Profil und die zurückzulegenden Höhenmeter sind, wäre man sehr viel schlauer. ;)




    Na dann versuchen wir doch mal Nägel mit Köpfen zu machen.:rolleyes:

    In welchen Formaten habt Ihr denn die SRTM-Kacheln in der Regel vorliegen, da gibt es ja verschiedene.

    (Für das Problem der einzelnen fehlenden Höhendaten in den NMEA-Dateien habe ich jetzt eine optional wählbare Interpolation der fehlenden Höhen während des Imports eingebaut.)

    Gruß
    blackwilli

  • In welchen Formaten habt Ihr denn die SRTM-Kacheln in der Regel vorliegen, da gibt es ja verschiedene.

    Ich kenne nur die Daten, die von der NASA als gezippte *.hgt-Files bereitgestellt werden (http://www2.jpl.nasa.gov/srtm/). Sie liegen auf einem NASA-ftp-Server: ftp://e0srp01u.ecs.nasa.gov/srtm/version2/


    Dort sind im Unterverzeichnis "Documentation" auch ein paar pdf's zu finden, welche die Daten beschreiben.


    Quickstart.pdf gibt einen schnellen Überblick: ftp://e0srp01u.ecs.nasa.gov/sr…umentation/Quickstart.pdf


    SRTM_Topo.pdf beschreibt die Daten ausführlicher. Dort ist auch eine Formatbeschreibung enthalten (Kapitel 3+4): ftp://e0srp01u.ecs.nasa.gov/sr…cumentation/SRTM_Topo.pdf


    Ich weiß aber, dass Jörn in dem Breich wesentlich mehr Know-How hat als ich. Darum warte doch bitte noch seinen Kommentar ab.;)

  • 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!
    Alternativ sehr gerne auch per Paypal spenden.
    Vielen, vielen Dank ...
  • ohne dass man grad diese riesendateien runterladen muss... vielleicht lässt sich hier was machen? http://www.nearby.org.uk/elevation-kml.php

    Das scheint zwar in die gleiche Richtung zu gehen, ist aber auf kml-Files und 100 Trackpunkte begrenzt. Vielleicht kann blackwilli ja etwas mit dem zur Verfügung gestellten Code anfangen.


    Um das herunterladen von "Riesenfiles" kommt aber aber wohl nicht herum, wenn man SRTM-Daten verwenden will.

  • hab noch was anderes gefunden: http://www.earthtools.org/webservices.htm#height

    das funktioniert folgendermassen:

    Zitat


    zum beispiel dort wo ich heute mittag gegessen habe ;)
    http://www.earthtools.org/height-1.0/46.9425/7.4336

    produziert folgenden output:

    XML
    <?xml version="1.0" encoding="ISO-8859-1" ?> 
    - <height xmlns:xsi="[URL]http://www.w3.org/2001/XMLSchema-instance[/URL]" xsi:noNamespaceSchemaLocation="[URL]http://www.earthtools.org/height.xsd[/URL]">
      <version>1.0</version> 
    - <location>
      <latitude>46.9425</latitude> 
      <longitude>7.4336</longitude> 
      </location>
      <meters>532</meters> 
      <feet>1745.4</feet> 
      </height>




    also 532m hoch...
    wäre das brauchbar?
    (im wesentlichen macht der sourcecode bei http://www.nearby.org.uk/elevation-kml.php genau das...)

  • Das wäre gar keine so schlechte Sache. Online gehen und die Werte zu den Trackpoints automatisch downloaden.

    Da muß ich nur noch mal sehen, ob man die xml-Codes direkt temporär als Datei speichern kann, ohne einen Browser öffnen zu müssen.


    Habt Ihr noch mehr gute Vorschläge? :rolleyes:

    blackwilli

  • 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!
    Alternativ sehr gerne auch per Paypal spenden.
    Vielen, vielen Dank ...
  • Na dann versuchen wir doch mal Nägel mit Köpfen zu machen.:rolleyes:

    In welchen Formaten habt Ihr denn die SRTM-Kacheln in der Regel vorliegen, da gibt es ja verschiedene.


    Die originalen Daten haben das *.hgt Format.


    Das gesammelte Know How mit den dazugehörigen Verweisen gibt es hier:
    http://de.wikipedia.org/wiki/SRTM-Daten Zum Datei-Format habe ich nur wenig herausgefunden:


    "[SIZE=-1]Each data file covers a one-degree-of-latitude by one-degree-of-longitude block of Earth's surface. The first seven characters indicate the southwest corner of the block, with N, S, E, and W referring to north, south, east, and west. Thus, the "N34W119.hgt" file covers latitudes 34 to 35 North and longitudes 118-119 West (this file includes downtown Los Angeles, California). The filename extension ".hgt" simply stands for the word "height", meaning elevation. It is NOT a format type. These files are in "raw" format (no headers and not compressed), 16-bit signed integers, elevation measured in meters above sea level, in a "geographic" (latitude and longitude array) projection, with data voids indicated by -32768. International 3-arc-second files have 1201 columns and 1201 rows of data, with a total filesize of 2,884,802 bytes ( = 1201 x 1201 x 2). United States 1-arc-second files have 3601 columns and 3601 rows of data, with a total filesize of 25,934,402 bytes ( = 3601 x 3601 x 2)."[/SIZE]



    Zitat


    (Für das Problem der einzelnen fehlenden Höhendaten in den NMEA-Dateien habe ich jetzt eine optional wählbare Interpolation der fehlenden Höhen während des Imports eingebaut.)

    Diese Löcher in den Eingangsdaten, egal ob GPX oder NMEA, mit den SRTM-Daten zu stopfen und dann wieder als kompletten Track zu exportieren ist mein Traum. Viele User erstellen Tracks und stellen sie im Internet zur Verfügung. Diese Tracks haben meist keine Höhendaten, weil diese wärend des Tracking durch fehlende 3D fix, aber vorhandenen 2D fix verloren gegangen sind. Folglich schmeissen dann die meisten User die Höhendaten weg, weil sie diese nicht Stopfen können. Das nächste Problem ist das die Löcher das Bild im GTA verschandeln. Interpolation ist zwar gut, kann aber nur kleine Löcher stopfen. Eine längere Waldtour im Sommer ist aber trotz interpolation ein Problem. Das einzige Tool, das diese Funktion beherrscht, ist das nicht ganz billige TTQV.


    Gruss Joern Weber

  • Das wäre gar keine so schlechte Sache. Online gehen und die Werte zu den Trackpoints automatisch downloaden.

    Da muß ich nur noch mal sehen, ob man die xml-Codes direkt temporär als Datei speichern kann, ohne einen Browser öffnen zu müssen.
    blackwilli



    ich bin kein programmierer.. aber hier ist der php code zu der elevetion-kml webpage:
    http://www.nearby.org.uk/elevation-kml.phps

    ein teil des codes:

    Code
    [FONT=Courier New][COLOR=#ff8000]#http://www.earthtools.org/height/<latitude>/<longitude> [/COLOR][/FONT]
    [FONT=Courier New][COLOR=#0000bb]$url [/COLOR][COLOR=#007700]= [/COLOR][COLOR=#dd0000]"http://www.earthtools.org/height/{$m[3][$i]}/{$m[2][$i]}"[/COLOR][/FONT][FONT=Courier New][COLOR=#007700]; [/COLOR][/FONT]
    [FONT=Courier New][COLOR=#0000bb]$file [/COLOR][COLOR=#007700]= [/COLOR][COLOR=red][size=14][B]@[/B][B]file_get_contents($url[/B][/SIZE][/COLOR][/FONT][FONT=Courier New][COLOR=#007700][B][size=14][COLOR=red])[/COLOR][/SIZE][/B]; [/COLOR][/FONT]
    [COLOR=#007700][FONT=Courier New]if ([/FONT][/COLOR][FONT=Courier New][COLOR=#0000bb]preg_match[/COLOR][COLOR=#007700]([/COLOR][COLOR=#dd0000]'/<meters>(-?\d+)<\/meters>/'[/COLOR][COLOR=#007700],[/COLOR][COLOR=#0000bb]$file[/COLOR][COLOR=#007700],[/COLOR][COLOR=#0000bb]$o[/COLOR][/FONT][FONT=Courier New][COLOR=#007700])) { [/COLOR][/FONT]
    [FONT=Courier New][COLOR=#0000bb]  $height [/COLOR][COLOR=#007700]= [/COLOR][COLOR=#0000bb]$o[/COLOR][COLOR=#007700][[/COLOR][COLOR=#0000bb]1[/COLOR][/FONT][COLOR=#007700][FONT=Courier New]]; [/FONT][/COLOR]



    ich nehme an dass in deiner bevorzugten programmiersprache auch funktionen wie die untigen gibt...

    • @file_get_contents($url)
      --> holen des inhalts einer webseite
    • preg_match('/<meters>(-?\d+)<\/meters>/',$file,$o)
      --> rauslesen einer variable aus einem string/file

    :)

    welche programmiersprache benützt du?

    dan

  • 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!
    Alternativ sehr gerne auch per Paypal spenden.
    Vielen, vielen Dank ...
  • @blackwilli
    ich hab's gerade mit C++ programmiert und ausprobiert,
    es geht ganz einfach wenn man die url mit der gewünschten
    Position als stream öffnet und in einen buffer lädt,
    dann xml parsen so wie in obigem posting dargestellt.


    falls jemand was mit C++ (mit wxWidgtes) anfangen kann,
    kann ich auch gerne das demo-sample posten.

  • Hallöchen,

    genau! URL mittels xml-Streamwriter als Input-Stream öffnen und dann kann man ganz normal das <meters> Element auslesen.


    Diese Variante gefällt mir eigentlich ganz gut, da man keine Datenkacheln mühevoll besorgen muss.

    Natürlich kann das ganze, je nach Internet-Zugang und Größe des Tracks einen kleinen Moment dauern, aber das ist wohl verschmerzbar.

    Bleibt dann nur noch zu hoffen, das der Service von earthtools in dieser Form erhalten bleibt.

    Tja, dann werde ich das mal probeweise umsetzen. :)

    Gruß
    blackwilli

  • Was soll ich sagen, mittels xml-Streamwriter funktioniert der Datenimport einwandfrei.

    Also wird es bald ein Freeware-Tool geben, das SRTM-Höhendaten in vorhandene Tracklogs automatisch einliest. :D


    Gruß
    blackwilli

  • 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!
    Alternativ sehr gerne auch per Paypal spenden.
    Vielen, vielen Dank ...
  • Noch ein kleiner Nachtrag:

    Ich möchte nur noch darauf hinweisen, dass die SRTM-Daten sehr mit Vorsicht zu genießen sind. Erstens sind die Daten für Europa nur in einem Raster von 3 Bogensekunden, also ca. 90m, aufgezeichnet - dazwischen wurde interpoliert und grundsätzlich konnte das Shuttle-Radar die Daten natürlich nur incl. Bebauung und Bewuchs ermitteln. Das heißt, dass gerade z.B. im Wald, wo einem die Höhendaten wegen schlechten Empfangs fehlen, die Höhe der Baumwipfel gemessen wurde und nicht die Bodenhöhe!

    So muß man also mit Abweichungen von 20, 30 oder mehr Metern rechnen. Als Beispiel: Bei mir vorm Haus ist die tatsächliche Höhe 89 m, der SRTM-Datensatz von earthtools.org liefert dagegen 105 m! Die Differenz ist in etwa die Höhe der umliegenden Häuser.

    Gruß
    blackwilli