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:
Distance | Elevation | Total Ascent (10m sampling) |
Total Ascent (50m sampling) |
0m | 10m | 0 | 0 |
10m | 12m | 2m | |
20m | 10m | 2m | |
30m | 10m | 2m | |
40m | 14m | 6m | |
50m | 11m | 6m | 1m |
60m | 10m | 6m | |
70m | 10m | 6m | |
80m | 8m | 6m | |
90m | 14m | 12m | |
100m | 12m | 12m | 2m |
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.
Elevation Interval (m) | Total Ascent (m) |
10 | 1349 |
20 | 1274 |
30 | 1219 |
40 | 1156 |
50 | 1132 |
60 | 1081 |
70 | 1052 |
80 | 1014 |
90 | 977 |
100 | 969 |
150 | 833 |
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:
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