Calculation of altitude. The second to last version and the last version too, shows errors
Solved
In the screenshut, you can see a corrected value of aprox. 1700 meters of elevation gain, none of elevation loss, while correct values should be aprox. 1100 meters.
The same problem 
Screenshot ?
Screenshot ?
Hi,
Locus Map processes elevation gain from the data it receives from your phone's GPS. The resulting elevation gain is incorrect if the data from the phone is incorrect or shows deviations. Locus Map, however, offers a few methods to limit these deviations.
Open Locus settings > GPS&sensors:
Hi,
Locus Map processes elevation gain from the data it receives from your phone's GPS. The resulting elevation gain is incorrect if the data from the phone is incorrect or shows deviations. Locus Map, however, offers a few methods to limit these deviations.
Open Locus settings > GPS&sensors:
Hi Michael. I know this issues and I use LM very often. The fact, that correction of altitude increases this values in such extremly way, apeared with the last 2 versions. Know, today, I remark, that LM shows no decreasing values.
Hi Michael. I know this issues and I use LM very often. The fact, that correction of altitude increases this values in such extremly way, apeared with the last 2 versions. Know, today, I remark, that LM shows no decreasing values.
Could you please send the screenshots and GPX of the track? Thanks
Could you please send the screenshots and GPX of the track? Thanks
Yesterday and today, I took some images/screenshots and selected them to be combined with my story, but after loading, I can't see them in this thread.....
Yesterday and today, I took some images/screenshots and selected them to be combined with my story, but after loading, I can't see them in this thread.....
Files up to 2 MB each can be sent. If they are bigger, place them on some cloud and send a link.
Files up to 2 MB each can be sent. If they are bigger, place them on some cloud and send a link.
Screenshot of missing decrease value
Screenshot of missing decrease value
Another screenshot
Another screenshot
GPX-file with maximum fail auf altitude correction
GPX-file with maximum fail auf altitude correction
Sorry for that latency, back at home, no more problems to load up. The same procedure failed while staying in italy in mountain region.
Sorry for that latency, back at home, no more problems to load up. The same procedure failed while staying in italy in mountain region.
Hi Jörg,
Thanks for the GPX — it pinned this down. The descent was being calculated correctly all along; the statistics screen simply refused to display it, because a plausibility check meant for a single altitude reading was also being applied to the total descent, and anything below -1000 m was discarded as implausible. That's why you saw a downhill *distance* but no downhill *metres*. Fixed for the next version.
On the other half of your report — the ~1700 m of gain where the real climb is ~1100 m — that one is genuine GPS/barometric noise in the recorded altitudes, not a display problem; the filter settings I listed earlier are the right answer there.
Hi Jörg,
Thanks for the GPX — it pinned this down. The descent was being calculated correctly all along; the statistics screen simply refused to display it, because a plausibility check meant for a single altitude reading was also being applied to the total descent, and anything below -1000 m was discarded as implausible. That's why you saw a downhill *distance* but no downhill *metres*. Fixed for the next version.
On the other half of your report — the ~1700 m of gain where the real climb is ~1100 m — that one is genuine GPS/barometric noise in the recorded altitudes, not a display problem; the filter settings I listed earlier are the right answer there.
One last question: The correction of altitude up to 1700m, I don't understand, how correction will increase so extraordinaty, while the origin values show 1000m.
As I understand, the filters will modify the recorded values, but how is it possible, that correction after record show such extreme differences? In my opinion, this correction should nevelate the origin values, not extend them, while origin values are nearer to correct ones?
One last question: The correction of altitude up to 1700m, I don't understand, how correction will increase so extraordinaty, while the origin values show 1000m.
As I understand, the filters will modify the recorded values, but how is it possible, that correction after record show such extreme differences? In my opinion, this correction should nevelate the origin values, not extend them, while origin values are nearer to correct ones?
Hi Jörg,
I've analysed the GPX and can explain what happened.
The two figures come from two different sources, and neither is a "corrected" version of the other.
In your case the second number (1700 m) is the less reliable one, and here's why. The standard elevation data has a grid spacing of about 90 × 65 m in your area, while your track has a point roughly every 5–6 m. That means around 15 track points fall inside a single grid cell, and each one gets an elevation interpolated from its exact position. In the steep Dolomite terrain you were walking (slopes of 30–50 % along most of the route) even a few metres of horizontal GPS scatter shifts the interpolated elevation by several metres — up, then down, then up again. Summed over 1,583 points, that adds several hundred metres of climbing that you never actually walked.
One example from your own track: between 11:07 and 11:17 you finished within 2 m of where you started, but the recalculated profile records 100 m of ascent and 101 m of descent in that same ten minutes. The horizontal accuracy there was poor (HDOP around 13), which is normal below rock faces. Across the hour you spent near the summit, the profile accumulates 579 m of ascent and 480 m of descent inside a band only 142 m tall.
What you can do
Locus Map lets you filter this out with a custom altitude threshold, which ignores altitude changes smaller than a set value:
Full instructions are here. Please run "Update elevation" first and set the threshold afterwards — the update sets the threshold back to its automatic value for the new data source, so a threshold set beforehand is overwritten. The automatic value with elevation data is 3, which is why you saw 1,700 m.
On your track a threshold of 10 gives about 1,310 m and 15 gives about 1,090 m. Somewhere in the 10–15 range is realistic for this route, and it matches what your GNSS recorded.
A second option worth considering for the Alps: Sonny's LiDAR terrain models offer 1″ (about 20 × 30 m) data for Italy, which is far more accurate than the standard data in steep rocky terrain. Copy the .hgt files into Locus/data/srtm and restart the app (details). Please note it improves the accuracy of the terrain shape itself, but it does not by itself remove the up-and-down oscillation described above — the threshold is what handles that.
Finally: for tracks recorded in this kind of terrain, your GNSS values were genuinely good. "Update elevation" is most useful the other way round — when the recorded altitude contains large spikes, or for imported routes with no elevation at all.
Hi Jörg,
I've analysed the GPX and can explain what happened.
The two figures come from two different sources, and neither is a "corrected" version of the other.
In your case the second number (1700 m) is the less reliable one, and here's why. The standard elevation data has a grid spacing of about 90 × 65 m in your area, while your track has a point roughly every 5–6 m. That means around 15 track points fall inside a single grid cell, and each one gets an elevation interpolated from its exact position. In the steep Dolomite terrain you were walking (slopes of 30–50 % along most of the route) even a few metres of horizontal GPS scatter shifts the interpolated elevation by several metres — up, then down, then up again. Summed over 1,583 points, that adds several hundred metres of climbing that you never actually walked.
One example from your own track: between 11:07 and 11:17 you finished within 2 m of where you started, but the recalculated profile records 100 m of ascent and 101 m of descent in that same ten minutes. The horizontal accuracy there was poor (HDOP around 13), which is normal below rock faces. Across the hour you spent near the summit, the profile accumulates 579 m of ascent and 480 m of descent inside a band only 142 m tall.
What you can do
Locus Map lets you filter this out with a custom altitude threshold, which ignores altitude changes smaller than a set value:
Full instructions are here. Please run "Update elevation" first and set the threshold afterwards — the update sets the threshold back to its automatic value for the new data source, so a threshold set beforehand is overwritten. The automatic value with elevation data is 3, which is why you saw 1,700 m.
On your track a threshold of 10 gives about 1,310 m and 15 gives about 1,090 m. Somewhere in the 10–15 range is realistic for this route, and it matches what your GNSS recorded.
A second option worth considering for the Alps: Sonny's LiDAR terrain models offer 1″ (about 20 × 30 m) data for Italy, which is far more accurate than the standard data in steep rocky terrain. Copy the .hgt files into Locus/data/srtm and restart the app (details). Please note it improves the accuracy of the terrain shape itself, but it does not by itself remove the up-and-down oscillation described above — the threshold is what handles that.
Finally: for tracks recorded in this kind of terrain, your GNSS values were genuinely good. "Update elevation" is most useful the other way round — when the recorded altitude contains large spikes, or for imported routes with no elevation at all.
Hello Michael. Thank you very much for the detailed explanations.
I’ll take another look at them, as even now I still don’t understand why the initial recording came within 10 per cent of the actual altitude values, yet the subsequent altitude correction based on these original values resulted in such a large deviation.
You don’t need to reply again if the explanation is in the previous text; I’ll read it through again, download Sonny’s hgt files once more and read up further on LM’s filtering strategy.
Thanks again.
Hello Michael. Thank you very much for the detailed explanations.
I’ll take another look at them, as even now I still don’t understand why the initial recording came within 10 per cent of the actual altitude values, yet the subsequent altitude correction based on these original values resulted in such a large deviation.
You don’t need to reply again if the explanation is in the previous text; I’ll read it through again, download Sonny’s hgt files once more and read up further on LM’s filtering strategy.
Thanks again.
Replies have been locked on this page!