'Glättung' von Höhendaten und Aktualisierung von SRTM-Daten

[WRPSoft]

Beim Aspekt "Glättung" sehe ich folgende Sachverhalte:
 
Die DGM1-Höhendaten sind extrem genau, was aber dazu führt, dass ein unebener, horizontal verlaufender Naturweg plötzlich Steigung und/oder Gefälle aufgrund der Unebenheiten aufweist. Glättung?

Die DGM1-Daten sind natürlich extrem genau (vergleichbar mit einer barometerbasierten Messung bei stabilem Wetter). In Kombination mit vielen GPS-Fehlern (schlechte Empfangsbedingungen oder 'schlechten' GPS-Chipsätze, die es leider immer noch gibt), sind sie aber nicht mehr so extrem genau, sondern nur noch feinauflösend.

Und bei sehr fein auflösenden Daten hat eine Glättung in der Regel weniger Auswirkung, zumal man die Glättung dann sehr fein runterregeln muss (bei DGM1-Daten operiert man dann ja im cm Bereich, analog zu Barometerbasierten Messungen, die heutztage auch im cm Bereich die Höhe messen).

Läuft bei Pausen die Trackaufzeichnung weiter, führt dies oft zu mehr oder weniger ausgeprägten Punktwolken. Diese Punktwolken führen zu Steigung und/oder Gefälle obwohl keine Bewegung erfolgte. Glättung?

Also kommt man leider nicht umhin, die (GPS)-Daten vorher - vor der Höhenwertzuweisung bzw. Höhenwertreparatur - aufzubereiten. Da gibt es mehrere Möglichkeiten, Tapio hat das ja beschrieben. In Echtzeit stelle ich mir das sehr schwierig vor; nachträglich durchaus machbar, wobei aber die Frage bleibt, wie weit man das automatisieren kann.

Vielleicht hilft ein Beispiel. Der Track sollte so um die 250 Meter Steigung und Gefälle aufweisen:

Höhenmeter-Auswertung basierend auf ungenauen Höhendaten via GPS-Signal:
Uphill: 672.4 m (weighted moving average)
Downhill: 676.5 m (weighted moving average)
Uphill: 1183.7 m (unfiltered)
Downhill: 1187.8 m (unfiltered)

Höhenmeter-Auswertung basierend auf hochgenauen DGM1-Höhendaten:
Uphill: 245.7 m (weighted moving average)
Downhill: 248.0 m (weighted moving average)
Uphill: 277.4 m (unfiltered)
Downhill: 279.7 m (unfiltered)

An deinem Beispiel sieht man recht gut, dass die Glättung vor allem bei verrauschten Daten große Auswirkungen hat, bei den fein abgestuften DGM1-Daten aber weniger.

Ich habe - wie gesagt - auch recht viel mit solchen Daten experimentiert, spätestens dann, wenn man stark unterschiedliche Touren aufbereiten/normalisieren will, kamen dann aber wieder größere Abweichungen zustande.
Z.B. Rennradtouren vers. MTB-Touren vers. Wandertouren, kurze Touren vers. langen Touren, stark verrauschte Daten vers. eher genauen Daten (auch oder vor allem, was die GPS-Daten betrifft), lange Anstiege gegenüber Achterbahntouren (z.B. Wandern in Weinbergen), verwendete Aufzeichnungsintervalle (da bietet Locus Map ja sehr viele Einstellungsmöglichkeiten), etc.

Ich konnte das mit einer Universalformel leider nicht einfangen. Wenn man z.B. einen Ötztaler Radmarathon alleine mit der Glättung der Höhendaten berechnen will, dann kommen m.E. immer deutlich zu viele Auf- und Abstiegsmeter heraus, sodass ich bei dieser Art Tour um eine zusätzliche Hysterese nicht umhingekommen bin.

Das mögen jetzt Sonderfälle sein, aber Locus Map muss das ja quasi alles eintüten und erschwerend kommt hinzu, dass Locus Map mit vielen Arten von Android Phones zusammenarbeiten muss und daher eine sehr große Bandbreite, was die Zuverlässigkeit der Aufzeichnungen betrifft, aufschlagen dürften).

Nicht gänzlich unmöglich, aber ich glaube, das ist schon eine sehr, sehr großen Baustelle, wenn man das alles auf dem Phone berechnen will. Wahrscheinich viele Stellschrauben, die man konfigurieren muss, um diese unterschiedlichen Ausgangsdaten handeln zu können.

PS: Das ist jetzt alles sehr subjektiv, da ich mich selbst sehr viel mit Radaufzeichnungen beschäftigt habe. Man hangelt sich ja immer von einer bestimmten Ausgangslage zur nächsten und versucht im nächsten Schritt, eine allgemeingültige Variante zu finden.

[WRPSoft]

@WRPSoft: Ich habe Deinen Blogeintrag zum dem Thema gelesen. Ein hervorragender Artikel zu den Problemen mit der Höhenberechnung. Und ich zweifle nochmals an meinen Fähigkeiten, ordentlich zu einem Thema zu recherchieren. Auch  die Seite hatte ich nicht gefunden 

Freut mich zu hören, danke für die netten Worte. Wobei ich natürlich sehr subjektiv an das Thema herangehe, weil meine Wurzeln wie gesagt im Bikecomputer- und Wanderuhren-Bereich liegen. Die erste Generation dieser Geräte konnte noch keine GPS-Daten protokollieren, das waren rein barometerbasierte Höhenmesser und da war die Hysterese quasi die einzige Stellschraube. Glätten musste man dabei nicht viel, da die Höhenmess-Chips schon recht früh im cm-Bereich auflösen konnten und dieses feine Grundrauschen konnte/kann man mit der Hysterese sehr gut egalisieren.

Heutzutage sieht das natürlich etwas anders aus, aber zumindest die Echtzeitberechnungen auf den Geräten selbst, laufen m.E. immer noch ähnlich ab (man hangelt sich von Datenpunkt zu Datenpunkt und operiert mit den Deltas).

Das ist sicher richtig. Die Frage ist, welchen Aufwand man betreiben muss, um aus offensichtlich falschen Werten einigermaßen vernünftige Werte zu machen. Da sollte Menion schon ein Interesse haben, insbesondere wenn das mit anderen Apps verglichen wird. Aus Aufnahmeprofil und Quelle für die Höhenangaben sollte man man schon mal in die richtige Richtung kommen. Absolute Genauigkeit erwarte ich nicht. Und ich ging davon aus (und sehe mich durch Deinen Blog-Eintrag bestätigt), dass die Algorithmen zu dem Thema bekannt sind. fsk hat mit seinem Service vielleicht die Möglichkeit viele verschiedene GPX-Dateien zu sammeln und auszuwerten (sofern es das in seinen Nutzungbedingungen darstellt, habe ich jetzt nicht geschaut). Vielleicht kommt er dann auch zur Erkenntnis, dass es die eine Methoden mit wenigen Parametern nicht gibt.

Ich glaube, Interesse wird bei Menion schon vorhanden sein, aber er muss halt gegen eine sehr große Bandbreite an Geräten und Daten ankämpfen und das macht's nicht gerade einfacher Wir haben hier drei aktuelle Mittelklasse-Smartphones in Verwendung, eines davon protokolliert leider sehr grausliche GPS-Koordinaten. Da macht dann sogar eine nachträgliche Korrektur der Höhendaten nur bedingt Sinn, weil man eigentlich vorher die GPS-Ausreißerkoordinaten korrigieren/filtern müsste.

Auch das könnte man natürlich irgendwie angehen, die einfachste Variante wäre ein Glätten der GPS-Koordianten mittels Douglas-Peucker-Filter, wobei das aber auch keine Universalwaffe ist und ich nicht weiß, ob Locus Map die GPS-Daten im Hintergrund bereits etwas aufbereitet.

Wie gesagt, recht anspruchsvoll, könnte man wahrscheinlich eine Doktorarbeit draus machen

[fzk]

@WRPSoft: Der Nutzen von ungenauen, stark verrauschten GNSS-Höhendaten ist sehr gering. Da hilft auch Glätten wenig. Am besten man verzichtet auf GNSS-Höhendaten. Die Höhendaten während einer Tour müssen also auf anderem Wege ermittelt werden (z.B. via DEM/DGM). Vor und nach der Tour ermittelt man die Höhendaten ja ohnehin schon via DEM/DGM.

[WRPSoft]

Abstrakt betrachtet möchte man mit Track-Statistiken drei Dinge erreichen:

• Vor der Tour: Informationen zur Streckenlänge und zu den Höhenmetern.
• Nach der Tour: Informationen zur Streckenlänge und zu den Höhenmetern.
• Während der Tour: Wieviel Strecke und wieviele Höhenmeter kommen noch?

Die Statistiken vor und nach der Tour macht man am besten auf Basis von DGM/DEM-Daten. Die Schwierigkeit während der Tour ist die Berechnung der Höhenmeter. Hier sind GNSS-Daten (Satellit) ungeeignet, weil sie zu ungenau und zu stark verrauscht sind. Der Vergleich von "GNSS-Höhendaten mit DGM/DEM-Höhendaten" entspricht einem Vergleich von "Äpfeln mit Birnen". Um während der Tour eine vernünftige Aussage zur Frage "Wieviele Höhenmeter kommen noch?" treffen zu können, sollte man richtigerweise dieselbe Basis verwenden wie für die Planung.

Anders ausgedrückt: Der Nutzen von GNSS-Höhendaten ist sehr gering. Am besten man verzichtet darauf. Die Höhenmeter während der Tour müssen auf anderem Wege ermittelt werden.

Daan bleibt zur Echtzeitberechnung aber nicht mehr viel, was man aufgreifen könnte:

- Barometerbasierte Höhenmessung wäre eine Möglichkeit, allemal besser als reine GPS-Höhenwerte.

- Oder die Höhenwerte bereits zur Echtzeit durch DEM-Daten ersetzen. Ist dann die Frage, wie hochauflösend die DEM-Daten sind, ob man diese lokal auf dem Gerät speichert oder diese jeweils per Internetverbindung pro Datenpunkt (ggfs. nur alle X Datenpunkte abfragen und die Zwischenwerte interpolieren) zuweist.

Das Thema ist sicherlich noch nicht ausgereizt, aber gerade die Echtzeitberechnung wird noch den ein oder anderen Stolperstein zu Tage befördern. Bin gespannt, wie sich das zukünftig entwickelt.

[WRPSoft]

@WRPSoft: Der Nutzen von ungenauen, stark verrauschten GNSS-Höhendaten ist sehr gering. Da hilft auch Glätten wenig. Am besten man verzichtet auf GNSS-Höhendaten. Die Höhendaten während einer Tour müssen also auf anderem Wege ermittelt werden (z.B. via DEM/DGM). Vor und nach der Tour ermittelt man die Höhendaten ja ohnehin schon via DEM/DGM.

Ja, das ist ja mein Reden Eine Frage ist halt, wie bzw. ob man das zur Echtzeit eintüten kann.

[fzk]

Ja, das ist ja mein Reden Eine Frage ist halt, wie bzw. ob man das zur Echtzeit eintüten kann.

Die Höhendaten während der Tour sollten aus derselben Quelle stammen, die auch die Grundlage für die Statistik der geplanten Tour war. Also z.B. dasselbe DEM/DGM. Nur so können die aktuellen Daten während der Tour mit den geplanten Tourdaten verglichen werden.

Fazit: Keine GNSS-Höhendaten in den Track schreiben. Stattdessen die Höhendaten aus einem DEM/DGM (offline oder online) ermitteln und in den Track schreiben.

[clausin]

Der Service schließt mit jeder Response die Verbindung. Möglicherweise versuchst du in deinem Client mehrere Requests über dieselbe Verbindung durchzuführen. Das würde zumindest zur Fehlermeldung 'Eine vorhandene Verbindung wurde vom Remotehost geschlossen' passen.

Das war es wohl. Auch wenn man requests nach Anleitung mit Session nutzt und nach jedem Aufruf die Connection schließt, kommt alle paar Aufrufe der Fehler. Wenn man die Basis-Lib urllib3 verwendet, tritt der Fehler nicht mehr auf.
Damit kann ich nun auch Tracks überarbeiten, die nicht in der näheren Umgebung liegen. Vielen Dank!