In my area there is a “one way” road with 4 lanes BEFORE a Traffic Signal AND 3 lanes AFTER the traffic Signal.
The traffic Signal is defined as NO LEFT Turns from the direction of the one way road being discussed.
The 4 lanes before the intersection are described as follows:
(Not Tagged yet).
left lane is a turn lane for the 1st connector PAST the Traffic Signal
Next lane is Through
Next lane is Through
4th lane is a Right Turn Only Lane.
The motor ways AFTER the traffic Signal was easy to Tag.
I used the following to Tag the three lanes after the Signal.
TAG: lanes =3
turn:lanes = left|through|through
However My FOCUS is on the motor way BEFORE the traffic Signal. Yes, the signal has No Left Turn defined.
Will the Traffic Signal’s No Left Turn rule take priority if I define a lane before the Traffic Signal with left turn properties intended for connector past the Traffic Signal.?
It would help if you’d provide a link to the intersection.
Turn restrictions and turn lanes are two completely different aspects and should not interfere, so I think you are fine with your current approach.
As the other comment says, please use both turn:lanes and a turning restriction. turn:lanes is only really for the markings on the road and more generally for indicated turns, as the Key:turn - OpenStreetMap Wiki page calls it.
Another interesting example from my own experience is OpenStreetMap, where there is a left turn lane, but no indication, and next to it two more lanes which are indicated left turns, but for the next intersection, like your example. Difference being that I can’t add a turn restriction to the way, because left turns are possible and allowed, just only from the left-most lane without indication.
Hi Jofban… thanks for your reply with insights.
Just so I understand… turn:lanes = left|||right is a TAG for the street.
Turn restrictions are defined within the Traffic Signal node.?
Is there also a TAG for lane turn restrictions to be add to the Street level Tags.??
Lastly, will the No Left Turn at the Traffic Signal take priority over (turn:lanes=left|||right in the Street Tags.?
RE: The example you gave, yes it’s similar but more complex. I wish OSM would allow to make a new way for that unmarked Left turn lane you mentioned. That would allow you do separate that LEFT from the other two lanes for LEFT turn past the intersection. Though there is no physical barrier… logic would dictate you “shouldn’t leave the far LEFT Lane when you are in it”. Probably NOT the correct edit. So please do not use this approach. Maybe worthy of a discussion with osm higher up the chain. :))
Hi Skyper… Thanks for your reply…
Unfortunately I don’t know how to link to map coordinates.
But I can upload a picture.
Just so I understand… TAG: (Turn:lanes) is TAG for the street level
Turn Restrictions are controlled by the Traffic Signal only.?
Are there any Street Level Tags for (Turn Restrictions) I should add.?
Yes, to map the indications given (e.g. road marking or sign).
No, they are Relation - OpenStreetMap Wiki. How to add a relation somewhat depends on the editor you use. If you are using the default editor, called iD, you can add them on the bottom of the page. Select “New relation” as the parent relation.
No, the relation contains the necessary ways and nodes.
Generally, I’d expect a router to simply ignore turn:lanes. A router should only consider turn restrictions for routing. The tagging can remain useful for clearer instructions and visualisations.
You know why that’s not allowed, and I don’t think it’s necessary to make an exception.
Not sure if you saw the edit to my post. Similar to turn restrictions, there is a relation to add exactly the information you want: The Connectivity relation. I have in the meantime added the relevant ones: Relation: 18278555 | OpenStreetMap and Relation: 18278556 | OpenStreetMap.
I believe this is the most exact way to map which lane can go where, in addition to turn:lanes and turn restrictions of course. I wasn’t aware of this myself until I researched my answer. Thanks for your question.
Hi Jofban… I hit the “solved button” before thanking you.
Your additional details give me confidence to make the changeset for this intersection. Thanks… Glad your problem got solved from researching my question. Bye for now… Take care…
In most cases using placement[:direction]=* works fine and there is no need for connectivity relations, though they do not harm besides the overhead of yet more relations.
It is a pity, that iD does not visualize the :lanes tagging and does not support many of the tagging.
Both examples could profit from change:lanes=*, for example.
On the map on www.osm.org, simply zoom in and/or out and the URL will contain the coordinates. Then you can copy & paste the URL.
Hi again Skyper… thanks for your additional insights re: direction and connectivity. Additional thanks for instructions about how I can send map links. The key is to zoom in or out after finding the right spot. Without zooming in or out the url stays the same as the prior map location. I never noticed that before.
One last question… in your latest reply… You say: " it is a pity, that iD does not visualize the :lanes tagging" I’m not familiar with what “iD” is. I did a search for "iD Navigation… thinking it was an app with no luck. Before leaving may I ask… what is iD.? With every post I learn more than I initially came for.
I do plan on asking the developer of the GPS app i use and ask if they use 'lanes" or “turn” Tagging… If they don’t I’ll suggest that is something they should consider.
thanks again for all your inputs.
iD is the editor to add tags, nodes, ways, and relations. If you are on osm.org and start editing, you are using the iD software. See also: iD - OpenStreetMap Wiki
Hi Jofban… Thanks for pointing out what “ID” means. YES i see now that’s the name of the online editor… :)) I just never associated “ID” with it’s name… though it clearly is shown. I simply knew or called it the “in-browser editor” and ignored “ID” as it’s real name. Thanks for your patience with me.
Thanks for pointing out “ID” is the editor I’m using. :)) As I shared with Jofban… I simply called my editor: “in-browser Editor”. Now I notice “ID” to be it’s actual name… :)) and a lot shorter than “in-browser Editor” to write in a post. Thanks also for sharing screen shot for: [JOSM] I wondered how JOSM and ID differed. For my purposes adding; speed limits, lane;turns, and an occasional driveway or two… ID has been great for me. Online tutorials recommended “ID” for beginners. Thanks for sharing what editor the pros use.
One last piece of NEW Info I learned about my initial Question…
Like others, I was researching a different ( turn:lanes ) question when I found a possible attribute I was unaware of before:
For:Tag:turn:lanes there is an attribute called: next_right.
article only mentions ( next_right) but prior lists other Right / Left combinations as valid keys. With most attributes being for both Right and Left… is it safe to assume ( next_left ) is also a valid “value”.?
Relying on the (“No Left” Restriction at the signal node) would probably work with ( left|||right ) as was discussed initially with my question. However ( next_left|||right ) just seems more appropriate to avoid any possible conflicts for clarity.?
Now I know how to attach link to a map coordinate… below is intersection in question. Segment on East Beltline - North bound before Cascade Rd.
I hope the tags: ( next_right ) or ( next_left ) if legal help in your future mapping needs as well.
If you look at the picture next to the table for next_right, you’ll see the intended meaning, which is a special symbol used by local authorities. If you see that marking (with the cut off arrow), then you may use it, but not for the regular left/right arrow.
In addition, it’s a rare tag, so unlikely to be supported in consumers, but that’s a minor reason.
Hi Jofban… My sincere THANKS for your input.!!!
I thought i had discovered some useful new “key” for: Tag:turn:lanes.
But as you point out… it did not apply… and it was a rare “value” to use.
As of the writing of this reply, I have already reverted the subject “key value” back to left|||right.
It seems now all my possible questions are fully addressed for this particular intersection.
Thanks again for your helpful replies, guidance and patience.
From this one topic, I have learned so much )
Knowing the background can be useful. turn:lanes tags were first used to describe the painted arrows but now it is more about the direction of the turn.
It does not really matter if a turn-lanes is there for multiple turn options or if it is forbidden to turn at the first option (as we already discussed the forbidden part is covered by the turn restriction relation). The only thing that really matters is the continuation of the lane and maybe if you are allowed to change lanes which is covered by change:lanes=*.
Using new values or values with a low number of usage will often lead to less support as each consuming software will have to support it in first place.
Off-topic note about links
Please, do not copy the URL from the editor or delete the part, e.g. instead of https://www.openstreetmap.org/edit?editor=id#map=18/42.956346/-85.589745 use https://www.openstreetmap.org/#map=18/42.956346/-85.589745
A word of caution: the wiki allows anyone to edit, which can be an advantage, but sometimes it’s a disadvantage when people hastily document a tagging idea they have before discussing it with others who might have useful feedback. In this case, the page was edited about a year ago to add the next_right and right;next_right values, but I can’t find any prior discussion about it. Currently, there are only 66 occurrences worldwide, which might not be enough for major routing engines and navigation applications to consider adding special support for it.
As I understand it, turn:lanes=* values are supposed to correspond to the indications on the ground, regardless of the broader surrounding road geometry. Routers only use turn:lanes=* in guidance instructions. Ideally they’d also use it as a hint in complex intersections, to avoid sending mixed messages to the user, but you never have to worry about this tag overriding a turn restriction relation or other geometry.
For example, even though this off-ramp in San Francisco technically forks to the left onto Bryant Street, the two left lanes are marked as through lanes, so we tag them as through, not left or slight_left. Rest assured, the through tag won’t cause the router to send the driver careening through the biergarten at the corner! And even if we had tagged it as a left, the router wouldn’t ignore the restriction against turning left onto 4th Street.
In the U.S., where the original example is located, a left turn lane still has either a standard through arrow or a standard left turn arrow no matter how many lights ahead the turn will be – it might not even be at the very next light. I’ve never seen a sign or marking similar to the diagram in the documentation, which comes from Danish traffic regulations:
In part that’s because we don’t use the “plugged road” symbol that it incorporates from the sign for a dead end, but also I don’t think I’ve ever seen any attempt at turning “second left” into a turn indication arrow. Since this is a distinction that the Danish authorities make, there is a need for a value such as right;next_right in Denmark, but not in the U.S.
Additionally, right;next_right seems to correspond to a sign with two arrows pointing right. Michigan doesn’t have a standard sign for this scenario, but there are standard signs both nationally and in neighboring Ohio. This sort of sign is currently documented as slight_right;right; likewise, left;slight_left when pointing to the left.
As far as I know, most navigation applications support this value combination. I would recommend slight_* over these novel next_* values.
Actually, glancing at the example on M-37, I don’t see any signs or lane markings indicating that the left lane is a turn lane of any kind until after you cross Cascade Road. There’s only a lane change restriction. So technically, the way before the intersection should be tagged turn:lanes=|||right. Marking it as left isn’t wrong; it’s just a bit of a stretch based on some signs the user can’t see yet by that point.
I gather that @GPS-GR is interested in this intersection because people often neglect to change to the left lane until after crossing Cascade. There are few if any implementations of lane-level guidance so far, but the most likely implementation would greedily expect the user to change lanes too late, despite the change:lanes=no|not_left|not_right|no, because it would assume there’s a break in the lane change restriction at the intersection. You’ll need a connectivity relation to clarify that the lane change restriction continues uninterrupted.
Based on this directional sign, destination:lanes:ref=M 37||| and destination:lanes=East Beltline South||| would also be appropriate. That would probably be the most effective way to prevent driver confusion. Some ride-sharing companies such as Lyft actively add lane-level destination tags, so it’s entirely likely that their navigation systems make use of these tags. Hopefully consumer applications will follow suit.
Finally, if you do ever come across any unusual lane use signs or markings, please add them to this running collection. One of these days we’ll come up with a bevy of bizarre values for these bizarre arrows.
