8

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.

2
  • 1
    The Openstreetmap has a router of its own. You can access it by the traffic sign icon next to the search box. It routes fine on your example, so there is nothing wrong to the data, and no need for your question 2. The routing might fail due to access=designated, but that should be fixed on your router's side.
    – AndreJ
    Apr 17, 2016 at 6:09
  • @AndreJ , yes you are right. Indeed, I should have try to do the route in OSM before assuming that its data were involved in my problem. This would have lead my sooner to look at my router settings. Apr 17, 2016 at 12:33

2 Answers 2

5

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

4

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
6
  • always there to answer questions about your software, thank you :) If I understand correctly, setting no as value for wtr.deny.motor[_vehicle|car] will basically render the wtr.allow.motor[car|_vehicle].[yes|destination] kind of useless, since now every values except no will be accepted ? If yes, I should think about it a little more, because I am not sure I want to allow agricultural and forestry for example. Apr 17, 2016 at 12:46
  • Also, about that. Do osm2po persists this tag into the final graph ? For example, instead of having to build two graphs (one allowing local access (permissive|destination), and one no) , I could build only one graph with all the allowed tags, and choose at runtime which one of the allowed tags to use for this specific routing session. Apr 17, 2016 at 12:58
  • I just saw the release notes you are talking about, I guess I should have RTFM, it would have prevented me a headache ;) Apr 17, 2016 at 13:32
  • Since I cannot accept my own answer, and yours is more generic anyway and most likely to help others, I accept yours. Apr 17, 2016 at 13:32
  • Not really useless. Imagine a track or path where the car-flag is usually not set. Or think of ferries or railways. Here it does make sense to raise them to some kind of "drivable" way.
    – Carsten
    Apr 17, 2016 at 15:43

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.