Elevation Profile widget Uphill / Downhill wrong numbers

mikehgentry commented 3 months ago

Description

The numbers reported by the Elevation Profile widget are initially wrong, tapping on it seems to fix them, sometimes they fix themselves of their own accord.

Steps to reproduce

Create a new profile (I used Moped as a base for this test). Add the Elevation Profile widget.

Long press somewhere far away and select 'Navigation'.

When the route finishes calculating, tap in the map to close the navigation menu.

Actual result

The elevation profile widget can report incorrect numbers. Tapping on the widget updates it to seemingly correct numbers. At least once it spontaneously fixed itself for me, not sure what triggered that.

Triggering the bug isn't 100% reliable. Some combination of long journeys and having intermediate destinations seems to make it more likely to happen. Possibly tapping on the map as quickly as possible after the route finishes calculating makes it more likely to happen.

Expected result

Numbers are always correct.

Your Environment (required)

WARNING Crash-Logs MAY contain information you deem sensitive. Review this CAREFULLY before posting your issue!

OsmAnd Version: +4.8.6
Android/iOS version: 11
Device model: XCover 4s
Crash-Logs: ?

yuriiurshuliak commented 3 months ago

Please provide the exact coordinates where you noticed the incorrect data in the widget. Also specify the correct data that should be displayed. Additionally, a video or screenshot showing the bug in action would be helpful for further investigation.

mikehgentry commented 3 months ago

It happens absolutely anywhere, it seems to be a UI problem not a data problem. Sometimes it seems like it is using the data up to the first intermediate, sometimes the numbers are inexplicable. It might decrease 'total ascent' by 5 meters, or it might double it from 300 to 600.

Unfortunately as I said it happens more on longer routes, and those tend to crash OsmAnd or the screen recorder on my hardware, so I'm having trouble recording it. Here's a trivial example though - total ascent goes down by 2 on tapping.

[edit - ignore this video, it's a bad example - see below]

https://github.com/user-attachments/assets/3a8644e8-6c46-4b57-a651-4032cf42513a

scaidermern commented 3 months ago

I think I can reproduce it:

Calculate a route, tap start, the elevation profile widget will appear
Add an additional destination, tap start
The elevation profile widget will show the previous numbers until you move the map, then an update happens

Apart from that, I experience another minor issue: There are slightly differing numbers for uphill/downhill between the elevation profile widget and the navigation widget (in my case 314/170 vs 333/173). These numbers stay and don't get corrected. I guess there are different algorithms used for computing both numbers?

mikehgentry commented 3 months ago

I didn't even notice the discrepancy between 864 and 28-something, was busy trying to get a video to record without crashing. But you're right, that's definitely significantly broken!

Edit: turns out zooming out the numbers are closer, but they still don't match. Also, distinctly possible that the reduction by 2 in the above video is just jogging the graph slightly and showing different data, so bad example. But I've seen it double from ~300 to ~600, which can't be explained by that.

mikehgentry commented 3 months ago

I can produce this pretty reliably without intermediate destinations if the journey is long enough. It still keeps crashing the video recorder though :(

Another symptom I've just noticed: if you trigger the bug, tap to update to the presumed correct data, then minimise OsmAnd and bring it back to the foreground, it reverts to showing the incorrect data.

edit - here you go

https://github.com/user-attachments/assets/0f7b3cd4-219e-4778-bab3-0942cadf736a

mikehgentry commented 3 months ago

I played around with it a little more, and sometimes it zooms the elevation profile in, sometimes it doesn't (this seems to be pretty arbitrary - I'd prefer it if it didn't).

The incorrect numbers seem to be fairly consistent for a given route, and at least sometimes correspond to the zoomed in graph's numbers, so I suspect part of the bug is sometimes it displays the graph zoomed out but the numbers for the zoomed in graph.

DmitryAlexei commented 2 months ago

OsmAnd~ 4.9.0#3098m, released: 2024-08-30

Expected behavior of the elevation widget is described by the link https://osmand.net/docs/user/widgets/nav-widgets/#interactions-with-the-graph:

by default, the graph shows the route from the current location up to 10 km ahead
if you want to see the altitude and degree value at a particular point ahead on your route, you can tap anywhere on the graph and a pointer with the values will appear
uphill / downhill – shows the sum of the all distances with increasing altitude from your location point to the end of the visible graph, or for the selected section of the route without location point visible on the screen.

Actual result:

no slope information on the graph - bug
the uphill and downhill data in the route details and in the elevation widget is slightly different - might be a bug
in some cases, even when calculating routes shorter than 10 km (3.91 km on the first video, 6.56 - on the second), the graph in the elevation widget is zoomed in. So you need to zoom out to see the whole picture. might be a bug
when the graph in the elevation profile widget is zoomed in, you can tap on some point on the graph and see uphill and downhill information for that particular point on the graph to the end of the visible graph (it is expected behavior) - second video.

mikehgentry commented 1 month ago

Unfortunately that isn't what I'm seeing on 4.9.0

The first number it displays (129) comes out of nowhere - it's defaulting to showing the entire ~30 mile route. Tapping once updates it to a much more plausible 625 over ~30 miles, and tapping more after that doesn't change anything.

https://github.com/user-attachments/assets/eebcec28-d5dd-48dd-8d59-88e84a791650

In this second case the number spontaneously changes (I tap a bit later, but at the point the number changes I didn't touch anything as far as I'm aware).

https://github.com/user-attachments/assets/c619cdd4-d41f-45e5-9f06-087593f05757

Once it's started doing this, minimising the app then bringing it back to the foreground reliably brings back the unexplained number.

I've also found that if I get the bug to not trigger for a route that is sometimes susceptible to the bug, selecting the same route again won't trigger it. In other words I can't just keep regenerating the same route over and over again hoping for it to trigger -- I have to select another route first (or shut OsmAnd fully), then try the susceptible route.

vshcherb commented 1 month ago

Looks like we don't apply correct algorithm here and these numbers are not correct though it's confusing with this implementation to see uphill between which points is calculated.

mikehgentry commented 1 month ago

I agree, it's confusing. In my opinion the 'Uphill' / 'Downhill' fields should always correspond to what's shown on the graph. If you tap on a point to get 'uphill / downhill from here to the end of the visible graph', it should be put somewhere else (in a popup presumably, maybe the same one as has the height / slope on).

osmandapp / OsmAnd