GPX-Import - Pausen verschluckt

[HHirsch]

Hallo,

folgendes Verhalten habe ich beobachtet (runalyze online):

Bevor ich mir im Sommer eine Laufuhr zugelegt habe (und etwas später dann runalyze.com [Lob] entdeckte),
habe ich meine Läufe, Skilanglauf, Wandern etc. mit dem Smartphone und der Software "Trekbuddy"
aufgezeichnet. Mein Archiv geht da bis 2009 zurück.
Durch Trekbuddy (kurz TB) bedingt sind alle Altdaten GPX-Files. Wenn ich Pause mache, habe ich in TB
"Pause" gedrückt, und dann wieder "Pause Ende". Analog mache ich das jetzt auch mit der TomTom Runner3,
ich nutze keine Autopause Funktion.
Die aktuellen Runner3 Tracks importiere ich über das *.fit File. Nur wenn ich was verschlampt habe
(z.B. am Ende des Laufes die Aufzeichnung nicht gestoppt), hole ich mir das GPX-File aus MySports
und schneide vor dem Import in Runalyze die überzähligen Trackpoints raus.
Generell sehen die Tracks in beiden Fällen gleich aus. Die Abschnitte zwischen manuellen Pausen
sind als <trkseg>..</trkseg> gekapselt.
Also etwa so bei einem Track mit 2 Pausen:

<trk>
<trkseg>
<trkpt>...</trkpt> # 1. Abschnitt
</trkseg> # Pause 1
<trkseg>
<trkpt>...</trkpt> # 2. Abschnitt
</trkseg> # Pause 2
<trkseg>
<trkpt>...</trkpt> # 3. Abschnitt
</trkseg> # Ende
</trk>

runalyze scheint hier aber nicht jede Pause als solche zu bewerten. In meinem realen Track
sind zwei Pausen @120s (2min) und noch weitere Pausen >= 180s. runalyze zeigt die beiden Pausen
von 2min weder in der Karte an, noch sind sie in den Werten der Übersicht "Zeit"/"Verstrichene Zeit"
berücksichtigt. Nur die längeren Pausen erscheinen in Karte und in der Zeitdifferenz "Zeit"/"Verstrichene Zeit".

Um zu testen, wo die Schwelle liegt, habe ich aus einem vorhandenem GPX-Track einen Experimental-Track
gebastelt, der nach obigen Schema aufgebaut ist. Dabei habe ich die Zeitdifferenzen (Pausenzeiten)
zwischen dem letzten Trackpoint des 1. Abschnitts und dem ersten Trackpoint des zweiten
Abschnitts auf 60s justiert, zwischen Abschnitt 2 und 3 auf 120s, nächster Abschnitt 180s
und dann nochmal 240s. Also ein Track mit vier Pausen.

Wenn ich diesen Experimental-Track nun in runalyze importiere, werden alle vier
Pausen korrekt in der Karte angezeigt und spiegeln sich in der Differenz von
"Zeit"/"Verstrichene Zeit" auch korrekt wieder.

Jetzt bin ich etwas verwirrt, denn es scheint nicht nur an der Pausendauer zu liegen,
ob runalyze die Zeitdifferenz zwischen zwei <trkseg> Abschnitten als Pause bewertet
oder nicht. Spielt die Gesamtlänge eine Rolle dabei, ab welcher Länge eine Pause eine Pause ist?
Mein realer Track mit fehlenden Pausen geht über fast 14km,
der Test-Track mit allen angezeigten Pausen nur über 1,3km.

Die Trackfiles kann ich nachreichen, wenn ich wieder mal zu Hause am PC sitze.

Es grüßt
Hubert

[laufhannes]

Was das Erkennen von Pausen betrifft, sind GPX-Dateien "grausam". Da das Format weit verbreitet ist und es keine offizielle Dokumentation gibt, wie Pausen dort gekennzeichnet sein sollen, setzt jeder Hersteller das anders um. Bei manchen Dateien bedeutet ein neues <trkseg> also eine Pause, bei manchen nicht.

Die minimale Zeitdifferenz, ab der eine solche Unterbrechung tatsächlich als Pause gewertet wird, hängt von der Gesamtdauer und Anzahl Punkte ab. Aktuell wird es als Pause gewertet, wenn die Zeitdifferenz das 10-fache der durchschnittlichen Zeitdifferenz übersteigt. Wenn also beispielsweise sekündlich Datenpunkte aufgezeichnet werden, wird jede Lücke von über 10 Sekunden als Pause gewertet.

Das Verfahren ist möglicherweise nicht optimal, aber aufgrund der untersschiedlichen Interpretationen des Dateiformats bei verschiedenen Herstellern lässt uns wenig Spielraum. Wir haben ein offenes Ticket, dem Prozess etwas mehr Flexibilität zu verleihen. Angesichts unserer sehr langen Todo-Liste und der einfachen Empfehlung, ein "vernünftiges" Dateiformat für den Import zu verwenden, ist es aber ungewiss, wann wir uns dem widmen.

[HHirsch]

Hallo laufhannes,

vielen Dank für die schnelle Antwort. Mit dieser Erläuterung erklärt sich
auch meine Beobachtung.

Mein Test-Track stammt von der Runner3, dort habe ich jede Sekunde einen
Trackpoint. Somit sind alle meine Testpausen oberhalb von 10*1s und
werden berücksichtigt.

Bei Trekbuddy ist das dynamisch. Ich habe im Setup eingestellt, dass
spätestens alle 50m oder nach 30s ein Trackpoint aufgezeichnet wird.
Ausserdem wird bei Richtungsänderung die Aufzeichnungsrate höher,
auf geraden Streckenabschnitten sinkt sie wieder auf die im Setup eingestellten
Werte.

Somit habe ich in der GPX-Datei variable Zeitabstände zwischen den
Trackpoints, von wenigen Sekunden bis zu 30s.

Nehmen wir also mal an, im Mittel über den ganzen Track liegt der Abstand bei
15s, dann fallen natürlich die Pausen <10*15s unter den Tisch, die längeren
bleiben erhalten.

Ich hatte impliziert, dass zwischen den Track-Segmenten immer eine Diskontinuität
im Track angenommen wird (wozu sollte man sonst segmentieren), und dass es
deshalb keinen Sinn machen würde, diese Segmentgrenze zu ignorieren und so
zu tun, als ob man sich kontinuierlich bewegt hätte.

>> ..der einfachen Empfehlung, ein "vernünftiges" Dateiformat für den Import zu verwenden...

Die Tracks vor Anschaffung der Uhr sind halt so wie sie sind - GPX.
Gäbe es eine Variante, die GPS-Tracks in ein anderes Format zu konvertieren,
bei dem dann nach dem runalyze Import auch die "kleinen" Pausen erhalten
bleiben?

Gruß
Hubert

[mipapo]

Jeder Konverter hätte ja mit dem gleichen Problem zu kämpfen wie wir. Dementsprechend wüsste ich auch keine andere Lösung

[HHirsch]

Ist ja auch nicht wirklich schlimm. Jetzt wo ich die Erklärung für dieses Verhalten kenne,
habe ich auch kein Herzdrücken mehr, dass ich was falsch gemacht habe (ausser zu kurze Pausen früher ).
Es betrifft bei mir nur wenige ältere Tracks vor der Zeit mit Laufuhr. Die sind zwar jetzt
beim Import noch voll im Fokus, aber rutschen irgendwann zeitlich auch aus
der Wahrnehmung raus. Auf den heutigen Fitnesslevel haben die wenigen Minuten Unterschied
eh keinen Einfluß mehr.

Programmtechnisch könnte eine zusätzliche Checkbox

"Immer Pause zwischen Tracksegmenten" (oder ählich)

dem User die Entscheidung überlassen, ob er mit dem bisherigen Alogrithmus importieren will,
oder halt anders.

Also Danke nochmal für die Erklärung
Hubert

[mipapo]

Hannes hatte vorhin nochmal geschaut und in unseren bisherigen Testdateien würde es zu keinem Problem führen an der Stelle eine Überprüfung hinzuzufügen.
Und nein, eine Checkbox wird es für soetwas nicht geben. Zu viele Optionen sind immer schlecht