VDOT-Berechnung mit Höhenmetern

[Andro]

Hallo zusammen,

auch wenn es schon einige Threads zu dem Thema gibt, möchte ich hierzu doch noch einen neuen aufmachen...

Grundsätzlich ist es gut, dass es in Runalyze die Möglichkeit gibt, den VDOT-Wert mit den Höhenmetern zu korrigieren. Allerdings funktioniert das nur sehr schlecht, und zwar aus folgendem Grund:
Man kann nur für alle Trainingseinheiten einen Wert angeben, der per Default auf +2 m für bergauf und -1 m für bergab steht. Man kann diesen Wert zwar anpassen, aber das ist wenig hilfreich, weil die "richtigen" Korrekturwerte von der Steigung abhängig sind, d.h. bei einer Steigung von 1% muß man pro Höhenmeter einen ganz anderen Wert ansetzen als bei einer Steigung von 10% pro Höhenmeter. Mit anderen Worten: jede Strecke benötigt eigene Korrekturfaktoren.
Näheres zu dem Thema findet man hier: http://www.laufen-in-siegen.de/index.ph ... n-strecken
(Sorry für die Eigenwerbung).

Da ich mir die Streckenlängenkorrektur in der Regel selber ausrechne (mit dem Rechner unter http://www.laufen-in-siegen.de/index.ph ... lkmrechner) oder die Werte über Strava umrechne (bei denen heißt das "SAT"), würde es mir sehr helfen,
wenn man in Runalyze bei jedem Lauf ein zusätzliches Eingabefeld "Leistungsstreckenlänge" oder "Flachstreckenäquivalent" hätte.
Dieses Feld könnte per Default mit den Werten belegt werden, die Runalyze als adaptierte Streckenlänge aus der Höhenmeterkorrektur berechnet. Wenn der Benutzer dieses Feld dann überschreiben sollte, dann sollte der geänderte Wert für die höhenmeterabhängige VDOT-Berechnung herangezogen werden.

Alternativ wäre es auch möglich (was eigentlich noch besser wäre), den Algorithmus zur Berechnung der Höhenkorrektur anzupassen. Der o.a. Rechner, den ich vor einigen Jahren programmiert habe, rechnet fast identische Werte aus wie das Strava-Tool. Falls jemand von den Entwicklern Interesse an dem Rechner hat, stelle ich ihn gerne zur Verfügung.

Hier mal ein Beispiel:

Aus Runalyze:

Distance: 17,2 km ⇒ VDOT 42.14 Dauer1:25:16

Korrektur: mit Beachtung der Höhenmeter
Auf-/Abstieg +458/-472 m ⇒ VDOT 51.36
Einfluss: 0,444 km => 17,644 km

-> Hieraus errechnet sich ein Tempo von 4:57 (17,2 km in 1:25:16) bzw. korrigiert von 4:50 (17,644 Leistungskilometer in 1:25:16).

Der korrigierte Streckenlänge ist viel zu kurz. Der berechnete VDOT-Wert liegt mit 51.36 etwa 6 bis 7 Punkte niedriger als bei meine momentanen Läufe auf flacher Strecke.

Rechner auf Homepage: 18,369 Leistungskilometer und somit ein Tempo von 4:39 (was zu einem realistischeren VDOT-Wert führt)
Strava: SAT=4:38 (also fast das gleiche korrigierte Tempo).

Nun könnte man ja auf die Idee kommen und die Faktoren für die Höhenmeter in Runalyze erhöhen. Das würde aber dann zu dem Effekt führen, dass Läufe mit leichten Steigungen übertrieben hohe VDOT-Werte bekommen würden.

Andreas

[laufhannes]

Wir haben das Problem durch die unterschiedlichen Steigungen durchaus auf dem Schirm, wobei natürlich die Liste der "Einflussfaktoren", die die VDOT-Schätzung ungenauer machen bzw. verkomplizieren, schier unendlich ist. Für den Moment kann sich in solchen Fällen jeder selbst helfen, indem entsprechende Läufe für die Schätzung der VDOT-Form ausgeschlossen werden.

Wir werden an der Distanzanpassung für Höhenmeter nichts ändern, solange wir nicht die "SAT" bzw. "GAP" haben. Die haben wir bereits seit einiger Zeit im Issue-Tracker:
- https://github.com/Runalyze/Runalyze/issues/917 (Grade adjusted pace)
- https://github.com/Runalyze/Runalyze/issues/1573 (VDOT based on grade adjusted pace)

Das Problem daran ist eine *zuverlässige* Berechnung der Steigung, die wiederum in hohem Grade von der Genauigkeit des Höhenprofils abhängt, welche bekanntermaßen meist eher mittelmäßig ist.

Wir zeigen inzwischen im Höhenprofil auch die jeweilige Steigung an, so ganz zufrieden bin ich mit den Werten aber noch nicht. Grundsätzlich schwebt mir noch ein Butterworth-Filter für die Glättung des Höhenprofils vor. Darauf wollte ich warten, bis ich mich dann an der SAT/GAP versuche und dann die VDOT-Schätzung entsprechend anpasse. ... long way to go

[Andro]

Wir haben das Problem durch die unterschiedlichen Steigungen durchaus auf dem Schirm, wobei natürlich die Liste der "Einflussfaktoren", die die VDOT-Schätzung ungenauer machen bzw. verkomplizieren, schier unendlich ist. Für den Moment kann sich in solchen Fällen jeder selbst helfen, indem entsprechende Läufe für die Schätzung der VDOT-Form ausgeschlossen werden.

Das Ausschließen ist eine nicht so tolle Option, wenn man im Mittelgebirge wohnt und es praktisch kaum schafft "flach" zu laufen.

Das Problem daran ist eine *zuverlässige* Berechnung der Steigung, die wiederum in hohem Grade von der Genauigkeit des Höhenprofils abhängt, welche bekanntermaßen meist eher mittelmäßig ist.

Da stimme ich Dir zu. Das Einzige, was halbwegs ordentlich funktioniert, sind barometrische Daten. GPS-Daten funktionieren im Mittelgebirge auch relativ schlecht. Oder auch bei Läuafen an Hängen, über Brücken usw..

Andreas

[Tida]

Habe mal die gescannte Grafik pixelweise ausgewertet, normiert und gefittet. Eigentlich sollte das doch einen guten Ausgangspunkt liefern.

Graphical Evaluation - Incline Compensation.jpg (93.22 KiB) Viewed 4638 times

[laufhannes]

Ich möchte dir ja ungern den Spaß verderben, aber in dem originalen Paper von Minetti (http://jap.physiology.org/content/93/3/1039.full) ist die angepasste Formel doch exakt angegeben?

Code: Select all

Cr,i = 155.4 i^5 - 30.4 i^4 - 43.3 i^3 + 46.3 i^2 + 19.5 i + 3.6

Dabei entspricht i der Steigung (also i = 0.05 = 5 %) und Cr ist die Energy Cost für Running (also entspricht 0 = 100% Effort).

In https://github.com/gerhardol/trails/blo ... st.cs#L303 ist sie ebenfalls so angegeben und wird dort verwendet. Einen wirklichen Überblick, welche anderen Modelle dort noch möglich sind, habe ich aber ehrlich gesagt nicht.

[Tida]

Genau das Gegenteil von Spass verderben. Perfekt, vielen Dank:-)

Allein diese Formel sollte sich somit dazu eignen den Kalorienverbrauch genauer zu berechnen, eine theoretische Distanz ohne Steigung zu ermitteln und VDOT eine dynamische hoehenkompensation zu verpassen.