WRPSofts Blog: Berechnung der Auf- und Abstiegsmeter bei protokollierten (GPS) Daten

Das Thema ist nicht neu, sondern in der Tat ein richtiger Dauerläufer: die (korrekte) Berechnung der Auf- und Abstiegsmeter.
In wirklich jedem sportspezifischen oder GPS lastigen (Fach)-Forum wurde diese Frage mindestens einmal diskutiert, gefühlt sogar alle paar Monate und je nach Diskussionskultur können solche Diskussionen dann auch mal etwas ausarten.

Aber auch am Ende der Diskussion wird man die allgemeingültige Lösung des Problems vergeblich suchen und der Kreis schließt sich somit wieder einmal. Einige Zeit später fängt die Diskussion dann wieder bei Null an :-)

Halten wir fest, auf die "Was ist richtig und was ist falsch" Frage gibt es nicht immer eine passende Antwort.

Auch ich werde daran nichts ändern können. Daher will ich diese Frage nur anhand einiger Fallbeispiele etwas illustrieren. Vorher werde ich aber natürlich auf einige Details eingehen, da die Fallbeispiele gänzlich ohne Hintergrundwissen nicht viel zur Erkenntnis beitragen werden.

Dieser Beitrag ist (wieder mal) etwas länger, da ich versucht habe, die dahinterstehende Problematik so gut wie möglich zu skizzieren.

Die nötigen Schlüsse - und die sich daraus für euch ergebenden Erkenntnisse - müsst ihr selbst ziehen!

Hinweis (31.10.2024): Nachdem ich heute explizit von einem Leser meines Blogs darauf hingewiesen wurde. Natürlich gibt es auch andere Methoden, um Auf- und Abstiegsmester zu berechnen. Die hier vorgestellte Delta-Methode ist aber eine Variante, die in den meisten Bike-Computern als auch Auswertungsprogrammen intern Verwendung finden dürfte. Das ist der Grund, weshalb ich mich nur auf diese Methode beziehe. In einigen der am Ende des Artikels aufgeführten Links, sind auch Artikel verlinkt, in denen auf einige andere Berechnungsmodelle verwiesen wird. Irgendwo muss man einen Cut machen, denn die eigentliche Frage "Was ist richtig, was ist falsch", die wird man auch mit anderen Berechnungsmodellen nicht abschließend klären können. Im Gegenteil, je mehr unterschiedliche Berechnungsmethoden Anwendung finden, desto komplizierter wird es, weil jeder das Rad neu erfinden will... und bekanntlich dreht sich das Rad immer weiter :-)

Ausgangssituation

PC-Programm bzw. App XY oder das Webportal der Wahl berechnen die Auf- und Abstiegsmeter einer protokollierten Aufzeichnung eines Sportcomputers oder GPS Geräts häufig eigenständig. Im Vergleich mit anderen Programmen oder der Aufschlüsselung dieser Werte im Gerät selbst, fallen dabei dann hin und wieder größere Abweichungen auf.

Auch kommt es gar nicht so selten vor, dass ein Garmin der Edge Serie andere Werte aufschlüsselt als ein Wahoo Elemnt, der Wahoo Elemnt wiederum andere Werte als ein Hammerhead Karoo Bike Computer. Und um das Bild zu komplettieren, auch bei Polar-, Sigma-, Bryton-, Igpsport-Bike Computer - und was es derzeit sonst noch so auf dem Markt gibt -, sieht es, was diese Frage aller Fragen betrifft, natürlich nicht besser aus :-)

Am Ende der gemeinsamen Radrunde stehen wir dann alle zusammen und fachsimplen mit roten Köpfen noch etwas, welche unserer Bike-Computer richtig liegen und welche daneben.

Im schlimmsten Fall wurden etliche Aufstiegsmeter gekappt, wenn es gut läuft, dann war der Anstieg aber viel schwerer/härter als geplant, da im Nachhinein einige Aufstiegsmeter mehr berechnet wurden. 'Gut' deswegen, weil mehr ja (fast) immer gut ist, nur weniger darf es halt nicht werden (denn wie immer gilt, nur die Harten kommen in den Garten) :-).

Kurz gesagt: so gut wie jedes Programm, jedes Webportal und jedes Endgerät präsentiert am Ende seine eigene Wahrheit.

Vorbetrachtung

Bevor wir uns mit dem eigentlichen Problem befassen, müssen wir erst einmal die Datenbasis begutachten, da diese protokollierten Daten auf unterschiedliche Art und Weise erzeugt werden können. Und natürlich spielt die Berechnungsmethode dabei eine zentrale Rolle.

Berechnungsmethoden:

Es ist wichtig zu wissen, wie man diese Auf- und Abstiegswerte berechnet. Stark vereinfacht gesagt (ACHTUNG: ganz so trivial ist es am Ende dann doch nicht!), berechnet man diese Werte anhand der Deltas zweier Punkte (der damit verknüpften Höhen) und addiert die jeweilige Differenz dieser Deltas.

Beispiel:

0 km -> 100 m (Delta: 0) -> 0 Auf, 0 Ab

5 km -> 150 m (Delta: 150 - 100 = 50) -> 50 Auf, 0 Ab

10 km -> 200 m (Delta: 200 - 150 = 50) -> 100 Auf, 0 Ab

15 km -> 180 m (Delta: 180 - 200 = -20) -> 100 Auf, -20 Ab

20 km -> 200 m (Delta: 200 - 180 = 20) -> 120 Auf, -20 Ab

25 km -> 170 m (Delta: 170 - 200 = -30) -> 120 Auf, -50 Ab

30 km -> 210 m (Delta: 210 - 170 = 40) -> 160 Auf, -50 Ab

Das ist jetzt ein stark abstrahiertes Beispiel, aber ihr könnt gut erkennen, dass es in der Regel nicht damit getan ist, den Aufstieg nur anhand des Ausgangshöhenwertes am Fuß des Berges und dem Endhöhenwert des Berggipfels zu berechnen, was vielleicht naheliegend ist und bei manchen Bergen durchaus sinnvoll sein kann. Der Computer, der diese Berechnung ausführt, wird aber nicht wissen, was es mit dem Charakter eines Anstiegs auf sich hat. Er kann sich also nur auf die jeweiligen Datenpunkte beziehen und muss diese zueinander in Relation setzen.

Wie auch immer, ohne diese Delta-Berechnung würden bei diesem Anstieg nur 110 Aufstiegsmeter resultieren (210 m - 100 m); mit der Delta-Methode sind es aber 160 Aufstiegsmeter und (-)50 Abstiegsmeter, denn viele Anstiege weisen auch diverse Flachpassagen und (leichte) Gegengefälle auf, die sich, wenn man das alles summiert, eben in zusätzlichen Auf- und Abstiegswerten niederschlagen.

Auch spielt die Sportart mitunter eine Rolle, denn einen kleinen Gegenanstieg (Hubbel, also eine kleinere Bodenerhebung) können wir mit dem Rad leicht mit Schwung überrollen, per pedes - also mit Wanderstiefeln oder Laufschuhen - eher nicht (da schmerzt am Ende der Tour manchmal jeder Meter).

Soll man also jeden noch so kleinen Gegenanstieg in die Berechnung miteinbeziehen oder nicht?

Daher werden die Auf- und Abstiegsmeter bei Bikecomputern häufig etwas konservativer berechnet (größerer Hysteresefaktor), wohingegen GPS-Outdoorgeräte oder Laufuhren die Auf- und Abstiegsmeter manchmal eher gutmütig, also übermäßig berechnen (kleinerer Hysteresefaktor). Das erklärt mitunter etwas die Abweichungen, die auftreten können, wenn man eine Bike-Tour parallel mit einer Laufuhr protokolliert und die Aufstiegswerte auf den Displays stark variieren. Das kann ein Zufall sein, aber eben auch intendiert.

Was diesen ominösen Hysteresefaktor und Filter betrifft, auf den ich in diesem Artikel noch öfters zurückkommen werde, so zitiere ich mich einmal - aus einem älteren Blogartikel - selbst:

"...Auch die alten Avocet Bikecomputer und die Avocet Vertech Bergsteigeruhr berechneten relativ akkurate Auf- und Abstiegswerte. Soweit ich weiß, hat kein geringerer als der in der Radszene sehr bekannte Jobst Brandt, den in den Avocet Bike Computern verwendeten (Hysterese)-Algorithmus beigesteuert (hier ein interessanter Newsgroup-Beitrag von Jobst Brandt, der das Thema ansatzweise beleuchtet: Altimeters)."

Den Ötztaler Radmarathon, dem offiziell 5.500 Höhenmeter attestiert werden, könnte man auch leicht auf 6000-7000 anwachsen lassen, wenn man denn wollte und gänzlich ohne Hysterese und Glättung die Höhenwerte der protokollierten GPS-Aufzeichnung einzeln aufsummiert. Auf gleiche Weise könnte man ihn aber künstlich auf 3000 Aufstiegsmeter herunterstutzen, wenn man es mit dem Hysteresefilter und vor allem der Glättung nämlich übertreibt.

Datenerhebung (Datenbasis):

Im Allgemeinen kann man diese Daten auf folgende Arten generieren:

Manuell erzeugte Routen (Tracks), die mit Hilfe eines Webportals oder Tourenprogrammes erstellt wurden.
(Häufig weisen diese Routen wenige Stützpunkte auf, die Höhenwerte werden dabei fast immer synthetisch mit Hilfe einer Geo-Höhendatenbank (z.B. SRTM Daten) generiert. Je nach dem wie viele Datenpunkte diese Routen/Tracks aufweisen, ergeben die Deltas (siehe oben) mitunter nur eine sehr grobe Annäherung. Es ist dann schwer, diese synthetisch erzeugte Route auf das reale Abbild runterzubrechen. In diesem Zusammenhang wird Euch wahrscheinlich auch häufig der Begriff DEM begegnen. Das digitale Höhenmodell ist quasi eine Art Überbegriff, der die Nutzung von SRTM Daten, etc., miteinbezieht, aber in diesem Beitrag nur eine untergeordnete Rolle).

Manuell erstellten Routen, die im Gegensatz zu protokollierten Tracks nur sehr wenige Datenpunkte aufweisen, wird man mit einfachen GPS Viewer Apps nicht sonderlich viele nützliche Statistikdaten entnehmen können. Allenfalls ein sehr grob auflösendes Höhenprofil.
Protokollierte GPS-Aufzeichnungen, die rein auf GPS-Daten basieren.
(Das führt häufig zu weiteren Diskussionen, auf die ich an dieser Stelle nicht eingehen will. Je nach Qualtität des GPS-Empfängers können diese Daten aber sehr verrauscht sein, gerade, was die Höhenwerte betrifft. Und wenn man sich die oben skizzierte Delta-Berechnungsmethode vor Augen hält, wird vielleicht ersichtlich, dass diese Berechnungsmethode bei verrauschten Daten schnell an ihre Grenzen stoßen kann und man diese Methode dann entsprechend aufbohren muss (Nutzung eines Hysteresefilters, vorgeschaltete Datenglättung, etc.)

Bei reinen GPS Aufzeichnungen steht und fällt die Aussagekraft des protokollierten Höhenverlaufs mit der Qualität des GPS Moduls.
Protokollierte GPS-Aufzeichnungen, bei denen die Höhenwerte mit Hilfe eines Höhenmessers (integrierter Barometerchip) ermittelt wurden.
(Auch das wird immer wieder diskutiert, die Genauigkeit von GPS-Höhen gegenüber Barometer-Höhen. Man kann das drehen und wenden wie man will: wenn man die Delta-Berechnungsmethode nutzt, sind Barometerhöhen immer eine sehr gute Grundlage, da selbst ein Wettersturz, der großen Einfluß auf die Barometerhöhen hat, bei der Deltaberechnung nur marginal aufschlagen wird. Bei einer Samplerate von 1 Sek., wie sie bei den meisten Sportcomputern- und Uhren Verwendung findet, schlägt ein normalerweise eher langsam verlaufender Barometerdrift nämlich so gut wie gar nicht auf!).

Auf die absoluten Höhen hat ein Wettersturz große Auswirkungen, was zu einem verzerrten Höhenprofil führen kann, auf die berechneten Auf- und Abstiegswerte aber eher nicht.

Das sind jetzt einmal die drei Kernarten, die uns in dieser Sache beschäftigen werden und wie man der Animation entnehmen kann, sind die daraus resultierenden Unterschiede nicht unbedingt marginal. Bei reinen GPS Daten spielt der verwendete GPS Empfänger (GPS Chipsatz), wie gesagt, eine sehr große Rolle. Die Abweichungen müssen nicht immer so ausgeprägt wie in dieser Animation sein, aber Abweichungen wird es immer geben, wenn unterschiedliche Messverfahren Anwendung finden oder Messapparate (GPS Module) unterschiedlicher Qualität verwendet werden.

Es gibt auch noch weitere Methoden (kombinierte GPS-/Barometer-Höhen, kombinierte GPS-/SRTM-Höhen, etc.), die aber letztlich auf die weiteren Ausführungen keinen so großen Einfluß haben, da sich das Kernproblem primär auf die unterschiedlichen Daten und deren Interpretation erstreckt.

Wichtig ist zu wissen, dass die Art der Datenerhebung großen Einfluß auf die Berechnung hat. Grobe Daten, verrauschte Daten und demgegenüber eher fein auflösende, akkurate Daten, wobei eine zu feine Auflösung der Höhenwerte auch negative Effekte mit sich bringen kann. Gerade dann, wenn die Höhenwerte im cm Bereich gemessen und protokolliert werden, wie das heutzutage fast immer der Fall ist. Man erkauft sich diese Genauigkeit durch ein feines Grundrauschen, bedingt durch die viel zu feine Abstufung. Das kann man aber mittels eines einfachen Hysterese-Algorithmus sehr leicht egalisieren (dazu gleich mehr).

Erste Schlussfolgerung

Es wird schwer sein, das alles in eine universelle Formel zu packen! Ja nach Art der Daten muss man an die eigentliche Berechnung anders herantreten.

Bei sehr groben Daten bietet sich womöglich eine Interpolation der Daten an. Wenn die Daten allerdings zu grob sind, kann man damit auch nichts reißen. Dann fehlen einfach zu viele Stützwerte, um brauchbare Ergebnisse zu berechnen. In dem Fall wird man die fehlenden Werte synthetisch hinzufügen müssen (DEM), also fehlende Routenpunkte auffüllen und die fehlenden Höhendaten z.B. aus SRTM-Daten ergänzen. Das machen in der Regel nur spezialisierte Online-Tourenportale oder ausgefeilte Tourenplaner-Programme und Apps (wie z.B. das weiter unten erwähnte Locus Map).
Bei stark sprunghaften und/oder stark verrauschten Daten kann es sinnvoll sein, die Daten (Höhenwerte) zuvor zu glätten. Einen geeigneten Glättungsfaktor zu finden, ist dabei häufig das Hauptproblem.

Im ungünstigsten Fall muss man sich von den ermittelten Höhenwerten vielleicht sogar verabschieden und diese durch SRTM-Daten ersetzen. Das geht natürlich nur, wenn man pro Datenpunkt auf GPS Koordinaten zugreifen kann, was bei GPS Aufzeichnungen aber der Fall sein sollte.

Länger andauernde Empfangsausetzer, die zu fehlenden oder mitunter komplett falschen GPS Koordinaten führen, können dabei ein echtes Problem sein, weil man in diesem Fall keine SRTM-Daten zuweisen kann (fehlende Bezugspunkte).
Bei (zu) fein auflösenden Daten - bei denen sozusagen ein sehr feines Rauschen inhärent ist - kann man, wie bereits erwähnt, mit einem einfachen Hysteresefilter dieses feine Rauschen sehr gut egalisieren. Auf eine Glättung kann oftmals verzichtet werden.

Die ersten beiden Punkte führen dazu, dass man die Datenreihen vor oder während der eigentlichen Berechnung intern aufbereiten muss (z.B. anhand eines DEM Modells oder mittels mathematischer Glättung, wobei man diese beiden Eingriffe sogar häufig kombinieren muss, da auch feinauflösende SRTM Daten normalerweise ein Rauschen aufweisen).

Beim letzten Punkt (fein auflösende Daten) ist der Hysteresefilter direkt in die Berechnungsmethode eingebettet, um die vorhergehende Datenaufbereitung (Glättung) kommt man also herum.

Allgemein kann man sagen, dass eine Datenglättung bei barometrisch ermittelten Höhen eher kontraproduktiv ist, bei GPS basierten Höhen hingegen sehr oft unabdingbar.

Ich beschäftige mich mit der Auswertung solcher Daten schon etliche Jahre. Eine zeitlang habe ich das sogar hauptberuflich gemacht, aber mir ist bis heute kein Geistesblitz gekommen, wie man das gänzlich ohne Userinput abhandeln könnte. Mit anderen Worten, zumindest in den Programmen/Apps, die ich programmiert habe, wird der User nicht umhinkommen, bestimmte Parameter zu justieren.

Und leider wird er davon öfters Gebrauch machen müssen, je nachdem, welche Daten er importiert und auswerten will. Eine automatisierte Anpassung der Steuerungsparameter wäre freilich schöner, aber ich selbst habe das bisher nicht hinbekommen. Mir ist auch kein Projekt bekannt, das das - Stand heute - verwirklichen konnte.

Im Zeitalter der AI (KI) könnte man sicherlich auch eine Erkennungsmethode basteln, denn mit KI ist ja alles möglich (oder besser gesagt, soll alles möglich sein, man darf daran aber auch zweifeln) :-) Letztlich wird es dadurch aber noch komplexer und künstliche Komplexität ist hier sicherlich nicht von Vorteil, vor allem dann, wenn viele Köche (Auswertungsplattformen, Auswertungsprogramme, Apps, etc.) mitwirken, von denen sicherlich nicht Alle, die KI Seminare, die man heutzutage beruflich so belegen 'muss', besucht haben.

Istzustand

Mein jetziger Entwicklungstand ist der, dass ich bei meinen Projekten in der Regel* um die folgend aufgeführten zwei Stellschrauben nicht umhinkomme. Zumindest dann, wenn man in universeller Form alle Arten von protokollierten (GPS) Daten auswerten will (also genau das, was GPS Viewer Programme/Apps im Normalfall ja machen). Wenn man sich auf eine bestimmte Art von Daten beschränkt, beispielsweise nur die Daten eines bestimmten Sportcomputers auswertet, wird es mitunter etwas einfacher, da man mit hardcodierten Parametern arbeiten kann, die mit dem Gerät fest verknüpft sind.

Datenglättung vor Aufruf der eigentlichen Berechnungsmethode
(kann/sollte bei fein auflösenden Daten entfallen, eine starke Glättung bewirkt dann nämlich das Gegenteil, da eine Datenglättung ja dazu führt, dass Ausreißerwerte gefiltert werden. Bei akkuraten - was auch immer akkurat in diesem Zuammenhang bedeutet? :-) - Daten, filtert man damit mitunter Spitzen weg, die durchaus ihre Berechtigung haben. Letztlich sollen damit ungewollte Ausreißerwerte neutralisiert werden, mehr aber nicht.)
Verwendung eines Hysteresefilters in der Berechnungsmethode
(dieser Hysteresefilter ist immer sinnvoll, a) um ungewolltes feines Grundrauschen zu egalisieren und b) um kleine Hubbel, die keinen nennenswerten Einfluss auf den Anstieg haben, zu filtern. Wie oben bereits angemerkt, kann es sinnvoll sein, beim Laufen, Wandern und Radfahren unterschiedliche Hysteresefaktoren zu verwenden).

In der einfachsten Variante könnte das z.B. so aussehen und bewirkt, dass nur Höhenänderungen unter- oder oberhalb eines spezifischen Schwellenwertes berücksichtigt werden:
```
if (alt > lastalt + hystfactor) {
    up += (alt - lastalt);
    lastalt = alt;
} else if (alt < lastalt - hystfactor) {
    down += (lastalt - alt);
    lastalt = alt;
}
```
Darüber hinaus besteht auch die Möglichkeit, die protokollierten Höhenwerte komplett neu zuzuweisen. Die vorhandenen Werte werden dabei durch Werte aus einer Höhendatenbank (z.B. SRTM Daten) ersetzt. Letztlich gehen die protokollierten (Höhen)Werte dabei komplett verloren -> bei ausnahmslos versaubeutelten Höhenwerten ist das sicherlich ein probates Mittel, halbwegs* valide Höhenwerte zu erhalten. Wenn die Höhenwerte mit einem Höhenmesser (Barometer) ermittelt wurden, kann man damit aber auch vieles kaputtmachen. Ich selbst erachte das als eine reine Fallback Lösung, die vor allem dann nützlich sein kann, wenn man die Daten mittels Mathematik nicht mehr aufbereiten kann.

* Mittlerweile kann man auf relativ hochauflösende SRTM-Daten zugreifen. Dadurch gewinnt man natürlich etwas Genauigkeit, aber es wird - technisch bedingt - immer mal Punkte geben, bei denen es trotzdem nicht 100% zusammenpassen wird.

Vielen dieser protokollierten Daten kann man nicht entnehmen, auf welche Art und Weise (rein GPS basierte Höhen oder Barometer basierte Höhen) sie aufgezeichnet wurden bzw. zustande gekommen sind. Mit etwas Augenmaß kann man das aber häufig visuell abschätzen:

ein feines Höhenprofil ohne große Sprünge kann ein Indiz dafür sein, dass die Höhendaten barometrisch emittelt wurden,
wenn ein Abändern des Glättungsfaktors kaum bzw. nur sehr geringe Auswirkungen auf die berechneten Auf- und Abstiegwerte hat, ist das ebenfalls ein Indiz für barometrisch ermittelte Höhenwerte oder bereits zuvor geglättete und/oder sehr hochauflösende STRM-Daten: je feiner die Höhenwerte abgestuft sind, desto geringer ist der Einfluß der Glättung und je grober, desto ausgeprägter.
Das ist natürlich nur eine Faustformel, aber im allgemeinen gilt dann doch, dass GPS basierte Höhenwerte eher sprunghaft sind und ein Glättungsalgorithmus hier größeren Einfluß hat.

Die dahinterstehende Sportart kann man den Importdaten auch nicht immer entnehmen. Daher führt häufig kein Weg daran vorbei, diese Parameter immer wieder und wieder manuell anzupassen, wenn die berechneten Werte überhaupt nicht passen. Und als Fallback-Lösung, wenn gar nichts mehr anders geht, die komplette Neuzuweisung der Höhenwerte (Variante 3).

Ausnahmen:

* Keine Regel ohne Ausnahme. Bei FIT Files - Industriestandard im Sportbereich - werden normalerweise die Sportart als auch die vom Gerät selbst berechneten Statistikwerte in das Fit File geschrieben. Man kann also der Importdatei häufig direkt die Sportart entnehmen und die Auf- und Abstiegswerte können durchgereicht werden, sodass diese nicht mehr selbst berechnet werden müssen.

Was man dem Fit File in der Regel aber nicht entnehmen kann, ist die Art der Höhendaten (GPS- oder Barometer basiert).

Nur am Rande erwähnt: Strava verwendet hierfür eine interne Gerätedatenbank, extrahiert die VID und PID aus dem Fit File und kann auf diese Weise erkennen, ob die Höhendaten von einem Gerät mit einem echten Höhenmesser stammen oder GPS basiert sind (sofern die VID/PID der Gerätedatenbank entnommen werden können). Dementsprechend werden die Höhenwerte dann entweder ohne Nachbehandlung übernommen oder mittels einer Höhenwertdatenbank nachbearbeitet.

Die durchgereichten Auf- und Abstiegswerte beziehen sich aber immer auf die Gesamtaufzeichnung. Viele Auswertungsprogramme erlauben ein Zoomen, also quasi ein Zerlegen der Aufzeichnung in einzelne Teilbereiche und berechnen die Auf- und Abstiegswerte für den angezeigten Zoombereich dann doch wieder eigenständig. Das kann im Extremfall dazu führen, dass die berechnten Werte eines Teilbereichs höher ausfallen als die durchgereichten Werte der Gesamtaufzeichnung, was natürlich keinen Sinn ergibt, da ein Teilbereich nie größer dem Gesamtbereich sein kann. Das ist sozusagen die Ausnahme der Ausnahme :-)

Bei der Darstellung des Gesamtprofils werden die Auf- und Abstiegswerte aus dem Fit File verwendet, beim Zoomen müssen Auf- und Abstieg hingegen eigenständig berechnet werden.

Mit anderen Worten, auch bei Fit Files finden die oben genannten Stellschrauben häufig Anwendung. Zumindest dann, wenn man tiefer in Teilbereiche hineinschauen kann. Man kann dem Problem also nicht generell aus dem Weg gehen.

Zweite Schlussfolgerung

Wir können diesem Problem - wie oben dargestellt - nur bedingt aus dem Weg gehen, wenn wir uns auf Fit Files oder GPS-Dateien, die jene essentiellen Statistikwerte mitliefern, beschränken und dabei nur die weitergereichten Daten verwenden/aufschlüsseln, also gänzlich auf eigene Berechnungen verzichten.

Spätestens dann, wenn wir genauer in die Aufzeichnung hineinsschauen wollen (Zoomen), werden wir um eine eigenständige Neuberechnung nicht umhinkommen (also immer dann, wenn wir einem Programm etwas Intelligenz verpassen wollen).

Das standardisierte Fit File Format kann die Analyse der Daten etwas vereinfachen, wenn es in die Tiefe geht, ist aber doch wieder Handarbeit angesagt.

Fallbeispiele

Genug der Theorie, am besten können wir das Gesagte anhand einiger konkreter Fallbespiele illustrieren. Ich greife hierfür unter anderem auf meine eigene Android App WRPElevationChart zurück, weil wir damit die Auswirkungen der genannten zwei Stellschrauben sehr gut in Echtzeit abbilden können. Und etwas Eigenwerbung sollte im eigenen Blog ja auch erlaubt sein :-)

Auch werde ich mich jetzt auf zwei konkrete und sehr einfach strukturierte Fälle beschränken. Wir könnten das bis auf die Spitze treiben und immer mal wieder Datenmaterial lokalisieren, bei dem es gut zusammenpasst, aber auch Aufzeichnungen, bei denen trotz jeglichen Feintunings, so gut wie jedes Auswertungstool stark oder weniger stark abweichende Werte aufschlüsseln wird. That's life :-)

Beispiel 1. (kurze abendliche, flache Laufrunde):

Verwendetes Gerät: Fenix 5 in Kombination mit einem Lauf-Pod, barometrisch ermittelte Höhenwerte.

Auf: 32 m, Ab: 49 m.

Verwendetes Gerät: Moto G72 in Kombination mit der Locus Map App, GPS basierte Höhenwerte.

Auf: 279 m, Ab: 355 m.

Es fällt sofort auf, dass diese Laufrunde auf einem sehr flachen Kurs entlang verläuft und daher im Normalfall auch nicht sonderlich viele Aufstiegsmeter aufsummiert werden sollten. Die Fenix berechnet auch nur 31 Auf- und 49 Abstiegsmeter, was durchaus hinkommen dürfte. Hier kann die barometrische Höhenmessung wirklich punkten.

Gegenübergestellt die gleiche Runde, allerdings mit einem Smartphone und mit der Android App Locus Map aufgezeichnet. Es sticht sofort ins Auge, dass die aufsummierten Höhenwerte viel zu hoch ausfallen (279 Aufstiegsmeter!). Daran ist weniger Locus Map schuld, sondern das verwendete Smartphone, ein Moto G72, zeichnet sich durch ein eher schlechtes GPS Modul aus. Gerade was die Höhenwerte betrifft, sind diese in dieser Form nicht wirklich brauchbar. Ein ausgemustertes Xiaomi Redmi Mittelklasse Smartphone generiert mit Locus Map - bei gleichen Einstellungen - deutlich genauere Daten (daher gehe ich davon aus, dass es wohl am GPS Modul liegen wird).

Fairerweise muss ich anmerken, dass das Smartphone in einer Laufgürteltasche vor dem Bauch getragen wurde, was die Empfangsbedingungen natürlich etwas erschwert hat. Die Fenix wurde am Arm getragen, was definitiv von Vorteil sein dürfte, da so eine relativ gute freie Sicht zum Himmel gegeben ist.

Anpassung der Werte mittels Korrektur bzw. Neuzuweisung der Höhenwerte:

Erst nachdem ich die Höhenkorrekturfunktion in Locus Map verwendet habe, harmonieren die (Höhen)Werte mit der Fenix Laufuhr relativ gut (34 Auf- und 43 Abstiegsmeter). Allerdings überschreibt die Höhenkorrektur, die mit dem GPS protokollierten Höhenwerte ausnahmslos mit SRTM-Höhen. Mit der ursprünglichen Aufzeichnung hat das Höhenprofil nun nichts mehr gemein!

Auch sind SRTM Daten kein Selbstläufer. Hier, bei diesem sehr flachen Profil, verteilt auf eine sehr kurze Strecke, stimmen die Daten ganz gut mit den Barometerdaten überein; bei einer längeren Runde im Gebirge könnte das aber anders aussehen (siehe auch entsprechende GIF-Animation weiter oben).

Wie auch immer, durch die Zuweisung synthetischer SRTM-Höhenwerte konnte das Problem gelöst werden, sodass wir uns weitere Anpassungen ersparen können :-)

Beispiel 2. (sehr kurze Wandertour um den Usinger Weiher):

Verwendetes Gerät: Fenix 5 in Kombination mit einem Lauf-Pod, barometrisch ermittelte Höhenwerte.

Auf: 8 m, Ab: 14 m.

Verwendetes Gerät: Moto G72 in Kombination mit der Locus Map App, GPS basierte Höhenwerte.

Auf: 99 m, Ab: 99 m

Alles sehr flach, auch wenn wir dem 3D Höhenprofil aufgrund einer gewollten Überbetonung der Skalierung ein paar Höhenänderungen entnehmen können. Acht (8) Auf- und 14 Abstiegsmeter kommen also Pi mal Daumen durchaus hin.

Bei der GPS basierten Messung erscheinen die aufgeschlüsselten Höhenwerte deutlich zu hoch!

Die GPS basierten Höhenwerte sind teilweise sehr sprunghaft. Normalerweise müsste das Höhenprofil eher glatt verlaufen. Im letzten Drittel sind viele Sprünge zu erkennen, was bei der Berechnung mit der weiter oben erläuterten Delta-Methode natürlich aufschlagen wird. Große Sprünge kann/will man mit dem Hysteresefilter nämlich nicht abfangen, daher fließen diese in die Berechnung weiterhin ein.

Anpassung der Werte rein mathematisch mittels Hysteresefilters und Datenglättung:

Mit diesem Beispiel kann ich sehr gut illustrieren, was es mit diesen spezifischen Anpassungen auf sich hat.

Die GPS Viewer App WRPElevationChart verwendet defaultmäßig einen sehr konservativen Glättungsfilter (20 Datenpunkte) in Kombination mit einem eher kleinen Hysteresefaktor (1 m). Bei vielen GPS basierten Importdaten fährt man damit recht gut, weshalb ich diese Werte auch als Defaultwerte verwende.

Somit werden viele Ausreißerwerte, die vor allem bei GPS basierten Höhendaten auftreten können, egalisiert und die Runde um den kleinen Weiher weist nun nur noch 19 Aufstiegsmeter auf. Nicht ganz gleichauf mit den Werten der Fenix, aber wir wollen es mit der künstlichen Glättung auch nicht übertreiben. Wir können der Profilgrafik entnehmen, dass das Rauschen durch die Datenglättung merklich reduziert wurde. Die GPS-Höhen wurden also nicht repariert, aber die durch die Ausreißerwerte (Höhensprünge) bedingten Einflüsse wurden deutlich reduziert. Mehr kann/will man mit diesen Methoden nicht erreichen.

Durch bewußtes Herabsetzen des Hysteresefilters und des Glättungsparameters können wir die berechneten Werte aber auch wieder schön in die Höhe treiben und liegen nun fast gleichauf mit Locus Map (Auf: 99 m, Ab: 98 m). Der Profilgrafik können wir entnehmen, dass die aufzeichnungsbedingten Höhensprünge nun wieder richtig krass aufschlagen.

Sinnvoll ist das in diesem Fall natürlich nicht, aber ich will ja nur veranschaulichen, welchen Einfluß diese Parameter auf die Berechnung haben können.

Diese weiter oben schon einmal gezeigte Animation verdeutlicht m.E. sehr schön, was eine Datenglättung bewirkt und welche Auswirkungen das alles auf die Höhenprofilgrafik und vor allem auf die nachfolgenden Berechnungen hat. Und ihr könnt sehr gut sehen, dass es nicht immer so einfach ist, einen geeigneten Glättungsfaktor zu bestimmen. Auch wenn ich mich wiederhole, bei verrauschten bzw. sehr sprunghaften Daten wird es eher auf einen hohen Glättungsfaktor hinauslaufen, wohingegen bei einer feinen (sauberen) Aufzeichnung - wenn überhaupt - nur ein sehr kleiner Faktor verwendet werden sollte.

Ich will jetzt nicht darüber urteilen, ob Locus Map an dieser Stelle vielleicht besser eine Datenglättung einbeziehen sollte oder nicht. In Locus Map gibt es wirklich sehr viele Stellschrauben, unter anderem die oben erwähnte Höhenkorrektur, sodass es wahrscheinlich nicht nötig ist, den User mit speziellen Glättungsfaktoren, die variabel angepasst werden können/müssen, zu drangsalieren.

Auch steht und fällt die Qualität der Daten mit dem GPS Modul: wer Locus Map primär als Tracking App nutzt, tut gut daran ein Smartphone zu nutzen, das mit einem guten GPS Modul auftrumpfen kann.

Wie gesagt, mitunter werden wir leider nicht umhinkommen, mit diesen Faktoren etwas zu experimentieren. Zumindest dann nicht, wenn wir das alles mathematisch eintüten wollen. Schön ist das nicht, aber es läßt sich nicht gänzlich vermeiden.

Möchtet ihr diese Auswirkungen selbst einmal am eigenen Objekt testen? Mit meiner App WRPElevationChart könnt ihr das sehr plastisch mit euren eigenen Testdaten nachstellen und begutachten. Mir hat das Tool selbst schon etliche Male beim Analysieren geholfen und auch am Radlerstammtisch konnte ich die Problematik damit einigermassen verständlich illustrieren.

Einige Zweifel bleiben immer, das hängt aber auch damit zusammen, dass dieses Thema sehr schnell auf einer Metaebene ausdiskutiert wird, eben jene Diskussionen, bei denen es kein richtig oder falsch gibt, weil es auch eine Frage der eigenen Interpretation ist.

Fazit

Ich weiß nicht, ob ich mein Anliegen einigermaßen gut rüberbringen konnte. Als direkt Betroffener (Entwickler solcher Auswertungstools) sehe ich mich häufig solchen Anfragen ausgesetzt. In den Fachforen wird das, wie oben angemerkt, auch immer wieder kontrovers diskutiert.

Ein Mensch kann solche Anstiege vielleicht besser charakterisieren/einschätzen und on-the-fly entscheiden, ob für ihn die Fuß-zum-Gipfel-Berechnung sinnvoller ist oder eine andere Variante (z.B. die 'Delta-Methode'). Computerprogramme können das eher nicht, auch wenn es denkbar ist, dass man eine Erkennungsmethode bastelt, die selbst entscheidet, welche Berechnung bei Anstieg XY Anwendung finden sollte und welche nicht.

Aber selbst dann bleibt es mitunter schwierig, weil längere Radtouren oft mehrere Anstiege einbeziehen und jeder Anstieg/Berg seinen eigenen Charakter aufweist. Das muss alles eingetütet werden.

Als User müssen wir uns damit irgendwie arrangieren. Wenn man eine übertragbare Messgröße haben will, könnte es sinnvoll sein, sich auf eine bestimmte Variante festzulegen.

Also die protokollierten Daten auf ein bestimmtes Medium hochladen, das die Importdaten generisch auswerten kann, indem es beispielsweise prinzipiell alle Höhenwerte durch SRTM-Höhen ersetzt (DEM) und eigenständige Berechnungen vornimmt. Einige Webportale machen das so, aber leider ist auch das nicht der heilige Gral, weil Importdaten nun einmal, wie hier dargelegt, alles andere als homogen sind, vor allem dann, wenn sie aus unterschiedlichen Quellen abstammen.

Strava schreibt dazu in seiner FAQ: FAQ: Höhenangaben auf Strava

Wie auch immer, geeignete Schlüsse müsst ihr selbst daraus ziehen, letztlich heißt es mal wieder: "alles ist relativ" oder "wer misst, misst Mist" :-)

Danke fürs Lesen.