Ascent calculation is inaccurateFORUMS HOME SEARCH FORUMS

Hello,

I realize that the calculation of the overall ascend is inaccurate and always overestimating (even by a factor of x 2) the real elevation gain.

Andrea

Hi Andrea - I'm happy to look into this if you can give me an example but I suspect the difference between our calculations and what you are comparing it to is down to sampling frequency.  

The total ascent is calculated by adding up all the height gains at regular intervals along the route. Taking elevation samples at more frequent intervals will tend to result in a higher total ascent than taking them at less frequent intervals, but is arguably more accurate.  We sample elevation readings every 10m, so our calculations should be very accurate. I'll give you an illustration:

This 100m route has a total ascent of 12m if you sample the elevation every 10m but only has a total ascent of 2m if you sample the elevation readings every 50m. For this reason, it is usually not possible to compare total ascent calculations from different sources due to differences in calculation methods.

Hi,

I have uploaded the track that is in my route section ID16448 "Oltreserchio 2014" - According to mu Garmin Edge 705  the overall elevation gain for the route is 819m, once uploaded the track on plotaroute it calculates 1349m - The 819m is pretty accurate as is in agreement with other bikers recording the same route. An error of 530m over a record of 819m total ascent seems to me not just related to the sampling.

I'm afraid elevation data captured by GPS devices is notoriously innaccurate.  This is partly to do with the fact that GPS devices need to have a clear view of more satellites to be able to measure height than distance.  Even Garmin's own advice is that "it is not uncommon for satellite heights to be off from map elevations by +/- 400 feet" (see here).

Ultimately it's hard to explain the difference in calculations without knowing the raw elevation readings that your Garmin collected and what formula it uses to calculate the total ascent.  However, I will have a closer look at the route you mentioned to see if there is anything obvious going wrong with the calculations.

John

Hi John, you are right, elevation data captured by GPS are notoriously inaccurate, this is also what I experienced using my Garmin Forerunner 305 in the past.

The Garmin Edge 705 I have used for this recording has a barometric sensor and it is quite accurate when calculating total elevation gain.

Ultimately if you upload the same GPS track data on software such as bikeroutetoaster or Strava, and you let the software recalculating the elevation gain there is quite an agreement with the Garmin Edge 705.

Andrea

Hi Andrea - I think you're probably right in that the 705 can more accurately record elevation than GPS models that rely solely on satellites, however I think even models with barometric altimeters are prone to errors from changes in the weather and pressure systems.  Of course that doesn't explain why our total ascent figure differs from that of other applications.  I suspect this is down to sampling frequency - as you can see in the example below, a small difference in sampling frequency can make a big difference in the total asscent.

Would you be able to email me a sample GPX or TCX file that I use to check and compare the raw elevation data from the GPS device?  I'll contact you directly with an email address to send this to.

Thanks for your feedback on this.

John

Hi, as soon as you send me your email address I will send you few tracks.

I have checked again the elevation profile with plotaroute versus my barometric recording and it seems to me that the overestimate elevation gain is due to the data sampling too frequent: With plotaroute the atimetry profile is looks very irregular (like going continuosly up and down by few meters) this over the entire route could end up with an overestimated elevation gain. To get a smoother profile I would suggest to reduce the sampling frequence.

Andrea

P.S. You did a great job with your web site, the autoplot option is very stable and reliable even when following small trails on OSM, and you have create a lot of useful features. This is the web site I was waiting for!

Hi Andrea - I've sent you an email.  If you didn't get it can you maybe check your spam?

Thanks for the nice feedback about the site BTW. 

I've had a further look into this with your Oltreserchio 2014 route (although if you can send me the raw data file too that would be great). There is indeed a big difference in Total Ascent depending on the interval between the elevation readings.  The following table shows how the Total Ascent reduces if elevation readings are taken less frequently.  

I suspect that partly explains the differences in Total Ascent values between different devices/applications, particularly if the Garmin device is set to use smart recording, which would only record an elevation reading when your direction or pace changes.  I would argue that a higher sampling frequency is more accurate though.

However, I think there may be another factor at play here.  From the research I've done it appears that Garmin (and some other applications) only count an increase in elevation if it is greater than a certain threshold.  I believe this is done due to allow for the inherent inaccuracies in GPS devices. This effectively smoothes out lumps and bumps along a route which we should really count as part of the Total Ascent if the data could be relied upon. It would also appear that some people are reporting that a side effect of this filtering is to understate the height gain on shallow gradients - for example, if you climbed from a height of 10m to a height of 100m (theoretically an ascent of at least 90m) the Garmin device may discount sections that are filtered out resulting in a total ascent that is less than 90m, even though you went from 10m to 100m.  I'm not sure how common this is - this was just one report that I read.

So, I think the differences in Total Ascent between the calculations on plotaroute and other devices/applications are probably down to:

• device recording inaccuracies (satellite visibility and weather changes)
  
  
• filtering/smoothing of elevation gains
  
  
• infrequent or irregular recording of elevation readings

I'm afraid I would still hold that our calculations are accurate, as we sample elevation data at very frequent and regular intervals, apply no filtering or smoothing and we use an elevation data source that does not depend in local recording conditions.

Obviously it all boils down to how you interpret the data at the end of the day!

Hi John,

I have been thinkin to your analysis, and I believe it is technically correct.

Said that, I belive that for sport cyclist filtering data should be considered: e.g. If you ride on a road in a flat area that has irregularities and the road goes up and down by 1m say 100 times, you will record 100m total ascent. This is technically correct but there is a big difference between this and 100m in a continuous ascent. A 1m ascent could require no additional effort, only a small decrease velocity at the top of 1m that would be mostly recovered going down.

In other terms for a sport analysis I would filter to the maximum elevation gain that a cyclist could overcome simply with its own inertia without putting extra effort in it and therefore I would suggest to filter ascent smaller than 3m.

For cycling activities I would suggest to update the elevation profile only when it changes for more than +/- 3m. While I would maintain your current criteria for walking routes

Does it make sense to you?

Regards

Andrea

Hi Andrea,

Thanks for your further suggestions on this - I understand the points you are making.  I don't think we would want to add smoothing into our default elevation calculations - we would rather give people the most accurate 'unfiltered' data and then allow them to apply filtering or smoothing themselves if they wish.  We are planning to introduce some additional tools for more advanced analysis of elevation profiles at some point, so will hopefully be able to build in options to ignore low gradient or low value ascents when calculating the total ascent in these new tools, with the ability to choose the level of filtering that you want.

John

Thank you John, that tool would be great!

Andrea

Hi,
I have just started to use plotaroute and find a lot of nice and usable features with this site which I would like to take advantage of.
I though also find that your measuring of altitude differs quite a lot from the real world.I have tried making a route in PAR I biked this summer and different on 49 km are 350 mtr from PAR to real world.
I have made the same route in RWG and this only differs 12 mtrs.

https://www.plotaroute.com/route/136253

I know that RWG had the same issue some time ago but this have been fixed but as far as I understood it was not that easy to make. (I had a direct correspondance with Cullen regarding this)

I have also tried to do Alpe d'Huez in PAR and this also is quite some mtrs out of the officiel data! (And I assume the officiel data must be the correct ones)

Have you had further thoughts regarding this since this thread ended last year?

Regards

AllanH

Hi Alan,

Unfortunately there is no correct answer when it comes to calculating the Total Ascent.  You can get a different figure each time by having different distances between the elevation readings, but that doesn't make each answer wrong.  Longer distances between elevation readings will have the effect of smoothing out bumps and dips, so tend to result in lower Total Ascent.  We take readings at regular 30m intervals by default (unless the route is very long), so probably more frequently than other sources you might be comparing to.  GPS devices can be notoriously innacurate when it comes to calculating Total Ascent.  Not only do they sometimes gather quite inaccurate readings, they also take readings at irregular intervals, so they are not good to compare with.  Sometimes a barometric altimeter can help with accuracy but when we looked at the example quoted below, where a Garmin device with a baraometric altimeter was used, it was recording elevation readings of 63m at sea level, so quite a long way out.

You can see how the Total Ascent changes as elevation readings are sampled less frequently by having a look at your route with our route profile tool - drag the Elevation Interval slider on the right to increase the distance between each elevation reading and see how the Total Ascent changes in the data at the top.

John

Hi John,

OK I see what you mean. I dont know what the others are doing but I can surely try to find out.
Can I ajust this somewhere when I'm creating a route?

It though seems a bit strange to me that the total ascent in la Marmotte this year was 7310 mtrs (in reality)

AllanH

I was just looking at the same thing, I created a route here and then exported the GPX file. Plot a route estimates the altitude at 3300m, RWG estimates it at 2100m and actually riding it gives 2100m (Garmin 705 with barometric altimeter). I am guessing the underlying map data is a bit off.

Other than that this site is brilliant and has become my goto place for mapping out new routes.

George

Hi George - glad you're enjoying using the site.  Unfortunatley there is no "right answer" when it comes to total ascent, as it depends on the sampling interval (see my post below on 9 Nov 2015).  Less frequent sampling of elevation readings will give a lower total ascent as it smoothes out lumps and bumps. I think we sample more frequently than most.  Neither figure is wrong - they just need to be interpreted in context, so you can't really compare figures calculated using different sampling intervals.

John

Thanks for the quick response John

Unfortunately I don't think that's quite right. My Garmin is set to record a point every second, so on an avrage hill climb that would be 3-5m apart (I am not the fastest climber out there). This is a far higher sampling rate than what is present in any publicly available mapset and should in turn result in the highest elevation reading. The reality is that Plot a Route comes in roughly 50% above that (and this is consistent for all routes I've created or looked at in this area).

So I still think there is an issue with the underlying elevation data provider and it would be great if that was addressed at some point in the future.

We'll certainly look into it a bit more but I think Garmin devices ignore readings with small elevation changes when calculating the total ascent due to assumptions about accuracy levels of the data, effectively applying smoothing to the data.  So although it may be collecting data every second, this data isn't necessarly all used in the calculation of the total ascent figure.  Also, by collecting data at time intervals, it will be at varying distance intervals, which creates another anonomly.  And if the time interval is very short (e.g. one second), then changes in elevation may also be very small and may be discounted in calculations.

It might be quite hard to get to the bottom of it without having access to both the raw elevation data and formulae used by different systems.  I'll try to do some research on it.

John

Hi,

I believe plotaroute is processing correctly the data, the point maybe is in the accuracy of the elevation data and contour lines in the maps itself.

As an example if you are analazing data on a flat route in the mountains with steep gradients on each side of the road, a small error when plotting the road on the map (even few meters each side) would generate a large elevation change although the road is flat. When plotting in areas with contour elevation lines very close each other i.e. with considerable gradient, this error could become significant. 

Regards

Andrea

From a quick bit a research it appears that other sources may indeed ignore some elevation readings within a certain threhsold, effectively applying smooting to the data collected. For example, Strava's site says

"A gain must exceed a threshold in order to be counted. The elevation data used for calculating gain is smoothed before elevation gain is calculated in order to reduce noise.  If you are riding or running in a very flat area, and none of the individual climbs on your activity exceed that threshold, it is possible that Strava will list a total elevation gain of 0ft, even if the elevation profile is not totally flat. This is an unfortunate side effect of the thresholds necessary to reduce noise on the majority of Strava activities."

I suspect Garmin does the same - if anyone can confirm this I'd be interested to know.  We don't ignore any readings or do any smoothing, so all lumps and bumps along the route are counted in our total ascent calculations, which would explain the higher figure.

John