Option to keep elevation data of imported routeFORUMS HOME SEARCH FORUMS

That's very interesting Anders, thanks for sharing that analysis. I guess one good thing is that the underlying shapes are all generally the same, with the main peaks and troughs in the same place.

Elevation data is definitely a minefield! One of the only certainties, it seems, is that relentless pursuit of accuracy has the tendency to consume vast amounts of time for questionable benefit! We could certainly spend more time researching this, but then it means we're not spending that time on other things that people want us to focus on, like offline maps for example, so we have to consider the wishes of all our users. Having said that there may be some low hanging fruit that we can look at.

Your suggestion of smoothing obvious spikes is a good one, so we'll look into that. And one of the other things we're planning to make available is a threshold filter for calculating ascents - often other devices and apps ignore small changes in elevation that don't exceed a minimum threshold, whereas we don't currently apply any filtering. We're going to add a threshold filter to our Route Profile tool, so that people can choose their own ascent threshold and see what impact it has on the calculations. Once we have some feedback on the level of filtering that works best, we can look at automatically calculating a filtered ascent figure (to go alongside the raw ascent figure) when routes are saved. 

Strava's use of barometric GPS recording as a data source is an interesting one. We've had people contact us in the past adamant that their GPS recording was 100% accurate, as it had a barometric altimeter, but on further investigation is was recording an elevation of 90m right next to the sea! I think they may struggle with this approach given the varying and unknown accuracy of large numbers of different measurement devices. The bottom line is that no one source is 100% acccurate, whether it collected by GPS, satellite or any other means.

We've also done a little be of investigation into the Jaxa data source you flagged up. One of the difficulties is that we have no way of knowing whether this would actually be any better in practice than SRTM data that we currently use. The data is a Digital Surface Model (DSM), so elevation data is likely to reflect the heights of structures like buildings and trees for example, rather than the bare earth elevation. We'd certainly need more expert advice on this.  In one small test we've carried out (using the same algorithms we use now), the Jaxa elevation data gave us a higher ascent reading than the SRTM data. Of course, that may not mean it is less accurate, but it's interesting none the less. The other main issue with using Jaxa data, is that we would need a new server to use this, as we don't have space on our current server, so changing data sources like that is no small undertaking. 

Out of interest, do you have the route saved on Plotaroute that you used for your analysis? And do you have the calculated ascent figures for each of the different sources you looked at? It would be helpful to have these when we do the changes I mentioned above.

Thanks again for your sharing your insights.

[IMAGE REMOVED DUE TO SIZE]

For your information / curiosity, here's a comparison plot from what elevations you get from various popular platforms, compared to the +/- 3 meter survey I've made for our 116 km race course. Strava is interesting as they actually use uploaded activtities and merge them statistically (only those with barometric measuremets). As you can see although the vertical offset is wrong the shape follows the reference quite well over large parts, but then it fall back to blocky fallback satellite data here and there, so their algorithm needs some work. As it's a race and Strava is popular among our participants they have plenty of data to work with. In places where noone has ridden yet, my experience is that Strava provides very bad elevation data outside US.

The others use satellite data only. Ride With GPS seems to not have filtered away any noise from the data. Garmin is the least bad for general use in this region, although the smoothing means elevation gain is typically 15-20% lower than actual. Plot a route has too many spikes in the data exaggerating elevation gain quite a lot, say 50% more than actual. An improvement I think you at plot a route could make is to filter your data more to clean up spikes, it's probably better to have too smooth data (like Garmin) than having to noisy data with lots of false detail.

Thanks for the link Anders. 

Sure I understand. However, I would say that the elevation gain accuracy in Sweden is so poor that it's virtually unusable. As it is now, I export the route to Garmin Connect and see what they come up with, which also isn't great, but a fair bit closer to the truth as I guess they use more premium satellite data at least in my part of the world. By the way, I've heard that the Japanese JAXA freely available satellite data is considerably better than the NASA data most services base their global elevation on. Maybe something to look into. I do quite some work in openstreetmap and I have always wanted them to host a elevation service consolidating all the free data out there for any small (or big) company to use, but it will probably never happen, so each one is on their own.

Anyway, here's a link to the jaxa elevation: https://global.jaxa.jp/press/2015/05/20150518_daichi.html

Hi Anders - thanks for the suggestion and I appreciate the issue, but I'm afraid that would actually be very difficult for us to implement, given the way we currently handle elevation data. Also, I'm not sure we would want to create a situation where elevation data on the site comes from two different sources, as the elevations of different routes are then no longer comparable. The other issue is that we already have a very large number of requests on our Feature Requests list, so we're trying to focus on those right now.

Perhaps a niche request, but should be relatively easy to implement, I hope:

Background:

Elevation gain accuracy in plot-a-route is limited as there's only satellite data available. In my part of the world (Sweden), the elevation profiles are very inaccurate.

When I ride a route with a cycling computer that has a barometric GPS the relative altitude is quite good. It may drift 5 - 30 meters over the course of 100 km, and the absolute value can be 30 - 100 meters off, but the accuracy is many times over better than satellite data.

In addition I've made myself a Python script that smartly combines several barometric GPS activities and calibrates them towards LIDAR fix points - so for important routes, like races I organize, I can make a really high quality GPX file with a very good elevation profile.

While I can distribute the raw GPX file it would be nice if I could disctribute it via plotaroute, but if I upload the GPX file to plotaroute, the elevation data is replaced with the satellite basemap, so it's a no-go.

Feature request:

So what would be nice is a checkbox "Keep elevation data from imported GPX". It would only need to work when you don't snap the data to roads, ie keep the imported route unchanged.