Routing Issues with ignoring access tags

General talk
8

But I think the mapper should know what is implemented in the most relevant router and what is not.
There are often different ways to model the situation. (I guess the most simplest way is mostly the best way.)

9

can you add here links to reports on their issue trackers?

Making such list without reporting issue to authors is not an optimal way of getting bugs fixed

10

is there any case at all where it is a good tagging?

why not just use oneway:bicycle ? Or is there some need for exotic bicycle=forward=destination ?

When this would be used?

cycleway:oneway | Keys | OpenStreetMap Taginfo is apparently not even documented and used 1520 times, lack of support in router seems to be a good thing to me

11

For cycleways that are designated (and mandatory) in one direction and only allowed in the other direction.

12

The bugs should be reported.
I corrected my first statement: Only issues that will not be fixed by reasons may be documented.

Sorry this was my generalization of cyleway:left, cycleway:right, cycleway:both.
Usage see my link to the discussion. (How to tag a oneside - both direction cycleway along a oneway street without seperate line?)

13

But this is a rare feature of Germany and can certainly be mapped.
remember: designated does not mean mandatory

not a oneway case:

bicycle:forward=designated    (because of DE:240)
bicycle:backward=yes             (because of DE:239,1022-10)

you may better (additionally) tag

bicycle=designated
maxspeed:bicycle:backward=walk

in case:

bicycle:forward=designated
bicycle:backward=no

you may better tag

bicycle=designated
oneway:bicycle=yes
14

There is typically a “misunderstanding” of “*=destination” - For this one has to understand how Routing and their respective algorithms work, and how the type of data is mapped into the graph. Basically the routing is done my searching for the “cheapest” solution to a graph problem. The cost is on the edges and these can be different depending on transportation type, maxspeed etc.

Now to get the routing to “most likely” avoid *=destination tagged edges one simply increases their “cost”. But this is not a real solution this is only an approximation. As long as there is a cheaper route one will get a solution around the *=destination tagged roads. But there is always a sweet spot between something expensive with *=destination and the road around. You cant make it “infinitly” expensive to go in there, then the routing will possibly even worse by forcing the router to ALWAYS enter the road on the shortest snippet.

So - even if we tag stuff as *=destination - in some corner cases you will see through traffic when there is no “good” solution to avoid it.

Flo

2 Likes
15

In theory routing could be smarter and allow destination only on final/initial stage.

Or to take into account not only raw position of address but also location of entrances/footways and so on.

1 Like
16

@folhhoff, You are right, this is how routing is often working with soft exclusions instead of hard conditions.

But in the bicycle case there seams to be no penalty at all. OpenStreetMap

17

OSRM’s automated tests show that it does respect bicycle:forward and bicycle:backward:

Note that OSRM sometimes produces routes that require you to dismount and push your bike against one-way traffic in the opposite direction, under the assumption that there’s a shoulder, sidewalk, or verge allowing you to do that.

There’s a proposal to apply the same logic to streets that prohibit cycling in one direction:

4 Likes
18

One idea would be not to penalise distance on the *=destination edges, but to insert “virtual edges” on ENTERING a *=destination road segment (read: subgraph - 2 virtual edges, oneways) and make that very expensive.

When your destination is in one of those segments/subgraphs its the same cost independent from where you enter, but it does not make a difference how much distance you travel on such a segment/subgraph.

Flo

1 Like
19

that would result in problems where routing could prefer to end routing far away from target without entering destination

(part of problem of high cost on entering or leaving is that in initial section leaving is fine and on final approach entering is fine)

20

Shouldnt. Typically you map an “address” to a point on a reachable point on the road network which will be reached disregarding the cost.

It may be something else when you assume routers have some “flight of a bird” capabilities, beeing able to disregard the graph altogether using a high cost.

And a high cost on entering that area is a NOOP as it doesnt make a difference from WHERE you enter. Its a one time fee.

Flo

1 Like
21

It depends. A truck delivery dispatcher may want to get “no routes found” rather than a route that unavoidably traverses hgv=no. On the other hand, in some localities, it is legal for certain trucks to ignore hgv=no at the end of the route or within a certain distance of the destination. California even has a standard sign for where trucks may go a certain distance for specific services like gas and food but are otherwise prohibited from using the road. hgv:national_network=service_access has been proposed for this purpose, but it hasn’t been mapped yet.

If you’d like to test out routing edge cases with access=destination, there are some entire towns that apply destination-like restrictions to their residential streets, but our coverage of these restrictions may be incomplete. In some cases, it might be necessary for a local to enter and exit multiple destination “zones” to visit a friend across town.

22

But this is not the case today. Here some QA stuff i am doing for Germany:

https://osm.zz.de/dbview/?db=addresses-nrw&layer=routeable#51.32741,7.14328,16z

The pin marks the position of an address, the line points to the position on the road network OSRM will send you to. This is the result for the /nearest api call in OSRM.

So whenever there is the slightest chance to send you to an address (whatever the cost is) you will be send to the nearest point. The long distances here are a result of road network not usable by car e.g. tracks, access=private and the like.

Flo

1 Like
23

most of them appears to be mistagged (many should be marked as driveways instead)

24

Thats correct. Thats why i produce this QA Map. But it shows that the nearest point on the reachable network will be navigated to. Not the one which is “reasonable cost effective”.

Flo

25

Yes, OSRM does ignore access restrictions like access=private if necessary for reaching the destination, and it is based on nearest neighbor search. I was merely pointing out that the expected behavior depends on the use case, especially when it comes to specialized vehicle types like hgv. Many truck restrictions exist not for the vehicle’s safety but for the comfort or safety of the neighborhood. Since the restrictions are based solely on law rather than any physical obstacle, there can often be very nuanced exceptions. I think it’s important to be aware that these nuances exist before jumping to the conclusion that a particular routing behavior is incorrect, for example.

26

Sorry - thats wrong. access=private or for your profile non existant (read: not usable) road segments fall of the graph completely. So the “nearest” api call search jumps to the nearest point on the next usable road which might be on the other side of the motorway, canal or rail track. To give you orientation the web framework draw you a line from the “nearest” result to the point you asked for. But thats far from “ignoring access restriction on the road network”.

That is the QA Map overlay i produce. An address, the “nearest” point on the usable road network (for that profile) and if they are >100m apart i draw it on the map because someone most like produced unusable roads. Made tracks to farmyards or sprinkled access=private all over the place.

OSRM shows you a “direct line” from the road to the final destination you tried to reach. But thats in a lot of cases a completely bogus assumption that that is passable.

Short example:

You end up on a differen Farmyard, on the other side of the rail track. Multiple kilometers away.
https://osm.zz.de/dbview/?db=addresses-nrw&layer=routeable#51.6884,7.61954,17z

On the other side of the Ruhr - 150m Water inbetween:
https://osm.zz.de/dbview/?db=addresses-nrw&layer=routeable#51.39366,7.44039,17z

Motorway A1 - “You have reached your destination”
https://osm.zz.de/dbview/?db=addresses-nrw&layer=routeable#51.19104,7.24068,17z

This was a basis for my discussions on a “Navaid relation” a couple years back on the tagging mailinglist which was shot down. Problem persists in the map data and is by todays tagging/relation unsolvable.

Flo

27

I’m aware of the crow-flies line from the requested waypoint to the snapped waypoint in the returned route, but I was referring to the behavior of actually ignoring the access=private at the beginning and end of the route, as described in the Mapbox blog post I linked. Maybe I was mistaken in thinking that this behavior is part of the default OSRM car profile; it might’ve been specific to the custom OSRM profile that the Mapbox Directions API used until it migrated to Valhalla.

Relatedly, OSRM conflates private with destination, classifying both as restricted unless a service road is involved: