Improve leaderboard calculation accuracy for shorter segments
The way Strava calculates time for leader boards seems imprecise for shorter segments. This can lead to either significantly higher-than-real or significantly lower-than-real speeds displayed in Strava. This can also cause different average speed to be shown in leader board vs ride analysis - see here https://strava.zendesk.com/entries/40529030-Average-Speed-in-segmen.
This is a proposal to do a very simple correction to the leaderboard time calculation formula which will lead to significant accuracy improvements.
This has been submitted as Request #433568 but Sean from Strava support suggested I put this here. This text is from the original request:
Example (all numbers are faked just to demonstrate the idea):
Let's say, there is a segment 100 meters long.
GPS track points selected by segment matching algorithm happened to be within the segment, and distance between the first and last GPS track points happened to be 80 meters.
Let's say, it took me 8 seconds to move between these GPS track points (according to the GPS track data).
Currently Strava calculates AVG speed on the segment like this:
(this is based on the information from this thread https://strava.zendesk.com/entries/40529030-Average-Speed-in-segmen )
AVG speed on segment = 100m (full segment length) / 8s (time between track points) = 12.5 m/s
Leaderboard time of the segment = 8s (the time between the track points is taken as is)
What I'm proposing is to tweak the formula very slightly:
AVG speed on segment = 80m (actual distance between the GPS track points) / 8s (time between track points) = 10m/s
Leaderboard time of the segment = 100m (full segment length) / 10m/s (AVG speed between track points) = 10s
This approach also works fine in all other track point configurations, e.g. when the first GPS track point is before the segment start and/or the last GPS track point is after the segment end.
As you see, the change to the formula is really simple - no new data is needed, and the math is very basic. But this simple change makes great improvement to accuracy!
The accuracy improvement is obvious - the 20m difference between the segment and the actual recorded track section is interpolated/assumed to have been run/ridden with AVG speed 10m/s, while the current Strava algorithm assumes they were run/ridden with the speed of light, i.e. "in no time" :)
I really hope you can propose this change to engineers - it would really make a huge difference for those of us users who enjoy 1 minute "all out" sprints :)