How can I know why an OSM way cannot be used for routing, and how can I fix it

Question

Background

I use osm2po in an application that needs to calculate distances, times and path between locations.

In short, I take data from Geofabrik as input to osm2po to output a directed graph with OSM Nodes as the graph nodes, and OSM Ways as the graph edges.

Later, to calculate distance, time, and path between two locations, I use this graph to locale the nearest nodes, then use one of the osm2po router to build a route between those two nodes.

This is working fine most of the time.

And when a routing can not be done, it is usually because the data from OSM (particularly OSM ways) contains error or is absent.

More to the point

Through debugging a particular case, I located two nodes that cannot be routed from one to the other.

This one and this one.

As you can see, the only way those two nodes can ever be routed together (using a car) is somehow exiting their local streets and going through this way.

After more debugging, I see that osm2po never use this way, I guess it does not see it as a valid segment.

My questions

1. Looking at the OSM data, how can I know (understand) why this way is not valid for routing ?
2. Related to my first question: how can I fix (submit modifications to) OSM to allow routing using this way ?

EDIT:

I forgot to say that if I try to route from one node to an other node that are part of this same way, the routing is obviously working fine.

Answer 1

Ok, I am sorry about me answering my own question. I guess I had to ask the question to think about it more and be able resolve the problem.

It turns out the problem was not in the OSM data but with the osm2po default config file I use to generate the graph.

The problem

Somewhere (line 188, if you are using osm2po 5.1.8) in the default config file, there is this line

wtr.allow.motor[car|_vehicle].[yes|destination] = car

This line is used to include in the final graph (for car routing) the ways that have the tag motorcar or motor_vehicle associated with the value yes or destination.

And a couple lines under:

wtr.deny.motor[_vehicle|car] = car

This line is used to not include in the final graph all the ways that have any other values (so other than yes or destination) for the above tags (motorcar or motor_vehicle).

And when we look at this way, we can see that it indeed have the motor_vehicle tag, but its value is designated.

So osm2po dutifully rejected the way from the final graph therefore kind of answering my first question.

The solution

I just needed to copy the defualt osm2po.config file in my project, replace this line

wtr.allow.motor[car|_vehicle].[yes|destination] = car

with this line

wtr.allow.motor[car|_vehicle].[yes|destination|designated] = car

then re-generate my graph and run my test case to see that it worked.

Now the final graph contains the way I was looking for and osm2po is now able to use it for routing.

Note

Depending on your routing needs, it may be worth looking at this page (in German, the English version is not very useful).

It explains somes of the values we can expect in this motor_vehicle tag.

For example, in found that I also need permissive. So in my osm2po.config file, I now have this line:

wtr.allow.motor[car|_vehicle].[yes|destination|designated|permissive] = car

Answer 2

Indeed, the default.config is very strict and to be honest it's too strict for my taste. I stumbled across a similar question weeks ago and modified the osm2po release notes for 5.1.0 to report this issue.

Your solution above is correct. But I think there are not so many more positive tags, It would be shorter to modify the deny-option instead to sth. like this:

wtr.deny.motor[_vehicle|car].no = car