24.05.2011, 11:21 (This post was last modified: 24.05.2011, 11:22 by ercebe.)
Hallo Christian,
ich wundere mich immer über die deutlichen Differenzen in den Höhenmetern bzw. Gesamtan/abstiegsangaben einer Tour, wie sie mir der RC ausgibt und was dann beim Hochladen auf GPSies noch übrig bleibt (GPSies hat immer geringere Summen).
Kannst du dir den Unterschied erklären oder hab ich eine unterschiedliche Begriffsdefinition übersehen?
Gruß
Ralf
Falls jemand anderes ne Erklärung hat, immer gerne
(24.05.2011, 11:21)ercebe Wrote: ich wundere mich immer über die deutlichen Differenzen in den Höhenmetern bzw. Gesamtan/abstiegsangaben einer Tour, wie sie mir der RC ausgibt und was dann beim Hochladen auf GPSies noch übrig bleibt (GPSies hat immer geringere Summen).
Kannst du dir den Unterschied erklären oder hab ich eine unterschiedliche Begriffsdefinition übersehen?
Hallo Ralf,
ich weiß nicht, was GPSies macht, insofern kann ich Dir den Unterschied nicht erklären. Doch ich kann Dir kurz erklären, was RouteConverter tut. Die Höhe-Spalte zeigt die Rohdaten, Gesamtsteigung bzw. Gesamtgefälle summieren dann die positiven bzw. negativen Differenzen zur vorigen Position (die eine Höhenangabe hat) auf.
Mir gefällt das Programm, aber am Algorythmus der Höhenmeter-Berechnung sollte dringend gefeilt werden.
GPS-Programme sind immer etwas ungenau diesbezüglich, wer exaktere Ergebnisse benötigt, sollte sich einen barometrischen Höhenmesser kaufen und nur bei schönem Wetter fahren - aber RouteConverter verzehnfacht (!) die tatsächlichen Steigungen gerne mal; das ist nicht mehr im Toleranzbereich.
(26.05.2011, 12:13)Wakeman Wrote: RouteConverter verzehnfacht (!) die tatsächlichen Steigungen gerne mal; das ist nicht mehr im Toleranzbereich.
Hallo Wakeman,
willkommen im RouteConverter Forum.
Christian selbst wird wegen Abwesenheit erst in ca. zehn Tagen antworten können.
Um das von dir beschriebene Symptom eingrenzen zu können, wird er einen Beispiel-Track (vorher, nachher, eventuell Vorgehensweise) gebrauchen können. Die Forensoftware akzeptiert nur bestimmte Dateiendungen - *.zip Archive gehören dazu.
(26.05.2011, 12:13)Wakeman Wrote: Mir gefällt das Programm, aber am Algorythmus der Höhenmeter-Berechnung sollte dringend gefeilt werden.
Hast Du einen Vorschlag wie der oben beschriebene Algorithmus verbessert werden könnte?
(26.05.2011, 12:13)Wakeman Wrote: GPS-Programme sind immer etwas ungenau diesbezüglich, wer exaktere Ergebnisse benötigt, sollte sich einen barometrischen Höhenmesser kaufen und nur bei schönem Wetter fahren - aber RouteConverter verzehnfacht (!) die tatsächlichen Steigungen gerne mal; das ist nicht mehr im Toleranzbereich.
Du könntest mit nachvollziehbaren Beispielen helfen herauszufinden, wie GPSies so viel genauere Ergebnisse erzielt. Letztlich bewegen sich beide ja auf Basis der von GPS-Loggern aufgezeichneten Daten.
08.06.2011, 18:57 (This post was last modified: 08.06.2011, 19:00 by maz.)
Dafür gibts zwei mögliche Ursachen:
1. Glättung der Höhendaten, da die Aufzeichung vieler Geräte in dem Punkt nix taugt und stark streut
2. Höhendaten aus Geo-Datenbank statt GPS-Track, da gibts allerdings je nach Dienst nur Messpunkte aller 30 bis 90 m (Quelle vergessen, sorry), d.h. wenn man innerhalb so einer Kachel über 'nen 10 m hohen Felsen klettert bleibts bei 0 m Gesamtsteigung
Meine jahrelange Erfahrung mit TomTom One (Software "NMEA-Logger") und jetzt Samsung Smartphone sagt, dass beide Methoden zumindest bei diesen Geräten + hoher Aufzeichnungsdichte + Bewegungsart=Wandern Pflicht sind. Danach sieht nicht nur der Track viel realistischer aus, sondern auch die Höhenmeter-Summe schrumpft gern mal auf 1/5. Und für beide Schritte gibts im RC die entsprechende Funktion bereits - die Verantwortung liegt beim User :-)
Ich hab allerdings gerade entdeckt, dass RC bei einem GPX-Track 2000m Gesamtsteigung anzeigt und in der von RC selbst gespeicherten KML-Version nach deren Laden dann lockere 4800m. Track gefällig oder Fehler bekannt?
(08.06.2011, 18:57)maz Wrote: 1. Glättung der Höhendaten, da die Aufzeichung vieler Geräte in dem Punkt nix taugt und stark streut
Bloß wie sieht ein Algorithmus dann aus, der die Höhe für einen Punkt glätten soll? Für ein Höhenprofil würde das gehen, doch in der Positionstabelle von RouteConverter steht ja pro Position ein Höhenwert.
(08.06.2011, 18:57)maz Wrote: 2. Höhendaten aus Geo-Datenbank statt GPS-Track, da gibts allerdings je nach Dienst nur Messpunkte aller 30 bis 90 m (Quelle vergessen, sorry), d.h. wenn man innerhalb so einer Kachel über 'nen 10 m hohen Felsen klettert bleibts bei 0 m Gesamtsteigung
Die SRTM-Daten nutzt RouteConverter seit der Version 2.0, wenn man Vervollständigen->Höhe auf Positionen aufruft.
(08.06.2011, 18:57)maz Wrote: Und für beide Schritte gibts im RC die entsprechende Funktion bereits - die Verantwortung liegt beim User :-)
Danke für den Hinweis, d.h. wir müssen @Wakeman zum Nutzen der Funktion bringen.
(08.06.2011, 18:57)maz Wrote: Ich hab allerdings gerade entdeckt, dass RC bei einem GPX-Track 2000m Gesamtsteigung anzeigt und in der von RC selbst gespeicherten KML-Version nach deren Laden dann lockere 4800m. Track gefällig oder Fehler bekannt?
Schick mir gerne ein Beispiel, da fällt mir das Nachvollziehen leichter.
Bei GPSIES muss man beim Hochladen des Tracks angeben, welche Fortbewegungsart (Laufen, Fahrrad, Auto ...) vorliegt. Damit lässt sich das Höhenprofil entsprechend der Fortbewegungsart wahrscheinlich gut glätten. Ich denke man kann z.B. annehmen, dass die x/y-Differenz zum Vorgänger-Punkt deutlich größer sein sollte als die Höhen-Differenz, sind ja alles recht "flache" Bewegungsarten. Je schneller, desto flacher. Da lässt sich per Analyse korrekter Tracks sicher ein typisches Verhältnis pro Fortbewegungsart ermitteln. Das Problem dürfte generell nur in der Kombination "langsame Fortbewegungsart" + "hohe Aufzeichnungsfrequenz" auftreten, weil da der aufsummierte Messfehler relativ zur tatsächlichen Bewegung sehr groß wird.
Beispiel: Eine 24 km Wanderung um eine Talsperre, d.h. viel kleinteiliges auf und ab, mit 1s-Abstand aufgezeichnet. Diesen Track *muss* ich nachbearbeiten, wenn eine realistische Angabe der Distanz und Gesamtsteigung rauskommen soll:
1. Nach Anwenden der Funktion "Position" --> "Doppelte Positionen löschen" --> "Markiere alle Positionen innerhalb einer Distanz von 10m zum Vorgänger" (in anderen Programmen "Reumann-Witkam" Verfahren genannt) und löschen der markierten Punkte schrumpft die Gesamtdistanz etwas (von 24 auf 22 km), die Gesamtsteigung jedoch drastisch, nämlich von 4000 auf 2000 m. Das "Gezappel" (und damit der aufsummierte Meßfehler) in den Höhendaten ist also deutlich größer als der in der Positionsbestimmung.
2. Dann alle noch vorhandenen Punkte markieren und SRTM-Höhendaten abholen (rechte Maus "Vervollständigen" --> "Höhe") und aus den 2000 m Gesamtsteigung werden niedliche 800 m. Und *das* ist dann brauchbar und taugt auch als Vergleich bei der Planung künftiger Wanderungen.
(08.06.2011, 19:25)routeconverter Wrote: Die SRTM-Daten nutzt RouteConverter seit der Version 2.0, wenn man Vervollständigen->Höhe auf Positionen aufruft.
Demnach sind das bei uns um Lande also tatsächlich 90m-Kacheln, hmm. Ganz schön grob, auf 90m kann ich ganz schön auf und ab kraxeln. Trotzdem hatte ich bisher immer das Gefühl, dass das Höhenprofil mit den SRTM-Daten realistischer aussieht als mit dem gemessenen Gezappel.
(08.06.2011, 19:25)routeconverter Wrote: Schick mir gerne ein Beispiel, da fällt mir das Nachvollziehen leichter.
Siehe Anhang, kleiner 5-Punkte-Track, der den Fall klar macht. Beim 3. Punkt des Tracks fehlt die Höhenangabe. In der Listenansicht ist das Feld leer, es wird bei der Berechnung der Gesamtsteigung ignoriert. Nach Speichern und Laden als KML-Datei steht im zuvor leeren Feld aber eine Null, und die fließt in die Berechnung ein.
09.06.2011, 06:39 (This post was last modified: 09.06.2011, 06:42 by routeconverter.)
(08.06.2011, 23:53)maz Wrote: Siehe Anhang, kleiner 5-Punkte-Track, der den Fall klar macht. Beim 3. Punkt des Tracks fehlt die Höhenangabe. In der Listenansicht ist das Feld leer, es wird bei der Berechnung der Gesamtsteigung ignoriert. Nach Speichern und Laden als KML-Datei steht im zuvor leeren Feld aber eine Null, und die fließt in die Berechnung ein.
Danke für die Erklärung, woher das Problem kommt. Dummerweise kann man da beim derzeit benutzten <LineString> nichts machen, denn eine Null für die Höhe läßt sich dort nicht repräsentieren:
