Routing Issues with ignoring access tags

General talk
1

I like to collect the known but not fixed issues of routing engines/profiles in ignoring access tags.

Ignoring these values can happen for different reasons.

  • Software bug
  • New tagging scheme
  • Different interpretation of access tags
  • Different order of interpretation of implicit defaults and exceptions
  • Country-specific exceptions
  • Ignore common mapping errors
  • Ignore common signage errors
  • Ignore because the target group is not interested in the access bans.

Some errors may turn out to be correct, because e.g. the bike should be pushed instead of ridden. So please check the travel time. And please check the issue at different locations.

I want to collect such issues so that we can better understand them and find weaknesses in the documentation. And of cause we should try to get the real bugs fixed in the data, documentation or software. Please report new found bugs yourself!

Issues found:

GraphHopper Bicycle (I guess both is intentionally)

OSMAnd Bicylce

Komoot Bicycle Profiles

  • ignore vehicle = private (reported)
1 Like
2

I would say this is only relevant to collect them in the wiki if a routing engine indicated that they don’t intent to fix an issue. Otherwise it may be better to just report it to them (with a use case) so they can fix the issue.

2 Likes
3

Graphhopper and OSRM seem to ignore bicycle:forward and bicycle:backward tags. I‘ll analyze the issue further and then open tickets at their issue trackers.

2 Likes
4

See (Key:oneway - OpenStreetMap Wiki)

they also do not have implemented cycleway:left/right/both:oneway yet

The answer from GraphHopper was, that at the moment they expect all access:directional things to be tagged with oneway or oneway:* instead.

5

It’s important to make clear which implementation of an algorithm has a problem. Graphhopper deployed on site A may have a problem, but site B may not, because of differenr routing parameters used.

2 Likes
6

Yes, report them to the relevant issue trackers rather than putting them on an obscure wiki page. I don’t think Komoot has an issue tracker but the others do.

As @SomeoneElse says, the problems are usually with the default profiles of the routing engines, not with the routing engines themselves. cycle.travel uses OSRM under the hood but has entirely different access parsing.

3 Likes
7

And most importantly just because we’ve come up with a scheme to tag some obscure facet of access doesn’t mean it is practical and feasible to implement support for it (for example conditional access and other weird things).

4 Likes
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