How do I tag turn lanes that cross-over the direction of travel?

Yes, you’re right according to a strict application of the physical separation principle. To be clear, the mockup above intentionally pairs a one-way carriageway on one side with a two-way carriageway on the other side. This would require us to pretend that the gore area marked off by chevrons is like a traffic island. That’s what it’s intended to be, but technically you could drive across it without damaging your car, and doing so would be in a legal gray area.

For example, there’s a stop sign poking out of this gore:

Woodside at Whiskey Hill © 2021 crabkilla, CC BY-SA 4.0

To accurately indicate the location of the left turn lane’s physical stop sign or the right turn lane’s stop bar, or the shape of the right turn lane, we do need to relax the physical separation rule for the whole gore, not just the little portion around the stop sign. Tags alone just aren’t very good at encoding geometry. But as I said, there are downsides to this approach, so the dual carriageway I mocked up above should be viewed as a last resort.

1 Like

Thank you Minh Nguyễn for the suggestion to share the location in this thread; I didn’t even think to do that. Here is an edit link in case it’s helpful: OpenStreetMap

1 Like

Why not make something like this:
Crossing 01
You will have to make some relations to send people in the right directions.
I’m not sure if I understand the crossing 100 %.

3 Likes

@Minh_Nguyen @Kogacarlo thank you both. That set me on the right path here. I basically did what @Kogacarlo suggested for this intersection, and even found another intersection in the same city modeled very similarly.

1 Like

I see that you specify the direction of traffic signals on oneway streets. Is that necessary?
I never do that.

Hehe, this takes the last resort I suggested and runs with it. If creating a dual carriageway based on the painted gore is questionable, then a triple carriageway based on the painted centerline and lane dividers would be moreso. But since this is such a rare configuration overall, any solution will probably have downsides.

I think a router trying to make a left turn here would say, “Keep left at the fork and make a slight left turn,” based on how these link ways representing the left turn lanes bend toward the intersection nodes. Whenever I map offset turn lanes as separate ways, I have them meet the cross street at a right angle, to avoid influencing the router’s turn angle classification.

1 Like

because there are no four separate carriageways there

2 Likes

You are right, but neither are here three carriageways:

I never digged very deep into this matter so I don’t have a theory of everything. I just had an idea and thought I might as well post it :slight_smile:

At least you could argue that this sign splits into two. Though yes, there are always ugly cases. Also, I converted some similar to this one to a single highway line (without sign in painted island, with smaller painted islands)

1 Like

It’s a tradeoff. In this case at Woodside and Whiskey Hill, the main practical benefits to a separate link way are that a navigation application won’t think you’ve gone off-route because you’ve ventured too far from the roadway and knows where you’re supposed to stop – there are actually two stop signs. The drawback is that we’re ignoring the possibility of doing doughnuts around the intersection, riding roughshod over the painted lines. I suppose that isn’t a theoretical possibility, but no one is waiting for a router’s permission to do doughnuts anyways. I think we could satisfy that use case by mapping the area:highway=* area.

In the original case at Buena Vista and Chandler, the main benefit to multiple carriageways is that we can express the fact that the lanes are swapped, so that a renderer could depict the lanes somewhat more accurately. On the other hand, a data consumer would assume there’s a physical separation between each lane when there is none, resulting in too many lines in some renderers and arguably too many instructions in routers.

I think the two-carriageway approach I suggested strikes a compromise between both approaches. It still violates the physical separation rule, but we already generally relax that rule on dual carriageways at intersections in the interest of geometric simplicity. That said, a tag-based solution such as driving_side:lanes wouldn’t be far-fetched as an even simpler solution, if we aren’t concerned about data consumers understanding it for such a rare edge case.

1 Like

Oh, now I finally see that you drew that and what your intentions are.
Yup, that configuration makes sense as well.

+1, from south to north with all three ways pointing to the north I would use:

south of the first intersection

access:lanes:forward=yes|no|yes|yes
change:lanes:backward=not_left|not_right
change:lanes:forward=no|no|not_left|not_right
emergency:lanes:forward=yes|yes|yes|yes
highway=secondary
lanes:backward=2
lanes:forward=3
lanes=5
turn:lanes:forward=left;through|none|through|through;right

between the two intersections

access:lanes:both_ways:backward=yes|no
access:lanes:both_ways:forward=yes|no
change:lanes:backward=no|no
change:lanes:both_ways=no|no
change:lanes:forward=no|no
highway=secondary
lanes:backward=2
lanes:both_ways=2
lanes:forward=2
lanes=6
turn:lanes:backward=through|through;right
turn:lanes:both_ways:backward=left|none
turn:lanes:both_ways:forward=left|none
turn:lanes:forward=through|through;right
(oneway:lanes:both_ways=yes|-1)

north of the second intersection

access:lanes:backward=yes|no|yes|yes
change:lanes:backward=no|no|not_left|not_right
change:lanes:forward=not_left|not_right
emergency:lanes:backward=yes|yes|yes|yes
highway=secondary
lanes:backward=3
lanes:forward=2
lanes=5
turn:lanes:backward=left;through|none|through|through;right

It is a pity that iD does not display the *:lanes-tagging.

The solution of @Minh_Nguyen is neat because it keeps the added virtual carriageways to a bare minimum.

Manoeuvre relations may be helpful to ensure proper navigation instructions.

The space between the left turn lane and through lane isn’t an emergency lane. It’s a virtual traffic island or gore area, which in this case happens to be painted with chevrons to discourage travel within it. Often, these virtual gore areas aren’t suitable for cutting across in a vehicle, because you’d run into debris, a paved drainage ditch, or other obstacles within it.

This abandoned proposal summarizes the attempts to define a tagging scheme for these virtual gore areas. This JOSM lane plugin supports an undocumented and seldom used width:dividers key, which allows you to maintain a single carriageway. I’m sympathetic to these attempts, because in some regions, gore areas are signposted as part of the intersection’s lane layout, yet a separate link way prevents routers from knowing that the lanes are related. At the same time, as I mentioned before, tags on a way are pretty bad at encoding geometry.

1 Like

I did it to make it explicitly clear that it’s a single intersection (in terms of the signal), and that there weren’t independent signals for each cross street. Saw both options listed here: Tag:highway=traffic_signals - OpenStreetMap Wiki

  • If it would be an emergency lane, I would have used designated instead yes as value.
  • If the lane is not suitable for any transport mode at all just skip emergency:lanes[:*].

I’m not sure it’s a good idea to model a virtual gore area as simply a closed lane, even if it seems convenient. (Lanes can be closed too, but they aren’t necessarily painted like this.) The only thing it has in common with a lane is that there are lane dividers on either side.

Like any virtual traffic island or bike lane buffer, a virtual gore area can be much narrower than a standard lane:

Or or much wider, varying in width from one end to the other:

There can be a real, physical traffic island at the very tip of a virtual gore area to protect the crosswalk:

To be fair, sometimes these virtual gore areas do get converted into travel lanes. Originally, the through lane on this roadway was closed off and painted as a virtual gore area until the road to the south of the intersection opened several years later, making it possible to go straight through the intersection.

1 Like

Note, I do not count them as lanes as the values for lanes=*, lanes:forward=* and lanes:backward=* show.

  • width is not a problem as we can use width:lanes[:*]=* similar to bicycle lanes which do not count as lanes=*
  • if there is a real physical separation (not just some paint on the tarmac), I would still split the way and use a separate way for the turn lane but only starting at the point of the physical separation and not at the beginning of the turn lane.

Personally, my biggest issue is how to handle these restricted “lanes” in the middle of a two-way road as some QA tools do not like *:both_ways or *:lanes:both_ways without lanes:both_ways=* and others if the sum of lanes:backward=*, lanes:forward=* and lanes:both_ways=* is not equal to the value of lanes=*, see both_ways für Straßen-Sperrflächen ?

You would be correct to exclude a traffic island from the lane count. But these aren’t actually lanes, so adding access tags and potentially other tags to undo the very essence of a lane would amount to mild troll-tagging.

I’m not very familiar with German traffic laws, but the original example in that thread would clearly not be a two-way turn lane (aka center turn lane) in any jurisdiction that I’m familiar with. In the U.S., both virtual traffic islands (aka buffer space) and two-way left turn lanes are extremely common, and every driver knows the difference between them. A virtual traffic island is required as a buffer any time the direction of a lane changes, such as from a two-way left turn lane to a standard left turn lane.

Perhaps it would help to see these distinctions visually. Going from east to west, Mount Carmel Tobasco Road’s eastbound and westbound lanes gradually diverge, forming a virtual traffic island in the middle that grows to a width of about two lanes. Eventually, half of it becomes a two-way left turn lane, providing access to some abutters, while the other half becomes a left turn lane for an intersection further to the west:

Modeling a traffic island as a closed two-way left turn lane would make it indistinguishable from a two-way left turn lane that is closed. For example, the center lane of Lafayette Street is sometimes a two-way left turn lane, sometimes a one-way lane, and sometimes closed, depending on the symbol on the activated blank-out signs overhead:

Given all the possible tags that have been proposed for virtual traffic islands specifically, it doesn’t seem to me that conflating them with travel lanes or turn lanes is worth the convenience.

Oh, maybe I caused some unnecessary confusion by bringing this up. What I was referring to was the use of both_ways to indicate this space within an intersection, not the virtual gore area or traffic island:

It doesn’t seem to be a common practice in the areas where I map though.