search

abrensch / brouter

configurable OSM offline router with elevation awareness, Java + Android
MIT License
473 stars 113 forks source link

The least cost route is not being used #696

Closed fkoester closed 1 month ago

fkoester commented 1 month ago

I created my own profile and when I encountered any deviations from the expected results I usually could identify the cause, either a wrong tagging or a case I missed in my profile.

But now I have a situation where I have no clue why things go wrong. This is the route: https://brouter.de/brouter-web/#map=19/50.00594/8.22455/osm-mapnik-german_style,route-quality&lonlats=8.226534,50.005845;8.222569,50.005746

This is the route that is calculated using my profile:

Screenshot_20240511_095948

It is obviously not the shortest route. And when I manually insert another point on the desired route, it produces the expected route, which also has lower costs (see bottom right).

Screenshot_20240511_100150

I probably did a mistake somewhere. What do I miss? Why is brouter taking a route with higher costs?

If anyone could point me in the right direction that would be much appreciated :pray:

That's the profile I used: https://gitlab.com/metabolite/brouter-profile/-/blob/0a54529fec5b9ec0dc6590975974b37831b8dd32/vehicular_cycling.brf

vodie commented 1 month ago

This is a problem with the height buffer. If you take a longer route and force the Route by no-go areas (don't use intermediate points, because they reset the buffer) you see in the data that this segment is evaluated with 6000/km. https://brouter.de/brouter-web/#map=16/50.0058/8.2233/osm-mapnik-german_style,route-quality&lonlats=8.23367,50.007737;8.20204,50.002272&nogos=8.224322,50.006674,32;8.219283,50.001746,205;8.223221,50.008357,185

Screenshot_20240511-134502

With the detour you get a lower overall cost: Screenshot_20240511-135042

This is your uphillcostfactor for this segment. If you lower mixed_traffic_uphill_penalty from 4.3 to 3.5 or rise the uphillcutoff from 1.1 to 3 you won't have the detour.

quaelnix commented 1 month ago

At first glance this seems to be some kind of aliasing issue in the elevation buffer logic. You can fix it by either raising the downhillcutoff and uphillcutoff values back to the default of 1.5 m or by raising the elevationpenaltybuffer to 10 m.

Edit: On an aside the problem does not occur when using Sonny's LiDAR elevation data.

fkoester commented 1 month ago

Ok, wow! Thank you @vodie and @quaelnix for the detailed and very helpful explanation!

I raised the elevationpenaltybuffer to 10m as suggested which resolved this problem for me :+1:

I will try to further dig into the elevation data topic when I find some time, looks promising.