This website uses Cookies. Click Accept to agree to our website's cookie use as described in our Privacy Policy. Click Preferences to customize your cookie settings.
The following article redescribes the problem with how the times of segment efforts are currently measured, suggests a solution, and provides an exemplaric implementation: Accurate timing of Strava segments
There could be improvements made with this approach in some cases I guess but bringing it to work would be a nightmare. The article just assumes that every GPS points of the rider and of the segment are in a straight line but the reality is much more fuzzy. There are many segments that start and end besides the road because of poor reception and the GPS points of the activities have the same problem. Therefore you will never really know if the GPS point recorded nearest the start of a segment is lucky or unlucky or even point on. Bringing other GPS points into the game that are even further away can diminish the accuracy in many cases.
Neither does the proposed algorithm assume (or require) the recorded GPS points to be on a straight line, nor that the activity path goes exactly through the segment start/end: - current/old approach: Use the recorded activity point closest to the segment start/end point. - proposed/new approach: On the polygonal chain defined by the recorded activity points, use any (potentially interpolated) point on it, which is closest to the segment start/end point.
The only approximation here is, that the parts of the polygonal chain between two recorded points are linearly interpolated, while in reality, the athlete probably moved somewhat non-linearly between two recorded points. Still, it should be much better compared to no interpolation at all.
(Analogy: Let's say you measure the height of a tree on every first of March (recorded activity GPS points in the analogy). 2022-03-01 it was 30 m tall. 2023-03-01 it was 36 m. Now you're interested in how tall it probably was on 2022-07-01 (segment start point in the analogy). The currently implemented approach would just take the nearest neighbor measurement (2022-03-01) and say "On 2022-07-01 the tree was likely 30 m tall.", while the new approach would say "On 2022-07-01 the tree was likely 32 m tall.", which is better.)
Could you please provide an example of a segment and an activity, that you think would break the new approach, so I can test the implementation with it?
Hi Tobias, I'm sure that in many or even most cases the interpolation gets the section of the activity nearer to the segment start and end point than just using the recorded GPS points. Only imagine the nearest GPS point used by Strava was in reality spot on the segment start or end but due to measurement inaccuracies the recorded value was nowhere near it. Any attempt to use another (calculated) GPS point here would make a perfect activity to segment match worse.
Maybe this solution should be used anyway (at least for future activities to avoid recalculating decades of former activities) but I only want to point out that it's not in any case better.
If a recorded GPS point of the activity is exactly on the segment start/end (up to floating-point-number precision) or the closest point (on the polygonal chain) overall, the new approach will choose exactly this point and not do any interpolation.
The calculated virtual point is always either an exact original point or the interpolation between two adjacent points. More than two points will never be used and thus not dilute the result.
>If a recorded GPS point of the activity is exactly on the segment start/end (up to floating-point-number precision) or the closest point (on the polygonal chain) overall, the new approach will choose exactly this point and not do any interpolation.
The interpolation WILL use another point if the recording was imprecise and a calculated point is nearer than a recorded point. It will do that even if the nearest recorded point was actually perfect and only seemed to be further away as the interpolated point.
There are two main factors, which currently make segment times inaccurate: - A: low sampling frequency in a stream of recorded GPS points - B: imperfect accuracy of the position of single GPS points
The proposed solution does only intend to solve problem A, not problem B.
After having thought about it a bit more (during a run 😀), I think I now understand what you mean:
Assuming the athlete actually physically recorded a GPS point at exactly the segment start/end, but the coordinates were somewhat inaccurate (problem "B" from above), it would actually be more correct to use this original point instead of an interpolated one.
So, yes, I agree. I too think you have correctly identified a situation, in which the old approach would give a more correct result than the new one. ✔️
On average (and in most cases), however, I'm still convinced, that the new approach should be much better than the old one. ⏱
Thanks a lot for this very good discussion. ❤️ Based on it, I've improved the explanations in my article. ✍️
An important reason to use interpolation is not only to improve accuracy of the match but also to improve quality of the match. With the current algorithm there are many false positives where segments get matched where a person hasn't truly competed a segment. Most often I see that on uphill running segments. When running it is too easy to turn around before reaching a segment finish. The current algorithm uses a fairly large matching radius because it has to accommodate devices that record points less often or devices with smart recording (Garmin uses smart recording by default). From what I read and observed the matching radius is rather large - 50-75 meters. That means that on an uphill someone can easily shave up to 30 seconds by turning around early and still have their segment matched. That is how some people have gotten their KOMs. Similarly, it is quite easy to start a segment late withouts going through the start.
Interpolation would allow to tighten the matching radius and better detect incomplete segment attempts, this it would help to keep leaderboards fairer.
