Distanzberechnung beim Edge

Eine interessante Frage ist, wie der der Edge eigentlich Entfernungen misst, denn hierfür gibt es zwei Möglichkeiten:

  1. Aus den GPS Längen- und Breiteninformationen allein, dies entspräche einer Projektion der Strecke auf die Ebene (2D Messung).
  2. Aus den GPS Koordinaten und der Höhe, die ja auch vom GPS geliefert wird. Dies würde theoretisch die exakte Länge der Strecke liefern (3D Messung).

Wie groß ist zunächst einmal der Unterschied zwischen den beiden Methoden? Gehen von folgendem für Radfahrer realistischen Szenario aus, einer Strecke von 10 km Länge (in der 2D Projektion) bei einer durchschnittlichen Steigung von 10%. Dann beträgt die wahre Länge der Strecke 10.05 km, was gerade mal einer Abweichung von 50m oder 5% entspricht. Nun ist aber die Genauigkeit sowohl der GPS- als auch der barometrischen Höhenmessung nicht hoch genug, um Höhendaten zu liefern, die präzise genug sind , diesen Fehler zu reduzieren.

Folglich benutzt der Edge zur Distanzmessung laut Garmin Product Support Methode 1. Hat man einen GSC-10 montiert, sieht die Sache anders aus: Dessen Sensoren messen über den Radumfang und die Zahl der Radumdrehungen exakt die zurückgelegte Strecke, so dass Methode 2 zum Einsatz kommen kann.

Diagramme selbstgemacht

Um die vom Edge aufgezeichneten Daten auszuwerten und in Form von Diagrammen darzustellen kann man natürlich eines der Windowsprogramme benutzen. Will man diese aber etwa unter Linux einsetzen, muss man schon einiges an Mehraufwand treiben (Stichwort wine oder mono) und auch einige Abstriche in Kauf nehmen, sofern sie überhaupt zum Laufen zu bringen sind. Programme, die nativ unter Linux laufen, sind noch selten. Allerdings liegen die aufgezeichneten Daten im TCX Format vor und dies ist ein XML basiertes, dokumentiertes Format. Was liegt also näher, als sich selbst an einem Auswerteprogramm zu versuchen? Genau das habe ich getan  und ein (erstes) einfaches Programm geschrieben, das .tcx Dateien einlesen, diverse Berechnungen durchführen und die Daten als Diagramm ausgeben kann. Als Programmiersprache habe ich Java gewählt, denn diese Sprache ist plattformunabhängig, bietet sehr gute Unterstützung für die Verarbeitung von XML, und es gibt mit JFreeChart eine komfortable Diagrammbibliothek, die einfach zu benutzen ist und von Haus aus Funktionen wie Zoomen, Drucken und die Ausgabe als Bilddatei  mitbringt.

Bei der Implementierung sind folgende Punkte zu beachten:

  • Der minimale Zeitabstand zwischen zwei Aufzeichnungspunkten beim Edge 705 beträgt 1 Sekunde. Hat man unter Einstellungen->Datenaufzeichnung “Jede Sekunde” eingestellt, wird auch in der Tat pro Sekunde ein Datensatz aufgezeichnet. Da diese Aufzeichnungsform aber mit einen hohen Speicherverbrauch einhergeht, der dazu führt, dass nur etwa 4,5 Stunden aufgezeichnet werden können, empfiehlt es sich, stattdessen “Intelli.Aufzeichg.” zu verwenden. Bei dieser Methode ist der Abstand zwischen den Messpunkten dynamisch. Um später Glättungsverfahren anwenden zu können, sollte man die Daten in diesem Fall linear interpolieren, so dass am Ende wieder ein Datensatz für jede Sekunde vorliegt. Die Kurven ändern sich dadurch nicht, sie entstehen, indem zwei benachbarte Messwerte durch eine gerade Linie verbunden werden. Die Interpolation fügt lediglich Zwischenpunkte auf dieser Linie hinzu.
  • Es kann vorkommen, dass einzelne Datensätze keine Positionsangaben haben. Diese Sätze sollte man eliminieren und durch interpolierte ersetzen. Ansonsten kann es zu extremen Sprüngen bei der Berechnung der Momentangeschwindigkeit kommen:
      <Trackpoint>
        <Time>2010-04-25T11:25:05Z</Time>
        <AltitudeMeters>327.566</AltitudeMeters>
        <DistanceMeters>45510.879</DistanceMeters>
      </Trackpoint>
      <Trackpoint>
        <Time>2010-04-25T11:25:09Z</Time>
        <Position>
          <LatitudeDegrees>48.714072</LatitudeDegrees>
          <LongitudeDegrees>8.741390</LongitudeDegrees>
        </Position>
        <AltitudeMeters>327.434</AltitudeMeters>
        <DistanceMeters>45783.461</DistanceMeters>
      </Trackpoint>
    

    Die beiden Punkte liegen 4 Sekunden auseinander und haben einen Abstand von 272,6 m. Das würde eine Geschwindigkeit von 245 km/h ergeben!

  • Ungenauigkeiten der aufgezeichneten Daten sind unvermeidlich: Das liegt an grundsätzlichen Beschränkungen der Hardware, an der Genauigkeit von GPS selbst, an der Qualität des empfangenen Satellitensignals und an Luftdruckschankungen. Diese  Fehler können zu Artefakten in der grafischen Darsttellung der Daten führen, etwa sprunghaften Anstiegen der Werte für Geschwindigkeit oder Steigung auf absurde Werte. Auch Zickzackmuster im Höhenprofil eines an sich gleichmäßigen Anstiegs sind möglich. Um diesen Effekten entgegenzuwirken und “realistischere” Ergebnisse zu bekommen, müssen die Daten geglättet werden, was auch die meisten einschlägigen Programme  tun, wenn auch auf unterschiedliche Weise.Die Glättung kann mittels eines “gleitenden Durchschnitts” erfolgen: Dazu benutzt man ein “Fenster” der Breite m (bezogen auf die Distanz der x-Werte, also hier m Sekunden). Zur Berechnung des neuen Wertes eines Messpunktes (x,y) werden zusätzlich die (m-1)/2 linken und die (m-1)/2 rechten Nachbarn von (x,y) herangezogen und ein gewichtetes Mittel dieser m Werte gebildet. Der einfachste Fall ist das gewöhnliche arithmetische Mittel: Dabei werden alle Punkte im Fenster gleich gewichtet (d.h. mit 1/m) . Es kommen aber auch andere sogenannte Fensterfunktionen in Frage, die die Mitte des Fensters und damit auch den Ausgangspunkt stärker gewichten und zu den Rändern symmetrisch abfallen.  Das folgende Bild zeigt drei gebräuchliche Funktionen:
    Fensterfunktionen
    Fensterfunktionen

    “Rectangular” entspricht dabei dem arithmetischen Mittel.

    Um dieses Verfahren anwenden zu können, sollte m ungerade sein, ferner muss die Menge der vorliegenden Messpunkte am Anfang und Ende um jeweils (m-1)/2 Punkte ergänzt werden. Dies kann durch Reflexion des Ausgangssignals geschehen: Für die am Anfang hinzuzufügenden Punkte werden die gespiegelten Werte der ersten (m-1)/2 Messpunkte genommen. Denkt man sich die Messwerte in ein Koordinatensystem mit Ursprung im ersten Messpunkt eingetragen, so entspricht dies einer Punktspegelung der ersten (m-1)/2 Werte am Ursprung. Am Ende wird analog verfahren.

    Die Glättung hat den Nachteil, dass sie die Extremwerte absenkt, damit stimmen zum Beispiel die Passhöhen im Höhenprofil nicht mehr. Dieser Effekt  ist je nach Fensterfunktion unterschiedlich stark, am stärksten natürlich bei der Rechteckfunktion. Im folgenden Beispiel wurde ein Fenster der Breite m = 21 Sekunden verwendet. Zu sehen sind die Originaldatem sowie die mit Rechteck- und Hann-Funktion geglätteten Daten:

    Glättung
    Glättung
  • Extremalwerte wie die Maximalhöhe sollte man aus den eben dargelegten Gründen nicht aus den geglätteten Daten berechnen sondern aus den Originalwerten. Die Maximalgeschwindigkeit speichert der Edge für jede Runde selbst im .tcx File ab. Dieser Wert ist nach meiner Erfahrung realistisch.

Auswertungen und Diagramme

Einer der Hauptgründe, aufzeichnungsfähige Fahrradcomputer wie den Edge einzusetzen, ist sicherlich die von ihnen gebotenene Möglichkeit, neben den Gesamtdaten einer gefahrenen Strecke wie Länge, Zeit und direkt daraus berechenbaren Werten wie der Durchschnittsgeschwindigkeit auch Daten wie Höhe, Steigung und Momentangeschwindigkeit zu bekommen, aus denen dann wiederum Diagramme über die Zeit oder Distanz wie zum Beispiel ein Höhenprofil erstellt werden können. Dies setzt eben voraus, dass das Gerät in kurzen, nicht notwendigerweise regelmäßigen Abständen die momentane Zeit, Position und Höhe aufzeichnet. Der Edge 705 speichert darüber hinaus noch die Entfernung vom Startpunkt, die sich theoretisch auch aus den GPS Koordinaten berechnen ließe. In der .tcx Datei sehen diese Daten dann so aus:

<Trackpoint>
   <Time>2010-05-23T09:25:36Z</Time>
   <Position>
     <LatitudeDegrees>48.439331</LatitudeDegrees>
     <LongitudeDegrees>8.674581</LongitudeDegrees>
   </Position>
   <AltitudeMeters>437.207</AltitudeMeters>
   <DistanceMeters>1764.645</DistanceMeters>
 </Trackpoint>
 <Trackpoint>
   <Time>2010-05-23T09:25:42Z</Time>
   <Position>
     <LatitudeDegrees>48.438944</LatitudeDegrees>
     <LongitudeDegrees>8.674294</LongitudeDegrees>
   </Position>
   <AltitudeMeters>436.469</AltitudeMeters>
   <DistanceMeters>1813.639</DistanceMeters>
 </Trackpoint>

Aus diesen einzelnen Messpunkten können nun Diagramme erstellt werden, indem etwa die Höhenwerte über den Zeit- oder Distanzwerten aufgetragen und benachbarte Punkte mit einer Linie verbunden werden. Andere Werte wie die Momentangeschwindigkeit oder  die Steigung müssen zuvor aus den gemessenen Werten berechnet werden. Das gilt auch für den Gesamtaufstieg, der sich als Summe aller Höhendifferenzen benachbarter Punkte ergibt, bei denen diese Höhendifferenz größer als Null ist.  All diese Rechnungen und natürlich auch deren Visualisierung in Form von Diagrammen können  von entsprechender Software durchgeführt werden, die das .tcx Format lesen und auswerten kann, wie zum Beispiel das mitgelieferte Garmin TrainingCenter. Jedes solche Programm sieht sich aber mit einem prinzipiellen Problem konfrontiert, nämlich der Messgenauigkeit: Sowohl die GPS Positionsbestimmung als auch die Höhenbestimmung (per GPS und barometrischer Höhenmessung) sind nicht 100% genau und überdies Schwankungen unterworfen. So können Luftdruckschwankungen etwa die Höhenberechnung beeinträchtigen und ein dichtes Blätterdach die Genauigkeit der Positionsermittlung deutlich verschlechtern. Dies kann dazu führen, dass z.B. die berechnete Momentangeschwindigkeit plötzlich auf absurde Werte schnellt, oder das Höhenprofil trotz gleichmäßig steigender Strecke einen Zickzackverlauf aufweist wie in folgendem Beispiel (rote Linie):

Ausschnitt aus einem Höhenprofil

Würde man wie oben angegeben den Gesamtaufstieg aus diesen Daten berechnen, käme ein zu großer Wert heraus.

Auswerteprogramme müssen also diese Rohdaten also in irgendeiner Weise “bearbeiten” (glätten), um zu realistischen Ergebnissen zu kommen. Dabei wenden sie anscheinend unterschiedliche Strategien an und kommen auch zu unterschiedlichen Resultaten, wie das folgende Experiment zeigt. Ich habe dazu die aufgezeichnete .tcx Datei einer von mir gefahrenen Strecke von mehreren Programmen analysieren lassen, darunter einem selbst geschriebenen, hier die Ergebnisse:

[table "1" not found /]

Anmerkungen

  • TourExplorer erlaubt über einen Schieberegler, den Grad der Glättung zu verändern, für das Beispiel wurde die Defaulteinstellung gewählt.
  • TourExplorer und BikeRouteToaster verfügen über eigene Höhendaten. Damit kann man Aufstieg, Maximalhöhe und Profil unabhängig von den aufgezeichneten Werten berechnen lassen.
  • Bei zu starker Glättung werden die “Spitzen” (Höhe, Geschwindigkeit) zu sehr abgeschliffen. Das scheint bei SportTracks der Fall zu sein.
  • Der Aufstiegswert von BikeRouteToaster (2228 m ) liegt noch über dem Wert, der sich aus den Rohdaten errechnet (2172 m).
  • Zumindest der Wert für die Maximalhöhe aus den eigenen Daten von TourExplorer scheint zu stimmen: Der höchste Punkt der Strecke liegt offiziell bei 973 m, die Strasse verläuft etwas unterhalb davon.
  • Die vom Gerät selbst angegebene und auch im .tcx File gespeicherte Maximalgeschwindigkeit betrug 61,7 km/h.