Weird driving directions / path generated in certain areas

[aarzhou]

I try to use OSRM to generate driving directions but it gives a weird result. I have checked the OSM data and I didn't see anything special there.

Can someone please help me find out whether this is an OSRM bug, or it is just a map issue that I can solve it by updating the OSM data.

I got the problem using version 5.25 built from source. But same problem can be directly reproduced on OSM website too. Here is an example:

I don't know why it does not just go straight and make a left turn at the end. The expected driving path can be generated using graphhopper though:

Thanks a lot in advance!

[danpat]

@mjjbell There is a no_u_turn via-way restriction in place here - any chance this is a bug with your support for via-way restrictions? I'm pretty sure you had a test case for this scenario.

[mjjbell]

@danpat this is a manifestation of an issue you pointed out in the original PR.

The duplicated edges that make up restriction paths are not included in the R-tree, so they can't be waypoints. This is a problem here as the optimal path to the target is half-way through the u-turn restriction path, so it instead finds a path to the target that doesn't go through a duplicated edge.

I don't know if there's a quick fix for this unfortunately. After applying the hefty #5953, support for duplicate restriction edges as waypoints is possible with a relatively small addition.

[mjjbell]

In case anyone has some suggestions, this is what OSRM is seeing in reduced form.

• Two edges are used to represent the target intersection.
• Only some turns exist from/to the boulevard, shown in red.
• The blue edge is the duplicate that implements the restriction and prevents the u-turn.
• The blue edge can not be a target for a route, so it's not possible to find a path via the one-way boulevard.

This is a single via-way restriction, so this issue predates the multi-via PR, hence why I suspect there isn't an easy fix without supporting multiple waypoints at each input location.

[aarzhou]

Is there any way to bypass the issue by modifying the OSM data?

[mjjbell]

Is there any way to bypass the issue by modifying the OSM data?

Only by removing the u-turn restriction, which isn't a good idea.

If you are already building from source, you can apply #5953 and mjjbell@5c8e729 as a patch fix.
Another report of the same issue confirmed that this worked.
I've also been using these changes in my own instance without any issues.

[aarzhou]

@mjjbell ,

Thanks a lot for your reply.

Just want to confirm. I need two fixes mjjbell/osrm-backend@3771e99 and mjjbell/osrm-backend@5c8e729, right?

And also, these two are from another repository, is there any difference? Can I just replicate these two changes to Project-OSRM I checked out, or I have to use mjjbell/osrm-backend?

Thanks again

[mjjbell]

And also, these two are from another repository, is there any difference?

It's just my personal fork of this repo. If you add it as a remote to your Project-OSRM/osrm-backend git directory, you should be able to cherry-pick those two commits over and make a build that fixes the issue.