Altitude gain correction

Andrea shared this question 13 months ago

Hi Menion,

I'm not sure I have fully understood how altitude correction filter works but I experience some troubles with it. I use a device with no pressure sensor, so the only data are from GPS and SRTM1 dem files. I tried with GPS only data and GPS corrected by SRTM without experiencing significant difference. I have set filter to medium. Sometimes saved altitude gain is quite reasonable as expected, some other times it's very high compared to the expected value (also about 2 times the expected value). Also, when planning with Brouter a 80km long trip, I got a altitude gain of about 2600 m while it should reasonably be between 1000-1200 m. This is probably caused by approximation between SRTM1 and Brouter map vector segments. I don't know if your filter works also with planned routes or only with registered tracks. If not, it could be a good idea to implement it.

I also wonder if it could be a good idea to let applying filter manually after the track (or planned route) is saved. I mean: 1) user sets the level of filter impact (low, medium, high,extra high); 2) then he pushes a button and sees results; 3) if result is satisfactory, he saves again (overwriting or duplicating), otherwise tries another filter level or aborts. What do you think?

Would you also explain the principle of the filter algorithm. Is it somehow averaging close points' altitude or taking one waypoint every a number?

Many thanks


Comments (3)


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.



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



Da: Locus Map []

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 ( , ), 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.