Ok. Jeg er i likhet med mange andre litt opptatt av Strava og segmenter, og som noen kanskje har fått med seg så er jeg lite begeistret for Stravas tilnærming til datakvalitet. Nå skal jeg skynde meg å si at jeg har ganske inngående kjennskap til GPS og systemets styrker og svakheter, men Strava kunne med enkelhet økt sannsynligheten betydelig for at segmentresultater ble korrekte (fordi det finnes mange segmenter der resultatene ikke er korrekte som følge av Stravas valg). Jeg fikk aldri gleden av å teste Veloviewers Alternative Leaderboard, og det er litt av bakgrunnen for denne posten.
Om noen leser på linken og kommentarene under, så hevdes det at Strava bruker det første datapunktet etter segmentets start og det siste datapunktet før segmentets slutt. Det er (heldigvis) ikke riktig, det riktige er (basert på min egen testing) at de velger det nærmeste datapunktet (i hver ende). Det betyr at man kan få den situasjonen som ble beskrevet, men det kan også bli motsatt. Det betyr altså også at hvis man velger å bruke "Smart recording" (eller tilsvarende), så øker man sjansen for å få uriktige segmentresultater, men dette kan slå begge veier. Ergo, om man ønsker å vinne stort i segmentlottoen, så bruker man "Smart recording", men man øker også sjansen for å få dårligere tider enn man skulle hatt.
Som nevnt så fikk jeg aldri testet "Alternative Leaderboard", så da laget jeg min egen versjon i stedet. Jeg er ingen web-programmerer, så jeg har bare laget en konsollapplikasjon (for Windows). Det aner meg at "Alternative Leaderboard" ble fjernet etter press fra Strava, så det er kanskje ikke så klokt å lage noe tilsvarende på web uansett.
Et segment hos Strava består (eksakt) av (de valgte) datapunktene fra sporloggen til den som laget segmentet, og det endres ikke på i ettertid (om ikke brukeren selv gjør det, da). Hvert datapunkt inneholder posisjon, avstand (akkumulert) og elevasjon. Tidsinformasjonen fra den opprinnelige sporloggen kastes (men finnes selvfølgelig i selve aktivitets-streamen som segmentet ble laget fra).
Programmet mitt tar som input segment-IDen, og bruker Stravas API til å hente data fra Strava, og så presenteres resultatet i konsollet. Programmet lager også en GPX-fil med alle sporene fra resultatlisten, og den filen kan lastes opp til f.eks http://www.gpsvisualizer.com/, som da viser alle sporene samtidig (veldig flott verktøy).
Jeg har sett på et antall segmenter, og selv om det er ganske mange tider som blir tildels mye feil, så er det overraskende ofte at rekkefølgen på resultatlisten likevel blir riktig. Som et eksempel der det ikke ble helt riktig, så kan vi se på et populært Oslo-segment: Tour de Finans - offisiell!. Dette er hva programmet mitt spytter ut:
Det meste er vel selvforklarende, men as/s trenger å forklares. Det står for average samples per second, og jeg har tatt det med for å kunne se om brukeren har redusert samplerate ("Smart Recording"). Om dette feltet viser 1.00 eller like under (fordi det er vanlig at enheter mister et datapunkt i ny og ne), så er sporloggen samplet med 1 s/s, men om tallet er lavere så er det lengre (i snitt) mellom datapunktene, og sjansen for feil tid er større.
Programmet gjør så en inter/ekstrapolering for å finne en tidskorreksjon for hver enkelt person på listen, og presenter så en ny resultatliste sortert på den nye tiden. Feltet Pos viser fremdeles den opprinnelige posisjonen, slik at det er enkelt å se endringer i rekkefølgen, og bakerst står det hvor mye tiden er blitt korrigert med, og i hvilken retning).
Som eksempelet viser, så skulle Jah Langleite vært ensom KOM på dette segmentet, og ikke delt den med flere andre. Om vi så ser på GPX-filen som programmet genererer (med GPS Visualizer), så ser vi hvorfor:
Legg merke til at det røde sporet er selve segmentet, og at Langleites spor starter litt etter selve segmentet (tenk virtuell startlinje 90 grader på segmentets start), så her får han en ørliten fordel. Dessverre for ham så har han en solid ulempe ved slutten av segmentet, der siste datapunkt i sporet hans går langt forbi segmentets slutt, og dermed gir ham dårligere tid. I sum så skal han altså ha 1.28 sek bedre tid som en følge av dette. Grunnen er at loggen hans i snitt kun inneholder knapt et halvt datapunkt per sekund (eller altså at det er ca 2 sekunder mellom hvert datapunkt).
Om du har lest helt hit så er det bare å gratulere, jeg antar at dette kun er for spesielt interesserte. :-) Og til sist: Jeg hevder ikke at min tilnærming på noen måte er perfekt, men jeg står hardt på at sannsynligheten for at resultatlisten ut av mitt program er mer riktig enn Stravas er stor.
Om du har lest helt hit så er det bare å gratulere, jeg antar at dette kun er for spesielt interesserte. :-)
Jeg leste dit, og enda litt lengre. Og venter spent på videre utgreiing. Stravasegmenter har kanskje tatt av mer enn det var forventet, så tidligere uviktige detaljer blir nå mindre uviktig. Det arrangeres jo til og med ritt basert på stravasegmenter nå..
Har en del moro av å kjøre Strava segmenter på diverse steder jeg er på tur i tillegg til der jeg trener til vanlig. Til å begynne med brukte jeg appen på telefonen. Etter at jeg kjøpte meg Polar V650 og sammenlignet tidene fant jeg ut at tlf.appen som regel var et sekund dårligere enn når jeg lastet opp fra Polar. Vet ikke hva årsaken til dette er da jeg ikke er gps kyndig. Så også at systemet fra tlf. ikke var helt pålitelig da jeg sammenlignet tidene på kona og meg. Vi trener mye sammen og brukte tlf. appen begge til å begynne med. Opplevde en del ganger at tidene ikke stemte helt selv om vi hadde samme avstand ved start og i mål.
Dette var stilig! Hva skal til for å kunne teste dette verktøyet på lokale segmenter?
Det er slik per i dag at programmet er assosiert til min Strava-konto, og hvis jeg skal la andre teste det så må jeg implementere autentiseringsprosedyren slik at programmet tilknyttes hver enkelt bruker i stedet. Det er ikke teknisk så veldig vanskelig, men noen utfordringer er det, spesielt siden programmet ikke kjører på en webserver.
Men om du lister opp noen segmenter, så kan jeg gjerne sjekke dem og poste resultatet i denne tråden.
Undersøkelsen din bekrefter min iherdige påstand om at korte segmenter er verdiløse. Brenn småsegmenter, brenn!!
I tillegg viser skjermbildet ditt at det er elendig kvalitet på det opprinnelige sporet, der det varier mellom 55 og 60 meter høyde og det er en kneik på 13% på Frognerstranda. Alle segmenter lagd på basis av telefonspor burde byttes med ett snitt av spor fra gpser med barometer.
Dette var stilig! Hva skal til for å kunne teste dette verktøyet på lokale segmenter?
Det er slik per i dag at programmet er assosiert til min Strava-konto, og hvis jeg skal la andre teste det så må jeg implementere autentiseringsprosedyren slik at programmet tilknyttes hver enkelt bruker i stedet. Det er ikke teknisk så veldig vanskelig, men noen utfordringer er det, spesielt siden programmet ikke kjører på en webserver.
Men om du lister opp noen segmenter, så kan jeg gjerne sjekke dem og poste resultatet i denne tråden.
Om dette hadde vert en nett- eller appbasert løsning, hadde jeg gledelig betalt en liten slant for å sjekke. Kanskje blir det veldig "poppis" og strava får øynene opp for at noe må gjøres. Skal se om jeg finner noen segmenter som er gode eksempler i området her.
Undersøkelsen din bekrefter min iherdige påstand om at korte segmenter er verdiløse. Brenn småsegmenter, brenn!!
I tillegg viser skjermbildet ditt at det er elendig kvalitet på det opprinnelige sporet, der det varier mellom 55 og 60 meter høyde og det er en kneik på 13% på Frognerstranda. Alle segmenter lagd på basis av telefonspor burde byttes med ett snitt av spor fra gpser med barometer.
Men sammenligningen var uansett interessant.
LarsB
At det opprinnelige sporet har feil høydeinfo spiller ikke noen videre rolle for tidtakingen, men det er klart at Strava kunne forbedret segmentsporene helt automagisk om de hadde ønsket.
Når det gjelder korte segmenter, så er det jo slik at unøyaktigheten til Strava strengt tatt blir den samme uansett, men siden korte segmenter også tar kort tid, så blir gjerne utslagene større. Så er det jo dessverre også slik at Strava er elendig på segmentmatching, og det er ikke en forutsetning at man faktisk krysser den virtuelle startlinjen (og mållinjen) for å få match. Her er et konkret eksempel fra Oslo:
Her blir listen ganske snudd om på, og legg merke til at han som har KOM havner langt ned på listen. Han sykler da heller ikke selve segmentet, men får match likevel. Det samme gjelder andremann, og slik ser deres spor ut:
Om dette hadde vert en nett- eller appbasert løsning, hadde jeg gledelig betalt en liten slant for å sjekke. Kanskje blir det veldig "poppis" og strava får øynene opp for at noe må gjøres. Skal se om jeg finner noen segmenter som er gode eksempler i området her.
Jeg er enig i det, men jeg tror det ville gitt store problemer med Strava. Strava vet jo godt at de suger på dette, men de ønsker åpenbart ikke å fikse det. Hvis da en tredjepart kommer inn og presenterer alternative lister, så ville de ganske sikkert blitt mugne.
Jeg ser forresten at jeg blingset på skjermbildet mitt fra "Opp på lokket"-segmentet. Det viser slutten av segmentet, ikke starten. De to nevnte herrene fullførte altså ikke egentlig segmentet, men på grunn av Stravas elendighet får de likevel (veldig gode) tider.
Interessant og bra satt opp. Forklaringen ligger vel i at Strava lever av massene og ikke av de få som gidder å fordype seg i tekniske unøyaktigheter. Det Strava enkelt kunne gjort var å kreve >0,75 as/s for å kvalifisere til å konkurrere på korte segmenter. Forøvrig helt enig i at korte segment har så høy unøyaktighet at verdien er lav. Nå er det jo også andre faktorer som gjør det vanskelig å sammenligne ryttere som har syklet samme segment. Sykler du feks "Tour de Finans - offisiell!" hver dag vil du før eller siden ha så sterk medvind at du sykler raskere enn norgeseliten. Når Strava får orden på sporloggene kan de lage en korrelasjon til Yr.no hvor rekorder underkjennes hvis de er satt på tider med for mye medvind.
Når det gjelder vær og vind, så har jeg den klare oppfatning at det er helt greit, og ikke bør korrigeres for (og dessuten er det nesten umulig å gjøre på en pålitelig og rettferdig måte). Da er det mye verre med alle rekordene som er satt når man ikke sykler solo (f.eks i ritt, der man sitter i felt/rulle), men så lenge ikke alle laster opp loggene på Strava så er det umulig for dem å detektere dette. De hadde jo tidligere en avkrysning for "Group ride", men det ble fjernet, antakelig fordi folk ikke brydde seg med å krysse av uansett.
Men å øke sjansen for mer nøyaktige segmenttider, det kunne Strava enkelt ha gjort, men de gidder ikke.
Strava bør ikkje takast som noko anna enn uhøgtideleg moro eigentleg, spesielt når ein ser kor unøyaktig det er Litt usikker på om det er så smart å bruke det i konkurransar for tidtaking som nokre forsøker, i så fall bør det brukast betre algoritmer enn Strava sine for segmentmatching.
Strava bør ikkje takast som noko anna enn uhøgtideleg moro eigentleg, spesielt når ein ser kor unøyaktig det er Litt usikker på om det er så smart å bruke det i konkurransar for tidtaking som nokre forsøker, i så fall bør det brukast betre algoritmer enn Strava sine for segmentmatching.
Forsåvidt enig i det, men nå har jo utviklingen gjort at segmenter blir tatt mer alvorlig, og det er fullt mulig å lage algoritmer og metoder som gjør segment-tidtaking temmelig nøyaktig.
Jeg kan jo også nevne at jeg for mange år siden laget en GPS-logger til bilbruk, og denne hadde automatisk rundetidtaking (typisk brukt på bane/trackdays). Selve GPS-enheten hadde heller ikke mer enn 1 Hz samplerate (som Garmin-enhetene kan ha), men empirisk testing (mot optisk tidtaking) viste at min enhet typisk oppnådde en nøyaktighet på 1/10 sek (eller bedre) gjennom interpolering. Det er tross alt ganske bra.
Takker for utfyllende info om problemet. Forstår bedre hva du mener med dårlig datakvalitet nå. Det er tydeligvis store rom for forbedringer, så det er synd Strava slurver. Er helt med deg på det.
Det med start- og stopp-punkt er kanskje det største problemet på de fleste segment. Men de aksepterer litt vel store avvik på sporene underveis også. De prioriterer vel å få med alle uansett om devicen av en eller annen grunn logger unøyaktig. Har brukt opptil flere minutter på å irritere meg over segment BhakkeSphurt. Det er også i Oslo, og går parallellt med bilveien. Problemet er at bilveien er så og si flat mens gangstien har en bhakke man kan sphurte i. De mest hardbarka sykler i bilveien her (selv om det ligner for mye på motorvei etter min smak) for å spare tid, og de beste tidene er naturligvis satt her på bilveien. Irriterende for oss som har lagt igjen flere millioner watt opp bakken på sykkelstien i håp om en topp 10. Om man klikker seg inn på rekordtidene ser man lett på sporet om de har syklet sykkelsti eller bilvei.
Har også sett en nisse i bil sette flere KOMs på de kjente kjære segmentene mellom Lysaker og Oslo fordi store avvik tillates. Men det er forsåvidt en positiv ting at han kjørte E18 i stedet for sykkelstien.
Ja, det er helt åpenbart at Strava kunne ha forbedret algoritmene sine for matching underveis også, men akkurat eksempelet du nevner er vanskelig. Der er det så tett mellom bilveien og gangveien at det er nesten umulig å skille. Jeg kan i hvert fall ikke si med sikkerhet hvor alle sporene egentlig hører hjemme, men det ser i hvert fall ut for at han som har KOM gjorde det på gangveien.
Jeg vedlegger for moro skyld GPX-filen (men omdøpt til .txt for å få laste den opp på forumet) fra programmet mitt her, så kan du selv laste den opp på GPS Visualizer og se på den. Merk at du kan skru av og på de forskjellige sporene ved å klikke på dem i listen.
Og om noen skulle se litt nøye på selve GPX-filen, så er tidsangivelsene ikke i standard format, jeg spytter bare ut relativ tid som hentet fra Strava-dataene. Det er det enkelt nok å fikse, men for manuell inspeksjon av dataene er det mer praktisk med relativ tid.
Dette var stilig! Hva skal til for å kunne teste dette verktøyet på lokale segmenter?
Det er slik per i dag at programmet er assosiert til min Strava-konto, og hvis jeg skal la andre teste det så må jeg implementere autentiseringsprosedyren slik at programmet tilknyttes hver enkelt bruker i stedet. Det er ikke teknisk så veldig vanskelig, men noen utfordringer er det, spesielt siden programmet ikke kjører på en webserver.
Men om du lister opp noen segmenter, så kan jeg gjerne sjekke dem og poste resultatet i denne tråden.
Om dette hadde vert en nett- eller appbasert løsning, hadde jeg gledelig betalt en liten slant for å sjekke. Kanskje blir det veldig "poppis" og strava får øynene opp for at noe må gjøres. Skal se om jeg finner noen segmenter som er gode eksempler i området her.
Merk at han som har KOM beholder denne, til tross for nesten tre sekunder dårligere tid etter min prosessering. Men når det er sagt, så er hans datagrunnlag for segmentet kun tre datapunkter, så her blir det nok litt bingo uansett. Det er i hvert fall helt sikkert at han har altfor god tid på Strava. Det er ganske tett mellom tidene på den alternative lista...
Legg også merke til at segmentet har et ganske dårlig dataspor (kun 7 datapunkter), og der datapunkt nummer 2 ligger ganske langt til siden for gangveien. Start- og sluttpunkter på segmenter bør helst settes utenom sving, i hvert fall hvis man ser at datasporet ikke følger og tangerer svingen skikkelig.
Jeg har lagt til snitt og makshastigheter, men merk følgende: Makshastigheten er den samme som Strava viser, siden den er hentet direkte fra Stravas data. Snitthastigheten er basert på interpolert avstand og tid (altså etter korreksjon for passering start/mål).
Vær også klar over at når Strava viser snitthastighet i sitt "leaderboard", så er den konsekvent feil, siden den er regnet ut fra segmentets lengde (altså ikke faktisk kjørt lengde). Om man klikker på "Analyze" for et gitt segment for en rytter, så får man opp en snitthastighet til venstre for hatighetskurven. Det er reell snitthastighet over utkjørt distanse, men distansen er altså også litt feil (i forhold til start/mål på segmentet), siden Strava ikke interpolerer. Denne snitthastigheten vil likevel normalt ha ganske små avvik i forhold til den som mitt program presenterer.
Forskjeller i reelt kjørt distanse gjør også at en person kan ha større snitthastighet enn personer foran seg på listen, også etter interpolering.
For dette segmentet er det også verd å merke seg at selve segmentet svinger på slutten (p.g.a dårlige data), og derfor blir også den virtuelle mållinjen min stående skjevt, som også er uheldig for utregningen. Jeg skal se på noen forbedringer jeg kan gjøre der, stay tuned.
Som du ser, så ville du (antar det er deg) ikke lenger hatt (delt) KOM på dette segmentet. Du har hatt høyere snittfart, men du har et lengre spor. Nå ser dette også ut til å være i skogen, så GPS-dekningen er kanskje også litt sjaber.
Store endringer i lista, som du ser. GPX-filen er vedlagt (med .txt på enden), så kan du selv se på den i GPS Visualizer.
Se spesielt på tiden/sporet til Ingebret Stana. Han har fått over 10 sekunder for god tid av Strava. Det tror jeg er det mest ekstreme eksempelet jeg har sett så langt. En ekte segmentlotto-vinner. :-)
![[Linket bilde fra veloviewer.com]](http://veloviewer.com/SigImage.php?a=33b04&r=2&c=4&u=M&g=n&f=bacoghlhij&z=a.png)
Litt usikker på om det er så smart å bruke det i konkurransar for tidtaking som nokre forsøker, i så fall bør det brukast betre algoritmer enn Strava sine for segmentmatching.
