Strava Live Segments S+ guide algorithm is most likely incorrect

[sky-runner]

I used Strava Live Segments S+ guide today to track a 30 km segment on variable terrain with multiple climbs and descents. What I observed makes me think that the algorithm used to determine the time ahead/behind is likely incorrect.

What Live Segment tracking is supposed to tell me in real time, is the following: for the current position on the segment, how much time I am ahead or behind my previous PR (or KOM, or Carrot - a person just in front of me on the leaderboard).

What Suunto implementation seems to be doing is the following - using my current speed it projects when I will finish the segment, then calculates the time ahead/behind from that vs the PR finish time.

What I observed is that when climbing I steadily and rather quickly lose time advantage over the PR. For example, on today’s run, at some point today I was almost 2 minutes ahead of the PR at the bottom of a climb. By the time I reached the top of the climb I was almost a minute behind - all while knowing that I certainly climbed as fast if not faster than during the previous PR run. According to Suunto implementation I lost 3 minutes vs. my previous PR run, but in reality I didn’t lose any time and possibly even gained some. Similarly, on downhills when the speed increases, Suunto implementation makes you think that you quickly gain a lot of time vs. the PR even if in reality you don’t gain any.

It is very frustrating because on rolling hills terrain the time ahead/behind behaves like a volatile yo-yo. It makes pacing to stay just ahead of the PR pretty much impossible. The current implementation works reasonably correctly only if the terrain remains nearly stable for the entire duration of the segment.

The correct algorithm that will work on variable terrain should be the following:

1. Take time Tnow from the beginning of the segment for the current position on the segment. This is simple the current elapsed time minus the elapsed time when the segment has started.
2. Determine the time Tpr using timestamps from the segment data, using interpolation as appropriate because segment data points can be multiple seconds apart.
3. The time ahead/behind should be Tnow - Tpr.

[Egika]

@sky-runner do the Strava segments provide more information than just the total distance, position of start and end (and in between) and the times, other people took to complete?
I wonder if there actually are time stamps from during the segment…

[sky-runner]

@Egika Yes there are up to 4-5 streams of timestamps that can be synced from Strava for different segments goals:
a) KOM
b) Your previous PR
c) Your friend’s PR in from of you on the leaderboard
d).Carrot - the person to beat just in front of you on the leaderboard
e) Wolf - if I remember correctly the person just behind you on the leaderboard

I know that Garmin can track goals (a), (b), and Coros can track all possible goals.

A Strava segment is represented as a stream of positions - a route - and several streams of goal timestamps - one for each goal. Timestamps are numbers of second from the segment start to reach position. It appears that Suunto implementation simply ignores the streams of timestamps because S+ Guide API simply doesn’t support that. Guide API can only follow a route so a segment is handled as a route and then the time ahead/behind is calculated based on the remaining distance and rolling pace the way I explained above.

If segments were implemented natively, doing the right algorithm would not be a problem, but I suspect that with the S+ Guide API the current implementation is the best that can be done. But as a explained it simply doesn’t work.correctly on a rolling terrain.

I think that in general segments are really underappreciated as a training tool. Tracking a live segment is like doing a virtual pace where you can complete both against yourself and against others. Today I completed against a private segment which I created from my previous 30 km run, and that allowed me to improve by 4 minutes. Without the extra “competitive motivation” it would be much harder to keep pushing for nearly 3 hours. And doing it based on pace alone would be impossible because of the variable terrain.

[Egika]

@sky-runner i did not know that the whole segment had multiple timestamps from start to end.
That means you could compute your ahead/behind times for like “sub-segments”. Not sure how to calbulate this so the times do not jump around, but it should be possible.