Your stats in VeloViewer are only as good as the data that is passed in from Strava, and around 1.5% (based on sample data I had a couple of months ago) of Strava segments seem to have bad data associated with them. The 2 main culprits are dodgy elevation data and non-matching distance data.
This isn’t entirely Strava’s fault although I believe there are ways that they could clear up the majority of these things automatically. But for the time being it is up to us, the Strava community, to tidy it up the best we can which will also result in much more accurate stats in VeloViewer.
Bad Elevation Data
Find out which of your segments has bad data…
How to correct your data…
This is the most common type of problem that effects your VAM and Relative Power stats often giving ludicrously high values. Typically this is down to the GPS device used for the created segment getting confused and not recording the elevations accurately. On some segments this can be hard to avoid due to severe gradients mixed with tree cover resulting in trouble picking up enough satellites but it usually more of an issue with the device being used for tracking, some are just much better than others.
When looking at a suspect segment in Strava then the tell-tale signs for bad elevation data are:
- Sudden steps in elevation.
- Gradients that just don’t match the lie of the land (see image below).
Comparing the elevation profile with the contours should give you enough info to tell if there is a probelm. I personally find the contours shown on VeloViewer’s Segment Detail page clearer to see than the Google view on Strava.
I’m not sure if this is still the case but historically Strava have automatically created segments where one doesn’t already exist for categorised climbs. Unfortunately they don’t check to make sure that this “categorised climb” isn’t in fact a flat section of road on which someone’s confused iPhone suddenly worked out how high it was and jumping it’s elevation by 100m vertically. I can’t believe that the user involved manually created these segments as they are most often on completely random bits of road that would be of no use as a segment in their own right.
If Strava could run a quick double check these automatically created segments to make sure the min/max elevation points are correct then that should avoid 95% of the problem. They only need check segments where the resulting KOM’s VAM is crazy high to cut down the processing a bit. I’m sure an automated check could also be done on mass to correct elevation data for all segments with a KOM VAM greater than say 2300 (or at least queue them up for correction when the servers aren’t so busy).
As it stands though, to sort out these elevations on your own dodgy segments is a fairly easy task:
How to correct your segment’s bad elevation data
- Visit the Strava Support Site.
- Login (if not already logged in).
- “SUBMIT A REQUEST”.
- Pick “Segments :: Bad data” from the “I need help with” list.
- Add a catchy subject like “Incorrect elevation data”.
- Paste each offending Strava segment url into the description box (e.g. https://www.strava.com/segments/808884, if you’ve navigated to the segment in the context of a ride then hit the “Go to segment page »” link at the top of the map). Worth adding all your dodgy segments in one support request to save extra admin hassle at Strava.
- Say a big THANK YOU to the support staff and hit the “Submit” button.
- Submit the request.
The support staff are happy to do this and usually complete them in a day or two.
When they’ve been updated then navigate to the Segment Details page for each segment concerned in VeloViewer and click the “Update segment details” link at the bottom right of the page.
Bad Distance Data
Less common this one but does still crop up from time-to-time. Historically this often occurred when looping segments were created with the start and finish points being very close together. The segment would be 20km long but people were recording times of 10 seconds giving remarkable average speeds and VAM/RPs:
These segments should probably just be flagged or create a support request to have them deleted.
These days Strava ensure that at least 75% of your route matches that of the segment so hopefully no new segments like this will be showing up but you potentially have some residual segments that were matched prior to this feature being implemented by Strava.
Which of My Segments Have Bad Data?
If you check out your Summary page then your Climb Stats table will give you a good idea if any of your categorised climb segments have bad elevation data. Just look for very high (>2000) VAM values. An exclamation mark is shown next to any values that warrant investigation:
Clicking on the Max VAM or Relative Power values will take you straight to the Segment Details page.
Another, and more thorough way, is to go to your segment list and order by the KOM Relative Power column. Any segments with a KOM Relative Power great than 7 Watts/Kg probably needs investigating. These will either be due to bad elevation/distance data or due to the KOM being from a car journey, in which case you should flag their ride.
If you’ve not tidied up your data before then you might need to set aside an evening going through your suspect segments and providing the list to Strava Support but once it’s done then your data is going to be much better on VeloViewer as well as on Strava and you can be content in the knowledge that you’ve done a little bit of good in the Strava community improving some of the data for everyone else as well as yourself.
Badger says:
Being able to sort the leaderboard by VAM/Rp (and KOM RP) is great for finding these segments with issues. If my RP is ok, but the KOM is dodgy, usually it means the KOM was driving a car (flag the ride). If my RP is high as well, then it is usually elevation data. Strava have been really good at fixing the stuff I report.
The problem is that RP is only calculated on segments that are climbs (or strava thinks are climbs – ie all the autogenerated segments with bad elevation data). It would be great to have those numbers for flat and downhill segments (although they might not mean anything) just to find the dodgy ones.
According to strava, they are working on something to fix the bad start/finish data. Let’s hope it is soon…
Ben says:
Hi Badger.
Do you have a link to the details about what Strava are fixing regarding start/finish data?
If you order by KOM RP then (as well as the car KOM’s which are good to sort out for the greater good anyway), then you’ll pick up those segments that have bad elevation data where you haven’t given them a good go yet. So even though your own VAM/RP isn’t overly high, it is still far higher than it should be and so can give misleading stats in the summary and graphs. Worth fixing if you’ve got the time.
Do you care about dodgy elevation data for non-climbs, at least those not big enough to trigger a VAM value? It’s only the gradient and elevation gain that could be affected (and the profile I suppose). VAM (and hence RP) just don’t work on these smaller climbs so it wouldn’t really help. You could order by average speed to find ones that have the wrong distance?
I am thinking of adding an automated elevation check option on the segment details page that will compare the min and max heights from the segment’s elevation data against those from Google’s mapping API just to give an indication if any are about right. Also maybe give the option to compare the elevation profile of the segment with that from your ride. Still won’t help you knowing which segments to check though…
badger says:
I don’t have any details, just a comment from one of the support team “As far as the segment problem you described, I think you’ll see some
changes in the relatively near future that you’ll be pretty happy about.
We’re working on ways to interpolate segment start/end points for
better segment matching when they fall between GPS points.”
As for non-climbs, you are right, if the VAM/RP data don’t exist then I guess it doesn’t matter as much…
Ben says:
Oh, ok. I was getting the wrong end of the stick with the start/end comment. Yeah, Strava are working on interpolating each rider’s intersection with the segment’s virtual start and finish lines as opposed to just using the closest recorded gps point. I looked into calculating this myself for my Alternative Leaderboard page but it would require retrieving the gps points of each and every ride in the leaderboard followed by a heap of number crunching so I just stuck with the actual distance covered to give a rough estimate.
Once Strava have implemented this then they will certainly have an interesting decision to make as to whether they apply that algorithm on all their historical leaderboard data or just apply it to new rides from that point forwards.
If they only apply it to new rides then KOM’s on a large number of the short segments will be unattainable despite going faster than the original rider due to their non-interpolated start/finish points. However, can you imagine how many disgruntled users they will have if they recalculate all the leaderboards as lots of people will lose a few of their KOM’s (and of course others will gain some)?
Personally I’m in favour of a full recalculation (if this is feasible from a processing perspective). Only people using this site will have easy visibility of how it effects all their placings.
Rob Martin says:
ok, Strava very quickly corrected two sets of bad data. How do I update the Max VAM in the Summary to get rid of this data?
Ben says:
Just hit the “Update segment details” link at the bottom right of each of the segment details page. This resets all of that segment’s data. Let me know if it doesn’t.
Rob Martin says:
Ben. Thanks very much. One has diappeared but the next spurious one is still there and I think it is because your viewer shows it as a climbing segment when Strava shows it as a descent. http://app.strava.com/segments/1151903
Ben says:
I’m seeing it ok now. You might need to hit F5 (refresh) on the page to refresh the cache as the elevation data can be stored by your browser for performance reasons. Clear you browser cache is that doesn’t work and you should be fine.
Rob Martin says:
it seems fine now, thanks
lukwe says:
It is more than understandable that the GPS device can have hard times acquiring correct altitude data; but I would expect that given a certain latlong route GarminConnect Correction, Strava Correction and bikeroutetoaster would finally result very close one to the others, since they all rely on the same DEM databeses. I tested this on a tour of Corsica I recently completed, but the corrections algorithms and the route-building sites are still diverging wildly!
My conclusion is the elevation gains figures are totally unreliable, stick to one method for all your rides to at least have a general reference for your rides.