Ascent always quite high

Hi Daniel,

Curious. I’m not quite sure honestly, perhaps a rounding error :-/ The logic for how this is calculated can be seen here, the number in question is stored as this.track_info.ascent.

Let me know if you make any discoveries or believe this to be a bug!

Cheers,

Joe

Hi

ok, I have a bit played with the source code now. There is no bug in this sense, but they did not care about the “ant-elephant problem”.

Everything depends on the number of elevation measurements on the track. As an extreme example, if you have a circular hike and you make only two measurements, one at the start and one at the end, you will always get 0 meters ascent and descent, even if you have climbed a mountain in between.

Leaflet does the opposite extreme. They measure at every waypoint, which is anything between 1 and 4 meters. So there is always a kind of ‘jittering’, which results in too many elevation changes and then in too high ascent and descent values. By the way the elevation data model accuracy is between 2m and 30m depending on the county.

So here we come to the ant-elephant problem: For an ant a curb is relevant, not so for an elephant. If all the curbs on a route were added together, the result would be a very high value, which is not true for an elephant – because it does not notice the curbs.

I have changed the code to measure the elevation every 25m of walked distance and then I get exactly the values of the swisstopo app. If I change to 180m, I get the values of komoot.

So it seems to be a question of decision. I decided to measure every 10 meters, which results in the most accurate values, in my personal opinion, of cause. Maybe this could be a user setting in the future.

If you want, I can send you the changed source code and you can implement it into yours. You can send me a pm for your e-mail address.

Best regards.
Daniel.

Hi @microteq,

Thanks for digging into this and for your explanation, that’s new to me so I found it very interesting.

Maybe this could be a user setting in the future.

Agreed.

If you want, I can send you the changed source code and you can implement it into yours. You can send me a pm for your e-mail address.

That would be helpful!

If the section in question is not too large feel free to paste it here, or on GitHub (issue – preferred)/GitHub Gists/Link to text file. You are welcome to connect directly with me here, however I like to keep as much non-private content to do with the project open and public as possible ??

I’m not sure what the best way to deal with this will be honestly. The ascent/descent values in question were added in a recent Pull Request and were pulled over from the Leaflet Elevation plugin that Waymark uses… but is not using the most recent version (I believe because of some conflicts I was not able to resolve a long time ago… but can’t quite remember).

So this is quite messy already and any other edits may compound the problem. I agree though that these values should be accurate and that user control over the measurement “<meta http-equiv=”content-type” content=”text/html; charset=utf-8″></meta>frequency” (there is probably a more accurate term) would be a good solution.

Thanks again for raising this and I will see what I can come up with.

Cheers,

Joe

Thanks for the issue!

Joe