08.06.2011, 23:53
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.
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.
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.
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.