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.
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=junctionjunction=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.
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.
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.
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.
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.
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.
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.
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.
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?
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.
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).
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.
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?
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.
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.)
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.
Roundabout naming… Somewhere 2021 or so the OSM mantra here became not to name the roundabout unless it has a name of it’s own. What name to give it when e.g. 4 streets each their own name used to connect of old at a crossing and modern times frenzy decided to slap a roundabout on them doing away with traffic lights on the go. At any rate my car navigator on this 4 way RB would tell me an RB is up and to take the Nth exit,
In the U.S., where relatively few roundabouts have their own names, mappers used to give the roundabout ways name tags based on the names of connecting streets. Often this resulted in a semicolon-delimited list. But Telenav and others removed most of these name tags in 2018, possibly influenced by how routers interpret these tags.
I assume @Peter_Elderson was instead referring to the name of the roundabout itself. Sometimes a street follows a boundary and therefore has a different name on either side, so I was hypothesizing that maybe the same thing can happen to a named roundabout that straddles a boundary.
I was, and it could, but AFAIK it never happened so far.
Streets/roads different names landing on the roundabout is very common, even when the through road has the same road ref and normal people would say it’s one road. To my osm-predecessors it seemed best to just leave out the names on the junction area, to simply avoid the naming issue and do away with label placement issues on this very confined map space, and I totally agree.
Most roundabouts have no official name, and it’s not customary to name them after the roads they serve. Some regions have taken to naming their precious new roundabouts, I personally think the custom wil grow because mayors and city councils like it, and I think we should have mapping for it and not wait until it’s an omission we could have prevented.
They also like to put monstruosities in the middle of roundabouts. I think they call it artwork. For the central islands, shrubbery is favourite, which means it won’t be rendered on OSM Carto, which in turn means that all kinds of substitus are being used to get some colour on the map, despite it being blatant tagging for the renderer.
You would be surprised how many village greens we have, surrounded by truck aprons, which also are not rendered. (BTW we do have true (but former) village greens, i.e. areas formerly serving as village greens and now often still with a public function, appropriate layout and named after the former village green. )
I have no experience mapping junctions so apologies if this is not relevant… I remember reading somewhere about creating areas with junction=yes that share one node with each way that enters or exits the junction. The idea being that you can put a name on them, but also that routers can give simplified turn instructions such as “turn left at the junction” instead of “turn slight left then continue straight for 5m then turn slight left again”. Maybe something like that would be useful here? By looking at the area, a router would be able to identify the exits, to count and announce them correctly, and also to calculate and announce the overall direction change. For example, “take the third exit to turn left at the turbo roundabout”, instead of the more complicated directions they currently produce.
I would also suggest, if you’re going to create issues in the issue trackers of routers, that you add an example of what the routing instructions currently look like and what you would like them to look like.
Ah, right, the other other meaning of junction=*. Junction areas are a cool solution to a number of guidance-related problems. There’s probably no harm in also surrounding the roundabout with one, but no router seems to support it yet, so it would be premature to remove junction=roundabout from the ways.
Valhalla already seems to understand that this Westland roundabout is a single intersection, even though it lacks support for junction=yes areas and there isn’t one here. It just chooses to present more detail about destinations and such.
OSRM doesn’t even call it a roundabout. The ways are tagged junction=circular, which is for circular intersections in general, probably because of the traffic lights. There are many kinds of circular intersections, such as the classic American traffic circles, which can also be signalized, or “neighborhood roundabouts” that are essentially just a traffic calming island in the middle of a standard two-way stop intersection. (Exits?)
I’m not sure it would be accurate to change the Westland example to junction=roundaboutroundabout=turbo just because of its shape. When a driver hears “at the roundabout” from the application, they probably expect a continuously flowing intersection.
No, it’s absolutely a roundabout, because it has the official roundabout signs and give_way signs at every entrance. It also has physical carriageway separation, drivers can not change carriageways on the roundabout, and you always arrive at an exit when following the carriageway. It’s just a biggy with three rings, where even the rings can have multiple lanes; that’s why I say separate carriageways, where usually I would say lanes.
The traffic authorities require traffic lights, because drivers at an entry point are supposed to be able to handle max 2 lanes to give way to (or pick a gap in the traffic). Most drivers actually can. This roundabout has entry points where drivers see 4 lanes to yield to. Then traffic lights are mandatory to regulate safe traffic flow.
There are many multi-lane (3 or more) non-turbo roundabouts with traffic lights for safe flow regulation. I think the sentence on the roundabout page about no traffic lights needs to be revised. The crucial requirements are: a. the roundabout sign visible form for all entries, and b. legal or explicit priority for traffic on the roundabout. You could say something like “one lane or two-lane roundabouts typically have no traffic lights. On larger or complicated roundabouts, traffic lights may be present to regulate traffic flow”.
The Westland junction as a whole has a name, Vlietpolderplein, currently tagged on all the sections of the rings. That is probably why it is mentioned in the navigation instructions. Awkward, because the driver is already on the Vlietpolderplein roundabout), then gets the instruction to enter the Vlietpolderplein (road). At that point, the driver can not make a decision, so it’s only confusing.
Then the instruction is: take the first exit to Piet Struykweg. Again, the driver cannot make a decision here; (s)he has to follow the lane onto the exit Piet Struykweg. This does not require what people what call “neem de afslag” (take the exit), which would be a manoevre. So it’s just confusing. Normally people would expect “U verlaat the rotonde” (You are leaving the roundabout), which says what happens, instead of giving an instruction to do something. The instruction even says: take the 1st exit. Usually people count the exits with regard to the whole roundabout.
This particular turbo roundabout has full guidance for left, through and right; once you have chosen the entry, you will always end up on the appropriate exit. On most turbo roundabouts, the driver will have one choice point where (s)he can take the exit (a manoevre) or continu (keep in lane) to the next exit. No choice usually means the vehicle will be forced off the roundabout at the next exit.
“Take the exit to <road name and/or destination>” or “keep in lane / continue on the roundabout” or in Dutch “Blijf op de rotonde” would be the right instruction here. At this point, no exit count should be given.