Closed Discostu36 closed 10 months ago
Both ways have
surface=paving_stones
.
Not exactly. The avoided way has cycleway:surface=paving_stones
and footway:surface=paving_stones
. So maybe this is because OsmAnd doesn't support these tags and thus has no knowledge about the surface?
Thanks for the hint. I've changed that and will have a look in a few hours if the routing is fixed. If yes, I'll add a new issue as a feature request that, for bicycle routing, cycleway:surface
should be considered.
It was a good idea, but not the source of the problem. The avoided way now as surface=paving_stones
, but the routing is still via the footway.
The problem is a different one:
https://github.com/osmandapp/OsmAnd-resources/blob/master/routing/routing.xml#L1675-L1678
<if param="avoid_unpaved">
<select value="0.3" t="highway" v="track"/>
<select value="0.2" t="highway" v="path"/>
</if>
The parameter doesn't do what it says on the cover. It doesn't check for surfaces, but it does only penalize tracks and paths. The behaviour should be changed, or the option should be renamed to "avoid paths and tracks".
But I am still not quite sure if that is the (only) problem here, as the "avoid footways" parameter should have a much bigger influence on the routing:
<if param="avoid_footways">
<select value="1.8" t="bicycle" v="official"/>
<select value="1.8" t="bicycle" v="designated"/>
<select value="1.3" t="bicycle" v="yes"/>
<select value="0.1" t="highway" v="footway"/>
</if>
The problem is a different one:
https://github.com/osmandapp/OsmAnd-resources/blob/master/routing/routing.xml#L1675-L1678
<if param="avoid_unpaved"> <select value="0.3" t="highway" v="track"/> <select value="0.2" t="highway" v="path"/> </if>
This is indeed strange and misleading - and wrong. Any way can be unpaved. In contrast, tracks and path can be paved. So the current implementation is just plain wrong.
This is mostly true for tracks / paths allowed for vehicles. Anyway will be open for suggestions especially if we can test the idea somehow in general
Anyway will be open for suggestions especially if we can test the idea somehow in general
Which kind of suggestions?
This option should check the surface tags. A paved road has surface paved, asphalt, concrete, concrete:plates, concrete:lanes, paving_stones, sett, cobblestone, unhewn_cobblestone, metal, wood, tartan, ...
In an attempt to reproduce this error, I entered the same settings as the user and navigated from point to point according to their coordinates. Currently, this bug is no longer reproduced. You can view it in our web version: https://osmand.net/map/?start=54.315300%2C10.122100&end=54.314560%2C10.122310&mode=bicycle#18/54.31495/10.12264
OsmAnd~ 4.5.0#351m, released: 2023-07-06
The web version doesn't work for me, route calculation doesn't finish. But you have chosen a different driving style than I did.
The bug has been resolved. After selecting the bicycle profile with all the specified settings, the navigation now correctly prefers the bike path when traveling from the starting point at coordinates 54.31528, 10.12205 to the destination point at coordinates 54.31456, 10.12230. You can access the preferred bike path using this link:: OpenStreetMap Bike Path.
For a web version of the navigation, you can visit the following link, which includes the specified start and finish coordinates, as well as the bicycle profile settings: Web Version Navigation.
OsmAnd~ 4.6.0#881m, released: 2023-10-17
Thanks!
Looks like this is no longer reproducible ever with reverted commit
Currently, routes using the specified parameters are calculated identically. It is only worth noting that when the "avoid unpaved roads" option is enabled, it is calculated correctly in iOS, but in Android the road is calculated via footway. However, if you turn off this option, the route will be calculated correctly.
OsmAnd~ 4.6.0#1160m, released: 2023-12-05
Android | iOS | Web |
---|---|---|
Ok, so the original bug still exists as reported in the original post. @xmd5a2 could you reopen?
I think it is fixed finally
Unfortunately, the bug was not fixed. I updated the maps and the app, but with the "avoid unpaved roads" option enabled, the route is calculated incorrectly. On the Web version and iOS, the route is calculated correctly, regardless of the "avoid unpaved roads" option.
OsmAnd~ 4.6.0#1181m, released: 2023-12-09
The "avoid unpaved roads" option is disabled | The "avoid unpaved roads" option is enabled |
---|---|
I can not reproduce the bug with nightly version of OsmAnd Android:
default | avoid unpaved |
---|---|
The bug has now been fixed. On the last nightly build, the road builds correctly regardless of the "avoid unpaved roads" option enabled.
OsmAnd~ 4.7.0#1233m, released: 2023-12-18
Description
I have the "avoid unpaved ways" and "avoid footways" options activated in bicycle routing. This leads to this footway being preferred over this designated cycling path in bicycle routing.
If I turn off the "avoid unpaved ways" rule, the correct route is chosen.
Both ways have
surface=paving_stones
.How to reproduce
Bicycle routing from 54.31530° N, 10.12210° E to 54.31456° N, 10.12231° E with these settings:
Map data: Schleswig-Holstein 2023-06-01 with Osmand Live.
Actual result
Footway is preferred over path with bicycle=designated with same surface.
Expected result
Cycling path should be preferred.
Environment OsmAnd Version: 4.3.12 Android/iOS version: Android 12 Device model: Fairphone 4