vehicle:conditional=no spreads from one node to whole highway

Peter0 commented 5 months ago

Describe the routing engine used (required)

[×] OsmAnd's in-app offline routing
[ ] Any online routing provider (YOURS, openrouteservice, OSRM, etc.)

Describe your routing Profile (required)

Standard car Consider temporary restrictions

Describe your start and end points (required)

Start: 50.73183 7.08673 Dest.: 50.73099 7.08747

Describe the actual route (required)

Actual route doesn't lead into dest. street (way #4692930). Route ends at position with lowest distance at neighbor-street (way #1152458094 or #1152458088). Note that there is a new node with temporary vehicle blocking (node #11877065356).

Describe the expected route (required)

I’d expect that route ends upon way #4692930. It does so already if I don't tick option "consider temporary restriction". Flipping direction shows no strange behaviour: Starting point opon way #4692930 seems to be no problem.

Describe what Maps you used (online or offline) (required)

[×] Offline maps offered within the OsmAnd app for download.
[ ] Online (tile / raster) maps Current maps used: Europe, Germany, NRW, LVR Köln as of May 2024 Live updates

Your Environment (required)

OsmAnd Version: ~ 7.4.10
Android/iOS version: e/OS similar Android 9
Device model: Samsung Galaxy J5

Anything else? (optional)

No response

aceman444 commented 5 months ago

Why is the tag vehicle:conditional=no? There is no condition specified. There is no OsmAnd 7.4.10. Did you mean 4.7.10 ?

But other than that, I agree OsmAnd should route up to that point where the blockade is, not just some neighbouring road. If that does not happen, I also think it would be a bug.

Peter0 commented 5 months ago

Of course, I meant 4.7.10. Sorry for the transposed digits.

Both Vespucci, as well as https://www.openstreetmap.org/node/11877065356 shows "no @ (2024 May 1-2024 Dec 31)". Where do you see that there is no condition?

aceman444 commented 5 months ago

It was 'vehicle:conditional=no' in your report title :) Yes, the data real has a condition specified. But that node is only 2 days old. It is quite possible it is not yet in OsmAnd maps. Do you use the Live updates of maps in OsmAnd?

Peter0 commented 5 months ago

Yes, I use live updates.

aceman444 commented 5 months ago

I think routing using live updated maps does not work 100% correct. You can see there is an option in navigation settings whether to use data from live updates or not. So maybe developers know there are some problems with it yet.

Peter0 commented 5 months ago

Indeed, I wasn’t aware of such an option. Could you please describe where it is? I’d expect it under "Settings" at the navigation start/dest. input dialog requester, where one can also find things like "permit private ground", "consider temporary restrictions" and the like. (Note that all mentioned setting’s names are translated by me on an ad hoc basis and therefore probably wont exactly match the english version’s terms.)

aceman444 commented 5 months ago

It is there below "consider temporary restrictions", there is "navigation settings", then "route parameters" and inside it is "OsmAndLive data" -> enabled/disabled .

yuriiurshuliak commented 5 months ago

The bug has been reproduced. When navigating using the specified coordinates and activating the "Consider temporary restrictions" feature, you can notice that the navigation ends too early. The route ends at the nearest turn to the destination point. Here is the link to the web version:link.

Related to #19707

OsmAnd~ 4.8.0#2270m, released: 2024-05-08

https://github.com/osmandapp/OsmAnd/assets/127092082/707d8a30-a5ca-4fff-a2ff-e5c3ff628f4b

Peter0 commented 5 months ago

To me, your video shows a slightly different effect/issue. The original posting is about an issue during route-planning time. Yuri's video, as well as the mentioned issue #19707 are about issues during navigation-in-progress time.

Peter0 commented 5 months ago

May the video shows an effect of inconsistent data? Take into consideration that the "barrier" node is a relatively young/new part of OSM data. It looks like the barrier wasn't seen during route planning, but was "feeled" during navigation-in-progress. In addition, I can't tell whether the last bit of planned route is a straight line due to the straight underlying street, or due to a tangled/clueless router that simply draws a straight line from last "accessible" place to final destination as kind of last resort action.

vshcherb commented 4 months ago

Looks like this https://www.openstreetmap.org/node/11877065356 not supported however it looks a bit strange

DmitryAlexei commented 3 months ago

Todo:

investigate how the tag vehicle:conditional=no should work. Is it already supported?
what do we have in binary inspector?

xmd5a2 commented 3 months ago

vehicle:conditional means access restriction while condition is true. As far as I know it is supported in routing: link We do have vehicle:conditional in data not on a whole way but only on a way's node Road 300347531 osmid 4692930 highway='residential' lit='yes' maxspeed='30' surface='asphalt' osmand_ele_start='59' osmand_ele_end='59' osmand_highway_integrity_brouting='0' sidewalk='yes' name="Händelstraße" name:etymology:wikidata="Q7302" pointtypes [[2. vehicle:conditional='no @ (2024 May 1-2024 Dec 31)' 50.730923 / 7.0865946 ]] lat/lon : 50.73091 / 7.0864444 , 50.730923 / 7.0865946 , 50.731037 / 7.0882792 , 50.73106 / 7.088362 ,

Peter0 commented 3 months ago

From a mapper's point of view, using it on a node instead of on a way seems straightforward, as long as there is a relatively small/short obstacle. Even when there is a direction-dependent tag (e.g. a short piece of oneway), it would seem reasonable that the direction is "inversely" inherited from the "underlying" way.

RZR-UA commented 2 months ago

The tag vehicle:no (also with conditional) is processed by OsmAnd in the same way as any other "restriction" tags.

The problem happens only when "restriction" node is placed on the edge of the long road segment (the whole highway is not affected indeed).

In such situation a whole street might be "avoided" if most of the street consists of 1 long segment.

That's exactly what this Issue's case is.

The fix is proposed.

Check the video:

https://github.com/user-attachments/assets/0707e2f4-d56c-44a8-80fa-e8c067a6e717

RZR-UA commented 2 months ago

TODO

[x] Java
[x] C++
[x] add routing tests
[x] test OsmAnd iOS (native)

RZR-UA commented 2 months ago

Android/iOS tested:

vshcherb commented 1 month ago

Simpler approach to be tested (https://github.com/osmandapp/OsmAnd/pull/20610/files)

RZR-UA commented 1 month ago

Simpler approach to be tested (https://github.com/osmandapp/OsmAnd/pull/20610/files)

It is not working correctly.

The tests are improved.

Please review.

vshcherb commented 1 month ago

[x] Attach OSM.gz to 68-70 test
[x] Port to C++

vshcherb commented 1 month ago

Looks the same issue but that wasn't fixed correctly ? https://github.com/osmandapp/OsmAnd/issues/16173

Peter0 commented 1 month ago

Thanks

RZR-UA commented 1 month ago

It should be fixed better:

https://test.osmand.net/map/navigate/?start=50.730968,7.086938&end=50.731600,7.089336&profile=car&params=car,routing:astar_normal_java#18/50.73131/7.08992

The route passes through a barrier if it starts on the "forbidden" segment.	Incorrect (master)	Correct (reached with more complex method)

vshcherb commented 1 month ago

Site clearly was not reloaded as it has bugs even for https://github.com/osmandapp/OsmAnd/issues/19773#issuecomment-2295382709. Probably site doesn't use current time restrictions

osmandapp / OsmAnd