Locus Map - forum

Support => Troubles & Questions => Topic started by: Graf Geo on March 12, 2023, 19:31:08

Title: New computation of elevation values shows nonsensically distance (uphill/downhill)
Post by: Graf Geo on March 12, 2023, 19:31:08
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?(https://uploads.tapatalk-cdn.com/20230312/0e452fa450418bb69d27e32d82f60785.jpg)(https://uploads.tapatalk-cdn.com/20230312/ddc64ec2f7c4b09d62faa04270aebd01.jpg)(https://uploads.tapatalk-cdn.com/20230312/5402e1c52be821c051b86302fca4b41b.jpg)
Title: Re: New computation of elevation values shows nonsensically distance (uphill/downhill)
Post by: Menion on March 13, 2023, 07:46:18
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.
Title: Re: New computation of elevation values shows nonsensically distance (uphill/downhill)
Post by: michaelbechtold on March 13, 2023, 09:35:13
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 :-)
Title: Re: New computation of elevation values shows nonsensically distance (uphill/downhill)
Post by: Graf Geo on March 13, 2023, 11:14:17
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:(https://uploads.tapatalk-cdn.com/20230313/4949e0421092d33d54e7bf82d11c9998.jpg)(https://uploads.tapatalk-cdn.com/20230313/43e755ccbe419d3305806f42a62ac69e.jpg)
Title: Re: New computation of elevation values shows nonsensically distance (uphill/downhill)
Post by: Graf Geo on March 13, 2023, 11:16:15
Here the gpx file.
Title: Re: New computation of elevation values shows nonsensically distance (uphill/downhill)
Post by: lor74cas on March 13, 2023, 12:07:14
Quote- 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
Title: Re: New computation of elevation values shows nonsensically distance (uphill/downhill)
Post by: Menion on March 13, 2023, 13:03:45
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.
Title: Re: New computation of elevation values shows nonsensically distance (uphill/downhill)
Post by: Graf Geo on March 13, 2023, 15:46:19
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.
Title: Re: New computation of elevation values shows nonsensically distance (uphill/downhill)
Post by: Graf Geo on March 20, 2023, 10:57:54
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.
Title: Re: New computation of elevation values shows nonsensically distance (uphill/downhill)
Post by: lor74cas on March 20, 2023, 16:34:51
Quote from: Menion on March 13, 2023, 13:03:45@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).
Title: Re: New computation of elevation values shows nonsensically distance (uphill/downhill)
Post by: freischneider on March 20, 2023, 18:18:15
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.
Title: Re: New computation of elevation values shows nonsensically distance (uphill/downhill)
Post by: lor74cas on March 21, 2023, 09:23:18
Quote from: freischneider on March 20, 2023, 18:18:15For 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.
Title: Re: New computation of elevation values shows nonsensically distance (uphill/downhill)
Post by: michaelbechtold on March 21, 2023, 10:59:21
Quote from: lor74cas on March 20, 2023, 16:34:51@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.
Title: Re: New computation of elevation values shows nonsensically distance (uphill/downhill)
Post by: Tapio on March 21, 2023, 13:57:52
Quote from: freischneider on March 20, 2023, 18:18:15For 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.
Title: Re: New computation of elevation values shows nonsensically distance (uphill/downhill)
Post by: Graf Geo on March 21, 2023, 20:02:05
^ Excellent explanation and summary in the linked tutorial, tapio!

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

Many thanks!
Title: Re: New computation of elevation values shows nonsensically distance (uphill/downhill)
Post by: michaelbechtold on March 21, 2023, 22:50:07
Quote from: Tapio on March 21, 2023, 13:57:52...
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.

Plus there are systematic errors by illiterate inch/foot followers. I learned some years ago, that the hightest peak on earth was 28000 high, on the Philippines :-)
I started correcting 1000+ essential peaks (high prominence etc.), but I fear there are 1000s left with crazy values ...
Title: Re: New computation of elevation values shows nonsensically distance (uphill/downhill)
Post by: lor74cas on April 15, 2023, 13:33:53
Quote from: michaelbechtold on March 21, 2023, 10:59:21
Quote from: lor74cas on March 20, 2023, 16:34:51@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.
HI,
I finally managed to install the 1" hgt files plus LIDAR (Sonny's DTMs) and they really make a difference.
To get around the problems accessing the srtm folder, I copied the files from the PC with adb by connecting the mobile phone to the PC with a USB cable.
There are several hurdles here as well:
you must have adb installed
You must have developer options enabled on your phone
you must have a good usb cable
you need to authorize the phone to connect
and you need to locate the full path to the srtm folder
but if you already have all or most of what you need then everything is resolved in a single command:
adb push /home/lorenzo/Scrivania/hgt/*.hgt /storage/self/primary/Android/data/menion.android.locus/files/Locus/data/srtm

I am more and more convinced that the webplanner must have 1" plus LIDAR data (Sonny's DTMs). There is too much difference between what locus compute with LIDAR data on the same trace computed on the webplanner.
If, for reasons of occupied space, it is reasonable that not all the 1" data be downloaded to the mobile phone, but only those of the most used areas, I don't see why on the server hosting the palnner it is not possible to have this data for all areas where they are available.




Title: Re: New computation of elevation values shows nonsensically distance (uphill/downhill)
Post by: Andrew Heard on April 16, 2023, 00:14:16
Quote from: lor74cas on April 15, 2023, 13:33:53I am more and more convinced that the webplanner must have 1" plus LIDAR data (Sonny's DTMs). There is too much difference between what locus compute with LIDAR data on the same trace computed on the webplanner.
If, for reasons of occupied space, it is reasonable that not all the 1" data be downloaded to the mobile phone, but only those of the most used areas, I don't see why on the server hosting the palnner it is not possible to have this data for all areas where they are available.
a new help topic?
Title: Re: New computation of elevation values shows nonsensically distance (uphill/downhill)
Post by: Menion on April 16, 2023, 07:55:48
The reason is currently pretty simple. We do not have (yet) a system for the automatic distribution of 1' files on mobile devices. Because of this, web and also LoRouter data are computed with 3'' SRTM data > to make it "wrong" identically on all platforms.

Btw. did anyone notice the "Altitude threshold" parameter in the track edit screen? I'm experimenting with this value. For now, this may be set only for single route. Automatically is used value 5, when using SRTM data it is equal to 3.
Title: Re: New computation of elevation values shows nonsensically distance (uphill/downhill)
Post by: michaelbechtold on April 16, 2023, 12:06:41
Well, two wrongs do not make one right :-)

I consider it better to have the high quality in the Web Planner - officially announced, incl. the consequences ...
Or, if too many people insist in "wrongs" in the Web Planner, give them a choice (switch).
Just my 2c.
Cheers
Michael
Title: Re: New computation of elevation values shows nonsensically distance (uphill/downhill)
Post by: lor74cas on April 17, 2023, 10:59:12
Quote from: Menion on April 16, 2023, 07:55:48The reason is currently pretty simple. We do not have (yet) a system for the automatic distribution of 1' files on mobile devices. Because of this, web and also LoRouter data are computed with 3'' SRTM data > to make it "wrong" identically on all platforms.

Btw. did anyone notice the "Altitude threshold" parameter in the track edit screen? I'm experimenting with this value. For now, this may be set only for single route. Automatically is used value 5, when using SRTM data it is equal to 3.

For my use, the app and the PC are two separate worlds that communicate with each other thanks to the cloud.
On the app, to avoid memory saturation, I would be inclined not to install the LIDAR data (only let expert and aware users do it) while maintaining the updating of altimetric data as it now happens in an automatic and precise way.
But the web server doesn't have space problems, so it could contain LIDAR data where available, updates can also be made periodically based on communications from Sonny.
You could also add a feature like this:

If then the problem is that of having two instruments that return two different results, just put a link on the web planner that explains what and how the altitude is calculated on the web and on the app.
Obviously it would be good to specify that it makes little sense to use a 1' reticle if you don't have a gps accuracy filter set at least below 50mt, preferably under 20mt.
Title: Re: New computation of elevation values shows nonsensically distance (uphill/downhill)
Post by: Gerhard57 on April 17, 2023, 11:59:30
Quote from: Menion on April 16, 2023, 07:55:48Btw. did anyone notice the "Altitude threshold" parameter in the track edit screen? I'm experimenting with this value. For now, this may be set only for single route. Automatically is used value 5, when using SRTM data it is equal to 3.

comparing elevation gain old / new (LM 4.15.0) method and different "Altitude threshold"
Settings are:
GPS & sensors -> Altitude manager ->
SETTINGS -> Use altitude offset -> ON
SETTINGS -> SRTM data -> Replace GPS values
SETTINGS -> Altitude filter -> light
OFFSET -> Automatic correction

Elevation gain:
km : Distance in km
VDO :  VDO bike computer barometric
SRTM : SRTM /LiDAR by Sonny LM 4.14.2   OLD computation of elevation values
At :   SRTM /LiDAR by Sonny LM 4.15.2.5 NEW computation of elevation values =Attitude threshold
Distance (uphill) and Distance (Downnhill) also changes but no value to compare to

km     VDO  SRTM  At=5  At=2  At=1
31,7   738   771   672   751   790
42,3   843   834   739   905  1019
19,7   515   482   432   491   515
64,8  1253  1191  1043  1191  1283
58,2  1030  1022   885  1038  1190
59,3  1061  1026   919  1050  1133
39,5   633   638   551   650   739
72,0  1425  1424  1292  1460  1542
56,8  1347  1283  1160  1296  1360
32,9   891   884   838   889   931


Neu deivice with pressure sensor
GPS & sensors -> Altitude manager ->
SETTINGS -> Use altitude offset -> OFF
SETTINGS -> Use pressure sensor -> ON
PRESSURE -> Altitunde -> Set manually at start

km    VDO At=5 At=2  At=1
14,8  421  365  403   428
14,8  402  349  397   415

It shoud be posible to set different "Attitude threshold" for different Altitude manager settings:
GPS, SRTM, pressure sensor
Title: Re: New computation of elevation values shows nonsensically distance (uphill/downhill)
Post by: Staudenkletterer on April 27, 2023, 18:24:52
Quote from: Menion on April 16, 2023, 07:55:48Btw. did anyone notice the "Altitude threshold" parameter in the track edit screen? I'm experimenting with this value. For now, this may be set only for single route. Automatically is used value 5, when using SRTM data it is equal to 3.
Please, can anyone tell me were I can find the track edit screen and change the "Altitude threshold"?
Title: Re: New computation of elevation values shows nonsensically distance (uphill/downhill)
Post by: Gerhard57 on April 27, 2023, 20:13:52
Quote from: Staudenkletterer on April 27, 2023, 18:24:52Please, can anyone tell me were I can find the track edit screen and change the "Altitude threshold"?

You must enable it via settings -> expert settings -> tracks -> customize altitude threshold

After that you open a recorded track an use the edit icon on the bottom (looks like a pencil)
Title: Re: New computation of elevation values shows nonsensically distance (uphill/downhill)
Post by: Gerhard57 on May 02, 2023, 11:09:37
Quote from: Menion on April 16, 2023, 07:55:48Automatically is used value 5, when using SRTM data it is equal to 3.
When using pressure sensor "Altitude threshold" parameter value 2 is used. Right?
Is the source of elevation data (GPS, SRTM, pressure sensor) stored in database to recalculate older tracks to keep them comparable?
Title: Re: New computation of elevation values shows nonsensically distance (uphill/downhill)
Post by: Menion on June 05, 2023, 11:42:29
Hi, right. Usage of the pressure sensor set AT value=2.
Anyway, tracks (better trackpoints) have no idea about their source or precision, so all tracks have predefined AT=5.