ascent accuracyFORUMS HOME SEARCH FORUMS

Hi,

With it be possible to use best  avaiable data as they do on GPS Visualizer DEM elevation database coverage ?

When I compare to this and other sites, Plotaroute most of the time get very generous ascent data :-)

Cheers

Peder

Hi Peder - you can't really compare ascent data from different sources. Please see our FAQ on this: Why does the Total Ascent figure for my route differ from figures calculated by my GPS device or other applications?

I understand the point about different sources but Plotaroute values are both wildly different to those I get in Strava and are simply unreasonable based on many years experience cycling. For example, my route today is credited with 50% more ascent than in Strava and is not credible. Plotaroute also indicates I cycled up a 30% gradient. Again, this is not reasonable (in fact it's not possible!). You can't dismiss this as simply being about different sources. Plotaroute's calculations of ascent and of gradients are very questionable imho. 

Without knowing exactly how Strava calculates its ascent figures it’s impossible to explain any differences. If someone has this information we’d be happy to look at it. That’s why we recommend that you don’t try to compare figures from different sources like this, as it’s meaningless to compare two figures calculated in different ways. When you look at the ascent calculation for a route, it only makes sense to compare it with the ascent figures for other routes calculated on the same system. 

Having said that, if there are errors in our calculation methodology of course we’d like to fix them, but past efforts to look into this haven’t identified any issues, so this isn’t something we can justify allocating further resources to right now, given the large number of other feature requests that people have asked us to consider. However, if any of our users have experience in Digital Elevation Models and programming skills and would be interested in volunteering to carry out a review of our approach and algorithms, please get in touch.  

I have been using an application, Tracklogs (an OS based system, now defunct) since 2008, and like Martien, I have effectively calibrated it against my cycling experience. I am also in agreement with admin “it only makes sense to compare it with the ascent figures for other routes calculated on the same system”.

When I have compared this with OSM, using different apps, over many rides, I have concluded that they underestimates a day's ascent by about 15-20% compared to Tracklogs. Strava gave about 20% under. It’s only rarely I get a monster difference that shows clear error.

OK, that’s just my own calibration.

As a matter of interest, I had this reply from Strava Support in 2020: Elevation data on Strava is smoothed to take out noise— we have a 'threshold' where climbing needs to occur consistently for more than 10 meters for activities without strong barometric data or two meters for an activity with barometric data before it is added to the total elevation gain.

And it would appear that Strava is trying to build a global elevation database https://support.strava.com/hc/en-us/articles/115000024864-Announcing-Strava-s-Elevation-Basemap

My overall conclusion is that “ascent” should be taken with a pinch of salt. Elevation is a minefield!

Thanks for sharing that Mark - that's very interesting.

The percentage difference between applications will of course depend on the nature of the route, as well as the method of calculation itself. For example, if one application applies smoothing and another doesn't, there will be a very large difference in the ascent calculations for a route that has lots of small undulating changes in elevation but very little difference for a route that is more consistently up or down. Hence, why people often question the calculations when trying to compare figures calculated by two different applications. 

Take the following example of elevation readings: 24, 25, 24, 25, 24, 25, 26

We would count the total ascent as 4 ((25-24) + (25-24) + (26-24)), but an app that applies smoothing may ignore the smaller changes and only count it as 2 (26-24). That's a big percentage difference!

From reading what you shared about Strava's ascent calculations it says "We smooth the data before calculating gain and depending on the resulting data, elevation changes may not be enough to pass a threshold that we use for determining whether or not you have gained elevation."  This means that small fluctuations in elevation are not being counted. We don't apply any smoothing, as we prefer to count all changes in elevation, but we also offer a Route Profile too that allows you to apply different levels of smoothing yourself. Neither approach is wrong - but the important thing is to only compare figures calculated in the same way.  

:)

I think that comparing Plotaroute results with those obtained with other tools may be a red herring anyway. The question should be how closely do Plotaroute calculated gradients and ascent figures match measurable, empirical values obtained from the real world. If I took as my reference, a national cartographer's maps (e.g. in the UK, Ordnance Survey) and cycled or walked between points on a number of adjacent contour lines representing a continuous ascent, the total ascent should be the difference between the highest of the countour lines and the lowest as far as I know. What would Plotaroute's calculated ascent be? This is a rhetorical question but hints at the kind of testing the tool should be put to, with or without help from the community.

A few weeks ago, I crossed the Swiss Alps on my bike, with one stage comprising Fluelen to Andermatt. This is generally described as having an average gradient of 8%. Yes, I note the word "average". But the route I created by uploading my recorded GPX file indicates that the steepest part has a 44.4% gradient. This is simply not credible. Trust me, not only is this not credible in a world where the Guiness Book of Records lists the steepest road in the world as having a gradient in the 30% range but.... I am no spring chicken and I would not be able to walk up a gradient like that, never mind cycle it! In fact I think I'd need to dig out my climbng gear for a 44.4% incline!

Surely this example alone should indicate something is not right here and warrant someone taking a look and doing some real world testing? 

It doesn't really matter whether it's another tool or a conventional map, you're still trying to compare two different approaches. Taking your example of a map and contour lines, you can't just add up the contour lines as there may be drops in elevation between them. This would lead to a greater ascent figure than simply adding the contours lines together. 

I'm afraid there will always be occasional situations where a gradient figure may look strange, but this could be for a number of reasons. It could be that the path you plotted may not match exactly what you did in the real world - if you ride next to steep hill for example, like there are in the Swiss Alps, a slight misplacement of the route when plotting could position it on the hill instead of on the path. Also, most global elevation data models don't have data points that follow paths - they use a system where the world is split up into squares, so the elevation at a point on a path will depend on the elevation around it in that square.

I think you're looking for a level of infallibility that isn't achievable, at least not with a low cost tool like ours. Elevation data should only be used as a guide and you'll get most value from it by comparing figures calculated in the same way.

I didn't plot the Swiss Alps route, I recorded it using a GPS device.

I don't agree with your opening statement. There has to be a reference which is regarded as "correct" and then how well a tool performs depends on a comparison with that reference. A national cartographer would be an obvious choice of reference. In my example, I was intending to describe a hill climb which has no descent in it at all in which case subtracting contour lines would give you the total ascent.

I don't think cost has anything to do with it either. I'm just a user attempting to highlight an area of the tool (which generally, I rate very highly) which could be improved. It feels like minds are rather closed on this issue though. The details are perhaps obscuring the basic point. Elevation and ascent figures produced by Plotaroute are often suspect.

I'll leave it there.

Elevation and ascent figures produced by any application I've used are sometimes suspect.

We do appreciate your feedback and certainly aren’t dismissing the concern, but we’ve already spent quite a bit of time looking into this issue in the past and haven’t managed to identify any major problems with our calculation methods, so that’s why we’re reluctant to spend more time on it. 

People have often cited GPS recordings as “correct” when GPS figures differ from ours, but every time we’ve looked at examples, the GPS recording has been flawed. Often there are gaps in the recording or the recorded positions are clearly inaccurate. One person was adamant that his GPS was 100% accurate as it had a barometric altimeter fitted, but when we looked at the data it was recording, it was showing him 90m above sea level when he was next to the sea! 

Having said that we also accept that our own calculations are not without flaws, but unfortunately every project has a cost and we have many thousands of users who all want us to focus on different things, so we have to choose what we spend our time on based on what we think will make the biggest difference for the majority of people.  As much as we would love to improve our elevation data, we’ve come to the conclusion that we’re chasing our tail by trying to make our calculations match those from other sources and that we’re better off spending our time on other things at the moment. 

At present our top priority is to develop a mobile app for offline navigation, so that’s where our time is currently focused, but I’ll repeat what I said below, if any of our users have experience in Digital Elevation Models and programming skills and would be interested in volunteering to carry out a review of our approach and algorithms, please get in touch.

OK, no worries. Thanks for listening. I'm certainly not dismissing the complexity either. Good luck with the mobile app :-)