Option to keep elevation data of imported routeFORUMS HOME SEARCH FORUMS

@Paul

You can see the quality of Strava's elevation in the first graph posted in this thread. It's clearly using the technique to process the reported data from users (and they also claim to do so), but their algorithm is so far not that great causing errors much larger than necessary as seen in the graph. It also takes quite a lot of rides, probably from many different riders, and a lot of waiting before ride-derived elevation data appears. In the long term Strava could be the best alternative for this application, but so far the file I have derived from gathered rides is of much higher quality than what I get out of Strava at this particular route.

@Anders Torger

Since you've discovered that Strava has good elevation data, why don't you change your "distribute the raw GPX file" desire from "distribute it via plotaroute" to "distribute it via Strava"?

Wholly relying on SRTM for elevation currently is, for the lack of a better word, unacceptable. There are just too many things that rely on the elevation data to not do better. One of those things is the virtual partner advanced settings. Being able to adjust the virtual partner is the only reason I'm a premium member of PAR. Lately, I've tried to tweak the settings to better model my riding. The PAR elevation data quality makes my task impossible.

The reason I can be so certain about my reference curve is quite accurate is that I have over 80 high resolution LIDAR fixpoint retrieved from the local government surveyor database over that course that I can anchor the barometric measurements too, and I can see the correlation of those measurements is very good once anchored.

However, the fewer fixpoints one have, the harder it becomes to merge the barometric measurements as there is quite significant drift over this 4 - 5 hour ride and altimeters have some lag that vary, so there is drift horizontally too.I was expecting vertical drift, but the lag horizontally which can be as much as +/-80 meters I did not know about before this investigation.

Many bike computers can nowadays present info about upcoming climbs, so you can see how steep a climb is and how long it is left.I think garmin calls their feature "ClimbPro". It's pretty cool, but here in Sweden its basically unusable as the elevation curves you get from typical services is just way off where the climb starts and ends.

The reason I want nice elevation profile for my race is to be able to provide this "service" to the participants that they can use the climb feature of their bike computers and trust what they see.

Reliable Permit Solutions, LLC

I added proof of concept code here to anyone interested. I've used this to calculate a elevation curve for a local race I'm organizing, data from that is included as a demo:
https://github.com/atorger/gpx-elevation

Way beyond my knowledge or need, but makes for very interesting reading, Anders!

Thanks for all the additional information Anders, that's very helpful.

Here is another plot for curiosity, it shows the raw measurements from various bike rides with barometric GPS (no post-processing corrections applied), some are shorter segments as they haven't followed the course all the way round. This is basically what Strava uses as input, and also what I have used to derive my reference. This plot also shows all the LIDAR fixpoints I have been using to properly anchor.

[IMAGE REMOVED DUE TO SIZE]

What you can see here is that with few exceptions, the shape of the barometric measurements track quite well, and at this zoomed out scale there's not too much drift either. However, the absolute elevation is often way off, which is expected as barometric altimeter has no notion of absolute value. Even with this it seems like most of the measurements are quite close in absolute level as well.

[IMAGE REMOVED DUE TO SIZE]

Let's look at a zoomed in section:

[IMAGE REMOVED DUE TO SIZE]

Although noise differs etc, the similarity is quite remarkable. When I have derived the reference I haven't just anchored them and made an average, but identified the largest group of curves with high similarity and take an average from that, to avoid taking the outliers into account, because there are always a few of those. I have in this example so many anchor points that my merging code doesn't need to do much guesswork. Without any fixpoints there would have to be much more guesswork but it still seems possible to get quite close to the reference as there is a clear cluster of tracks around that.

A couple of other observations, which you probably know about, but anyway here it comes:

Ride With GPS has introduced a flatten-elevation feature so that users that want can manually correct the elevation at tunnels and bridges. Actually this information could be automatically retrieved from openstreetmap (tunnels and bridges are marked with tags), not sure if this is a good API to extract them though. They do not support to replace the elevation completely from an imported file though.

Apart from not detecting bridges and tunnels where they exist, a typical issue with the elevation databases is that resolution is not high enough in terms of alignment. 100+ meter spacing or so would be quite okay if it was just along the road. However when a road passes nearby a mountain with somewhat steep sides it's often the case that the elevation database have the mountain elevation smeared over a bigger area so it seems like the road is passing over it rather on the side, the false peaks around 12 km in the route is probably that type of issue. This is impossible to do anything about other than having higher resolution data. Fortunately it doesn't happen on all routes.

I'm a mapping nerd, openstreetmap contributor and a software engineer, plus a race organizer, so I'm naturally interested in this topic, but I also do understand that the value-add is not huge compared to many other features that are much easier to implement, so you have my full understanding. The big data approach Strava is doing is super-interesting from a software engineering standpoint, but they are of course in a special position in terms of data gathering and probably development resources. They still seem to have quite some way to go. Garmin could do the same type of processing as they have a huge wealth of data from hardware they know the exact capabilities of, but they have always been weak on the software side.

The reason I can be so certain about my reference curve is quite accurate is that I have over 80 high resolution LIDAR fixpoint retrieved from the local government surveyor database over that course that I can anchor the barometric measurements too, and I can see the correlation of those measurements is very good once anchored. However, the fewer fixpoints one have, the harder it becomes to merge the barometric measurements as there is quite significant drift over this 4 - 5 hour ride and altimeters have some lag that vary, so there is drift horizontally too. I was expecting vertical drift, but the lag horizontally which can be as much as +/-80 meters I did not know about before this investigation.

Many bike computers can nowadays present info about upcoming climbs, so you can see how steep a climb is and how long it is left. I think garmin calls their feature "ClimbPro". It's pretty cool, but here in Sweden its basically unusable as the elevation curves you get from typical services is just way off where the climb starts and ends. The reason I want nice elevation profile for my race is to be able to provide this "service" to the participants that they can use the climb feature of their bike computers and trust what they see.

I have no detailed knowledge of JAXA myself, I just have heard people speaking about it a bit, I'm not sure if any of the popular services actually use it. I was not aware that it included buildings and trees, that's a bummer. But is it really *that* high resolution that it would make a practical difference?

Here's my reference GPX file: https://www.storumangravel.se/files/storuman-gravel-116km-v1.gpx
Same route at plotaroute: https://www.plotaroute.com/route/1256451?units=km
Strava: https://www.strava.com/routes/2997036907876487582
RideWithGPS: https://ridewithgps.com/routes/40870575
Garmin Connect: https://connect.garmin.com/modern/course/54891056

Same area as presented in Swedish government where one can click and get LIDAR fixpoints (not 100% sure this website is accessible abroad). The high resolution LIDAR data as shown in this map is not open data, but there is lower resolution that is. "Stealing" 80 or so mouse clicks from the map for a GPX to a non-profit race like I've done here won't land me in jail though, I hope :-):
https://minkarta.lantmateriet.se/plats/3006/v1.0/?e=591317&n=7222385&z=14&mapprofile=bergodal&background=3&boundaries=false

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.