New computation of elevation values shows nonsensically distance (uphill/downhill)

[Graf Geo]

Hello Menion,

since the update to version 4.15, the calculation of the elevation values has been changed. I don't know why this was done at all, for me the calculation was fine before. But maybe I missed something.

Apparently, minor elevation changes up to five or six metres are now ignored, so that in flat regions 0 m elevation gain / loss is always displayed despite slight ups and downs. I am not quite sure if this is what is intended. Since the elevation profile still shows the (small) elevation differences, this is at least inconsistent (see screenshot 1).

Absolutely illogical, however, is the calculation of the distance (uphill/downhill), which is now much too short. Even on routes that go steeply uphill continuously, the distance (uphill) is only displayed for a nonsensically small part of the route. This can be reproduced without any problems. See screenshot 2 and 3, which shows a steep ascent. You can believe me, every single metre of the 1.1 km long route goes steeply uphill, yet only 686 m are displayed as distance (uphill). Is this a bug or how can it be explained?

[Menion]

Hi,
thanks for opening this topic, finally someone .

What you see is not a bug, but really a changed algorithm currently used for compute of elevation sums.

Reasons to change were mainly following
- different algorithms during track recording & track after saving = different results
- too high results compared to most of the other apps
- too complex algorithm in the background where we had problems implementing it same also on the web and coming iOS app

The current algorithm really ignores small elevation changes up to 5 meters.

---

Anyway
1. small elevation changes > I do not see a big problem here. Yes, the chart displays almost unfiltered values so there is a clear difference. On the second side, jumps a few meters up & down are really common and this heavily helps ignore them.

2. But this one is more interesting I believe and I would like to look at it. It is a recorded track? If so, may you share it, please? Maybe there is something I may do with it, thanks.

[michaelbechtold]

Hi Menion, appreciate the new algorithm. And there are parameters that control this algorithm. Those 5m you mention are not carved in stone, but could be an expert setting. So people can change according their liking - and take responsibility for the outcomes themselves :-)

[Graf Geo]

Hello Menion,

thank you for the explanations on 1. Fine.

To 2: this happens both with recorded tracks and with routes created with the route planner. In my opinion, the length of the calculated distance uphill/downhill is always (much) too short. Enclosed is another track that was recorded:

[Graf Geo]

Here the gpx file.

[lor74cas]

- too high results compared to most of the other apps

I think this goal has not been achieved

When I go out, I record with both Garmin and Locus, I use Locus for maps and as a backup, often after the activity I delete the track on Locus. But I noticed a notable difference between the difference in altitude calculated between the two. Thinking it was due to the separate GPS data recordings or the fact that I often forget to stop the Locus track in time, I didn't give it any importance.
But reading Graf Geo's post I checked better and the calculation of Locus makes me doubt.

So to avoid comparing tracks taken with different devices, I downloaded the GPX from Garmin and loaded it into Locus, updating the altitude.

Locus 998
Garmin 860
Strava 864


Strava uses the same data as Garmin and there is a small difference between Garmin and Strava due to the different algorithm used, but Locus is very far from these values.

@Menion if you need I'll send you the GPX and the Garmin and Strava links privately

[Menion]

Thanks for the route. It was a different one in the first post.

Anyway even here is also a clearly visible problem, so thanks. I think I've found one obvious problem (with the incorrect sum of the used distance for computing of the slope) and after the fix, I have these results (screen).

And now tell me ... is it wrong? Because here are the changes registered by the algo:

addElevationToStats, distance: 858.5077, elevation: 5.119999237060547
addElevationToStats, distance: 588.86194, elevation: -5.02999969482422
addElevationToStats, distance: 1270.1581, elevation: 5.179999084472655
addElevationToStats, distance: 411.74136, elevation: 5.209998779296875

It simply displays that after the first 858m, elevation change was finally above +-5m, then -5m after another 588m, etc. In the end, changes are so small, that distance up/down are simply = 0m! And I think it is correct.

App requires at least 2% slope change to be registered for up/down distance. So at least 2 metres change per 100m!

@Michael Bechtold
and here is the problem. I really do not want to have this parameter customizable. The main reason is to have exactly the same algorithm (results) on all three platforms. So track re-computed on the web after sync should be able to get identical results (that does not happen now).

@lor74cas
thanks. But it was worst before I believe  . You may also find apps that will have a higher values...

The difference 14% is not bad. Anyway best is to get better results of altitude values instead of tuning algorithm that filter these values. So suggest checking the "replace of SRTM data" or "Pressure sensor" values in the Altitude manager.

[Graf Geo]

Sorry Menion, I thought you needed a recorded track. The first one was created with the route planner.

But that shouldn't matter, because I always use the setting "replace GPS values" for "srtm data" in the altitude manager. Nevertheless, here are the gpx data of the first track.

[Graf Geo]

Hello Menion,

once again on this topic. I had some time to look into it over the weekend and found some inconsistencies and, in my opinion, a bug.

First of all, thanks for the update 4.15.2 (impoved computation of uphill/downhill distance) - this is more realistic now.

I am still not completely happy with the new calculation of the elevations. In my opinion, ignoring elevation differences of up to 5 metres is too strict. In relatively flat regions such as Berlin and the surrounding area, too many actually existing inclines and declines are calculated out, and the result is then not very realistic. If I go on a cycling or jogging tour and have several short but distinctive inclines, which clearly require effort when running and can also be seen in the altitude graph, and the result then shows 0 metres of altitude, this is not ideal. 

In addition, there are sometimes strange results that make no sense from a purely mathematical point of view: A recorded track shows "Min altitude" 30 m, "Max. altitude" 66 m (a difference of 36 m), but only 30 m elevation gain is displayed. (Screenshot 1 and 2.) So 6 metres of altitude are "swallowed".

Then I noticed a faulty behaviour in the Track Analyzer, which might be a bug. A track section selected with the analyzer always shows exactly the same value for elevation gain and loss, even if it only goes uphill or downhill (screenshot 3 and 4). This can be reproduced everywhere.

[lor74cas]

@lor74cas
thanks. But it was worst before I believe  . You may also find apps that will have a higher values...

The difference 14% is not bad. Anyway best is to get better results of altitude values instead of tuning algorithm that filter these values. So suggest checking the "replace of SRTM data" or "Pressure sensor" values in the Altitude manager.

You are right, I can find bad apps and websites that calculate absurd elevations, but Locus being one of the best apps must give the most correct information possible while always remaining at the high standards that distinguish it from the others.

Yesterday's excursion compared with Locus, Garmin and Strava gave more similar data: Locus 462, Garmin 445, Strava 509. However, I compared the 3 graphs and I noticed that only Strava gave the correct maximum altitude 323 meters, Locus and Garmin 316.
323 is correct as it is exactly the height of the small peak climbed.

Obviously we can't know what algorithms and what data Strava or Garmin use, but to have such an accurate altitude, I suspect that Strava uses a higher SRTM detail than Garmin and Locus.

Unfortunately, currently I'm not able to make a comparison between the normal SRTM data and the more accurate 1' data because with the switch to android 13, I can't place them in the folder.

I find the accuracy of the altimetry only useful when planning on site, when you are far from the network, and these are rare cases (at least for me). I generally plan at home, preferably on the PC. However, the web planner could use more detailed SRTM data where available in order to return more correct information.
We could also have normal SRTM data on the phones avoiding clogging them with the GB data necessary for the 1' SRTM and updating the altimetry on the server in the cloud when the track is transferred (perhaps as an option).

[freischneider]

For me it is so that Strava currently always shows more altitude than Locus. Yesterday I had in Locus 905 hm and in Strava 1022. Use the Current Beta
Small differences should already be taken into account. Only unrealistic jumps should be filtered out. E.g. 3 hm within 3 meters.

[lor74cas]

For me it is so that Strava currently always shows more altitude than Locus. Yesterday I had in Locus 905 hm and in Strava 1022. Use the Current Beta
Small differences should already be taken into account. Only unrealistic jumps should be filtered out. E.g. 3 hm within 3 meters.

Different algorithms for calculating the height difference can obviously give different results, but the top of a mountain must have the correct height regardless of the algorithm.

[michaelbechtold]

@lor74cas
...
because with the switch to android 13, I can't place them in the folder.
...

I just tested with x-plore on Android 13: even on EXT SD, this app can write to the private folders of /Android/data.
BTW: 1" alone is not delivering better results per se; only 1" plus LIDAR (Sonny's DTMs) will do.

[Tapio]

For me it is so that Strava currently always shows more altitude than Locus. Yesterday I had in Locus 905 hm and in Strava 1022. Use the Current Beta
Small differences should already be taken into account. Only unrealistic jumps should be filtered out. E.g. 3 hm within 3 meters.

Here's a good read for a better understanding of why elevation gain calculation can vary drastically - there is no simple truth. It helped me a lot. Eg., "Choosing an elevation threshold" is a very relevant factor.

https://www.gpsvisualizer.com/tutorials/elevation_gain.html

Haha yeah, I only use Sonny's best hgt files. Last year I had to disappoint a friend of mine who proudly walked over a 1050m hill in Schwäbische Alb, which in fact was <1000m. Also a lot of hill elevations in OSM are rather drastically off (>50m at times), source may have been barometric measurement or lack of geoid model, I correct those attributes if I find them. Well, some data are pretty old.

[Graf Geo]

^ Excellent explanation and summary in the linked tutorial, tapio!

Indeed, there is no generally valid calculation that provides absolutely realistic height values.

Many thanks!