track slope glitch in WebPlanner but not identical track in LM4 app

Andrew Heard shared this problem ago

Known

I used Cloud Sync from the phone to the Web Planner for this route. In latest LM4 app v3.9.0 there is only +3.8% slope (as expected from contours) but in the WebPlanner the identical route (noticed for a 2nd time, reported for a different reason here) is a nonsense +25% slope, as calculated for very short section of the track. Is the Web Planner track auto-recalculated even when not modified? It reduces your confidence in planning the route via the WebPlanner, whereas it should be making life easier than using the app because of a bigger screen & mouse.

a590c6f225790d39b6bbdfc93745ef40

zoomed in even further shows how unreal this calculation is:

d5f23929cea9ef2664d76138720cc788

Also note above (minus) -20% on Y-axis above when the calculated minimum slope is only -7.3%, so the auto-scaling of the Y-axis could also be improved to maximize effective area of the chart (surely -10% to +25%) - another topic?

The same problem 0

Replies (1)

Ondřej Janata ●

Hi Andrew, we are aware of this issue but we still have no easy, quick solution for it :/ ... as you have already pointed out this glitch is caused for very short section of the track when there is e.g. 0.25m (minimum altitude step in Brouter) altitude difference between point A and B that are 0.5m from each other ... the result is 50% slope.

We plan to add some more advanced filter for detecting and removing these outliers ... unfortunately, I have no ETA here :/. Any quick and easy ideas are welcome :).

Kind regards, Ondrej

Reply URL

Andrew Heard ●

Hi Ondrej. Thanks for looking into this.

So why is LM4 better than the Web Planner for these calculations - when sharing same SRTM & GPX data? LM4 app handles these track glitches better, again not perfect ;-) I'm no mathematician, but why would you make any slope calculation over a very short section of track? I would think minimum 10 or 25m distance with filtering is sufficient.

Also in my last screen capture, although not directly related, and won't fix this problem, if X-axis scale resolution is to 10m then prevent zooming in to 50.65, 50.65, 50.65, 50.65km.

Unfortunately these large track glitches make Y-axis auto-scaling problematic. The huge error crams the actual valid Y-variation into a smaller band where no detail can be displayed. Could the user set their own Y-axis scale - in my own example I would have set +/-10% rather than +25% to -20%.

URL