Come calcolare il Race Score ITRA (più o meno)
Inviato: 05/01/2025, 15:49
Ciao a tutti!
In questi mesi ho provato ad approfondire e a replicare l’algoritmo usato da ITRA per il calcolo delle Race scores (RS) e, quindi del Performance Index (PI). L’algortimo usato da ITRA dovrebbe essere molto simile a quello usato anche da UTMB per il loro indice.
Sul sito ufficiale ITRA c’è una spiegazione qualitativa di come viengono calcolate le RS. In partica i passaggi sono 2:
1. Calcolo del Raw Race Score (RRS): vengono calcolati i km-effort della gara come km_effort= km+dislivello/100. Per i km_effort calcolati si va a vedere qual è il teoretico record del mondo su quella distanza, da cui si ottiene che:
RRS=tempo_record/tempo_gara*1000
2. Dopdichè si usano i dati dei vari atleti che hanno partecipato alla gara per calcolare un coefficiente di aggiustamento. In pratica si va a vedere come si distribuiscono statisticamente i tempi dei vari atleti su una particolare gara rispetto al loro PI, in base a questa distribuzione statistica si calcola un coeffciente di correzione Kc, da cui il RS diventerà:
RS=RRS*Kc=tempo_record*Kc/tempo_gara*1000
Si noti che il valore tempo_record*Kc è il miglior tempo possibile che un atleta “ideale” può ottenere su quel percorso. Di fatto è il tempo di un atleta con un PI pari a 1000 (per paragone Kilian ha un PI di 945).
La parte più oscura e difficile da ricorstruire è come viene calcolato il coefficiente di correzione Kc. Esso ha, di fatto, due componenti:
• Una componente oggettiva data da dislivello, pendenze e altitudine della gara
• Una componente non-oggettiva: data da tipo di terreno (difficoltà tecnica dei sentieri percorsi, fango, neve…) e tempo atmosferico (temperatura, pioggia, neve…)
Il secondo punto può essere corretto solo tramite un analisi statistica e, quindi, disponendo di un buon database da cui attingere. Tuttavia, il primo punto può ancora essere valutato matematicamente tramite tre formule.
Correzione del % di VO2max utilizzabile in base alla quota:
fract_altitude = 1 - 11.7 * 10^(-9) * altitude^2 – 4.01 * 10^(-6) * altitude [1]
Correzione del passo secondo il Grade Adjusted Pace (GAP) [1]:
K_GAP=0.4317*grad_%^5 - 0.084*grad_%^4 – 0.1203*grad_%^3 + 0.1286*grad_%^2 + 0.05417*grad_% + 0.01
Oppure anche secondo Strava [2]:
K_GAP = -3.16*10^(-6)*grad_%^3+0.001486*grad_%^2+0.03113*grad_%+1.0337
K_GAP è una costante maggiore di 0 che relaziona il passo effettivamente tenuto su una strada con pendenza al suo passo equivalente in piano:
pace_flat = pace / K_GAP
Infine, quindi, il passo in min/km che un atleta ideale con PI pari a 1000 potrebbe tenere sul percorso verrà calcolato come:
pace_1000 = pace_wr * K_GAP/frac_altitude
L’array pace_1000 sarà quindi il passo in min/km calcolato punto per punto a partire da un file gpx contente le informazioni di posizione ed altitudine. Tramite pace_1000 si può, quindi, calcolare il tempo minimo che un atleta ideale ci impiegherà a percorrere il tracciato.
Riporto alcuni risultati:
• Traversata Colli Euganei (42km/2150+): 3h:13, secondo ITRA: 3h:12
• Euganeus Trail (21km/1170+): 1h:32, secondo ITRA: 1h:24
• Delicious Trail (42km/ 3000+): 4h:09, secondo ITRA: 4h:05
• UTLO (75km/4100+): 7h:17, secondo ITRA: 6h:00
• DXT (103km/7100+): 12:28, secondo ITRA: 11h:47
Alcune considerazioni:
1. Il risultato è più affidabile, migliore è la qualità del file gpx: tendenzialmente è meglio se il file gpx è stato tracciato su una mappa, più che tracciato seguendo il percorso nel mondo reale (vedi il caso UTLO dove il file gpx conteneva un po’ di artefatti strani dovuto al fatto che il gpx proviene da una attività tracciata via orologio gps)
2. Il calcolo è più preciso sulle distanze più brevi: più è lunga la distanza, più incidono i fattori non-oggettivi
3. Dai pochi dati che ho mi sembra che i fattori non-oggettivi possono incidere fino al 10% del tempo finale calcolato e, quindi, fino al 10% del RS calcolato.
Più di questo è difficile fare, perché il resto dell’algoritmo ITRA funziona grazie al vasto database che hanno. L’unica cosa che si potrebbe migliorare è il sistema di smoothing dei dati del file gpx.
L’algoritmo l’ho sviluppato su Python, ve lo posso inviare via DM.
Bibliografia:
[1] E. Minetti et al., Energy cost of walking and running at extreme uphill and downhill slopes, 2002
[2] D. Robb, An improved GAP model, 2017, web: https://medium.com/strava-engineering/a ... 07ae8886c3
In questi mesi ho provato ad approfondire e a replicare l’algoritmo usato da ITRA per il calcolo delle Race scores (RS) e, quindi del Performance Index (PI). L’algortimo usato da ITRA dovrebbe essere molto simile a quello usato anche da UTMB per il loro indice.
Sul sito ufficiale ITRA c’è una spiegazione qualitativa di come viengono calcolate le RS. In partica i passaggi sono 2:
1. Calcolo del Raw Race Score (RRS): vengono calcolati i km-effort della gara come km_effort= km+dislivello/100. Per i km_effort calcolati si va a vedere qual è il teoretico record del mondo su quella distanza, da cui si ottiene che:
RRS=tempo_record/tempo_gara*1000
2. Dopdichè si usano i dati dei vari atleti che hanno partecipato alla gara per calcolare un coefficiente di aggiustamento. In pratica si va a vedere come si distribuiscono statisticamente i tempi dei vari atleti su una particolare gara rispetto al loro PI, in base a questa distribuzione statistica si calcola un coeffciente di correzione Kc, da cui il RS diventerà:
RS=RRS*Kc=tempo_record*Kc/tempo_gara*1000
Si noti che il valore tempo_record*Kc è il miglior tempo possibile che un atleta “ideale” può ottenere su quel percorso. Di fatto è il tempo di un atleta con un PI pari a 1000 (per paragone Kilian ha un PI di 945).
La parte più oscura e difficile da ricorstruire è come viene calcolato il coefficiente di correzione Kc. Esso ha, di fatto, due componenti:
• Una componente oggettiva data da dislivello, pendenze e altitudine della gara
• Una componente non-oggettiva: data da tipo di terreno (difficoltà tecnica dei sentieri percorsi, fango, neve…) e tempo atmosferico (temperatura, pioggia, neve…)
Il secondo punto può essere corretto solo tramite un analisi statistica e, quindi, disponendo di un buon database da cui attingere. Tuttavia, il primo punto può ancora essere valutato matematicamente tramite tre formule.
Correzione del % di VO2max utilizzabile in base alla quota:
fract_altitude = 1 - 11.7 * 10^(-9) * altitude^2 – 4.01 * 10^(-6) * altitude [1]
Correzione del passo secondo il Grade Adjusted Pace (GAP) [1]:
K_GAP=0.4317*grad_%^5 - 0.084*grad_%^4 – 0.1203*grad_%^3 + 0.1286*grad_%^2 + 0.05417*grad_% + 0.01
Oppure anche secondo Strava [2]:
K_GAP = -3.16*10^(-6)*grad_%^3+0.001486*grad_%^2+0.03113*grad_%+1.0337
K_GAP è una costante maggiore di 0 che relaziona il passo effettivamente tenuto su una strada con pendenza al suo passo equivalente in piano:
pace_flat = pace / K_GAP
Infine, quindi, il passo in min/km che un atleta ideale con PI pari a 1000 potrebbe tenere sul percorso verrà calcolato come:
pace_1000 = pace_wr * K_GAP/frac_altitude
L’array pace_1000 sarà quindi il passo in min/km calcolato punto per punto a partire da un file gpx contente le informazioni di posizione ed altitudine. Tramite pace_1000 si può, quindi, calcolare il tempo minimo che un atleta ideale ci impiegherà a percorrere il tracciato.
Riporto alcuni risultati:
• Traversata Colli Euganei (42km/2150+): 3h:13, secondo ITRA: 3h:12
• Euganeus Trail (21km/1170+): 1h:32, secondo ITRA: 1h:24
• Delicious Trail (42km/ 3000+): 4h:09, secondo ITRA: 4h:05
• UTLO (75km/4100+): 7h:17, secondo ITRA: 6h:00
• DXT (103km/7100+): 12:28, secondo ITRA: 11h:47
Alcune considerazioni:
1. Il risultato è più affidabile, migliore è la qualità del file gpx: tendenzialmente è meglio se il file gpx è stato tracciato su una mappa, più che tracciato seguendo il percorso nel mondo reale (vedi il caso UTLO dove il file gpx conteneva un po’ di artefatti strani dovuto al fatto che il gpx proviene da una attività tracciata via orologio gps)
2. Il calcolo è più preciso sulle distanze più brevi: più è lunga la distanza, più incidono i fattori non-oggettivi
3. Dai pochi dati che ho mi sembra che i fattori non-oggettivi possono incidere fino al 10% del tempo finale calcolato e, quindi, fino al 10% del RS calcolato.
Più di questo è difficile fare, perché il resto dell’algoritmo ITRA funziona grazie al vasto database che hanno. L’unica cosa che si potrebbe migliorare è il sistema di smoothing dei dati del file gpx.
L’algoritmo l’ho sviluppato su Python, ve lo posso inviare via DM.
Bibliografia:
[1] E. Minetti et al., Energy cost of walking and running at extreme uphill and downhill slopes, 2002
[2] D. Robb, An improved GAP model, 2017, web: https://medium.com/strava-engineering/a ... 07ae8886c3