Richard,
I am on holiday in Slovenia following routes I have ( as usual) planned on cycle.travel. I have completed two routes now and in both cases the total ascents ( as given on the elevation profile) are significantly at odds with my garmin totals ie 70% of the garmin total for one and a v surprising 50% for the other. Obviously, this causes some issues with accurate day planning, although at least they were underestimates. Do you know why this should be?
Regards
John Buswell
Comments
Sorry, I meant ‘overestimates’. ie cycle.travel’s figure was higher than the ‘actual’ garmin figure
Regards
John Buswell
Elevation calculation is a bit of a dark art but it shouldn't be that far askew. Could you give me a link to the route?
Richard,
Thanks for replying. Here is one of them. The other to follow.
John
https://cycle.travel/map/journey/116912
And the other.
Thanks
John
https://cycle.travel/map/journey/116887
Is your garmin a model that has a barometric altimeter?
https://www.dcrainmaker.com/2010/05/understanding-sport-device-gps.html
The type of elevation readings is definitely a consideration, yes!
The other issue is that cycle.travel uses a grid of elevation data at a resolution of 3 arc seconds (that is, 1/1200th of a degree of latitude or longitude). So when it’s calculating the elevation for a route, it looks up each point on a grid, and works it out by averaging the nearest points.
That’s absolutely fine for most places, but it does struggle in the Alps, where the valleys can be very steep-sided. If the road is close to the side of the valley, then sometimes it will think it’s further up the hill than it actually is. The result is that it sees lots of little ups and downs that aren’t there. All these ups and downs conspire to inflate the total climb.
I’ve been looking at this for a while to work out how best to tackle it. Just smoothing out the graph would be simplest (and we already do this a bit) but might lead to underestimating the climb in other places. More detailed elevation data is available for some places (a 1 arc second grid), but increasing the amount of elevation data nine-fold may cause the server to run out of memory.
I have also wondered about always taking the lowest of the four surrounding grid points in hilly regions, but haven’t yet had chance to experiment to see how well this will work.
I’ve adjusted the smoothing upwards a bit more and the results seem to be better. I’ll keep looking at it.
Richard, ( and Graham)
Thanks ever so much for looking at this so quickly and getting back to me. As ever your work and cycle.travel is greatly valued.. and much used. As regards Graham Bowers question I have an Edge 820, which has a barometric altimeter. Leaving aside the relative merits of that feature I have found the Garmin’s elevation ‘reporting’ to be ‘reasonably’ accurate, but only with reference to data from other devices on established routes in the UK.
Thanks again
John Buswell
PS out of the Julian alps now so will check the data with interest
Richard,
I have just completed this route in S Slovenia:
https://cycle.travel/map/journey/117420
Pre your ‘tweaks’ Cycle.travel was estimating 1400 m of ascent. Post it was estimating 900m . My Garmin recorded 935 m. So, you were ‘on the money’. Thanks
John Buswell
I’ve tweaked it some more (well, ‘tweak’ is a bit of an understatement – open-heart surgery really). It’s now showing 926m for that route. It’s still a little bumpier than I’d like in the river valley section (looks like an amazing ride, by the way!) but generally better.
In may and june I created some routes through the French Alps, and noted all total elevation estimates down. When I now open the same routes, the estimates are quite different; all much lower: a route that was supposed to climb a total of 3000 meters, now shows 1800; 3200 has become 1700; 3300 - 2200; 3500 - 1800; 3800 - 2100, etcetera. The same applies to routes in the Swiss Alps and the Vosges mountains, although the differences there are somewhat smaller. This sudden change seems to have occurred in september. What happened?
It’s a complex story but, essentially, the elevation data works on roughly a 70m grid, so in narrow Alpine valleys it would often give a wrong reading. This meant that it would count lots of short ups and downs when in reality the valley was flat or had a slow incline.
If you want to see the effect, take a route like https://cycle.travel/map?from=45.3471,6.0962&to=45.3235,6.0881, open the elevation profile, and then drag the start point without letting go of the mouse button. You’ll see that the raw elevation data causes lots of bumps which in reality aren’t there. When you let go of the button, cycle.travel does a bit of extra processing (a complex, adaptive form of smoothing) and you get a more realistic graph.
Previously the smoothing was fairly rudimentary and didn’t work well in the Alps. It’s now much more sophisticated and has some special handling to cope with steep-sided valleys. Getting the total elevation figure right is a bit of a dark art but it should now be more accurate than it was previously. Sorry for any confusion!
Hi Richard, thanks for your answer (and your awesome site). However, something is not right, at least in the Alps. If I for instance plot a trip over the Col de la Madeleine and the Col du Glandon, the total elevation is given as 2300 meters - while these cols are, respectively 1600 and 1450 meters - as is accurately reflected in the elevation profile. The total calculated does not at all match the accompanying profile. Any thoughts?
This is the route: https://cycle.travel/map/journey/128159
Hmmm, yes. I’ll take a look…