Mapping turbo roundabouts

[Peter_Elderson]

(draught)

Support request routing over turbo roundabouts

2023-05-08

This is a request to support turbo roundabouts in the router. Turbo is a type of two-lane roundabout where the two lanes are physically separated and no lane switching is allowed on the roundabout. From a particular lane on the roundabout, not all roundabout exits are available. On the other hand, often there is a choice of two lanes for a particular exit road, because multiple exits may lead to one multi-lane road.

We have developed and tested mapping and tagging for turbo roundabouts, which ensures that routers will find the correct lanes and exits as indicated on the road, if they pre-choose the right presort-lane.

Issues are:

1. If there is a choice of lanes to exit on a particular exit road, the router just picks one.

a. When navigating, the driver might want to have a choice. The choice may depend on local circumstances such as traffic density, which the router does not know.
b. If the driver approaches “automaticaly” on a particular lane which would be perfectly fine, the router may “force” a last second unnecessary side movement of the vehicle.

2. The announcements/turn by turn direction steps are not ideal. Ideally, the router would:

On approach of the junction

1. Announce the junction as a roundabout (seems to fail for turbo roundabouts)
2. Announce the overall direction change (according to the angle between approach road and exit road)
3. Announce the presort lane or lanes that will lead to the exit road (by lane number?)
4. Announce the exit to be taken (by number? See issue 3.)

On the roundabout:

5. Tell J.I.T. when the exit is to be taken (right turn, for my country, but maybe left for UK)
6. Announce a merge movement, if applicable.

3. Exit count

On regular roundabouts, all exits are available and will be included in the count.

On turbo roundabouts, it seems that non-available exits are not counted in. While exit counting on roundabouts is often confusing enough as it is, a count depending on the roundabout lane is even more confusing.

We don’t know solutions for these issues. Maybe solutions can be found in wording of the turn-by-turn directions, maybe the router profile needs to be adapted, maybe it’s a coding matter, maybe mapping and tagging need adaptations or additions. Can you help?

[Minh_Nguyen (Minh Nguyễn)]

@Peter_Elderson

We did not tag conditional turn restrictions based on the presort lane you came from!

It is possible to tag this using a connectivity relation. The benefit would be that routers could not only tell the user to follow the correct way but also tell them which lane to get into ahead of time, despite the gaps. But router support is still poor, and it wouldn’t be necessary to tag connectivity if routers could infer maneuver directions based on turn lane indications.

[Peter_Elderson]

@Minh_Nguyen

It is possible to tag this using a connectivity relation. The benefit would be that routers could not only tell the user to follow the correct way but also tell them which lane to get into ahead of time, despite the gaps. But router support is still poor, and it wouldn’t be necessary to tag connectivity if routers could infer maneuver directions based on turn lane indications.

True. As it stands, the Dutch mapping supports regular routing over turbo roundabouts. The just do not tell which lane to pick. The information is there, however, in the turn:lane=* tags of every approach. And because the multilane approaches actually split into two separate ways, they can actually tell the driver to keep left or keep right.
Thinking out loud about tree-lane approaches… (“rotor turbo” design) they know which one to take, so they could indicate that as left lane, middle lane, right lane.

We have even more complicated roundabouts where approaches, after separation for the end direction, can have multiple lanes (lets call them sublanes) going there. The router/navigator does not need to pick a sublane, but it should tell the driver which set of sublanes to pick. I can imagine that’s a challenge, although the information is there. Once on the roundabout, just announcing the exit JIT is enough. An exit never crosses another lane.

PS sorry, didn’t look at the quote!

[Peter_Elderson]

@Minh_Nguyen

@Peter_Elderson

We did not tag conditional turn restrictions based on the presort lane you came from!

It is possible to tag this using a connectivity relation. The benefit would be that routers could not only tell the user to follow the correct way but also tell them which lane to get into ahead of time, despite the gaps. But router support is still poor, and it wouldn’t be necessary to tag connectivity if routers could infer maneuver directions based on turn lane indications.

How would this work? As I understand it, you would need connectivity relations for all possible routes over the roundabout. Or is your suggestion to use a connectivity relation only for the situation I described?

Edit: Did some digging. Turn restrictions can have multiple via ways. I think this would cover the restriction I described: members > role via > “The … way(s) between the end points across which you would travel (if the turn weren’t restricted)”. I believe turn restriction relations are supported by most routers, thought I don’t know how far this support goes.

[Minh_Nguyen (Minh Nguyễn)]

Connectivity relations are similar to turn restrictions but more granular and not necessarily about turning. They indicate how you get from one lane of a way to one lane of another way when that detail isn’t otherwise obvious. A turn restriction with via ways is potentially useful for a roundabout, but it can’t tell the router anything about the lanes before the roundabout that aren’t physically separate.

[Peter_Elderson]

@Minh_Nguyen

A turn restriction with via ways is potentially useful for a roundabout, but it can’t tell the router anything about the lanes before the roundabout that aren’t physically separate.

No, that information is in the turn:lanes tag. Note that with turbo roundabouts, the approach lanes are phyically separate so in the detailed mapping scheme they are separate ways, usually with a turn tag. I think if it would help routers to give better driver instructions, it would be alright to make the turn tags “strongly recommended” for turbo roundabouts (or else the driver instructions would be less precise).

Anyway, I think there is no ground truth for this restriction, so I will not map it. Other mappers think it should be mapped; discussion is still going on, but it’s good to know a documented way to (not) do it.

[Minh_Nguyen (Minh Nguyễn)]

@Peter_Elderson

I think if it would help routers to give better driver instructions, it would be alright to make the turn tags “strongly recommended” for turbo roundabouts (or else the driver instructions would be less precise).

Yes, I agree. I think this is the part that’s lacking in OSRM, if not other routers. Dropping “illogical” turn:lanes tags does eliminate a probably large class of tagging errors at conventional intersections (due to mappers remodeling the intersection without considering turn lanes), but I think it’s suspect around roundabouts, where turn:lanes is more like destination:lanes. After all, it would be unreasonable for a router to automatically drop destinations that the way doesn’t connect to directly.

[Peter_Elderson]

Yesterday (2023-05-22) the Dutch osm-community completed the detailed mapping of all turbo roundabouts in Nederland. We still have some quality checking to do.

Here are some stats about this feauture.

Multi-lane approaching roads have been tagged with turn:lanes=* , then split into separate lanes (lanes=1) tagged with either turn:lanes=* or turn=*

I have been thinking about the junction=roundabout tag, which was meant to indicate a junction node. For roundabouts mapped as one ring it made sense to apply junction=roundabout to the ring, which replaces the junction node as a ‘landing point’.
Then the ring was split into several segments, together still forming a ring. A single segment is not a junction, so we stretch the idea further.

Now with turbo mapping, the junction=roundabout and roundabout=turbo tags are applied to all the way segments on the roundabout, which can easily amount to 15-30 ways. The real junctions are the nodes connecting the segments to enable routing over single lanes within the whole of the roundabout.

I can’t help but thinking we gradually overstretched (and devaluated) the meaning of the junction tag. On turbo roundabouts, it now just replaces oneway=yes. If the junction has its own name, I have to apply the name tag to the separate way segments within the junction as well - that’s not logical to me. Operator, same thing.

[Minh_Nguyen (Minh Nguyễn)]

@Peter_Elderson

Then the ring was split into several segments, together still forming a ring. A single segment is not a junction, so we stretch the idea further.

For what it’s worth, it is reasonable to split a conventional roundabout into multiple ways, for example so that a route relation can traverse the roundabout without forming a topologically incorrect loop. Though some software is resilient to such loops, they do run counter to standard notions of a route, and iD unfortunately mangles routes containing them.

A type=junction junction=roundabout relation can collect the individual ways into a logical roundabout. Here’s an example that’s typical of conventional roundabouts where I map. One route actually traverses this roundabout twice, which would be difficult to model accurately if the whole roundabout were a single way. Regardless, the individual ways also have junction=roundabout tags, because junction relations are more esoteric.

As far as I know, there’s no expectation that a junction relation must represent a routable subgraph, so you can add anything to the relation that’s logically part of the junction. In other kinds of junctions, like SPUIs, I end up adding each of the approaches too, so that the junction’s shape can be more recognizable.

I suppose this dilutes the junction key even further, but at least it’s easy enough to distinguish usage on relations from usage on ways.

[Peter_Elderson]

@Minh_Nguyen

A type=junction junction=roundabout relation can collect the individual ways into a logical roundabout. Here’s an example that’s typical of conventional roundabouts where I map. One route actually traverses this roundabout twice, which would be difficult to model accurately if the whole roundabout were a single way. Regardless, the individual ways also have junction=roundabout tags, because junction relations are more esoteric.

On turbo roundabouts, the shape, the road connections and all the possible routes are determined by the ways representing single lanes. Allowed vehicle movements within the area of the roundabout are represented by connection ways. Illegal turns on the roundabout are handled by the junction=roundabout tags on the ways, and turn restriction relations.
Information which lane to choose on approach is handled by turn:lanes tags on the approach road and turn tags on the separated approach lanes.

Besides the small scale, the only thing setting this apart from regular routing is the use of junction=roundabout to indicate oneway.

Route relations are also handled by the “lane is way” style mapping. You just enter the right ways in the right order as relation members. In Nederland, many bi-directional route=road relations contain roundabouts, and often multiple bus routes use the roundabout, often multiple times even for one direction!

This all goes to say: I do not see much added value (for rendering and routing) in assembling all the pieces into a roundabout relation.
However, if the roundabout itself has a name, operator, class, ref, … I would like to enter that information once for the roundabout object, and not on all the individual elements. If I want to select all turbo roundabouts, I don’t want to find a myriad of tiny ways, I want a map, list and count of all turbo roundabouts.
A roundabout relation could hold that information, but to tie it to the map, it must contain a mapped member. One of the multitude of roundabout way segments could do that, but which one? I was thinking about using the central island for this purpose. A polygon of the roundabout area could also do it. The outline would usually be defined by the give_way circle. But wait - then you could simply use that object itself to hold the name/operator/ref/type information. Could a router use access this information if it’s not on the road ways themselves, but on a near object in the centre or around the area? A single central node maybe?

Just thinking out loud here - please don’t hang me up on these thoughts!

I’m not too familiar with routing and navigation, but I think for turbo roundabouts a routing/navigation system has all the information it needs, except for the detailed wording of the navigation instructions and the labels on a detail junction display. To my mind, that should contain the word roundabout (with name if present), and information which lane to choose. Lane choice over the roundabout should preferably depend on which approach lane has been chosen, preventing unnecessary side movements of the vehicle; that’s a routing issue I think.

[Mammi71]

@Peter_Elderson

Besides the small scale, the only thing setting this apart from regular routing is the use of junction=roundabout to indicate oneway.

Well then, I think you have overlooked another important point: junction=roundabout indicates that traffic in the roundabout has the right of way!
This should also be the case in turbo roundabouts. And if this is not the case, junction=roundabout should not be used.

[Peter_Elderson]

@Mammi71

Well then, I think you have overlooked another important point: junction=roundabout indicates that traffic in the roundabout has the right of way!
This should also be the case in turbo roundabouts. And if this is not the case, junction=roundabout should not be used.

In Nederland, traffic on roundabouts does not have legal right of way. Almost all roundabouts have explicit yield signs and markings all around, though. So we have the rule: add junction=roundabout only if all approaches have explicit give_way signs/markings. Otherwise it’s a junction=rotary, which people still call a roundabout. I know one example of that in Nederland, and I have seen almost all roundabouts in the country.

Question is: how important is the giveway information? On the road, obviously, but does routing software use it? If it does, it needs to know exactly where the give_way points are; the ways tagged as junction=roundabout do not start exactly on those points.
The roundabout wiki recommends to add give way nodes to the approach ways to pinpoint these locations. So the software would not need to infer this information from the roundabout status.

[Minh_Nguyen (Minh Nguyễn)]

@Peter_Elderson

I do not see much added value (for rendering and routing) in assembling all the pieces into a roundabout relation.
However, if the roundabout itself has a name, operator, class, ref, … I would like to enter that information once for the roundabout object, and not on all the individual elements. If I want to select all turbo roundabouts, I don’t want to find a myriad of tiny ways, I want a map, list and count of all turbo roundabouts.

Exactly, junction relations in general are useful for geocoding and analysis purposes (and sharing links to other mappers), but there isn’t an obvious benefit to routers.

@Peter_Elderson

Question is: how important is the giveway information? On the road, obviously, but does routing software use it? If it does, it needs to know exactly where the give_way points are; the ways tagged as junction=roundabout do not start exactly on those points.

Some routers might penalize give way (yield) signs very slightly, less than stop signs. But just as with traffic lights, any penalty would be watered down by the fact that you don’t end up having to slow down 100% of the time. So I’d expect it to be a negligible penalty anyways.

Assuming you’re talking about visibly posted signs or markings, the more interesting thing about highway=give_way is that a navigation application’s map could mark it as a safety reminder. Mapbox-powered applications do this, for example. At the zoom levels we’re talking about, I’m not sure the precise location particularly matters, but highway=give_way has to be tagged at the position where the vehicle pauses, since it doesn’t apply to all the incoming ways equally.

@Peter_Elderson

The roundabout wiki recommends to add give way nodes to the approach ways to pinpoint these locations. So the software would not need to infer this information from the roundabout status.

You’re probably right. Any router that’s so detail-oriented as to care about right of way would probably be consuming highway=give_way anyways.

That said, most routers do use junction=roundabout on the way as a signal to switch to roundabout-style guidance instructions. Even if the guidance instructions include turn lane information, users would still benefit from hearing something like, “Take the left turn lane through the roundabout,” instead of just “Take the left lane to turn left.” And even interpreting these turn:lanes values holistically based on the whole roundabout geometry, instead of dropping them as invalid, requires some indication of a roundabout.

Besides, I think it is good to aim for completeness with respect to intersection control devices. For example, any future StreetComplete quest about the form of traffic control at an intersection would rely on the fact that there’s always something to be tagged there. However, this is more of a consideration in regions like the U.S. that much more frequently post intersection control signs, particularly stop and yield signs.

Partially mapped two-way stops

How should a two-way stop intersection be tagged if it isn’t known which approaching streets have to stop, just that not all of them have to stop? I’ve proposed a new quest for StreetComplete that would encourage mapping traffic lights, stop signs, and yield signs at intersections. It would be limited to the U.S., where there’s no such thing as a “priority road” and stop signs are very common. It would be further limited to intersections where no traffic control has been mapped yet: This inf…

[Peter_Elderson]

@Minh_Nguyen

hat said, most routers do use junction=roundabout on the way as a signal to switch to roundabout-style guidance instructions. Even if the guidance instructions include turn lane information, users would still benefit from hearing something like, “Take the left turn lane through the roundabout,” instead of just “Take the left lane to turn left.” And even interpreting these turn:lanes values holistically based on the whole roundabout geometry, instead of dropping them as invalid, requires some indication of a roundabout.

That’s important. I guess they would also take it from a node, since the primitive of the roundabout is a node tagged junction=roundabout?

The question I have is: could this switch-to-roundabout-style signal also be triggered by a node tagged junction=roundabout in the vicinity of this part of the route, but not attached to any of the ways? I’m thinking at the centre. Or maybe by tagging the central island with junction=roundabout.
I now nearness can be used because routers can announce POIs in the vicinity when you go near. E.g. in OsmAnd I can set the required distance for announcing Parkings or Hotels.

[Minh_Nguyen (Minh Nguyễn)]

@Peter_Elderson

That’s important. I guess they would also take it from a node, since the primitive of the roundabout is a node tagged junction=roundabout?

Currently, routers announce a roundabout if and only if the route geometry traverses an edge of the routing graph that corresponds to a way tagged junction=roundabout. It’s important not to connect one road’s entrance and another road’s exit at the same node on the roundabout: that would short-circuit the roundabout out of the portion of the routing graph that the route traverses, resulting in guidance that’s oblivious to the roundabout.

From a routing perspective, it’s pointless to tag junction=roundabout on a node, because that would force the router to postprocess OSM data just to copy the tag onto the roundabout ways before building the routing graph. A standalone node would be even less practical. It would be sort of like deciding that it’s no longer necessary to connect barrier=gate to the road network.

@Peter_Elderson

I now nearness can be used because routers can announce POIs in the vicinity when you go near. E.g. in OsmAnd I can set the required distance for announcing Parkings or Hotels.

Landmark-based guidance does require this sort of postprocessing after generating the route, but roundabouts affect maneuver classification, which is more fundamental and probably can’t be tacked on in the same way.

Besides, roundabouts are really common and already fragile enough in terms of the user experience. Backwards compatibility with existing routers would weigh heavily against experimental tagging, unless there’s a practical problem with the existing tagging?

[Peter_Elderson]

@Minh_Nguyen

unless there’s a practical problem with the existing tagging?

Not fundamentally. It’s just that I don’t like the tagging of a dozen or more tiny ways as junctions, where in fact they are just a part of it. And I still would like a method to select whole roundabouts, not 12-25 ways per turbo roundabout (in the multi-lane style tagging, a turbo roundabout took 3 to 6 ways per roundabout)

Thinking further on “traversing an edge”. I’m not sure what “traverse” is, sorry, not a native English speaker. Does this junction=roundabout way you “traverse” need to be a part of the route, or just connected to a way that’s part of the route? Does the vehicle cross this edge way or actually use it?

If crossing it is enough, I return to the idea of an outline around the roundabout area.

[Minh_Nguyen (Minh Nguyễn)]

@Peter_Elderson

Not fundamentally. It’s just that I don’t like the tagging of a dozen or more tiny ways as junctions, where in fact they are just a part of it. And I still would like a method to select whole roundabouts, not 12-25 ways per turbo roundabout (in the multi-lane style tagging, a turbo roundabout took 3 to 6 ways per roundabout)

Yes, it does sound awkward when you put it like that, but it’s basically the same story with any navigable feature. A highway=motorway way isn’t a whole motorway or a whole highway, just an arbitrarily short segment of one carriageway of one. A waterway=river is often just a segment of the main channel. Route, waterway, and junction relations create higher-order representations of these primitives, for the use cases that need them (humans as much as machines).

@Peter_Elderson

Thinking further on “traversing an edge”. I’m not sure what “traverse” is, sorry, not a native English speaker. Does this junction=roundabout way you “traverse” need to be a part of the route, or just connected to a way that’s part of the route? Does the vehicle cross this edge way or actually use it?

If crossing it is enough, I return to the idea of an outline around the roundabout area.

Traversing an edge means that the suggested route includes the edge. Sometimes this is called “walking” or “crossing” an edge, but “traversing” is more precise and less prone to misunderstanding.

An edge is usually defined as the connection from one intersection node to another. One exception is that OSRM can be configured to detect a roundabout loop (based on junction=roundabout) and collapse it down into a node, discarding its geometry. But this behavior is normally disabled because it results in poor guidance instructions and map rendering.

I was just pointing out a common mistake of assuming that the router can just “touch” the roundabout to know that the user needs to enter and immediately exit a roundabout, but this is not the case, the best/shortest path found by a router is literally a list of edge IDs.

Your idea of a landuse-like roundabout area sounds interesting, but it reminds me of the long-discredited practice of drawing overlapping roads to represent a road that has two route numbers. If you require a single feature to represent the roundabout, the junction relation is for you. In a perfect world, we would’ve invented junction relations before junction=roundabout way-tagging to avoid this redundancy, but here we are.

This Overpass query returns 11 roundabout junction relations and 72 standalone roundabout ways in Hamilton County, Ohio, without double-counting ways that are part of a relation. A slightly modified query shows me 14 unclosed roundabout ways that I could group into four roundabout relations, which would get me a more accurate count of roundabouts in the county.

[Peter_Elderson]

@Minh_Nguyen

Traversing an edge means that the suggested route includes the edge. Sometimes this is called “walking” or “crossing” an edge, but “traversing” is more precise and less prone to misunderstanding.

An edge is usually defined as the connection from one intersection node to another.

Ah, thanks for crushing all my illusions in one strike!
However, now I know that the junction=roundabout tag on the ways serves the purposes of
a. The way is oneway
b. The way grants priority over incoming ways
c. The way enables the router to switch the instructions to roundabout mode.
and that c. cannot easily be replaced.

Now about named roundabouts: does c also mean that the name of the roundabout needs to be on all the ways constituing the roundabout, to enable the use of the roundabout name in the instructions?

[Peter_Elderson]

@Minh_Nguyen

Your idea of a landuse-like roundabout area sounds interesting, but it reminds me of the long-discredited practice of drawing overlapping roads to represent a road that has two route numbers.

It reminds me of the bridge relations we are currently deleting, because the only purpose they served, carrying the bridge name, is now served by man_made=bridge polygons, allowing me to search for bridges and get an accurate count. Well, near accurate, because some bridges actually have two outlines in OSM, while normal human beings would count only one bridge.

[Minh_Nguyen (Minh Nguyễn)]

@Peter_Elderson

Now about named roundabouts: does c also mean that the name of the roundabout needs to be on all the ways constituing the roundabout, to enable the use of the roundabout name in the instructions?

OSRM does require the roundabout way(s) to have a name tag in order to announce the name. However, I don’t think it requires consistency throughout the roundabout. I’m unsure what other routers expect.

Do you have roundabouts that are named differently on different sides? In my neck of the woods, neighboring towns sometimes build a roundabout together along the border, but we don’t tend to name roundabouts anyhow. (At most, the roundabout construction project gets a name. That can end up on the relation for convenience, but it isn’t useful enough for wayfinding to be tagged where routers would see it.)

@Peter_Elderson

It reminds me of the bridge relations we are currently deleting, because the only purpose they served, carrying the bridge name, is now served by man_made=bridge polygons, allowing me to search for bridges and get an accurate count. Well, near accurate, because some bridges actually have two outlines in OSM, while normal human beings would count only one bridge.

Maybe in the future there will be demand for reviving bridge relations, just as with building relations once 3D building parts became popular. I’ll keep an eye out for the Dutch community’s proposal for 3D micromapping the structure of a roundabout, using a relation to group its central monument, shrubbery, and truck apron.