This object is in archive!
Wrong elevation loss and gain
Closed
I created the following testtrack with 10 trackpoints. The distance of each trackpoint is about 200 metres, so no Locus-internal filter should take affect. The first trackpoint has elevation=100 m, the second= 200 m, the third = 100 m, the fourth = 200 m and so on.
It's easy to determine that the overall elevation loss should be -400m and the gain +500m
But locus just calculates -364m and 459m in the statistics tab of the track. Why is it wrong that much? I also noticed: the less the trackpoints distance, the more the difference calculated values - Locus values. Is there some hidden, undocumented "filter" which Locus applies to each track, even if the trackpoints are that far seperated from each other?
Files:
Testtrack.gpx
The same problem 
Good day sonny,
limit in the application is set to 250 m. So points in less/equal to 250 meters are used for computing of filtered value. If points are closer to each other, then more points is used to compute of filtered value so final value is "more optimized".
So the distance of 250+ meters should cause no filtration.
Good day sonny,
limit in the application is set to 250 m. So points in less/equal to 250 meters are used for computing of filtered value. If points are closer to each other, then more points is used to compute of filtered value so final value is "more optimized".
So the distance of 250+ meters should cause no filtration.
Hi Menion,
there must be some else parameter which causes a GPX-track to miss some of the overall elevation meters. I created another track, now each trackpoint is apart 333 meter from each other. But still the sums in statistics tab are just -377 and +474 instead of -400 / +500
And could you please explain the method of filtering on point distances <250m. It would be great to understand in detail how Locus calculates the overall elevation values of IMPORTED tracks. I think this part of filter/calculation has nothing to do with recording a track by GPS and the parameters (e.g. filter) defined within Altitude mananger.
Hi Menion,
there must be some else parameter which causes a GPX-track to miss some of the overall elevation meters. I created another track, now each trackpoint is apart 333 meter from each other. But still the sums in statistics tab are just -377 and +474 instead of -400 / +500
And could you please explain the method of filtering on point distances <250m. It would be great to understand in detail how Locus calculates the overall elevation values of IMPORTED tracks. I think this part of filter/calculation has nothing to do with recording a track by GPS and the parameters (e.g. filter) defined within Altitude mananger.
Ah, you are correct, I overlooked one part of the code. Always at least one point before and after the filtered point is used so there is always at least "little filtration".
How to explain it? It's hard for me, so I rather revealed this small secret over existing source code I made years ago. Here it is: https://gist.github.com/menion/807f4fe480f8abb6455a536d1f6762e1
Key is the function `optimizeDataPoint` (line 163) that do all the logic. It just sums original value, then add few points back, then few forward and then compute result by dividing the sum with computed wight. Hope this gives you more sense then when I try to explain it :).
Ah, you are correct, I overlooked one part of the code. Always at least one point before and after the filtered point is used so there is always at least "little filtration".
How to explain it? It's hard for me, so I rather revealed this small secret over existing source code I made years ago. Here it is: https://gist.github.com/menion/807f4fe480f8abb6455a536d1f6762e1
Key is the function `optimizeDataPoint` (line 163) that do all the logic. It just sums original value, then add few points back, then few forward and then compute result by dividing the sum with computed wight. Hope this gives you more sense then when I try to explain it :).
Hehehe, WOW! I didn't thought that calculation of Elevation sums is that quite complicated in Locus ;-) Weights, distances and a bunch full of methods and iterations.
But at the end, the sums of my test tracks and the max/min-Values of the tracks I helped analyzed lately here https://help.locusmap.eu/topic/altitude are not exactly the ones we could expect. Especially if the elevation values are based on good LIDAR elevation sources, where not too much filtering should be necessary.
But I understand, that it's not a good idea to change something in this well-established, non trivial method of filtering and elevetion point optimizations.
Hehehe, WOW! I didn't thought that calculation of Elevation sums is that quite complicated in Locus ;-) Weights, distances and a bunch full of methods and iterations.
But at the end, the sums of my test tracks and the max/min-Values of the tracks I helped analyzed lately here https://help.locusmap.eu/topic/altitude are not exactly the ones we could expect. Especially if the elevation values are based on good LIDAR elevation sources, where not too much filtering should be necessary.
But I understand, that it's not a good idea to change something in this well-established, non trivial method of filtering and elevetion point optimizations.
It is not so big magic, just a primitive mathmatics I'm capable of.
Anyway more interesting topic (for me) is here : https://help.locusmap.eu/agent/object/3194#comment-65397 . Poutník wrote me there some interesting algorithm that may helps here. I just need to find some time on this.
I've also improved algorithm we talk about a little bit, so in next version, 250 m will be really used even for first point, so for your second track, values will be expected -400/+500.
It is not so big magic, just a primitive mathmatics I'm capable of.
Anyway more interesting topic (for me) is here : https://help.locusmap.eu/agent/object/3194#comment-65397 . Poutník wrote me there some interesting algorithm that may helps here. I just need to find some time on this.
I've also improved algorithm we talk about a little bit, so in next version, 250 m will be really used even for first point, so for your second track, values will be expected -400/+500.
Moved to Optimize altitude during import
Moved to Optimize altitude during import
Replies have been locked on this page!