Fehlerbereinigung von GPS-Daten (GPX)

[demlak]

Moin,
auf der Suche nach einer Lösung, bei der ich aus einem GPX-File brauchbare Analyse-Werte errechnen lasse (Ziel: Anzeige im eigenen Blog) habe ich ein wenig experimentiert um auf Werte wie Durchschnittsgeschwindigkeit und tatsächliche aktive Zeit etc. zu kommen.
Wer bereits ein wenig im Thema ist, kann runterscrollen zu "Summa Summarum")

Als Referenz dienten mir die Auswertungen im Strava-Webinterface meiner Strava-Aufzeichnungen. Im Webinterface bekommt man ja die rohen/unverfälschten GPX Files zum Download. Im Vergleich dazu: Per Api auf Strava zuzugreifen ermöglicht einem nur einen "optimierten" GPS-Stream zu erhalten.

Wie vielen Leuten immer wieder auffällt, sind die Analyse-Daten unterschiedlicher Geräte sehr unterschiedlich. Dazu muss man sich nicht mal einen Vergleich zu anderen Portalen antun. Es reicht ja schon, wenn man mit einem identischen Gerät direkt nebeneinander zu zweit eine Strecke trackt. Am Ende spukt Strava unterschiedliche Analyse-Werte aus.

Hat mich bisher nicht sonderlich gestört. Doch nun will ich für die Anzeige auf meinem Blog automatisiert Analyse-Werte aus GPX Dateien erhalten/berechnen lassen und hab mir dafür Software angeschaut. Z.B. Waddle (PHP Parser mit Statistik-Ausgabe), gpxpy (python Parser mit Statistik-Ausgabe) oder auch direkt am Rechner tools wie "BikeExperience", "GPX-Viewer", etc.
Was dabei auffällt ist der starke Unterschied in den Werten. z.B. bei ein und dem selben GPX-Track kamen Höchstgeschwindigkeiten zwischen 22 und 38kmh und Durchschnittsgeschwindigkeiten von 4,8 bis 9,9 kmh bei der Analyse heraus. Und kein Tool und kein Parser war in all seinen Werten Deckungsgleich mit einer der anderen - geschweige denn mit den Werten von Strava.

Das machte mich natürlich stutzig und ich hab versucht mich ein wenig schlau zu lesen.

Nun. Am Ende läuft es darauf hinaus, dass bei ein und der selben Datenlage unterschiedliche Auswertungen darauf basieren, dass unterschiedliche Algorithmen zur Berechnung herangezogen werden. Im Prinzip kocht da jeder sein eigenes Süppchen. Manch einer ignoriert bei Durchschnittswerten, dass auch Pausen eingelegt werden. Die meisten ignorieren aufgezeichnete Höhendaten und generieren die Z-Achse auf Basis der 2d-Werte in Abgleich mit (online-)Datenbanken, etc.. etc..
Hinzu kommt, dass die Datenbasis schon extrem wackelig ist: Unsere Geräte zeichnen viel zu grobe Werte in viel zu groben Intervallen auf. Z.B. im Sekundenbereich statt Millisekunden. Dadurch entsteht ein Jitter und dicke Ausreißer wie z.B.: zwischen zwei Punkten mit konstanter Geschwindigkeit eine Erhöhung um 40% der Geschwindigkeit, etc..

Um das alles besser zu verstehen, hat mir dieser sehr aufschlussreiche Blog-Artikel geholfen: http://regex.info/blog/2015-05-09/2568
Schön ist auch, wie dort klar wird, dass Strava teils fast 300% bei den geleisteten Höhenmetern daneben liegt.

Insg. ist das natürlich alles stark herunter gebrochen. Das Thema gestaltet sich weit aus komplexer. Ich denke aber, dass es hier nicht tiefer ins Thema eingedrungen werden muss, als es der verlinkte Blog-Artikel schon tut.

Summa Summarum: Egal wo, egal wer, egal womit. Es ist immer eine sehr fehlerhafte Auswertung aufgrund einer sehr fehlerhaften Datenlage.

Nun denn, bis hier hin war es zur Erklärung für diejenigen die nicht im Thema sind.

Mir geht es um folgendes:
Es sollte durchaus möglich sein, Anhand von einem Profil wie "Mountainbike - Gelände" oder "Rennrad - Asphalt" oder "Wandern", etc. eine automatisierte Fehlerkorrektur von GPX-Files vornehmen zu lassen.

Klar ist, dass grobe Ausschläge immer geglättet werden müssen. Was dabei grob ist und was nicht, ist abhängig vom Bewegungsprofil. 5kmh Unterschied beim Wandern sind anders zu bewerten als beim Rennradfahren. Bei Rennrad kann in der Regel ein Abgleich der Höhendaten mit Datenbanken wie SRTM stattfinden. Bei Mountainbike ist klar, dass ein Jitter zu extrem fehlerhaften Gesamt-Höhenmeter führt und ein Abgleich mit externen Datenbanken zu weiteren Fehlern bzw. zu einer Potenzierung selbiger führt (siehe verlinktes Blog zum Thema "very-3D mountain pressed into a mostly-2D face".

Etc. etc.

Das Thema ist nicht neu und sicher viel diskutiert worden. Alleine der Umstand, dass hunderte verschiedene Dateiformate und Analysetools existieren, zeigt auf, wie viele Gedanken zu dem Thema existieren.

Ich hab mich auch heute mit jemanden darüber unterhalten, dessen Fachgebiet genau diese Fehlerbehaftung von Geo-Daten ist - Endanwender sind jedoch nicht sein Arbeitsbereich.

Nun möchte ich hier fragen, ob hier Erfahrungswerte zur Fehlerbereinigung (Jitter, Extremausschläge, etc.) existieren. Da mir das Web und auch der Fachmann nicht beantworten konnten, ob es dazu brauchbare Tools/Methoden gibt, die über eine theoretische Funktionsweise hinaus gehen.

Grundsätzlich sind für mich Tools, welche unter Linux per Script ansprechbar sind, am interessantesten.

Kennt ihr fertige Tools, die intelligent GPX-Files korrigieren?
Mit "intelligent" ist gemeint, dass diese nicht einfach nur Mittelwerte aus z.B. drei Wegpunkten generieren oder Spitzen pauschal wegbügeln. Es geht auch nicht darum von z.B. 5000 Wegpunkten eine pauschal geglättete Version von z.B. 500 Wegpunkten zu erhalten. Letzteres kann GPSBabel z.B. mit Standardfiltern. Ich hab mich mit GPSBabel noch nicht im Detail auseinandergesetzt, ob dort z.B. in Abhängigkeit des Profils (z.B. Wandern, Rennrad, MTB, etc.) unterschiedlich gefiltert werden kann. Vermutlich kann man hier Jitter recht gut wegfiltern ohne den Rest des Tracks zu verfälschen.

Was nicht in Frage kommt: Ein anderes Gerät als ein Smartphone oder eine Smartwatch zur Aufzeichnung zu nutzen. Einen dedizierten Tracker und/oder Navigator, welcher extra-Geld, Strom und Platz kostet, fällt einfach raus. Es ist klar, dass mit der vorhandenen Datenlage niemals ein perfektes Ergebnis entstehen kann. Daher geht es hierbei auch "nur" darum, aus der vorhanden Datenlage das Optimum heraus zu holen und nicht um eine bessere Aufzeichnung.

Wie macht ihr das?

 

[Ralphi]

Moin,

...

Nun möchte ich hier fragen, ob hier Erfahrungswerte zur Fehlerbereinigung (Jitter, Extremausschläge, etc.) existieren. Da mir das Web und auch der Fachmann nicht beantworten konnten, ob es dazu brauchbare Tools/Methoden gibt, die über eine theoretische Funktionsweise hinaus gehen.

Grundsätzlich sind für mich Tools, welche unter Linux per Script ansprechbar sind, am interessantesten.

Kennt ihr fertige Tools, die intelligent GPX-Files korrigieren?
Mit "intelligent" ist gemeint, dass diese nicht einfach nur Mittelwerte aus z.B. drei Wegpunkten generieren oder Spitzen pauschal wegbügeln. Es geht auch nicht darum von z.B. 5000 Wegpunkten eine pauschal geglättete Version von z.B. 500 Wegpunkten zu erhalten. Letzteres kann GPSBabel z.B. mit Standardfiltern. Ich hab mich mit GPSBabel noch nicht im Detail auseinandergesetzt, ob dort z.B. in Abhängigkeit des Profils (z.B. Wandern, Rennrad, MTB, etc.) unterschiedlich gefiltert werden kann. Vermutlich kann man hier Jitter recht gut wegfiltern ohne den Rest des Tracks zu verfälschen.

Was nicht in Frage kommt: Ein anderes Gerät als ein Smartphone oder eine Smartwatch zur Aufzeichnung zu nutzen. Einen dedizierten Tracker und/oder Navigator, welcher extra-Geld, Strom und Platz kostet, fällt einfach raus. Es ist klar, dass mit der vorhandenen Datenlage niemals ein perfektes Ergebnis entstehen kann. Daher geht es hierbei auch "nur" darum, aus der vorhanden Datenlage das Optimum heraus zu holen und nicht um eine bessere Aufzeichnung.

Wie macht ihr das?

Gleich vorweg, um Deine eigentliche Frage zu beantworten: mir sind keine Tools bekannt, die wirklich das tun, was Dir vorschwebt.

Meines Erachtens kannst Du da im Nachhinein recht wenig (automatisiert) reparieren. Von den bekannten Glättungsalgorithmen, die Du bereits genannt hast, abgesehen.
Das Problem ist, dass die Daten häufig schon in geglätteter Form protokolliert werden, also eine Datennachbearbeitung oder sagen wir besser Fehlerkorrektur intern schon stattgefunden hat. Bessere GPS-(Bike-/Lauf)-Computer glätten z.B. auch die SPD-Werte, wenn diese rein GPS-basiert protokolliert werden. Und die aktuellen GPS-Chipsätze interpolieren die GPS-Daten bereits, bevor diese an das Gerät weitergeben werden. Da die GPS-Hersteller mit dieser Materie vertraut sein dürften, werden sie schon das Optimum aus den GPS-Chipsätzen herausholen

Höhendaten könnte man mittels SRTM-Daten nachjustieren, genauer wird es damit aber aber auch nicht werden, zumindest dann nicht, wenn ein barometerbasiertes Gerät die GPS-Daten protokolliert hat und die Höhendaten vom Barometer genutzt werden.

Die beste (akkurat will ich aus diversen Gründen jetzt nicht schreiben) Ausgangsbasis hat man, wenn die Höhendaten barometerbasiert protokolliert werden und ein SPD-Sensor verwendet wird und eine feste, möglichst geringe Samplerate verwendet wird. Aber selbst dann gibt es sogar innerhalb gleicher Geräteserien Abweichungen (wie Du ja bereits selbst erkannt hast!).

Trifft das nicht zu (keine barometerbasierten Höhenwerte, kein SPD-Sensor und auch kein festes Sampleintervall), dann wird man nicht mehr viel retten können.

Egal wie man das Pferd aufzäumt, es wird immer nur auf eine Annäherung hinauslaufen und spätestens dann, wenn man Zwischenzeiten oder bei Strava Segmente genauer unter die Luppe nehmen will, wird man wieder eine Ungenauigkeit erkennen.

Ich habe ein paar eigene Erfahrunsgwerte in meinem Blog (etwas unstrukturiert) festgehalten, falls es interessiert, hier die Links:
(ich gehe aber davon aus, dass Dir das meiste dort Aufgeführte schon bekannt sein dürfte, da Du Dich mit der Materie ja schon ziemlich gut vertraut gemacht hast).

https://wrpsoft.blogspot.com/2017/09/schnell-oder-langsam-alles-relativ-wer.html
https://wrpsoft.blogspot.com/2017/07/gps-daten-oder-spezifische-sensor-daten.html

 

[demlak]

Hey, danke für deine Antwort. In den bridrn Blog-Einträgen bringst du es ja auch ganz gut auf den Punkt.
Am Ende des zweiten Eintrags bist du allerdings noch die Software schuldig geblieben =)

 

[Ralphi]

Hey, danke für deine Antwort. In den bridrn Blog-Einträgen bringst du es ja auch ganz gut auf den Punkt.
Am Ende des zweiten Eintrags bist du allerdings noch die Software schuldig geblieben =)

Bin auch noch am Suchen

 

[demlak]

Ich suche und suche und find nix.
Dabei sollte das theoretisch recht simpel sein bei den verschiedenen Analysewerten auf einen grünen Zweig zu kommen. Z.B. bei der Geschwindigkeit:
So wie beim Simplifizieren eines Tracks auch ein Spline über die Positionsdaten gelegt wird um dann abweichende Punkte weg-zuwerfen, sollte es doch eigentlich auch möglich sein, einen Spline über die errechneten Geschwindigkeiten zu werfen. Ein Glätten wäre dann ein Feinjustieren der gespeicherten Positionszeiten im Millisekunden-Bereich, so dass am Ende im GPX File kein starres 1s Intervall mehr stehen würde.
Oder halt "einfach" die Position anhand des Splines welcher über der Strecke liegt, anpassen.

Ich bin kein Coder und kein Mathematiker. Klingt für mich dennoch nach einer relativ simplen Angelegenheit.

 

[Deleted 30320]

GPS-Track-Analyse kann SRTM-Daten zur Höhenkorrektur heranziehen.
Wird leider nicht mehr unterstützt

https://www.google.com/search?q=gps+track+analyse

 

[demlak]

SRTM Höhenkorrektur ist aber, wie oben erwähnt, genau der Fehler, den auch Strava macht. Das kann in flachen Gegenden helfen. Im Gelände bzw. im Gebirge kommt da außerhalb von Straßen viel Mist bei raus, der die Datenlage noch um einiges verschlechtert.

Siehe im Eingangsposting verlinktes Blog zum Thema "very-3D mountain pressed into a mostly-2D face": http://regex.info/blog/2015-05-09/2568

 

[Ralphi]

Ich suche und suche und find nix.
Dabei sollte das theoretisch recht simpel sein bei den verschiedenen Analysewerten auf einen grünen Zweig zu kommen. Z.B. bei der Geschwindigkeit:
So wie beim Simplifizieren eines Tracks auch ein Spline über die Positionsdaten gelegt wird um dann abweichende Punkte weg-zuwerfen, sollte es doch eigentlich auch möglich sein, einen Spline über die errechneten Geschwindigkeiten zu werfen. Ein Glätten wäre dann ein Feinjustieren der gespeicherten Positionszeiten im Millisekunden-Bereich, so dass am Ende im GPX File kein starres 1s Intervall mehr stehen würde.
Oder halt "einfach" die Position anhand des Splines welcher über der Strecke liegt, anpassen.

Ich bin kein Coder und kein Mathematiker. Klingt für mich dennoch nach einer relativ simplen Angelegenheit.

Die Frage ist halt, wo es Sinn macht zu abstrahieren und wo nicht.

Was willst Du z.B. mit interpolierten Daten (< 1 sek. Samplerate) erreichen? Letztlich erzeugst Du damit nur wieder ein (geglättetes) Rauschen, das eine Genauigkeit simuliert, die den Ausgangsdaten aber nicht zu entnehmen ist.
Die Datenmasse nimmt zu, ohne dabei aber wirklich an Aussagekraft zu gewinnen.
1 Sek. Intervalle sind m.E. völlig ausreichend, um solche Daten einigermassen akkurat zu analysieren. Mag sein, dass z.B. im Motorsport eine noch geringere Samplerate Sinn machte, um die Ideallinie einer Kurve zu analysieren (aber doch nicht beim Biken ) .

Die Grafiken (Kurvendiagramme) werden dadurch auch nicht schöner und die statistischen Werte werden auch nicht genauer.

Das kann man auch mit einer normale Glättung erreichen. Die unterschiedlichen Glättungsverfahren schenken sich - zumindest bei dieser Art Daten - nicht viel. Ausreißerwerte - letztlich bei GPS Daten das Hauptproblem - werden aber egalisiert.

Je nach Glättungsfaktor stärker oder weniger stark, was dann wieder problemtisch sein kann -> nützt ja nix, wenn zuviel geglättet wird und dadurch reale Spitzen (Min- und Maxspitzen) gefiltert werden. Das kann man eigentlich nur visuell beurteilen, in dem man den Glättungsfaktor ändert und schaut, wie sich das auf die Daten auswirkt.

Du willst das automatisiert haben, also liefe es wohl auf sowas hinaus:

1.) Daten zuerst variabel filtern (Ausreißerwerte filtern). Der Filter müsste den Tourentyp berücksichtigen, also z.B. unterschiedliche Filter für Wandern, Bergwandern, MTB und Rennrad Profile, etc.

2.) Nachdem die Ausreißerwerte gefiltert wurden eine Datenglättung vornehmen, um das Grundrauschen (GPS-Daten) zu eliminieren (in der Hoffnung, dass die Glättung aufgrund der vorherigen Filterung der Ausreißerwerte nicht zu brutal aufschlägt).

3.) Sollte eine sehr große Samplerate vorliegen (oder gar eine variable Samplerate), denn eventuell fehlende Stützdaten interpolieren. Ob man dadurch dann wirklich an Genauigkeit gewinnt, sei mal dahin gestellt. Zumindest werden aber die Kurvendiagramme schöner, da 'smoother'

Für die GPS-Koordinaten müsste man dazu noch parallel die Daten glätten, man wird dann wohl wieder beim guten alten Douglas-Peucker Algorithmus (https://de.wikipedia.org/wiki/Douglas-Peucker-Algorithmus) landen.

Eventuell machte es bei reinen GPS-Daten Sinn, erst die Daten mittels dem Douglas-Peucker zu bereinigen und dann mit Punkt 1. fortzufahren. Da der Douglas-Peucker die GPS-Koordinaten (= Datenpunkte) aber mittels einer Reduzierung glättet, würde diese Bereinigung vor Punkt 1. wahrscheinlich wieder zu einer neuen Ungenauigkeit führen, was die SPD-, Höhen-, etc. Werte betrifft.

Du siehst, das kann man machen, aber das Ergebnis wird nicht so sehr von der ersten Variante, die lediglich eine Glättung vornimmt, abweichen bzw. neue Ungenauigkeiten generieren.

Und wer sich schon mal GPS-Daten unterschiedlicher Geräte genauer angesehen hat, wird gesehen haben, dass diese einen eigenen Charakter aufweisen können, was sämtliche autom. Nachbearbeitungen schon wieder relativiert. Hinzu kommt, dass viele neuere Geräte (oder auch die Apps, die jene Daten protokollieren), die Daten bereits glätten.

Ich glaube, ein Mathematiker oder Physiker könnte eventuell Spass an solch einer Sache finden, aber die haben dann wahrscheinlich doch andere Projekte, die ihnen sinniger erscheinen

Trotzdem viel Glück bei der Suche. Es kann schon gut sein, dass es doch solche Tools gibt, die versuchen, die Problematik anders anzupacken.

 

[Ralphi]

SRTM Höhenkorrektur ist aber, wie oben erwähnt, genau der Fehler, den auch Strava macht. Das kann in flachen Gegenden helfen. Im Gelände bzw. im Gebirge kommt da außerhalb von Straßen viel Mist bei raus, der die Datenlage noch um einiges verschlechtert.

Siehe im Eingangsposting verlinktes Blog zum Thema "very-3D mountain pressed into a mostly-2D face": http://regex.info/blog/2015-05-09/2568

Wenn wirklich das im Vordergrund stehen sollte:

'This means the important statistic for me is how much “vertical climb” or “elevation gain” I did during a ride, the sum of all the rises/climbs/ascents on the route.'

Ein guter Bikecomputer mit barometerbasierter Messung (ein Smartphone das diese Voraussetzung erfüllt geht natürlich auch) in Kombination mit einem guten Hysterese-Algorithmus (https://yarchive.net/bike/altimeter.html) und fertig ist die Maus. 'Genauer' wird man es m.E. nicht hinbekommen.

 

[demlak]

Evtl. hab ich mich missverständlich ausgedrückt.

zu erst zu deinem letzten Post: Natürlich kann man die Datenerhebung verbessern. Z.B. durch Barometer.
Mir geht es aber um die Fehlerbereinigung und explizit NICHT um die verbesserung der Datenerhebung.

zum Vorletzten Post:
Es ging mir ja gerade um eine Glättung. Aber eben aufgrund der Geschwindigkeit und nicht aufgrund der Position.
Die GPX Dateien haben ja nun mal nur Position und Zeit gespeichert. Daraus wird dann ja Geschwindigkeit etc. errechnet. Leztendlich war mein Satz zum Thema Spline genau darauf gemünzt, dass GPSBabel anscheinend nur anhand der Positionen glättet in dem es einfach Wegpunkte löscht, dabei wird aber explizit die Zeit außer acht gelassen. Entsprechend KANN so auf keinen Fall die Geschwindigkeit geglättet werden. Denn um einen Spline über die Geschwindigkeitskurve zu legen, benötigt man ja auch die Zeitdaten.

Ich wollte lediglich sagen, dass dies evtl. ein Ansatz wäre, der zu gehen ist.

 

[Ralphi]

Evtl. hab ich mich missverständlich ausgedrückt.

zu erst zu deinem letzten Post: Natürlich kann man die Datenerhebung verbessern. Z.B. durch Barometer.
Mir geht es aber um die Fehlerbereinigung und explizit NICHT um die verbesserung der Datenerhebung.

zum Vorletzten Post:
Es ging mir ja gerade um eine Glättung. Aber eben aufgrund der Geschwindigkeit und nicht aufgrund der Position.
Die GPX Dateien haben ja nun mal nur Position und Zeit gespeichert. Daraus wird dann ja Geschwindigkeit etc. errechnet. Leztendlich war mein Satz zum Thema Spline genau darauf gemünzt, dass GPSBabel anscheinend nur anhand der Positionen glättet in dem es einfach Wegpunkte löscht, dabei wird aber explizit die Zeit außer acht gelassen. Entsprechend KANN so auf keinen Fall die Geschwindigkeit geglättet werden. Denn um einen Spline über die Geschwindigkeitskurve zu legen, benötigt man ja auch die Zeitdaten.

Ich wollte lediglich sagen, dass dies evtl. ein Ansatz wäre, der zu gehen ist.

Hm, vielleicht stehe ich jetzt etwas auf dem Schlauch, aber das Problem ist doch, dass man aus Zeit und/oder SPD-Parametern keine Positionsdaten herleiten kann. Wie sollte Strava denn anders dabei verfahren, wenn man sich vor Augen hält, dass Strava zumindest bei den Segmenten auf weitestgehend genaue GPS-Koordinaten angewiesen ist?

Ansonsten bleibt natürlich nur, die SPD-Daten von den GPS-Koordinaten zu trennen Dazu müssen die SPD-Werte trotzdem erstmal aus den GPS-Koordinaten und den dazugehörenden Zeitstempeln berechnet werden, um dann im nächsten Schritt noch mal explizit nachbearbeitet (geglättet) zu werden. Das macht eigentlich jede mir bekannte Software -> zuerst die GPS-Daten auswerten und ggfs. - wenn keine dedizierten SPD-Werte vorliegen - die SPD-Werte anhand der GPS-Koordinaten/Zeitstempel errechnen und dann, falls nötig/gewollt, die erechenten SPD-Daten noch einmal zu glätten.

Man hat dann halt eine gesonderte SPD-Datenreihe, die nicht unbedingt rechnerisch mit den GPS-/Zeitstempeln harmonieren muss (was zum Zwecke der statistischen Auswertung aber nicht problematisch sein sollte). Das ist ja auch der Fall, wenn GPS-Koordinaten und mit einem gesonderten SPD-Sensor erfasste SPD-Daten zusammen protokolliert werden (wie das ja die meisten Bike-Computer machen, wenn ein SPD-Sensor gekoppelt ist).

Auch wenn Du die Datenerhebung nicht verbessern willst, was spricht denn dagegen, einen BT-SPD Sensor mit einer APP, die das unterstützt, zu koppeln, um die SPD-Daten gesondert zu tracken?

PS: es mag sein, dass GPSBabel hier etwas anders vorgehen muss, weil diese Tool (eigentlich ja nur eine Schnittstelle, um an die Daten zu gelangen) sonst die Daten eigenhändig verfälschen müsste.
GPSBabel kann ja keine Dummy-GPS Koordinaten generieren und die Zeitstempel auch nicht umbiegen, da die Zeitstempel nun mal einen festen Bezug zu den erfassten GPS-Koordinaten haben
Es kann nur SPD-Daten berechnen und diese z.B. im GPX-Format dort als eigenständigen zusätzlichen Parameter einbetten. Da spricht nix dagegen.

Du siehst, es wird dann doch sehr schnell akademisch...

PS: Ich gehe jetzt aber radeln, dieses Wetter sollte man ausnutzen, wenn man mal frei hat

 

[demlak]

Ich kann nur nochmals betonen, dass ich kein Mathematiker bin.. ich versuch es dennoch mal zu visualisieren, was ich oben meinte.

Edit: Im Diagramm ist die Geschwindigkeit falsch deklariert. Es sind Km/H und nicht m/s.

Ich stelle es mir wie folgt vor:

In einer GPX Datei sind Positionsdaten und die korrespondierenden Uhrzeiten.
Oder anders ausgedrückt: im Intervall von genau einer Sekunde Abstand ist angegeben, wo auf einer _Strecke_ ich mich befinde. Dabei spielt erst mal keine Rolle, ob diese Strecke voller Kurven ist oder ob sie eine Gerade ist. Der Streckenverlauf ergibt sich aus dem aneinanderreihen der Positionsdaten und dem Interpolieren der Zwischenwerte.
Wir befinden uns also zu jedem Messzeitpunkt an einer Stelle auf dieser _Strecke_.
Wir haben damit letztlich die zurückgelegten Meter (auf Strecke X) und die verstrichene Zeit. Daraus ergibt sich dann die zum jeweiligen Zeitpunkt passende Geschwindigkeit.

Um es nochmal explizit zu sagen: Geschwindigkeitswerte sind nicht gemessen, sondern liegen grundsätzlich nur berechnet aus Strecken-Position und Zeit vor.

Wenn ich jetzt davon ausgehe, durchgehend nahezu die selbe Geschwindigkeit gehabt zu haben, muss ja einer der beiden zugrunde liegenden Messdaten (Position auf der Strecke oder Zeit) fehlerhaft sein.
In dem Diagramm läuft das dann darauf hinaus, dass die rote Linie eigentlich eine konstante sein sollte, ohne die beiden Ausschläge bei Sekunde 5 und Sekunde 7. Das wäre dann der Spline auf die Geschwindigkeit.

Was ich anhand des Diagramms darstellen möchte: Wenn jetzt bei Sekunde 5 der korrespondiere Streckenwert (Position auf der Strecke (Strecke ist die Interpolation bzw. der Spline der einzelnen Positionsdaten)) angepasst wird um auf der roten Diagramm-Linie für die Geschwindigkeit eine Glättung zu erreichen, habe ich grundsätzlich nicht die Strecke verlassen aber dennoch eine geglättete Geschwindigkeitskurve mit Ausgleich der Ausreißer erreicht.

Sprich: Wenn ich die Position auf der Strecke bei Sekunde 5 von 30m auf 25m (Interpolierte Position auf der Strecke!) korrigiere, ist die rote Kurve an der Stelle geglättet.

Welche Daten/Splines hier zu interpolieren/berechnen sind, liegt relativ simpel auf der Hand. Soweit ich weiß geht das Programm GPSBabel allerdings nicht so weit. Es arbeitet nur mit Interpolation bzw. Splines alleine aufgrund der Strecke und setzt dies nicht in Abhängigkeit von Zeit. Aber genau das wäre wohl das von mir gesuchte Feature eines tools.

Das sind jetzt fiktive Werte. Ich hoffe ich konnte anschaulich machen, worauf ich hinaus will.
Es mag durchaus sein, dass ich hierbei einen Denkfehler habe.

 

[MadCyborg]

Ich denke ich verstehe, was du sagen willst. (Darüber hinaus habe ich keine Ahnung und Folge den Thema mit Interesse.)

 

[trail_hawk]

@demlak: Ich glaube mit deiner Beispieltabelle stiftest du etwas Verwirrung. Du rechnest doch die Durchschnittsgeschwindigkeit der ganzen Strecke aus. Das ist doch nicht ernsthaft dein Problem?
Die Momentangeschwindigkeit aus den Differnzen (z.B. über Vorgänger und Nachfolger) liefert viel größere Ausschläge, die zu glätten wären.
In Sec. 6 z.B. würde ich die Geschwindigkeit mit (32-30)/(7-5) = 1m/s bzw. 3.6 km/h "schätzen".
Das hilft dir nun aber auch nicht weiter.
Wenn du wirklich (nur) an Momentangeschwindigkeiten interessiert bist, dann könnte es helfen wenn du eine APP verwendest, die FIT Dateien aufzeichnet. Dort sollte mMn die Geschwindigkeit direkt mitgeschrieben werden. Das macht aber auch nur Sinn, wenn die Information von einem Geschwindigkeitssensor kommt. Und das ist ja wohl nicht dein Ziel?
Aber wenn man von FIT in GPX konvertiert, sind halt nur die Positionen übrig und damit ein Teil der Informationen weg.

 

[demlak]

Hey,
die Tabelle sollte lediglich meinen Gedankengenag bezüglich spline der Geschwindigkeitskurve im Bezug auf GPS-Position veranschaulichen. Dabei ging/geht es ja um das Glätten bzw. das Ausbügeln von Messfehlern.

Du hast natürlich recht, dass in der Tabelle an den jeweiligen "Messpunkten" "nur" die Durchschnittsgeschwindigkeit vom Streckenanfang bis zum Messpunkt gezeigt wird. Bei deinem Vorschlag wäre es die Durchschnittsgeschwindkeit zwischen 1s vor und 1s nach dem entsprechenden Streckenpunkt.

Algorithmus hin oder her, die Geschwindigkeit ist abhängig von Strecke und Zeit. Und mir ging es lediglich darum, dass die Optimierung in Richtung Spline mit dem Schrauben an der einen Stelle machbar sein könnte.

Zur Veranschaulichung nochmals ein Diagramm. Selbe Messwerte, jedoch dein vorgeschlagener Algorithmus.
Auch hier würde das Verschieben des Streckenpunktes zur Messzeit eine Glättung der Geschwindigkeitskurve ermöglichen. Offensichtlich sind die Messwerte an Sekunde 6 und 7 zu ungenau bzw. fehlerhaft.
Der Fehler in einer Aufzeichnung, bei der nur Messzeitpunkt und Streckenposition vorhanden ist, kann ja nur hierdurch bereinigt werden.
Der Messfehler ist ja die Position. Bzw. das viel zu grobe Messintervall. Wenn die Zeit genauer festgehalten werden würde, wären vermutlich auch weniger Fehler im Resultat zu finden.

Nochmals: mir geht es um die Bereinigung von unrealistischen Extremausschlägen. Diese extremausschläge basieren auf Messungenauigkeiten. Eine Fehlerbereinigung könnte sich am Spline der Kurve orientieren und sich damit (über entsprechende, mir unbekannte Algorithmen) der Realität annähern.

 

[demlak]

Und hier noch mit eingezeichneten Splines. Mathematisch nicht korrekt, sollte aber zur Veranschaulichung reichen.

Meine Aussage ist ja, dass z.B. ein verschieben der Punkte auf der Blauen Linie bei z.B. Sekunde 6 u. 7 in Richtung der Grünen Linie, dazu führt, dass die Ausschläge der Roten Linie sich der Orangenen Linie nähern.

Es wäre natürlich fatal, dies zu pauschalisieren. Man sollte das dann wohl nur an den Stellen machen, die sich als Extremwerte herausstellen. Einen entsprechenden Algorithmus vorausgesetzt, würde dann nicht jeder Punkt der Roten Linie in Richtung orangene Linie verschoben werden, sondern nur die, die eine starke Abweichung haben.

 

[trail_hawk]

Aus fehlerhaften Messdaten kann kein Algorithmus die "Wahrheit" basteln. Wenn du glätten willst, dann reicht auch einfach die Messrate zu reduzieren. Oder eben die Geschwindigkeit z.B über zwei (oder mehr) Sekunden vor und nach der aktuellen Zeit zu rechnen.
Wenn du ein "echtes" GPS-Gerät verwenden würdest, könnte die GPX Datei auch den "Messfehler" enthalten. Dann könnte man wissen, wo man korrigieren sollte. Das wird aber eine Trainings-APP vermutlich nicht aufschreiben.

Aber nochmal: Wenn ich Geschwindigkeiten wissen will, dann würde ich versuchen eine APP zu verwenden, die das auch direkt aufzeichnet (z.B im FIT Format). GPX Dateien sind das Problem und nicht die Lösung.

 

[demlak]

Nochmal: Es geht nicht um darum die "Wahrheit" zu finden. Das kann, wie mehrfach erwähnt, natürlich nicht klappen.
Es geht darum Fehler zu minimieren. Extremwerte anhand eines aufs Mountainbiken optimierten Splines zu finden und anzugleichen/zu glätten. Die Messrate einfach zu minimieren birgt andere Fehler mit sich. Wenn ich die werte 10, 20, 25, 40 habe, ist klar, dass die 25 der Fehler ist. Aber wenn ich jeden zweiten Wert eliminiere, bleibt die 25 drin. Zudem geht es bei der Geschwindigkeit nicht um die Strecke. Die Strecke anhand der Messwerten-Minimierung hin zu einem Spline über den Streckenverlauf zu "simplifizieren" (und damit nicht stumpf z.b. jeden zweiten Messwert zu löschen), macht ja, wie oben erwähnt, GPSBabel wunderbar. Es wird dabei aber die berechnete Geschwindigkeit nicht berücksichtigt. Und genau darum dreht sich dieser Thread =)
Ziel ist nicht Zauberei um ein komplett akkurates Geschwindigkeitsprofil zu erreichen, sondern Fehlerbereinigung von Extremwerten.

 

[Oldie-Paul]

... Auch wenn Du die Datenerhebung nicht verbessern willst, was spricht denn dagegen, einen BT-SPD Sensor mit einer APP, die das unterstützt, zu koppeln, um die SPD-Daten gesondert zu tracken?

Trotz google o.ä. komm ich nicht weiter. Was sind SPD-sensoren und SPD-daten? Ich würde die problemlage gern genauer verstehen.

 

[Ralphi]

Trotz google o.ä. komm ich nicht weiter. Was sind SPD-sensoren und SPD-daten? Ich würde die problemlage gern genauer verstehen.

Sowas z.B. (SPD = Speed):
https://amzn.to/2Oms4fn

Hintergrund: wenn man weiß, dass eine Messmethode (hier die 'Gewinnung' der SPD-Daten anhand von GPS-Koordinaten) fehlerbehaftet ist, dann macht es nur begrenzt Sinn, die Daten nachträglich reparieren zu wollen, wenn es denn geeignete Maßnahmen gibt, diese technisch bedingten Fehlmessungen, von vornerein zu umgehen (oder zumindest merklich einzuschränken).
Und da die meisten Bike-Computer als auch Smartphone Apps, mit eben jenen SPD-Sensoren gepairt werden können, was dazu führt, dass diese Apps (und/oder Bike-Computer) die SPD-Werte direkt von einem SPD-Sensor empfangen - und nicht mehr aus den GPS-Koordinaten selbst berechnen müssen -, wäre das der Ansatz, den ich verfolgen würde. Mit wenigen Mitteln das Maximum herausholen sozusagen

 

[Ralphi]

Sowas z.B. (SPD = Speed):
https://amzn.to/2Oms4fn

Nachtrag: Diese Sensoren gibt es auch deutlich preiswerter (die zuvor verlinkten waren nur das erste Ergebnis, das mir Google ausgeworfen hat).

 

[demlak]

Natürlich kann ein externer Sensor das Messergenis maßgeblich positiv beeinflussen. Das ist aber eine Thematik um die es hier im Thread nicht geht.

Mir (und vermutlich vielen anderen, die nicht um jedes kmh feilschen) reicht eine Fehlerbereinigung, um die es hier im Thread geht =)
Für diesen Personenkreis macht es durchaus auch Sinn.

 

[Oldie-Paul]

Sowas z.B. (SPD = Speed):
https://amzn.to/2Oms4fn
...
Und da die meisten Bike-Computer als auch Smartphone Apps, mit eben jenen SPD-Sensoren gepairt werden können, was dazu führt, dass diese Apps (und/oder Bike-Computer) die SPD-Werte direkt von einem SPD-Sensor empfangen - und nicht mehr aus den GPS-Koordinaten selbst berechnen müssen -, wäre das der Ansatz, den ich verfolgen würde. Mit wenigen Mitteln das Maximum herausholen sozusagen

Verstanden, ist sinnvoll. Bin ja schon mal mit gps 800 km/h im wald gefahren!

Natürlich kann ein externer Sensor das Messergenis maßgeblich positiv beeinflussen. Das ist aber eine Thematik um die es hier im Thread nicht geht.

Mir (und vermutlich vielen anderen, die nicht um jedes kmh feilschen) reicht eine Fehlerbereinigung, um die es hier im Thread geht =)
Für diesen Personenkreis macht es durchaus auch Sinn.

Ich meine, du unterliegst einem fundamentalen irrtum. Leg mal dein gps gerät einige stunden irgendwo im freien ab und schau dir danach den datenschrotschuss an. Das ist der fehlerbereich der messung. Du kannst dann mittels 2d-gausskurve den fehlerbereich (σ, 2σ, 3σ) festlegen. Dann kannst du etwas über die genauigkeit der einzeldaten aussagen. Das fließt dann natürlich in die parameter einer ausgleichskurve ein. Aber die geschwindigkeit ist eine abgeleitete größe, die sich aus einem bekannten zeitintervall (sehr genau) und einer differenz von zwei orten (σ s.zuvor) ergibt. Diese differenz hat einen fehler, der sich aus der faltung zweier gausskurven ergibt (s.h. σ=√(σ₁²+σ₂²)).

Jetzt hast du also einen datensatz von ortsdifferenzen mit diesem größeren fehler. Da kann dann ermitteln einer ausgleichskurve kein besseres ergebnis bringen als die ausgangsdaten schon hatten. SPD-daten (danke für die aufklärung) haben noch den vorteil, dass ihre messung nicht in festen zeitabständen erfolgen muss, sondern mit konstanten ortsdifferenzen (radumdrehung) arbeiten kann. Dadurch können auch variationen der geschwindigkeit zwischen zwei zeitmarken der ortsmessung erfasst werden. Aber das war dir ja nicht wichtig, wie du schriebst.

 

[demlak]

Natürlich geht es dabei immer nur um die Durchschnittsgeschwindigkeit zwischen zwei Orten in einem bestimmten Zeitintervall.

Fakt ist, dass die Orte genauso ungenau sind, wie die Zeitintervalle (auch wenn da Sekundentakt im GPS File steht, sind das vermutlich gerundete Werte).

Ihr habt absolut recht, dass die Datenbasis echt mies ist. Mir geht es ja auch nicht darum aus dem Nichts gute Daten zu zaubern. Sondern um das Ausbügeln von offensichtlichen Ausreißern. Also quasi die schlechtesten der schlechten Daten zu ermitteln und diese dem Durchschnitt der Nachbardaten anzugleichen.

Reden wir dauernd an einander vorbei, oder ist mein Gedankengang zu unverständlich formuliert?

Ich verstehe einfach nicht, was das Problem sein soll, bei der aus Zeitintervall und Streckendifferenz ermittelten Geschwindigkeitskurve eine Glättung zu vollziehen, die nur bestimmte Werte glättet. Und diese bestimmten Werte sind halt so Ausreißer wie deine 800kmh. Wo da nun Schwellen liegen, was ein Ausreißer definiert und was nicht, ließe sich doch sicherlich mit einem Algorithmus relativ klar definieren.

Wo liegt der Fehler in meinem Gedankengang?
Mir geht es nicht darum auf teufelkommraus recht zu haben. Aber ich sehe einfach nicht wo der Fehler in meinem Gedankengang sein soll.

 

[Oldie-Paul]

Reden wir dauernd an einander vorbei, oder ist mein Gedankengang zu unverständlich formuliert?

Nein, das ist schon klar. Die frage ist, kann dieser weg prinzipiell genauere werte erbringen als die aus glättungen im weg zeit diagramm stammenden?

Ich verstehe einfach nicht, was das Problem sein soll, bei der aus Zeitintervall und Streckendifferenz ermittelten Geschwindigkeitskurve eine Glättung zu vollziehen, die nur bestimmte Werte glättet. Und diese bestimmten Werte sind halt so Ausreißer wie deine 800kmh. Wo da nun Schwellen liegen, was ein Ausreißer definiert und was nicht, ließe sich doch sicherlich mit einem Algorithmus relativ klar definieren.

Naja, wie definierst du einen ausreißer? Da hilft dir kein algorithmus. Du legst das fest. Welches kriterium wählst du? Mir fiele da der 3σ wert (empirische standartabweichung) der ortsmessung ein. Wenn du die gerechneten geschwindigkeitsdaten verwendest, wird dieser wert größer (in diesem fall mit √2 multipliziert. Du musst also mehr werte zulassen als bei den ortswerten.
Und wenn du einen algorithmus definierst, schau mal nach den typischen wertegruppen, die auftreten können: Abbiegen 90°. Ich finde in den daten immer wieder abgschnittene ecken bei diesen kurven. Eine folge von engen kehren wird gebügelt.
Ich wünsch dir gute ideen und glück bei deinem vorhaben, bin aber wenig optimistisch. Lass halt hören, wenn du weiterr kommst.