Baumtränzer

Soda, ein paar Stuendchen hatte ich noch uebrig fuer den 3. Teil der Zeitfahrverwurstelung. Muss sein. Weil ich draufgekommen bin, auf Trainingpeaks tun sie veroeffentlichen die Rohdaten von Chris Anker Sorensen beim Zeitfahren. Der ist doch sicher interessant! 1. 20. geworden, also nicht schlecht, 2. als 101. gestartet, also gerade beim gestern angesprochenen Umschwung. Da duerfte der Wind angefangen haben. In Relation zu den spaeter gestarteten GC-Favoriten sieht er aber erstaunlich gleichmaessig aus:



Also schauen wir uns mal seine Leistungsdaten genauer an, wenn sie schon da sind. Naja, das war dann gar net so einfach - das WKO-File ist irgendein raeudiges Binaer-Format. Ein frisch angelegter testhase fuers Webinterface von Trainingpeaks hat dann auch nur herausgefunden, dass das Flash fuer die Fisch ist. Man kann ein paar bunte Linien machen, aber nix exportieren. WKO+ ist nur fuer Windosen. Zum Glueck gibt's Open Source, naemlich wko2csv, ein schon laenger nicht mehr gewartetes Sourceforge-Projekt. Das erkannte zuerst den Versions-String net im File, ein wenig C++-Hack spaeter war die Nuss dann geknackt, und ein CSV-Dump da. Der musste noch beschnitten werden, weil Ein- und Ausrollen auch aufgezeichnet. Etwas geraten, aber es wird wohl hinkommen.

Allerdings: Mit Zeit, Watt, Kadenz, Geschwindigkeit, Hoehe, Temperatur. Was? Keine Distanz? Vielleicht doch Binaerformat noch inkompatibel, aber was soll's: Wir haben eine Zeile fuer jede Sekunde, und da steht die aktuelle Geschwindigkeit drin. Also schnell im R: Neue Spalte, mit Summe aus vorheriger Zeile + aktuelle Geschwindigkeit/3.6 (dann hamma m/s). Summiert sich auf 51800 m, knapp genug an 52 km dran, passt mir.

Zuerst mach ma das, was man in R immer macht: plot(sorensen$Speed ~ sorensen$Power), einfach, damit man mal ein Gefuehl fuer die Daten kriegt:



Schauen wir nochmals. Zuerst die Daten nach Distanz in Sektionen partitionieren, und dann nur Sektion 1 und 2 malen:



Naja. Das Auge meint, dass da nix linear ist. Man sieht hoechstens, dass er immer brav zwischen 40 und 55 gefahren ist und dabei 300 bis 450 Watt erstrampeln musste. Tatsaechlich, Korrelationskoeffizient ist raeudigste -0.07 (sollte nah an -1 oder 1 sein fuer negative bzw. positive Korrelation), das heisst: Staerker Treten nicht automatisch schneller. Klar, Wind und, oha! Steigungen. Wir haben ja die Hoehen angegeben:



Sieht aber auch nicht wirklich aus nach einer Begruendung, warum 2. Abschnitt langsamer als die anderen. Au contraire, tut man die positiven Hoehenaenderungen aufsummieren (mit etwas R-Magie in 2 Zeilen gemacht!), kommt man fuer Abschnitt 1 auf 50 der insgesamt 150 Hoehenmeter, Abschnitt 2 hat gar nur 35. Abschnitt 3 hat genauso viel auf der halben Strecke!

Hmpf. Naja, lustiges Zwischenintermezzo:



Bergauf muss man staerker treten und ist trotzdem langsamer! Wahnsinn, was einen die fortgeschrittene Datenmassage fuer arge Erkenntnisse liefern kann. Man koennte da noch Clustering betreiben, oder aus Geschwindigkeit, Watten, Kadenz und Steigung ausrechnen, mit welcher Uebersetzung er vielleicht gefahren ist, aber ich zu bloed, Zeit zu knapp und eh uninteressant. War Abschnitt 2 jetzt wirklich anstrengender?

Vielleicht kommen wir ueber die Verteilung der Watte, aufgeschluesselt nach Abschnitt drauf:



Hmpf. Abschnitt 3 und 4 sind ja viel kuerzer, daher weniger Datenpunkte, daher Kurve niedriger. Also doch density-Plot, der tut (hoffe ich!) nach Anzahl der Datenpunkte normalisieren und Wahrscheinlichkeiten angeben, dass ein Datenpunkt in einen Slot faellt:



Whoa. Abschnitt 2 ist weiter links als 1, und damit eigentlich sogar weniger anstrengend! 4 ist erwartungsgemaess viel weiter rechts, da wird nochmals ordentlich angedrueckt. Man koennte jetzt noch Masszahlen fuer Skew und Breite angeben. Koennte man. Haette man die muehsam massierten Daten noch.

Weil einmal zu bloed gespielt, und ich hab geglaubt, ich lasse R jetzt nur ein paar Tausend Datenpunkte aufsummieren nach Abschnitten, aber irgendwas lief da schief. Jedenfalls bliess sich der Prozess auf ein paar GB Speicher auf, bevor er explodierte. Und Zwischenspeichern ist ja fuer Deppen, die nicht wissen, was sie tun. Mpf.

Man muss schon sagen, R.app fuer OS X ist zwar fein, aber ein wenig mit der heissen Nadel gestrickt. Den richtigen Moment verpasst, und der Stop-Knopf funktioniert nimmer, dann muss man der aktuellen Berechnung ihren Lauf lassen. So ein eigener Thread fuer GUI-Aktionen, den sollte man sich doch leisten koennen.

Aber, hat eh was gutes: Ein ungeloestes Raetsel, das die Forschung noch Jahrzehnte beschaeftigen wird, und ich kann mich endlich wieder um sowas aehnliches wie Leben kuemmern. Ich schliesse: Vielleicht ist es ja Absicht - schnell starten, dann normalisieren auf hohem Niveau und gegen Ende dann die letzten Reserven zusaetzlich verbrennen. Und aus.