STOP historical search for Rerouted trail updates

[doubleduhric]

So I keep running into a GREAT problem and I wanted to see if it was something anyone may already be working on. 

In Summit County, CO (and countless other areas) trail-building and re-routing has become a fairly BIG business. This is AMAZING for our environment but has at least one major drawback in coordination with STRAVA's platform. Currently you can make all the new segments you would like, but if a historical run is 'close' enough to the new trails path, it counts.

I propose an option when adding/creating new segments to select a 'reroute'. This would then essentially allow the creator to add a 'start date' or 'trail completion date' to limit the leaderboards from searching and finding historical data from before the update to the trail was complete. i.e. Hattie's Trail (Frisco, CO) reroute was just finished. The reroute allows the trail to be ridden both up and down, rather than almost entirely down. Almost 1/2 a mile of trail was added via switchbacks and flow. Obviously old statistics from the 'straighter' trail will be much different than those from the reroute. 

Just a thought.. hope its helpful!

[Soren]

Thanks for submitting your idea. It has been reviewed by our moderation team and is now open to voting.

[Soren]

Hi @jedoubleve 

We're aware of segments within close proximity of each other presenting issues with matching like the ones you described. Because our system allows for some small margin of error to account for GPS drift, if a segment runs parallel to another segment or the two are close enough together, it may not be possible for Strava to provide mutually exclusive results. This means that athletes riding or running on the road may match on the different segment, and vice versa. Unfortunately, if the two paths are close enough together for this to be an issue, the only way to improve your chances for accurate matches is to move the segment endpoints further away. 

We do have a way for the community to up and downvote segments using the star and hide features. You will always be shown segments that you have created, starred, unhidden, or set a goal on. If you have a strong preference for one segment over another, then you can indicate that preference by starring it. We factor the total number of segment 'stars' into our algorithm as well, so you'll be helping us serve better segments to the entire community.

• Hide Segments
• Star Segments
• How to Create Good Segments

[doubleduhric]

The GPS accounting for error I completely understood prior to making my idea. My idea idea is for the SAME trail (not adjacent). One that has been remade, rerouted, and is no longer really the "same" after completion. i.e. a date mechanism to prevent your algorithm from matching historical rides from before the change. Again, the GPS error margin is understood. I'm trying to prevent bad data by essentially adding a 'filter'. See the image below. The yellow was the historical trail prior to Sept 2022. The Red is the update, completed approx. 7-10 days ago (This is Hatties, as described in my idea). The statistics generated from the new trail no longer compare to the old. So if there were a way to make a hard stop or suggest one on a segment that has undergone a rebuild it would be helpful for comparison. 

[Soren]

Thanks so much for the clarification and the visual, a dated filter makes sense for these kinds of cases. We appreciate your suggestion.

[PoppyRex]

Segments change, particularly off road cycling, MTB and eMTB, change regularly. Trees fall down, course changes and other stuff, council fences, National Parks, what ever. So the segment I created twelve months ago is not the same segment I ride now, but it is in Strava, close match, but different. Should there be an expiry time for a segment and its associated records. There is a local segment that we used to ride but it does not exist any more, local infrastructure expanding, but our work around still records on the original segment.

regards

mick

[Jane]

Hi @PoppyRex 

Thanks for sharing your thoughts!  We have a similar discussion already underway so I've merged the posts together.

This helps us keep the forums organized and makes sure suggestions are easy to find and votes for them aren’t divided across duplicate ideas. Don’t forget to show your support by clicking on the kudos button.

[Silentvoyager]

I've run into exactly the same issue when I tried to create a new segment for a rerouted trail. The old trail went straight up. The new trail is much more gradual and has a number of switchbacks, and is considerably longer adding at least a few minutes. 

Yet, when I created a new segment, all results on the top of the new segment leaderboard are from the previous year when people ran the old trail. It even picked my own previous attempt on the old trail as the PR for the new segment, which I'll have a hard time beating going forward.

I think either the tolerance should be reduced because modern GPS devices are much more accurate or perhaps there should be an option when creating a segment to specify how long to look back in time when populating the leaderboard. 

[kiwidoc]

Can the system look at heat map data to assign segments? The heatmaps imply greater accuracy than strava accounts for.

Example is picture below. The pink arrow is a fast flow track below the ridge, the green arrow indicates is a technical track on the ridge with us and downs, clearly very different times! Riders who start the segment on flow then join the tech track later are put in the same leader board as those who rode the techy trick from the start. 

If the heatmap can clealrr differentiate them surely the leaderboard calculation could as well? Its all maths and thresholds....

[EDH]

This looks like an old topic but I hope the idea hasn't died. This problem drives us crazy! We have trials that have been evolving for years. With each update, mileage is added. Even when we make a new segment that represents the re route and additional mileage, Strava still gives credit for the newly created segment for rides that were completed years ago on the old course layout. Strava surely has the knowledge and resources to overcome such a problem. Why would it not be possible to simply allow the creator of the segment to specify a date for which the new segment became effective, and not allow older activities to show up on the leaderboard. Leaving this problem unsolved essentially renders the whole concept of segments useless under these circumstances.

[doubleduhric]

Considering the subscription increase I surely hope this is resolved this summer of 2023. If it is not, I will surely be exiting the community as segments and individual/team goals are the basis for my subscription.