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

[michaelbechtold]

...
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 ...

[lor74cas]

@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.

[Andrew Heard]

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.

a new help topic?

[Menion]

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.

[michaelbechtold]

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

[lor74cas]

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.

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:

• in Locus, in tracks settings an option "update altitude automatically during cloud sync"
• tracks are sent from the app to the cloud where the altimetry is reprocessed and then sent back to the app with a flag or description indicating that the altimetry has been reprocessed
• if you don't want an automatism, you could add an item to the already present "update altitude" in the tools with an "update altitude in cloud"

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.

[Gerhard57]

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.

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

[Staudenkletterer]

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.

Please, can anyone tell me were I can find the track edit screen and change the "Altitude threshold"?

[Gerhard57]

Please, 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)

[Gerhard57]

Automatically 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?

[Menion]

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.