# Altitude gain correction

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

Andrea

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.

Loading...Comments have been locked on this page!