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

Andrew Heard shared this problem 2 years 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?

Replies (7)

photo
1

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

photo
1

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

photo
photo
1

22 months later - a new record of 337% slope - really? No advanced filtering like in LM4. It makes using the web planner to plan a route then check the slope almost useless when this happens because the actual/ real slope is reduced to a horizontal line.

example: https://link.locusmap.app/t/hjzgf5

2aa0210820ec387342e835aa1c9f0bc3

5867a80a123e26e2d2c1a4c3505b8ac4

Fortunately there is a workaround: import or Cloud Sync the route into LM4, and the slope glitch is entirely removed!! No update of elevation performed. Why the difference? And at this point 215m from the start, LM4 shows a transition from +7% to -7% over distance of 170m which is roughly true from the street view: https://www.google.com.au/maps/@-42.8749307,147.3333871,3a,90y,64.44h,81.89t/data=!3m7!1e1!3m5!1srWyw6jlC1gqyBjdmBXzhEg!2e0!6shttps:%2F%2Fstreetviewpixels-pa.googleapis.com%2Fv1%2Fthumbnail%3Fpanoid%3DrWyw6jlC1gqyBjdmBXzhEg%26cb_client%3Dmaps_sv.tactile.gps%26w%3D203%26h%3D100%26yaw%3D161.6578%26pitch%3D0%26thumbfov%3D100!7i16384!8i8192?entry=ttu

d3715ebc224c798cc484ee672e1de3f1

photo
1

Hi Andrew, please, how was this track created? I have tried to plan the same in web planner and I can not create this glitch. Was it planned in the app? Which router? Thanks a lot.

Kind regards, Ondrej

d7902396fb635c4b2e87309fe637b7ec 5176bbcfa4fb4371bdd0b15d596c8ca0

photo
1

Hi Ondrej - thanks for checking. It was planned in the WebPlanner. Nothing unusual I can recall. I wasn't charting the slope while planning the route, so only noticed after saving. When I download (edit) the GPX & view in Garmin Basecamp, I can see a potential issue - point #11 appears to go backwards (180 degrees):

6f010b849a2f37312fdca9f2a6858be0

photo
1

Hi Ondrej - what if a point near the glitch was dragged just slightly, enough (maybe) to create a duplicate point but still the exact same lat/lon? GPX below - 3 points with exact same lat/lon but different ele. The GPX is created by the Route Planner - it has to be a bug.

877141dd195769048e13644c11bbc318

photo
1

Hi Andrew,

Thanks for looking into the GPX. It appears we're not filtering the planned track, leading to points being too close and causing spikes in slope despite minimal altitude changes. I'll consult with the Android team to align our web filtering/smoothing approaches.

This seems to be a rare occurrence, likely related to OSM data quality, as points are usually spaced at least 1 meter apart. I've noted this for future updates, though I can't provide an ETA at the moment. Appreciate your report.

Kind regards, Ondrej

photo
1

> Hi Ondrej - what if a point near the glitch was dragged just slightly, enough (maybe) to create a duplicate point but still the exact same lat/lon? GPX below - 3 points with exact same lat/lon but different ele. The GPX is created by the Route Planner - it has to be a bug.

It might not be an issue. Even though the longitude is the same, differing latitudes can result in varying elevations.

Leave a Comment
 
Attach a file