Going around roundabouts strictly more than 360 should be discouraged

[phillegroom]

this cornercase

https://map.project-osrm.org/?z=16&center=49.457874%2C7.809327&loc=49.454958%2C7.814133&loc=49.458250%2C7.802889&hl=en&alt=0&srv=0

shows a restriction in place that discourages traffic to use a parasitic autobahn exit via a roundabout and encourages using the wide right-turn loop. OSRM decides to go around the roundabout more than once to circumvent this restriction.

Going around roundabouts more than once is caused by restrictions and should be penalized or even impossible.

[mjjbell]

I think there are two issues here.

Turn Restriction as Routing Suggestion

In OSM the no_right_turn relation added in this case is a prohibitive restriction, so this means that the path shown is not allowed under any circumstances. Turn restrictions shouldn't be added purely to influence routing choices.

If you want to change the routing choices, it should be via the routing profiles. OSRM does consider the costs of turns/u-turns when planning a route, see the car profile as an example.

Looping to avoid turn restriction

The weird looping to avoid a restriction is a known issue and a consequence of how the turn restriction is represented in the OSRM graph. Being able to detect these loops is going to require some additional path tracking logic, the complexity of which would require scoping out.

However, usually this only happens when the restriction is too specific. Take this no_u_turn example:

Which is performing the same looping trick to avoid the u-turn restriction.

When you look at the turn restriction, you can see that it covers a longer path than necessary.

If it is reduced to the section that we want to prevent u-turns on, then the looping behaviour would no longer be possible (as the extra loop would also be prohibited).

So strictly speaking, the routing engine is finding a valid route when looping, because it's never taking a restricted turn. There are some turn restrictions in OSM data that will need changing to avoid the looping behaviour. This requires reducing the restriction path to the minimal section required to represent it, which is probably a good thing (there might still be some edge cases, but they can be dealt with).

In the original example, reducing the restriction path would mean it only covers the roundabout section, which wouldn't make sense, and is probably an indication that there shouldn't be a turn restriction in place there.

[phillegroom]

Thank you for your comprehensive explanation.

All restrictions are routing suggestions. Which ones are morally or politically acceptable is lengthyly dicussed at OSM. Routers should be agnostic of that. I agree that it is up to the map's authors to avoid clumsily placed restrictions. Routers should not go out of their way to make sense of these in terms of a general loop-prevention.

If routers allow for looping in junction=roundabouts, however, restrictions involving roundabouts become (almost) meaningless. They just increase the route's cost by the additional loop (which is luckily enough in the original example).

OSRM seems to maintain some state for a roundabout because it gives an ordinal number in the driving directions when to leave the roundabout. (6th in the discussed case)

Since avoiding looping in roundabouts is a general traffic rule, couldn't that ordinal counter be expanded to avoid looping as part of how roundabouts are handled by OSRM in general?

[danpat]

Another somewhat related example here: -77.2121207,39.109386 to -77.215591,39.109920

Here, the intersection has an "only straight on" restriction, but no further restrictions on the internal intersection edges.

It does make me wonder whether a heuristic around "don't cross the same node again within X m" would be an appropriate general-purpose rule to avoid these kind of mini-loops.

[mjjbell]

Another example to confuse things. There are cases where doing a full loop of a roundabout is the correct route.

See this example, which is often part of bus routes and is too sharp a left-turn to take.

no_left_turn turn restriction

[phillegroom]

This would be exactly 360 but not strictly more than that.

To dan pat: Wouldn't that route be appropriate if a driver missed the right slip lane? It seems, there is no u-turn preventing restrictions in place. If this is not desired the router could be told so by appropriate restrictions. (I agree though that this route is not what any sane driver would choose...) I think this is a separate issue.

[phillegroom]

A 360 use of roundabouts is ok because it is a safe way of u-turning -- at least safer than other u-turn acrobatics.

[danpat]

@phillegroom The issue for the example I posted is that the way mappers choose to create ways/edges within an intersection often varies from the reality of the intersection. In the real world, doing a 270 degree turn inside the intersection space is almost certainly illegal.

There's a doc we wrote up at Mapbox about intersection modelling which covers lots of the issues:

https://labs.mapbox.com/mapping/mapping-for-navigation/modeling-intersections-for-map-navigation/

The pavement area that represents an intersection is often an open space. Connectivity between the incoming and outgoing roadways can be represented in multiple ways, for example, both of these approaches can give identical routing results, despite the visual representation differing.

Often mappers prefer to create lines on the map that create a visual map that looks best when rendered, but creates a more complex routing graph that ends up with surprising connectivity like my example. It's a lot less of an issue for singly-digitized roads, but it appears a lot for doubly+ digitized roads with large open space intersections with complex connectivity between incoming/outgoing roadways.

[phillegroom]

Dan, I fully agree with you that the substitution of a 90right by 3*90left is inappropriate and should not be suggested regardless of whether or not restrictions are inplace. (Good if they are but shouldn't be required to prevent suggestions your example shows.) Nonetheless, I think it is a similar topic not related to junction=roundabout because there is no explicit tagging. It may be related to junction=yes (which is not allowed for edges, mhhh... ).

Idea: Instead of a radius the minimal area circumscribed by the loop could be the criterion. How mappers describe intersections is a mess, indeed. It is a wonder that routers can make sense of that at all.

[phillegroom]

For roundabouts, the first edge of the roundabout stepped upon may not be re-stepped upon.

For "square-abouts" (the structures danpat mentions) there is two differences: 1.) There is no explicit tagging so some heuristic would be needed to detect these. 2.) The first vertex of the square-about stepped upon may not be re-stepped upon.

[mjjbell]

For roundabouts, the first edge of the roundabout stepped upon may not be re-stepped upon.

I have found examples of turn restrictions that lead to routes that traverse the first roundabout edge twice. This can happen when the restriction is preventing a sharp turn and includes a via way that is part of the roundabout itself.

• https://www.openstreetmap.org/relation/12602325
• https://www.openstreetmap.org/relation/11528691
• https://www.openstreetmap.org/relation/11500768
• https://www.openstreetmap.org/relation/10151595

https://map.project-osrm.org/?z=18&center=52.627673%2C-2.482417&loc=52.627778%2C-2.481633&loc=52.627459%2C-2.481869&hl=en&alt=0&srv=0

I expect there are similar cases for square junctions.

The concern I would have with a heuristic approach is that it makes the routing engine responsible for dealing with all the weird edge-cases, and might end up blocking valid turns too.

As it is now, OSM mappers can add restrictions to fix each individual case and not rely on an OSRM tweak. For example, to prevent circumvention of roundabout turn restrictions, a second restriction that prevents full loops could be added. That could be seen as tagging for the router though.

[phillegroom]

Out of curiosity, how did you find these?

As we can see, there is a need for restricting certain entry-exit combinations. When it comes to angular restrictions, the practice shown above is compatible with the (more or less unspecified) behavior of routers -- de-facto specifying the semantics of certain tagging practices. How restrictions are handled should be a property of roundabouts. Which I am sure could be agreed upon in lengthy discussions. Definitely not worth it.

A second restriction in the original example could indeed be used. However, that, by principle, would interfere with unrelated traffic. All in all, unpretty for various reasons.

OSM obviously grew before the advent of routing. Danpat's example shows that even the basics are lacking. Frustrating. And users of OSM-based routers feel this (I am one). Compared to the big G's routing services, OSM occupies a niche -- justifiably so. There is still a long way to go.

[mjjbell]

Out of curiosity, how did you find these?

I used Overpass Turbo to have a browse through restrictions with a via-way that is part of a roundabout: https://overpass-turbo.eu/s/19ue

[github-actions[bot]]

This issue seems to be stale. It will be closed in 30 days if no further activity occurs.