There’s an interesting intersection near me, where two parts of the same street are separated by a bicycle path. To accommodate this they made it so the turn lanes actually cross-over to one another to make turning easier, but it’s not clear to me how to tag this intersection so the directions of travel are correctly indicted.
Here is how that looks from the Bing satellite images. The through;left turn indicator should help clear up the directions of travel:
So the problem is that in the middle of crossing left turn lanes are locally inverted to left hand traffic, without physical separation from forward lanes?
I would likely map it as usual crossing with left turn lane and two forward lanes in each direction, even if that would not be 100% accurate.
Though I guess some special per lane oneway and per lane turn lane tagging would be technically possible.
So the problem is that in the middle of crossing left turn lanes are locally inverted to left hand traffic, without physical separation from forward lanes?
Yeah, that’s an accurate interpretation.
I would likely map it as usual crossing with left turn lane and two forward lanes in each direction, even if that would not be 100% accurate.
Though I guess some special per lane oneway and per lane turn lane tagging would be technically possible.
Yeah, that was my concern with the accuracy. The other idea I wrestled with is, even though there is no physical separation, would be to convert that through;left to a one way segment. But that also feels a bit off.
Edit: Thinking about this more it probably wouldn’t work so well.
The northbound and southbound approaches to this double intersection have turn lanes with a lane’s worth of positive offset. Although the gore area is only marked off by painted chevrons, some mappers would model it as though there’s a traffic island, bending the physical separation rule a bit, because nothing is ever supposed to enter that space anyways. (Sometimes there are even signs and other obstacles poking up out of the gore.)
The upshot is that you can model the approach as a dual carriageway, then continue that dual carriageway all the way through the intersection. Within the intersection, each carriageway becomes two-way to accommodate the left turn lane. Something like this:
There are downsides to mapping this offset configuration as a dual carriageway. For one thing, routers are currently unable to associate the left turn lane with the rest of the lanes when coming up with a lane use diagram or telling you which lane to get into. Instead, they’ll say to “keep left at the fork”, which is technically correct but misleading. Another downside is that you won’t need to indicate anything abnormal in the tags, which will make it more difficult to find this and other similar oddball cases in the future by querying for certain tags.
Another option would be to overlook the fact that there are two left turn lanes within the intersection and model it as a single two-way left turn lane, similar to the center turn lane south of this intersection. You’d add lanes:both_ways=1 and turn:lanes:both_ways=left. Originally, the *:both_ways suffix was intended to apply to the left-turning area within an intersection, but I don’t think it’s often used that way anymore. Most often, I see mappers just extending the left turn lane of each approach through the intersection, resulting in one extra lane within the intersection.
If it’s all one expanse of asphalt I don’t think a dual carriageway is appropriate unless there are bollards or other barrier to separate the traffic.
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:
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.
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
Why not make something like this:
You will have to make some relations to send people in the right directions.
I’m not sure if I understand the crossing 100 %.
@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.
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.
because there are no four separate carriageways there
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 
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)
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.
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.
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