Routing for roads with no entry or exit

[samlown]

Is there any way to force OSRM to come up with a route when the origin or destination points are on a one-way road with no apparent exit?

Here's an example in Madrid where both the origin and destination are problematic: http://osrm.at/6t4

There are obviously errors in the source data causing this, but I'd love to try and find a way to get around this issue. I'm less worried about accuracy, and more interested in always getting some kind of result.

Thanks in advance for any suggestions.

[emiltin]

wouldn't it be better to fix the map errors? maybe a tool like this can help http://tools.geofabrik.de/osmi/

otherwise a quick fix would be to simply ignore oneways tags? if you're already going against oneways at the start/end, maybe it's not so bad to do it elsewhere?

[samlown]

It would be interesting to find an algorithm that could ignore or fix one-way streets with no exit, but I don't know enough about this subject to know if that is possible. I didn't see anything in your osmi link that might help with that.

I did actually try ignoring the oneway tags, but it looks like there are lots of one-way streets in Madrid as the routes and distances of even short journeys changed radically.

[emiltin]

another work-around is to do something like bicycle routing, where you are allowed to push bikes against oneways. this is what we do at http://ibikecph.dk. each instruction step includes a mode flag that tells you wether you're riding or walking. however we're using a custom branch to achieve this. the code is on github.

[emiltin]

a simpler version of the above would be to always allow routing against oneways, but at a low speed. that way, it would be avoided usually, but if there is not other way, it will go against oneways. the downside would be that your travel time might be less accurate.

[emiltin]

@DennisOSRM doesn't the 'island' tool on geofabrik use osrm routing to also catch dead-end oneways?

[DennisOSRM]

It has been a conscious decision not to fix any of these errors in the router, but to let them be fixed in the input data, i.e. OpenStreetMap.

[samlown]

@DennisOSRM isn't that a tad unrealistic? I'm sure many people would love the source data to be 100% accurate, but you're talking about community provided data with potentially thousands of unskilled contributors who potentially don't appreciate that one-way streets with no exit are wrong.

Unfortunately, I don't have a deep enough understanding of OSRM to appreciate how complicated it might be to to solve this type of issue. My understanding however is that "accuracy" from a datasource, i.e. not finding the most optimal route, is very different to outright refusal to do anything, which is the result OSRM is providing in this scenario.

I find it a little inconsistent that I can set a pick-up location in the middle of the countryside and OSRM will find a route from the nearest road. Yet when I'm trying to find a path in the city there is much higher probability it will fail.

[emiltin]

one could argue that you're free to soften the requirement of perfect data in this case, by allowing routing against one ways, at a lower speed

[emiltin]

once separation of impedance and travel time is implemented in osrm, you could provide the same travel time for oneways, but use a very high impedance.

[samlown]

@emiltin thanks, that sounds like a good idea! Do you know when the separation is planned for?

[emiltin]

i don't know. i opened a ticket two years ago, #77 , and @DennisOSRM seems positive to the idea.

i had a go at it in this branch https://github.com/DennisOSRM/Project-OSRM/tree/feature/lua_impedance, however i didn't manage to get it working correctly.

[samlown]

I've been thinking about this some more. @DennisOSRM while this sort of issue might be regarded outside the scope of the router, would it be possible to exclude these types of roads from the extractor?

A one-way street without an entry or exit is about as useful as a waste paper basket or a footpath for a car. So surely it would make sense to simply ignore them from the data in the same way?

Any pointers as to where I might look in the code to solve this?

[emiltin]

Although you might not be able to exit from one of these roads, you can still enter them. If you remove them altogether you can neither enter nor leave. So i'm not sure it makes sense to exclude them.

Another idea: OSRM uses the z parameter to selectively ignore certain parts of the network depending on zoom level when you request a route. This is to avoid picking a start location on an island which would produce no routing result. Could this be extended to exclude islands caused by dead-end oneways?

[DennisOSRM]

Although you might not be able to exit from one of these roads, you can still enter them. If you remove them altogether you can neither enter nor leave. So i'm not sure it makes sense to exclude them.

+1

Another idea: OSRM uses the z parameter to selectively ignore certain parts of the network depending on zoom level when you request a route. This is to avoid picking a start location on an island which would produce no routing result. Could this be extended to exclude islands caused by dead-end one ways?

This is how we do it already. z14 is the threshold, IIRC.

[emiltin]

But are oneway deadends marked as islands? Since you can enter it, it's not entirely isolated - you just cannot leave it. So acutally osrm should have two sets of islands: Islands that you can leave, and islands that you cannot enter. When routing, osrm would then avoid 'cant leave' as origins, and avoid 'cant enter' as destination.

[DennisOSRM]

One could analyze that, yes. But OSRM is deliberately agonistic to these kind of issues on purpose. Only, when these issues are visible, the data gets fixed. And to aim the great Wayne Gretzky, the idea is to not aim where the puck is, but to where it is going.

[woodbri]

I can think of at least one valid situation where these oneway sinks and sources make sense. Think about a large parking garage say in a building basement. I could have a oneway access into it it and a separate one way exit out of it say on the opposite side of the block. While these are physically connected by the garage, the garage does not need to be modeled as the through way but it is a valid destination or source. So dealing with them this way does make sense.

[emiltin]

while the garage example makes sense, it could be easier modelled by using access=destination, which allows starting or ending, but not passing through.

[DennisOSRM]

@emiltin is right. Such parking garages should be properly tagged.

[emiltin]

doesn't osrm avoid islands when z is small, even though islands is usually caused by invalid tagging, ex unconnected ways?

[samlown]

Thanks for all the interesting feedback on this. In the case of a garage entrance, I'd probably still be more interested in arriving "as near as possible".

I'm convinced with all your analysis though. There are too many pitfalls to modifying the source data.

I'll try to approach the problem from a different angle in a new issue. The reason we're dealing with one-way streets in the first place is because we're trying to route between GPS data points, which are inaccurate. While the true starting point may be on a main road, the GPS might point to one of these one-way side roads. So perhaps a better idea is to route to "the nearest routable point", if possible.