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.
Fair enough. In that case, this roundabout is mistagged as junction=circular. To a router, that tag and the traffic signals must make it look a lot like a classic American traffic circle, the kind that conventional roundabouts were supposed to replace.
By design, routers sometimes issue unavoidable instructions. For example, many routers say, “Merge onto [motorway],” at the end of an on-ramp, even though there’s nowhere to go but forward. Some routers say, “At the end of the street, turn left onto [street],” as you approach an L-intersection where you can only turn left. During turn-by-turn navigation, these instructions can reassure the driver that the application is still following along, although some users prefer less chatty instructions.
There are also situations where routers should be issuing unavoidable instructions but aren’t. For example, if the upcoming intersection has an only_straight_on restriction but the driver needs to turn left at the intersection immediately past it, the router would ideally say something like, “Go past this intersection, then turn left.” Another example:
I agree, exit counts are not always very helpful in roundabouts. As I alluded to earlier, I suspect they’re often counterproductive in American roundabouts, where exits are usually assigned a direction, even when there’s only one lane. It sounds like you have enough detail to file bug reports with the major routing engines.
Hm… I’m hesitant to call it bug reports - I ask for support/adaptations for an existing but still not widespread situation. Maybe a change at the tagging end is needed to convey the necessary information to the router.
In the meantime, I’m still thinking about the give_way situation. Suppose a router/navigator does something with that information, way by way. Penalise or display or whatever.
And suppose I have a standard turbo roundabout. Then there are entry lanes crossing the outer ring to a short connection between the outer lane and the inner lane. I think if only the ways are taken into account, the short connections woud have priority over the inner ring! Because both are on the roundabout, both have equal priority because of the junction=roundabout tag, so the default priority rule would apply (in NL: traffic coming from the right has priority).
In reality of course, everybody regards this segment as an incoming way that has to yield to all traffic already on the roundabout. But suppose that we feed this osm-roundabout to a self-navigating car… am I missing something?
PS I’ll answer this myself… priority is not determined and applied at each crossing separately , but at the point where the sign is, and is then applied to all the crossing ways at once. If software had to handle the situation that two cars approach the same intersection node, and had to determine who is to continue and who is to stop, then it would matter. But that has nothing to do with routing.
So just forget it, please, my mistake!
I didnt think it would be manageable to open development-issues for the three routers at osm.org. Arbitrarily, I chose the one with letters osm in the name.
The other two will of course follow, once we have more answers about what could be done.
I imagine most routers encounter the same issues if they would build support for turbo roundabouts.
“Use the left or right lane to enter the roundabout” [depending on if both lanes lead to the desired exit]
“Take the second exit on the roundabout” [second overall exit. if the inner lane is taken, this could be the inner lane’s first exit]
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 