Her er et annet kort segment med unøyaktige GPS-målinger: "Thugen" Den virkelige hastighetenen på KOM her burde vel ligge litt lavere? Fartsgrensa der er jo 50 km/t, og segmentet går tvers gjennom ei rundkjøring...
Interpolering fordrer at sykkelistene starter litt før startlinja i jevn fart, og fortsetter etter sluttlinja i rimelig jevn fart, eller i det minste jevn aksellerasjon. Har tenkt litt på hvorfor Strava ikke bruker det og tenker at det kan være fordi dette er vanskelig i skogen?
Da har jeg nerdet enda litt mer med programmet mitt, og har funnet på noe jeg syntes var lurt. Programmet regner jo ut virtuelle start- og mållinjer som så brukes til å regne ut tidskorreksjonene. Så er det jo slik at noen segmenter har dårlige data, og der starten og/eller slutten på segmentsporet avviker fra slik folk faktisk sykler. Programmet mitt var opprinnelig slik at den virtuelle linjen alltid ble satt 90 grader på segmentets endepunkter. Det er helt OK så lenge segmentets spor faktisk går der folk sykler, men altfor mange som lager segmenter sjekker ikke dette nøye når de definerer segmentet.
Ballettbakke-segmentet er et godt eksempel, for der svinger segmentsporet ganske mye til venstre helt på slutten, som gjør at den virtuelle mållinjen blir veldig skjev.
Jeg fant også på at visuelt sett ville det være fint om start- og mållinjen kunne vises i GPX-filen, så da har jeg gjort det slik at jeg regner ut ytterpunktene på disse linjene (25 meter til hver side, så 50 meter bredde totalt), og føyer de på segmentsporet. Om vi ser på ballettbakke-segmentet, så ser det da slik ut:
Startlinjen er grei, men mållinjen blir jo veldig skjev, og fører til at de som passerer den langt fra senterpunktet får feil tidskorreksjoner i forhold til det som er naturlig.
Så tenkte jeg litt mer, og kom frem til at dette kunne gjøres bedre. Jeg henter nå derfor topp 20 på et segment, og finner medianen på retningen disse har syklet (men kun de som har en samplefrekvens over 0.8 as/s), hhv for start og slutt på segmentet. Så bruker jeg denne retningen til å bestemme vinkelen på de virtuelle linjene, men senterpunktet er fremdeles hentet fra det opprinnelige segmentsporet. Ballettbakken får da plutselig en mållinje som ser mye mer fornuftig ut:
I mitt hode er dette en mye bedre og mer rettferdig måte å gjøre det på, og det får da også store utslag for segmentets toppliste:
Erik Resell ble tidligere straffet fordi hans spor ligger et stykke fra det opprinnelige segmentsporet, og derfor krysser den skjeve mållinjen mye senere. Med den nye (og forbedrede) metoden kommer han mye bedre ut, som bildene anskueliggjør. Merk at selv om mållinjen (og startlinjen) er 50 meter bred på bildene, så er den egentlig "uendelig" lang internt.
Så kan man jo si at hvis et segment er laget i sving med vilje, men at folk flest får sin tid ved å sykle inn i segmentet fra en annen vinkel, så vil den nye metoden gi segmentskaperen dårligere tid, men totalt sett er det likevel mer riktig å basere det på hvordan folk flest sykler, siden det da er slik Strava har matchet segmentet. Det er jo Stravas feil at de ikke har implementert dette skikkelig.
Begynner å ligne noe nå, synes jeg.:-) Skal sjekke opp de sist foreslåtte segmentene også, etter ny metode.
Interpolering fordrer at sykkelistene starter litt før startlinja i jevn fart, og fortsetter etter sluttlinja i rimelig jevn fart, eller i det minste jevn aksellerasjon. Har tenkt litt på hvorfor Strava ikke bruker det og tenker at det kan være fordi dette er vanskelig i skogen?
På landevei bør det være greit?
Ja, skal man interpolere så trenger man egentlig punkter på begge sider av den virtuelle krysningslinjen, men dessverre så har Strava valgt å gjøre matchingen på dårligst mulig vis, ved å bare plukke det nærmeste punktet. Hvis dette punktet da ligger f.eks etter linjekryssingen, så må man ekstrapolere bakover til man treffer linjen. Det er det jeg gjør i mitt program.
Hadde det vært slik at jeg alltid kunne få punktet før linjen og punktet etter linjen, så ville jeg interpolert basert på konstant (eller jevn om du vil) akselerasjon, siden det vil gi den mest korrekte interpoleringen. Det får jeg imidlertid dessverre ikke, så da må jeg bare basere det på konstant fart, der farten som benyttes er den som er registrert i Stravas endepunkter for rytterens segmentspor.
At GPS får dårligere signal i skogen er sant, men om Strava hadde brukt tilsvarende metodikk som jeg gjør, så er det ingen tvil om at resultatene ville blitt mer rettferdige. Dette blir aldri helt eksakt, men det kunne vært dramatisk forbedret.
Her er et annet kort segment med unøyaktige GPS-målinger: "Thugen" Den virkelige hastighetenen på KOM her burde vel ligge litt lavere? Fartsgrensa der er jo 50 km/t, og segmentet går tvers gjennom ei rundkjøring...
Segment brief:
Name: Straumebro stigning
ID: 4818471
Created at: 2013-07-21T18:33:50Z
Updated at: 2015-08-03T08:03:52Z
Length: 210.80
Min ele: 22.70
Max ele: 44.20
Avg grade: 9.20
Max grade: 12.00
Datapoints: 6
Segment leaderboard (original):
Pos 1: Ole Bergtun time: 0:18.00, dist: 158.60, as/s: 0.333
Pos 1: Atle Sommer time: 0:18.00, dist: 197.80, as/s: 0.889
Pos 3: Tommy R time: 0:19.00, dist: 147.10, as/s: 0.526
Pos 3: Endre H time: 0:19.00, dist: 185.50, as/s: 0.579
Pos 3: Kjetil F. Larsen time: 0:19.00, dist: 210.60, as/s: 1.000
Pos 3: Stig otto Berntsen time: 0:19.00, dist: 194.30, as/s: 0.789
Pos 7: Jan Ove Grasdal time: 0:20.00, dist: 204.70, as/s: 0.850
Pos 7: Richard jansen time: 0:20.00, dist: 193.50, as/s: 0.800
Pos 7: Kristoffer Nielsen time: 0:20.00, dist: 190.60, as/s: 0.450
Pos 7: Bjørn Erik Grimstad time: 0:20.00, dist: 184.40, as/s: 0.700
Segment leaderboard (interpolated):
Pos 3: Kjetil F. Larsen time: 0:18.74 (corr: -0.25) speed avg: 39.9 max: 42.1
Pos 1: Atle Sommer time: 0:19.04 (corr: +1.05) speed avg: 39.6 max: 41.4
Pos 7: Jan Ove Grasdal time: 0:19.75 (corr: -0.25) speed avg: 36.9 max: 50.4
Pos 3: Stig otto Berntsen time: 0:20.43 (corr: +1.43) speed avg: 36.7 max: 38.5
Pos 3: Endre H time: 0:21.77 (corr: +2.78) speed avg: 35.1 max: 42.1
Pos 7: Kristoffer Nielsen time: 0:21.82 (corr: +1.82) speed avg: 34.3 max: 35.6
Pos 7: Richard jansen time: 0:22.05 (corr: +2.05) speed avg: 34.6 max: 36.7
Pos 7: Bjørn Erik Grimstad time: 0:23.06 (corr: +3.07) speed avg: 32.8 max: 36.0
Pos 1: Ole Bergtun time: 0:23.47 (corr: +5.47) speed avg: 29.5 max: 35.6
Pos 3: Tommy R time: 0:25.90 (corr: +6.90) speed avg: 27.8 max: 29.9
Om dere ser på GPX-filen i GPS Visualizer, så ser dere hvor dårlig det opprinnelige segmentsporet er, og hvor bra den nye metoden for start- og mållinje fungerer. :-)
Kan du se hva du får ut av denne? KOM her er satt urealistisk overlegent pga en voldsom U-sving like etter start, så vidt jeg kan se. Ser dette litt pga at det er et lengre segment rundt dette som inneholder mer normalt god tid. Dog er vedkommende såpass rask at han mye mulig har kom uansett, men kanskje ikke så vanvittig overlegent
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. :-)
Takker!
Ble overrasket over at sporet i det hele tatt var der det vises i kartet, det står jo 5% stigning, så jeg trodde det var bakken rett før, fra venstre side, en kort og bratt grusbakke, og at alle som kom ovenfra (fra høyre) egentlig ikke syklet segmentet, men ser at segmentet rett og slett er på feil plass, og med helt feil høydedata. Det er -1% i en av mine logger. Irriterende at slike segmenter ikke blir automatisk korrigert eller slettet når det har kjørt 2300 mann der med andre høydedata.
Kan du se hva du får ut av denne? KOM her er satt urealistisk overlegent pga en voldsom U-sving like etter start, så vidt jeg kan se. Ser dette litt pga at det er et lengre segment rundt dette som inneholder mer normalt god tid. Dog er vedkommende såpass rask at han mye mulig har kom uansett, men kanskje ikke så vanvittig overlegent
Som du ser så har du helt rett, KOM-holder får en enorm korreksjon her, men beholder likevel KOM, men med en veldig mye mindre margin enn før.
Men som GPX-filen viser, her er sporene "all over the place", og Stravas segmentmatching fungerer i praksis ikke i det hele tatt. Så skal jeg også legge til at her er det vanskelig å si noe som helst helt sikkert, gitt sporenes kvalitet (eller mangel på det).
Er det slik at når man skal lage et nytt segment så burde man egentlig sykle supersakte gjennom med GPS satt til fast samplingsfrekvens? Da vil jo originalsporet få flest mulig punkter. Kanskje GPS greier å holde seg på best mulig presisjon også når det går sakte?
Er det slik at når man skal lage et nytt segment så burde man egentlig sykle supersakte gjennom med GPS satt til fast samplingsfrekvens? Da vil jo originalsporet få flest mulig punkter. Kanskje GPS greier å holde seg på best mulig presisjon også når det går sakte?
For tidtakingen sin rolle er det egentlig bare start og mål som er viktig, det som skjer mellom der betyr kun noe for hvorvidt man får match på segmentet eller ei, og der er som kjent Strava ganske løsslupne.
Det er alltid best å ha høyest mulig (og fast) samplefrekvens på GPSen. "Smart Recording" er noe forbannet dritt, og må kun brukes om man er i nød og trenger å spare lagringsplass (og det kan man i praksis stort sett alltid unngå).
Om jeg skulle sette opp et sett med regler for å lage best mulig segmenter, så ville det bli slik:
1) Om mulig, sett endepunktene på steder der det går rett frem (og helst at det er et par-tre datapunkter til sving, både før og etter) 2) Om mulig, sett endepunktene på steder der man har en viss fart (segmenter fra stille start blir typisk ikke bra) 3) Sørg for høyest mulig samplerate (1 s/s er vanligvis maks) 4) Lag gjerne segmentsporet fra en gjennomsykling med passelig fart, trenger ikke å være spupersakte og heller ikke et KOM-forsøk
Mer nerding, muligens kun interessant for meg selv, men jeg poster for referansens skyld.
I går syklet jeg en runde, men i tillegg til Edge 510 så satte jeg også min gamle Edge 500 på styret. Jeg satte med vilje Edge 500 til 'Smart recording', mens 510 sto på 1 sekund. Dere ser kanskje hvor jeg vil hen... :-)
Etterpå lastet jeg opp turen som normalt fra Edge 510, men for å få lov til å laste opp også loggen fra 500 så kjørte jeg en times offset på den loggen, slik at Strava skulle tro at det var to forskjellige turer (selv om turen tok mer enn en time, så strengt tatt var det likevel en umulighet).
Begge enhetene fikk match på 14 segmenter på denne turen, noen korte og noen lange, uten at det er vesentlig her. Siden begge enhetene var med på samme tur, plassert 3 centimeter fra hverandre, så vet vi på forhånd at alle segmenttidene skal være like. Det var de selvfølgelig ikke, og her er en liste som viser både Stravas tider og de interpolerte tidene fra mitt program. Loggen fra Edge 500 kan identifiseres ved at den har lavere as/s enn loggen fra 510:
Så har jeg sett litt på hvert enkelt av segmentene, og laget en liste som viser differansen mellom loggene, både Stravas og den interpolerte. I alle tilfeller er den interpolerte differansen under 1 sek, men noen ganger ville en avrunding til nærmeste hele sekund gi en diff på 1 sek i stedet for 0 sek (som jo er "fasit"). Jeg har valgt å si at det er uavgjort mellom Strava og interpolert dersom Stravas diff og den interpolerte diffen gir samme resultat. Om den ene har lavere diff enn den andre, så kåres den til vinner. Her er listen:
På kun ett av 14 segmenter er Strava mest riktig (altså har lavest differanse), på 8 av 14 er det uavgjort, mens interpolert er best på hele 5 av segmentene. Altså:
Legg også merke til segment 10, som veldig tydelig viser hvor galt det kan gå med Stravas metode. Hele 4 sek differanse får Strava, mens den interpolerte differansen er under tre tideler.
Et viktig moment å ta med her er at sammenligningen er relativ, og at hvis vi også hadde hatt stoppeklokketidtaging på hvert av segmentene, så kunne sammenligningen vært gjort mot reell tid, og da kunne resultatet sett annerledes ut.
Neste steg er (om jeg gidder), å teste ren interpolering der jeg bruker punkter på begge sider av den virtuelle start- og mållinjen. Det forutsetter tilgang til hele aktivitetsstrømmen, og det har jeg i dette tilfellet (siden det er mine egne aktiviteter). Dessverre tillater ikke Strava dette for andre brukeres aktiviteter, og når da ett (eller begge) av endepunktene i effort-streamen ligger inni selve segmentet så må det ekstrapoleres, som i utgangspunkt er dårligere.
Segmentet "Grefsenkollen" som ligger til grunn for kåringen av Oslos klatrkonge hadde vært interessant om du sjekket. Det slutter jo i en sving, og mange gode ryttere kniver om toppplassering....
Segmentet "Grefsenkollen" som ligger til grunn for kåringen av Oslos klatrkonge hadde vært interessant om du sjekket. Det slutter jo i en sving, og mange gode ryttere kniver om toppplassering....
