routing for bike doesn't use height information to estimage duration of trip

starbrights commented 1 year ago

Description

The router returns a much to less time for bicycle rides and doesn't seem to use information of height.

Steps to reproduce

Using 4.5.10 (latest version from FDroid). Select a trip of around 6.5km and 400 high meters and I get a result of 21min. That's far to less. Or 11km and 900hm in 20min. This is far to less.

Used the offline map of Piemont/Italy, 3D map of (hole) Italy and lines of hight are loaded.

Actual result

Time is like drive in flat environment

Expected result

brouter returns a much longer time

Your Environment (required)

OsmAnd Version: 4.5.10 Android/iOS version: LOS 20 / A13 Device model: Samsung S10

sonora commented 1 year ago

Perhaps the issue title is mislesding because elevation data (if present on your device) is actually used when "Use elevation data" is active, right? Please activate/deactivate (there's a shortcut button on the route config screen) and observe the difference in travel time estimate.

scaidermern commented 1 year ago

For me the chosen route changes but the travel time doesn't (after adding via points so that the chosen route is the same in both cases). So it looks like height data doesn't influence the displayed the travel duration in bicycle routing.

With foot routing everything works as expected. The height information influences the travel time.

OsmAnd 4.6.2.

sonora commented 1 year ago

Yes, that's due to the "Hilly", "Less hilly" etc. route optimization setting for bicycles. Perhaps to start debugging this, select a short route up a road where there's no alternatives. For me the travel time does change, like e.g. between 11 and 14 minutes (1.9 km 60 m uphill).

starbrights commented 1 year ago

For me the route indeed changes when activate that, but not travel time (or only for a very small time that is caused by the few more/less meters to go. I would expect that travel time always uses hight information if available, even if route is not "optimized" for that, right?

BTW: Do you know what this height optimzation does? It can reduce the max number of hight, but sometimes it might be better to limit the steepness.

You might have newer versions, but in my version (which is latest available) this doesn't seem to work.

scaidermern commented 1 year ago

Perhaps to start debugging this, select a short route up a road where there's no alternatives. For me the travel time does change, like e.g. between 11 and 14 minutes (1.9 km 60 m uphill).

Nope, the travel time is the same, despite having to go 133 meters up.

photo_2023-10-05_09-53-43

https://osmand.net/map?start=47.593422%2C10.346116&end=47.608791%2C10.374468&mode=bicycle#13/47.576386/10.360292

From: 47.59342, 10.34612 To: 47.60879, 10.37447

With foot routing, there is a difference (51 min vs 1h 8 min).

starbrights commented 1 year ago

So, that seems to be a confirmed bug now. Thanks! Question for me is: Shouldn't be used height information in any case for travel time estimation? I mean optimizing the route is one thing, but taking into account for travel time a second.

sonora commented 1 year ago

BTW: Do you know what this height optimization does? It can reduce the max number of hight, but sometimes it might be better to limit the steepness.

If in the Navigation settings you tap on the text (not just the switch) "Use elevation data", you can select a preference in what fashion the routing engine should consider the topography (Essentially what degree of "hilliness" you want to afford or avoid vs. the detours needed.)

@scaidermern Yes, that looks like a bug, then. Have not been able to reproduce yet on my installations,. so it may depend on something we have not discovered yet.

DmitryAlexei commented 1 year ago

@starbrights Please add coordinates of your routes and profile export (menu > settings > your bicycle profile > swipe to the bottom > export profile)

aSemy commented 1 year ago

Here's another route with a very ambitious estimate for travel speed.

https://osmand.net/map?start=42.999203%2C142.859573&end=42.970737%2C142.752960&mode=bicycle#12/42.915255/142.806249

It's a 20km route with around 800m in elevation. OsmAnd (using Brouter) estimates 2 hours 40 minutes.

I've lowered the speed settings as much as possible.

When I rode this route over 5 years ago it actually took over 4 hours.

If I use Brouter and adjust the profile to match my power output and my bike's aerodynamic, weight, and air/rolling resistance properties I can get a much more accurate estimate of 4 hours 48 minutes.

DmitryAlexei commented 1 year ago

According to OsmAnd documentation (see articles about elevation data https://osmand.net/docs/user/navigation/routing/bicycle-based-routing#route-parameters---bicycle and default speed https://osmand.net/docs/user/navigation/guidance/navigation-settings#default-speed):

Elevation data option affects only routing (or how your route is calculated), not the Estimated time of arrival.
Default speed should impact on the arrival time.

Further testing shows, that Default speed doesn't change the arrival time. On the other hand сhanging max. speed change the arrival time, but do that disproportionally: reducing max. speed from 23 km/h to 9 km/h added only 4 minutes to estimated time of arrival.

starbrights commented 1 year ago

Sorry for delay, I am abroad. @DmitryAlexei : If docu says "elevation info does not effect ETA" : that might be correct (observed behaviour matches) - but that doesn't mean it is good or useful. And it is in opposite to pedestrian routing ETA. I just can repeat: Enable elevation optimization for routing is on thing and can be adjusted by switch - that is fine. But in ANY case it should use this data to change the ETA, because elevation is a fact and it has influence.

Min/Ave/Max speed goes with the surface than? Or what's its usage?

DmitryAlexei commented 1 year ago

Tested on the same route in default pedestrian and bicycle profile https://test.osmand.net/map/?start=47.078671,10.673660&finish=47.082111,10.705333&type=osmand&profile=bicycle#15/47.0806/10.6792

Pedestrian profile. Elevation data option (set to Less hilly) affects route distance (+0.59 km or + 17%) and time (+1h02min or + 119%).

Default speed doesn't change the arrival time	Max. speed changes the arrival time

Elevation data disabled	Elevation data enabled

Bicycle profile. Elevation data option (set to Less hilly) affects route distance (+0.73 km or +21%) and time (+5 min or +38%)

Elevation data disabled	Elevation data enabled

Now we can say, that:

Use elevation data option affects both distance and time in pedestrian and bicycle profiles
Use elevation data option has higher impact on ETA in pedestrian routing, than on bicycle routing
In pedestrian routing without Use elevation data option enabled, ETA is calculated using Default speed (Navigation > Settings > Navigation settings > Vehicle parameters > Default speed). It was set to 4 km/h in
In bicycle routing without Use elevation data option enabled, it is not clear how ETA is calculated. If it was calculated based on the Default speed (it is set to 10 km/h), the result would be 21 minutes. If it was calculated based on the Maximum speed, the result would be 6.4 min. So used values are somewhere in between.

So it looks like there may be an error in the ETA calculation algorithm in the bicycle routing. The approach to calculation can be synchronized with pedestrian profile, then the ETA calculation will improve and become clearer.

scaidermern commented 1 year ago

Now we can say, that:

Use elevation data option affects both distance and time in pedestrian and bicycle profiles

No. Unfortunately your test is flawed, therefore your observations are not useful. With elevation data enabled, the calculated route is a different one. The router is longer and therefore the time is longer, too. That doesn't tell us anything about whether enabled elevation data affects time, though!

Instead, choose a location where enabled elevation data will lead to the same route in order to check whether it influences time at all. I've done exactly this in my example https://github.com/osmandapp/OsmAnd/issues/18284#issuecomment-1748316984. In my case it is clearly shown that enabled elevation data does not affect time in bicycle routing. However, it does affect time in foot routing (as expected).

DmitryAlexei commented 1 year ago

@scaidermern just a small points to that discussion

From my point of view, when the routes completely identical, we cannot be 100% sure that the Use elevation data option works in this situation. Can it be, that routing algorithm doesn't use (or cannot use) elevation data in some cases?
On the other hand, when the distance and time increase disproportionately (the % increase in time is significantly greater than the % increase in distance), this may indicate that the Use elevation data is somehow taken into account.

RZR-UA commented 1 year ago

https://github.com/osmandapp/OsmAnd/pull/18549

RZR-UA commented 1 year ago

https://github.com/osmandapp/OsmAnd-core-legacy/pull/152

RZR-UA commented 1 year ago

Proposal:

Use vertial-to-flat meters ratio (Naismith's/Scarf rules) for the bicycle profile. Ratio 1:8.2 is based on Scarf's analysis of cycling on mountainous roads. More complicated method (VAM) would be used in the future.

vshcherb commented 1 year ago

Fixed

RZR-UA commented 1 year ago

Elevation data is used to optimize routing: reducing priority for higher slopes, penalties non-preferred roads. Finally, elevation data affects the routing time using the vertical-to-flat distance ratio. For the latter, OsmAnd uses Naismith's number by Scarf (1:7.92 for pedestrian profile, 1:8.2 for bike profile). Link: https://en.wikipedia.org/wiki/Naismith%27s_rule

sonora commented 1 year ago

@DmitryAlexei Yes, for the documentation you may focus on section "Scarf's equivalence between distance and climb" in the above wiki article. Scarf is the generalization of Naismith, facilitating scaling with your individual default speed (a parameter you can set individually in OsmAnd's profiles). From that, as per Sacarf, we determine the extra seconds you need per vertical ascent meter, and add it to your estimated travel time.

RZR-UA commented 1 year ago

Naismith's numbers by Scarf are now used by default, regardless of whether Use height obstacles is activated or not.

sonora commented 1 year ago

Naismith's numbers by Scarf are now used by default, regardless of whether Use height obstacles is activated or not.

Only disadvantage of the latest commit is you now cannot ever disable it? Not even if a user wants to convince himself if it is used, right? I would have said

let's enable "Use elevation data" by default (then Naismith is active),
but if users explicitly toggle the "Use elevation data" button on the route config screen, the difference in estimated travel time should be reflected (like we had it so far), or else we will receive support calls about the button not working as intended?

vshcherb commented 1 year ago

Nope we need to display routing cost as on web to avoid confusion with routing time. Routing cost needs to be explained

RZR-UA commented 1 year ago

Not even if a user wants to convince himself if it is used, right?

The easiest way to convince is to simply swap the Start/Finish points to ensure that the uphill route are slower than the downhill one.

Enabling "Use elevation data" seems like a good idea, in my opinion, but we need to improve its algorithms and performance first.

sonora commented 1 year ago

@RZR-UA Regarding "Swap Start/Finish points": I agree! But so far users could simply tap the button "Use elevation data" and it did the trick...

And when you think about it: If you disable "Use elevation data", as a user you would expect that Naismith/Scarf does not apply anymore, right? I think the latest commit has now changed that, or do I misunderstand?

RZR-UA commented 1 year ago

@sonora

In our opinion, users would prefer to feel the difference between uphill and downhill routes when they plan a trip.

This is the reason why we've changed the default behavior to always affect the routing time visible to users.

If you enable "Use elevation data", you'll have a more realistic route (hilly, less hilly, etc).

Indeed, in this case, the routing time might increase but become more realistic.

PS. We should understand that Naismith's numbers by Scarf (7.92, 8.2, etc) are based on the real track data analysis. Therefore, these numbers would be correct only for the realistic routes. This is why I personally agree with you about the idea of using elevation data by default (for foot/bike profiles), but first, we should revise algorithms used for this option.

sonora commented 1 year ago

Here's the problem with the latest commit:

In the pedestrian profile, the only functionality of the "Use elevation data" button is whether Naismith should be applied or not. The latest commit has made that button functionless.
It's true that in the bicycle profile, the button "Use elevation data" also governs the impact on route selection, so there it's different: But also there: If we decide to apply Naismith even if a user explicitly selects "Use elevation data"=No, that makes no sense, it will be perceived as a bug.

What problem exactly were you trying to solve by the latest commit? If it is that Naismith should be used by default for ped/bike navigation (if elevation data is available on the device), I propose the proper solution for that is to enable the "Use elevation data" button by default upon entering the route configuration. But I propose to back out https://github.com/osmandapp/OsmAnd/commit/5bd3fff16f6f11d73eeed3921ab8da98fd216bc6 which simply ignores a setting the user has set, that introduces a bug?

RZR-UA commented 1 year ago

Pedestrian profile, w/o use elevation data:

Pedestrian profile, use elevation data enabled (= less hilly route):

So, with the pedestrian profile, the Use elevation data option affects the routing results, too.

The latest commit makes routing time more realistic even with default settings without optimizing route itself by using elevation data.

Let's try to differentiate between concepts:

1) The "Use elevation data" option might optimize your route to be less hilly and/or more realistic

2) Routing time calculations always use Naismith's rule to help estimate the time you will spend on a route

vshcherb commented 1 year ago

Yes @sonora use elevation data will be deprecated and buried in settings. The direction, routing UI time will always include penalty by Scarf rule which we can do configurable later in UI similar to CO2 settings.

Instead of Elevation data will be global setting Preferred Terrain: Any, and others which will calculate routes with coeffiecients:

Any - give me fastest route unrelated elevation
- 1 km detour equals to 50 m uphill 5% = 30 m uphill 13%, ...
- 10 km detour equals to 50 m uphill 5% = 30 m uphill 13%, ...
....

They will have reasonable name but we will work out on displaying number of equivalents. Though it's not related to time ! Time is subject to personal settings, its related to the route geometry.

So let's not confuse routingTime which is minimal energy (or in case any where energy is equal for whole relief)

vshcherb commented 1 year ago

@RZR-UA plesase provide numbers for relief smoothness settings cyclist / pedestrian to include in documentation

Hilly - 1 km flat detour = 50 m uphill 5% = 30 m uphill 13% = ...

sonora commented 1 year ago

Ah, ok, maybe I remembered that wrong then. In that case we probably need better wording then, something like "Topography optimized route" instead of "Use elevation data".

RZR-UA commented 12 months ago

@DmitryAlexei please update doc by this way:

For pedestrian/bicycle profiles, append the text to Note section of Use elevation data parameter:

Regardless of whether elevation data is used to optimize the route, OsmAnd always takes elevation into account for the route time (time to cover the distance) by using Naismith's rule (Link: https://en.wikipedia.org/wiki/Naismith%27s_rule#Scarf's_equivalence_between_distance_and_climb)

That's all at the moment...

DmitryAlexei commented 12 months ago

Added info, that OsmAnd always takes elevation data into account with pedestrian and bicycle routing https://osmand.net/docs/user/navigation/routing/pedestrian-routing#overview https://osmand.net/docs/user/navigation/routing/bicycle-based-routing#overview

yuriiurshuliak commented 11 months ago

Following the recent modifications, the elevation data is now employed irrespective of the setting "use elevation data" being disabled. OsmAnd consistently utilizes elevation data based on Naismith's rule to calculate estimated time of arrival (ETA) or time taken to cover the distance. When the option is off, the app computes the shortest path exclusively. You can compare this functionality through the screenshots provided below.

OsmAnd~ 4.7.0#1264m, released: 2023-12-22

Before fixing	After fixing

Before fixing	After fixing

Before fixing	After fixing

EugeneZmeuk commented 7 months ago

16-04-2024 Review

osmandapp / OsmAnd