Bad elevation when importing a GPX.

[gri38]

Hello.

First, and I'll repeat each time: congratulation and thanks for that awesome project!!

I know it's not "your fault", and it's a common gpx analysis issue to compute the total elevation (a lot of discussion exists on internet).

For instance, a gpx I've imported to "my" wanderer says 2045m, where I know the true elevation gain (easy it's just up all along) = 1660.
That is an error of almost 5%.

A proposal could be to offer to enable a configuration in the settings, something like that:

And the settings could be:

1. Enable / Disable
   1. Enabled: Activates the elevation correction.
   2. Disabled: Deactivates the elevation correction.
   3. Ask when importing: Prompts the user to choose whether to activate the correction when importing data.
2. Correction Model
   1. dropdown for different correction models
      1. ??
      2. ??
   2. Use DEM data instead of source

I would be happy to contribute, I'm an experienced developer.
If that can suit... let's contact.

Thanks.

[gri38]

O maybe better: in the edit of a track. So user could test several ways of computing the elevation ...

[Flomp]

Hi! Happy you like it so far.

The fact that GPX is inaccurate in this regard is news to me. Should it not just depend on how accurate the device is that you recorded your altitude on?
Also, please mind that the number displayed in wanderer is not the vertical distance from the lowest to the highest point in the GPX but rather the cumulative sum of all elevation gain/loss. This means if you hike up 1000m down 500m and again up 1000m the number displayed for elevation gain in wanderer will be 2000m and not 1500m.
In any case, it is also completely possible that I made a mistake when calculating the totals. The function in question is located here.

[gri38]

Hi @Flomp

Regarding elevation, this page provides an excellent explanation of the issue.

Summary:
Calculating elevation gain is tricky. GPS data is often unreliable, and while DEM (Digital Elevation Model) data is generally more accurate, it can still be impacted by noise from GPS track inaccuracies. Summing elevation changes often leads to significant overestimation—errors can exceed 100% with GPS and around 30% with DEM, even after filtering. Using DEM data with vertical and horizontal smoothing helps, but the results are still approximations.

I'll take a look at the code, though this feels more like a "product-level question" about applying filtering. It might improve things, but I’m not sure it always will. Also, offering users a choice might be overly technical—most just want a simple way to import tracks.

I'll keep you updated!

[Flomp]

Very interesting read! Thanks for that. I found this API to facilitate the DEM lookup:
https://api.elevationapi.com/index.html

The other corrections could be done client side.

PS:
I saw in my mail that you were having issues setting up a dev environment. Since I don't find it here anymore I assume it's resolved?

[gri38]

Hello.

Thanks for info.
About setting the dev env yes, it's finally ok.

I've already done the filtering, at client side indeed, it's quite simple. But I had no time to propose a PR so far... I'll probabely do next week.

I also did some tests with DEM but it's not so easy to get a good source. I did some test with an API that gives a tif file of elevation for the area we ask (the boundig box of the gpx), but it was not very good data (SRTM3) the total elevation computed from that was bad (I only tested on one track, I should test on several locations, but also several types of tracks: flat, clim, up down up dow up..... I searched the web for some "elevation ground truth with gpx" but I dont think it exists.)

I saw here the best available data for each region: https://www.gpsvisualizer.com/DEM_coverage.php but it seems it's a pain to provide the dem feature easily (for instance without the need for the user to get a google map api key...)

Thanks for the link, I'll have a look.