6

I'm planning a few routes, and while I've generally used Google maps and cyclestreets, the former makes exporting to GPX a pain (there are third party tools, but once you've customised a route they sometime refuse to work, and Google doesn't pass on the customisation properly) and the latter doesn't allow custimsed routes (though its 3 options are generally good).

After hunting for another tool I tried Strava's route builder planning tool (I don't feel any need to log my rides online so don't use Strava for anything else). This apparently uses openstreetmap data.

Now when I put the same loop into Strava and Google I get a difference in elevation gain, and not a small one: 522m from Google and 774m from Strava which is 48% more. The distance is within rounding error (Google: 68.5km; Strava 67.7). At 10% or even 20% I wouldn't be too worried but that's a big difference.

So which one should I trust?

  • I've compared strava to my own gps logs, and it comes in about 5% higher. But we know that gps isn't very reliable for altitude and I believe the app I use gets its altitude data from the GPS alone (though 2 rides of the same 70km route only differ by 2m in 500m). – Chris H Jun 2 '17 at 16:50
  • It turns out my phone has a barometer, and my app (ipbike) probably uses that instead of GPS (it depends whether the phone lets it; some have bugs). Google comes in way less once again. – Chris H Jun 5 '17 at 15:43
  • I plan to compare a route to paper OS maps as well – Chris H Jun 7 '17 at 16:01
  • Strava is notorious for inflating elevation gains. Jeffrey Friedel has a detailed explanation: regex.info/blog/2015-05-09/2568 – SLR Jun 7 '17 at 22:13
  • 1
    Google is pretty inaccurate in my area. For example, this segment of my ride home is shown as being uphill almost the whole way when, in fact, the second half of the B4495 is downhill, as is the second half of Old Road. – David Richerby Jun 8 '17 at 9:47
4

None of them will be "right"

Strava may throw away your elevation data depending on the device used to record it. So for any phone-based app the height is ignored, and your track is placed on a map, then the known elevation is read off that.

For devices with known-good barometric sensors (Garmins and some others) the data in the upload IS used by strava.

Example of an unfixed garmin

The weather was horrible at the start, cold spitty rain. About 20 riders simply chose to abandon before starting. The rain cleared about level with "Lincoln" and the road was dry by about halfway. So the air pressure increased, throwing the Garmin sensor out of calibration. This rider had about 800 metres of climbing

Example of an android device in strava Here's my recording of the same event in March 2017. My recording shows 1820 metres of climbing, and this graph represents the real road elevation properly.


Furthermore you might think a map would be accurate, and in the main it will be. Except the elevation of a map is based on contour lines, lines around the slope at the same elevation above sea level.

There is generally no continuous elevation data for a road.

Instead the map is divided up into square blocks and an "average" height for that block is calculated. If the blocks are 1m square then its pretty good-enough. If the blocks are 10m square, its "okay" because that's about the width of a roadway. If the blocks are 100m square, then its terrible.

Consider this road with a 7% grade. If the elevation blocks were much larger than 10m they could be positioned up or down the hill, giving an artificial high/low spot, increasing your recorded elevation gain. enter image description here The hillside here has a slope of about 45 degrees so its the same as a 100% grade.

  • 1
    I think you're right but in my case this was strava's route planning tool, i.e. entirely map based. My app has openstreetmap mapping but uses GPS for altitude. But a map should be accurate – Chris H Jun 3 '17 at 6:30
  • 1
    Strava route builder uses openstreetmap data, meaning roads mapped by GPS (and possibly barometer), so while it still won't have continuous elevation data, it might well have elevation data pinned to the road, averaged over a large number of users. This shouldn't be a bad match to what a single GPS user -- with a good signal -- sees, just less noisy. – Chris H Jun 7 '17 at 16:00
3

The people at Audax UK have given this some thought. They regard the gold standard as counting contours on an Ordnance Survey map (for those not in the UK, the output of our national mapping agency can be expensive, but is very good). This is rather tricky in areas with lots of features, such as towns, and is tedious at the best of times. It works best for sustained climbs in open country -- which is what they mainly want it for. So they've tried to find an automated system that's just as good. For track logs they recommend http://www.bikehike.co.uk (UK) and http://www.ridewithgps.com (overseas) which are both free. Bikehike works for routes as well (in the UK). As my original question was about building routes, I've tried a few tools for comparison to my own logs.

Test 1: 20km of undulating road and bridleways with around 230m of climb

I've recreated a ride I did today using Strava route builder and bikehike bikehike screenshot Strava needs to have 1km and 10m added to account for different start/end points (I don't start Strava stuff from home, even with privacy zones).

Both are a good match to my GPS log (which may actually use the barometer):

Method          Distance/km     Total climb/m
==============================================
IPBike          21.513          231
Strava track    21.4            233     (Strava's interpretation of IPbike data)
Strava route    20.8            207     (Recreated online)
Bikehike        21.44           204
OS Map      (not measured)      220     (Counting contours with a magnifying glass)

These all seem to be within a reasonable margin of error (bikehike was 12% less than my GPS, the biggest difference). Note that this route wasn't hilly, and didn't run in any steep-sided valleys, so lateral GPS errors will only have had a small effect.

I counted 5m contour lines on the 1:25000 OS map, using a magnifying glass. I'm surprised that at the first attempt I got so close to my measured data. In some places the road almost follows the contours and in other places the contours are obscured by other features.

Unfortunately Google doesn't understand UK rights of way very well, and can only get a small fraction of the off-road sections, so my comparison can't be extended to include that.

Test 2: 67.5km of road with around 470m of climb

I applied the same test to a longer road ride (but not one I plan to publish). Much of the ride is quite flat, with a couple of decent climbs. I do this ride every few weeks so have some average data. We have:

Method          Distance/km     Total climb/m
==============================================
IPBike          67.51           464
IPBike average  67.63           473.57  } of seven rides 
IPBike StDev    0.252           20.743  } over the same route
Strava track    67.51           445     (Strava's interpretation of IPbike data)
Strava route    67.6            557     (Recreated online)
Bikehike route  67.29           445
Google route    67.5            285

Taking the average measured data as a reference, all the horizontal distances are within 0.5%.

Vertically, bikehike is a good match to my data (and recall that AUK reckon it's a good match to counting contours). Strava route builder over-estimates by 18%, but Google under-estimates by 40%.

I don't have all the OS maps for this route at a sufficient scale, neither do I have the patience (and the contours might well be omitted in the urban sections).

Strava segments

Segments are created by users, and appear to be based on the originator's tracklog. Some are clearly prone to the error reported in Criggie's answer, as they have vertical jumps, as demonstrated by one I rode recently. In this case the error causes the segment to be called a Cat3 climb. It's nowhere near.

Conclusions

When building a route:

  • Strava might be a little generous -- good for bragging rights and gives a margin for error.
  • Google can seriously underestimate. I'd say that this is enough to be dangerous -- if you're pushing yourself according to Google and it's 40% under you're going to really struggle.
  • Bikehike seems good, but is mainly for UK riders
  • Horizontal is much easier than vertical
  • 1
    Well that turned into more of an exercise than I thought! – Chris H Nov 12 '17 at 18:54
  • Hilly rides e.g. always going up or down most things get fairly good numbers for. The hard case is the flatter rolling terrain. IpBike with my Z3 compact which has a barometer looses about a meter every time you crest a rise due to the way it filters things to stop getting climb on the flat. I consider it better than you can do with an OS map counting contours. – Ifor Nov 12 '17 at 20:07
  • @Ifor I've got the same phone, and I think you're right so long as the air pressure doesn't change too much -- I didn't expect to get anywhere near by counting contours in rolling terrain. I believe you're almost a neighbour of mine so you may know the area I used for testing today. I think Strava routebuilder rounds up -- my long test above includes the coast road between Cardiff and Newport. That's flat according to the OS map, feels flat, and IPBike finds very little change in altitude, but Strava finds a couple of metres her and a couple of metres there, adding up quite quickly. – Chris H Nov 12 '17 at 20:21
  • For those who don't know, @Ifor wrote the bike computer app I use (IpBike). I tend to follow a GPX route using it if I don't already know the way, and that's where this question came from -- of the services that can give me a hand-tuned GPX bike route, which can I believe? – Chris H Nov 12 '17 at 20:24
  • If you find a Strava segment with inaccurate elevation data, you can submit a support request and ask them to fix it -- they'll discard the original rider's data and re-do it from the map. I'm not sure why they don't have some sort of check that the original rider's data is plausible. I remember finding one that was something like a 25-mile time-trial loop which was pretty flat and should have zero net elevation gain anyway, since it starts and ends at the same point. But the segment claimed to begin with an 8000% gradient up to greater-than-Everest heights and never come back down. – David Richerby Jul 11 '18 at 16:29

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.