Altitude gain correction

Good day Andrea,

On planned routes is, of course, applied only SRTM source for elevation, but no filter. Elevation from HGT files is already interpolated from more values around a required place, so there definitely is no filtering needed. Huge difference you write about after planning by BRouter is really interesting. May you send me a GPX of such planned track? I would like to look at it.

Problem with an application of the filter AFTER track is saved is in a sequence of actions in app. Received altitude from GPS firstly pass over everything set in "Altitude manager" and in the second step if is send to services that use it, like track recording. So, recorded data are already modified with all these offsets, filters, srtm optimizations etc. and should be quite complicated to change this.

Menion

Hi Menion,

here is a route generated with Locus and Brouter offline service.

Statistics in Locus show 2136 m gain, 2812 m loss

Same file opened with Orux shows 1093 m gain, 1755 m loss

Same file opened with Routeconverter on PC shows 3633 gain, 4316 loss (not corrected)

The reason I believe is because it has ~ 3200 waypoints with approximated height  in many cases by about +1m or -1m with regards to the previous point. Which increases a lot altitude gain. I deem the cause  is that a path follows the real shape of the terrain while SRTM tiles approximate it by squares and average height within the square. It’s like if you had to go up and down a lot of single stair steps instead of walking along a flat trail.

If I am correct, in my view some possible work around could be (is this the way your filter works??):

1)In altitude gain/loss calculation reduce the number of used waypoints: use a waypoint every 10 (generically every # variable number) or every x(TBD)  m

2)Group close waypoints in batches and average their height, then calculate gain/loss of such batch against previous. Example:

Wpt1     wpt2     wpt3     wpt4     wpt5     wpt6     wpt7     wpt8     wpt9     wpt10   wpt11   wpt12   wpt13   wpt14   wpt15                 wpt16   wpt17

                |---------------------------------------|         |-----------------------------------------|     |------------------------------------------|

                A1 = Average height of wpt2-6                 A2= average height of wpt 7-11                               A3= average height of wpt 12-16

Calculate gain/loss  of wpt1 – a1 –a2 –a3 - wpt17

Points in batches should be sufficiently close to avoid loosing real gain/loss information (use also variance/or some regression dispersion to choose batch dimension???)

3)Use other similar concept algorithms to minimize the small altitude errors, whether generated by GPS or by SRTM

I hope this may help

Many thanks for your job

Andrea

Da: Locus Map [mailto:locus.map@asamm.com]

Inviato: 20 aprile 2018 08:30

A: Andrea

Oggetto: New Comment in "Altitude gain correction"

Hello Andrea,

thanks for a track. As I wrote, on planned routes is not applied any filtering. It is because every computed elevation value is interpolated by bicubic interpolation from 16 points around. So we may expect, that such value is already quite filtered. Anyway as I see, elevations for your route are jumping quite a lot as you wrote.

I tried two more web services ( http://utrack.crempa.net/ , http://www.trackreport.net/ ), where one return a lot higher values, second a lot lower values. So at least, Locus Map is in the middle :).

There is a few more topics where people complain on computed results by Locus Map app, so I collect them and will work on it a little later. For now, thanks for suggestions, we'll write you here when some changes happen.

Hi Menion,

like Andrea, I also noticed that elevation filtering for planned routes is a little off. When I plan routes in Locus with Brouter the shown elevation data is (most of the time) several times higher than with other route planning apps (like OSMand or the brouter web edition). In areas I personally know, their values unfortunately seem way more plausible than Locus' values so I expect it to be the same in other areas.

As some time has passed since Andreas post, has there been some development in the last 1,5 years? I would really appreciate the possibilty to at least manually filter the computed values (even if the values for the bicubic interpolation are already filtered, like you stated above).

Thanks and keep up the good work!

Hello Hans,

if I remember correctly, no changes were made in the algorithm used in Locus Map. If you read a few posts we exchanges here, you may see that problem is quite complex and I think there won't be a single universal solution.

Result highly depends on the area where you plan a route. In more flatty areas, results should be very precise. In more and more alpine areas, results will be worst and worst. May you post here your planned route and also values Locus Map gives you vs what you expect? Thanks

I took a look at Andrea's track and in my opinion it's an ideal testtrack for analyzing methods of calculating and filtering altitude gains. Alpine terrain, narrow serpentine roads - each divergence of a trackpoint in the horizontal postition could results in a huge aditinional vertical error.

I noticed that Andrea's track ist based on the Openstreetmap-streets, so it's NOT a recorded track which could suffer of horizontal jitter due to bad GPS reception. And I took the best available elevation (LIDAR) source of the region, and used them to fill the elevation of the trackpoints. The resulting elevation gains/losses calculated with Locus:

LIDAR-DTM 3": - 2728 m / + 2048 m

LIDAR-DTM 1": -2075 m / +1390 m

the approximate "real" values by analyzing by eye of the elevation-diagram should be about - 1800 m / + 1100 m

So the first important thing is: Use as exact elevtion files as possible, if available LIDAR-1". No SRTM files, no LIDAR-DTM 3" files. Even if at first sight in theory we could think "Elevation from HGT files is already interpolated from more values around a required place", and so for example a 3" and a 1"-HGT-file of the same elevation source should result in similar values, which is not true as you can see above.

Second thing: Even if have the most exact elevation files possible, it's important that the horizontal postition of a track is exact, no divergence from realitiy, no jitter due to GPS-reception. This is also quite good for this track, since it's based on OSM, hence no jitter. But even OSM roads in this region difffer some meter from aerial-images of this region. No track can be 100% exact with reality - neither if recorced by GPS nor if planned using OSM-roads. - Hence especially in alpine terrain resulting in some "virtual" altitude differences are applied.

Third: As we can see using Andrea's track, based on quite good OSM-data, using best available elevation sources it's maybe a good idea to additionally filter the resulting elevation values of the track within an app. For example I used a vertical filter of 20 m (so each alevation change of less than 20m is disregarded), and i get values -1740 m / +1046 m which quite confirms the values we estimated by eye before.

Hello Sonny,

you save me a lot of time, thanks :). Exactly this > compare the result with more precise LIDAR data > is what I wanted to do with a track from Hans.

Seems that difference is even higher then I've expected. Best I see I may do on our side is to offer for alpine areas, more precise LIDAR 1'' data for download directly over Locus Map instead of current SRTM files.

Menion

You're right menion, but please don't forget the additional filter which is quite important. I did an additional test with a vertical filter of "just" 10 m. And even there we get quite a very good result and same time hardly loosing precision (each vertical altitude change >10m is still regarded):

-1828 m / + 1134 m

But don't forget this is just quite good because we have precise 1"-LIDAR elevation data and a good OSM-based track here. So maybe better use a filter of 20m or even more. At least for alpine roads/hikes. You still have to test how such a filter influences tracks in flater regions.

Not sure if this is really necessary. Elevation changes below 10 meters are still changes! Also, depending on the distance between points so it more about grade change on the segment. Here solution suggested by Andrea a long time ago seems more logical as it covers also this distance between points.

Anyway for manually drawn track, we may consider elevation values from SRTM1 as correct. I see no extra reason to apply another filter.

In case of own recorded track, it is, of course, more complicated. Here comes a pressure sensor to help as an alpine hiker best friend :).

You're right menion, elevation changes of 10 meters are still changes. But you have to be careful: Are this changes "real" changes or just virtual changes due to horizontal differences of the track to reality. Example: if a road within OSM differs just horizontal 10 meters to reality - could cause the elevation be off 20, 30m in alpine terrain.

And the same systematic error is true for the fact that even if using very good 1"-elevation files, such a files covers an horiziontal area of about 20 x 30meter which also leads to the mentioned systematic vertical error.

So even if we use the best available elevation sources, quite good horizontal positioned track we get systematical vertical errors. And to remove this errors a filter is necessary. Just look at the values I got using the 1"-LIDAR files. They are still "wrong" by about 300 vertical meters without aplying an additional filter.

You can of course think of the kind of filter which is best by testing it with Andrea's track. For example Keep each trackpoint and apply a filter on its vertical values. Or average the altitude of several following trackpoints etc...

The good thing is, that his track is very good to test such algorithms since it is in alpine area with prominent terrain changes next to the track.

Hi, very interesting discussion and thanks to all for contributions. I would like to add a couple of considerations from my experience. I have a basic bike computer with pressure altimeter and I could experience in trails that I know by heart that it is quite precise, also trails that are monotone (always up, no up-down). in monotone trails altitude gain is simply the difference between higher and lower points, so it's easy to check. I could verify that my bike computer is quite reliable also in mixed trails, alpine or flat, error on recorded gain usually not exceeding approx 2%. The same tracks, in the same trips recorded with locus instead, usually show a high gain error (error is always positive, showing higher elevation gain, never negative), sometimes even more than 30%. Using higher compensation filters reduces error but it remains anyhow significant. If I save the track on gpx and load it on other app, the error shown for the same file is much much lower, almost close to the pressure based computer. Is it simply a question of filter sensitivity? This is independent from srtm or other data. It's only the filter that probably works on a better alghoritm. And it works the same also on mixed trails with uphill and downhill or flat. I currently live on a very flat area and also here the altitude error of locus is quite significant. On a trail of about 20 km it may show gains of2-3 hundreds meters, while I believe they shouldn't be more than 50.

Consequences of filtering are like denoising in photography - removing noise removes fine details. Nevertheless it useful to some limited degree.

1. Finding out what filtering to use should be based on analysis of very big base of tracks saved with a barometer, for example from track sharing sites. I wouldn't be surprised if such an analysis is somewhere available.

2. SRTM or LIDAR data are data with a ground cover so filtering edges of woodlands should be beneficial with the option to switch off for areas without woodlands. In my tests of an antiflat BRouter profile on a flat like table area I set elevationmaxbuffer and elevationpenaltybuffer to 5 to start attracting a route to nearby hills.

I guess it might be a reason why in Locus using Navigation to or Planning options I got 112 m elevation gain, using BRouter as ad-on according to Brouter ad-on message 9 m, later from Locus UI 94 m, or web Brouter 8 m http://brouter.de/brouter-web/#map=11/48.5464/22.1306/standard&lonlats=22.301522,48.621832;22.102089,48.400187

On my bike computer with barometer 4 m - but it shows only multiples of 4 m, so I could get 7 m.

As to the track sent above - it cuts a lot of side ridges and valleys - often then roads go up and down to make them shorter so the toothed plot is understandable. Btw. alpine terrain is with post glacial relief like U-shaped valleys so not this part of the Apennines.

Hi everybody

This is also my concern since the early time of Locus development.

I alway found that, when planning a route, altitude gain computation is still not satisfactory and gives overestimation often over 20%. I think this is due to the many curves that a road does when climbing on a hill: while the slope is somewhat steady and there are not segments that go downhill, since SRTM data are somewhat simplified, every time the road makes a curve to overcome a ridge without a steep climb and a steep descent, tha algoritm count an up hill and down hill.

I think tha a simple averaging on the altitude prifile would give much more accurate results.

I think many other planner have similar problems: trying to do the same route with Locus, Garmin, Strava and Brouter web client I get good results with strava and Brouter, awful with Garmin, with Locus in the middle.

Please give us a way to remove "noise" from altitude profile!!

Also the altitude graph will give better indication on slope gradients

hi I have the same problem like Andrea. quite hilly and longer track in route planner gives +1850m although reality is +1500. for an entire day of biking a huge difference. any idea how to solve it? thx Peter

hello did something change in the meantime which makes it possible to recalculate the elevation? in case of long and steep roadbike its all off. short moves work great. if I click on track detail > update elevation nothing changes (alt+ remains wrong). thank you, dekuji :)