# Talk:Lanes

## Node features

Can this be applied to tagged nodes on a highway, for example traffic lights which are only applicable to a subset of the lanes? --achadwick 13:31, 23 May 2012 (BST)

Hmm... I would say yes, if and only if the node is not an intersection of ways. However this was never discussed. --Imagic 15:17, 23 May 2012 (BST)

## Generalities-with-exceptions pattern?

It seems most natural to use the lanes scheme as a way of marking very occasional lane-specific exceptions to a general rule applicable to all of a highway. Hypothetically;

lanes:forward=3
maxspeed=50 mph
maxspeed:lanes:forward=40 mph||

In this case, the undefined lane-values should inherit the general maxspeed=50 mph, I think. Is that the intent? If so, the main page should clarify it. --achadwick 13:41, 23 May 2012 (BST)

Yes, this was the idea. The accepted proposal contained a section about default values, but obviously this information got lost.--Martinq 14:44, 23 May 2012 (BST)
It seems I have to update the article... this was indeed lost. I'll try to update the article within the next days. --Imagic 15:19, 23 May 2012 (BST)
Better now? --Imagic 10:09, 24 May 2012 (BST)

## Better explain how to add multiple values for turn lanes?

Could you please explain how adding multiple values for turn lanes work? Say I have two (forward) turn lanes, lane 1 with allowed direction: left, slight_left, straight; lane2 with straight, slight_right, right. how would i tag this? thanks, jose

You separate each lane-dependent value with | and if one lane-value needs to contain more than one value you separate them with ; . Your example would be; turn:lanes=through;left;slight_left|through;right;slight_right . Hope this helps. --Imagic 06:35, 29 November 2012 (UTC)
Thank you. Damn, I was always seeing two pairs of X|X, instead of one X, one X+Y and one Y. Also, please what is the difference between (turn) straight and through? Or are they synonymous (at least for one direction ways)?
You're welcome. Regarding straight vs. through: the value straight is not specified, only through is. So please only use through. I used the value straight right at the beginning when I started the :lanes-proposal, but dropped it in favour of through after some discussions. BTW: do you know the JOSM style Styles_Lane_features-style.mapcss? It's really great to verify your edits. It also started to support the proposed key change however only the positive values (like left, right) and not the proposed negative values (like not_right, not_left). Give it a try! If you intend to use the key change:lanes=* let me know and I can provide you with a patched version of the JOSM style which supports the proposed negative values. --Imagic 08:03, 29 November 2012 (UTC)
Thanks again. No need for allowed/forbidden values for now and that CSS for JOSM seems very useful!

## "Turn lanes as relation" proposal made obsolete?

Did I understand it correctly that now Relations/Proposed/turn_lanes proposal is obsolete?

I guess you have to ask the creator of that proposal. Info from taginfo: turn:lanes is today (29.11.2012) used about 7600 times and was proposed February 2012. The relation is used about 6600 times and was proposed March 2011. --Imagic 08:08, 29 November 2012 (UTC)

## More real-world examples

I think we need more real world examples, I started tagging a nice (but not too complex) junction with detailed bing coverage here -- could you possibly take a look at it and provide feedback? Also, I see you're very familiar with the subject so maybe you'd wanna join the discussion with MapFactor devs about the possibility of adding turn-lanes display to Navigator Free software. This could be the very first navigation software that could make use of the lanes info.

I started to create some motorway examples based on aerial images here. Currently I'm concentrating on motorway tagging, because 1) information about turning lanes is very important there (imagine you missed an exit on a motorway) and 2) tagging of junctions is still highly disputed.
But I also thought about junctions like yours and created some time ago a proposal that should make things a lot easier regarding turning restrictions. But as I can see you already mapped according to it - just without the highway=junction-area - so no news for you in there! Still may you have a look at the proposal of highway=junction and comment on it?
Regarding your tagging of the junction you provided: looks quite fine, but contains some errors. As this is pretty hard to explain here maybe you could contact me directly?
Regarding Navigator Free: another forum? Another login? I think I already have enough of this ;-) But regarding your last comment there: turn:lanes is not equal turn:lanes:forward - only if oneway=yes! And regarding the connectivity relation: I'm planning to write a proposal for it in the next weeks. Any feedback is very welcome. --Imagic 11:50, 29 November 2012 (UTC)

## Define 'forwards'

I'm having a bit of trouble with the tag lanes:forward and lanes:backward. With a two-way road, which way is "forwards"? For example, a set of traffic lights where the side approaching the intersection is divided into two lanes, one for turning left and the other for straight through/turn right. The side of the road leaving the intersection is a single lane. So do i put lanes=3 and turn:lanes=left|through;right|through with lanes:forward=2 and lanes:backward=1 ?

Thalass (talk) 05:08, 24 September 2013 (UTC)

The :forward and :backward key suffixes always refer to the direction of the osm data entity / way. It's explained on Forward & backward, left & right. The ways consist of an ordered list of nodes. If the way has been drawn towards the intersection, then your example would be lanes=3 lanes:forward=2 lanes:backward=1 turn:lanes:forward=left. If the way was draw in the other direction, you flip the :backward and :forward suffixes. Alv (talk) 06:06, 24 September 2013 (UTC)

Hi! It has been a little while since lanes (and turns) have been introduced. But I do wonder, is it adopted by any end-user application thus far, eg. navigation software? -- MrManny (talk) 09:43, 10 June 2014 (UTC)

OsmAnd uses the number of lanes to display the preferred lanes to drive on (see http://www.appsapk.com/wp-content/uploads/2013/09/OsmAnd-Maps-Navigation-1.jpg as an example). I don't think it uses turn:lanes due to its low adoption, but it counts the number of lanes from the way segment before and the segments after a highway split.--Sanderd17
you are right. The corresponding issue is http://code.google.com/p/osmand/issues/detail?id=1448 --Zuse (talk) 13:17, 29 August 2014 (UTC)

## Crossing with a designated lane for bicycles

Shouldn't this be

bicycle:lanes=yes|use_sidepath|designated|yes

It is not explicitly forbidden to use that lane.

I guess this depends on the country and other circumstances. Access tags should be discussed on the appropriate wiki page. Thanks. --Imagic (talk) 07:41, 22 December 2014 (UTC)

## Crossing with a designated lane for bicycles (second issue)

The page says

``` lanes=3
turn:lanes=left|through|through|right
vehicle:lanes=yes|yes|no|yes
bicycle:lanes=yes|no|designated|yes
```

This is in contradiction with the Vehicle types page. According to that page bicycle is a vehicle and automobile is the general term for all motorised vehicles. Hence this example should be:

...

``` automobile:lanes=yes|yes|no|yes
bicycle:lanes=yes|no|designated|yes
```

--voschix (talk) 17:44, 30 March 2015 (UTC)

That's not a contradiction. The tag bicycle is more specific than vehicle, so first we forbid all kind of vehicles on the third lane and afterwards - because "bicycle" is more specific - we specify the third lane as designated to bicycles. In fact you have to use "vehicle" and not "automobile", because otherwise all kind of non-motorized vehicles would be allowed on the third lane, which is not the case. And last but not least: I have never seen the tag automobile used anywhere and a quick look on taginfo shows that I am not alone ;-) --Imagic (talk) 07:34, 31 March 2015 (UTC)

### Another issue

Excluding bicycle lanes but not HOV, bus lanes or turn lanes breaks lane guidance. Bicycle facilities often have more than one lane and it's increasingly common to not have bicycle lanes as the rightmost or leftmost lane. Not being able to include these with lane tagging explicitly breaks accurate description of the lane layout. If width of the lane is a concern, tag for lane widths, don't exclude bicycle lanes. Paul Johnson (talk) 15:09, 25 September 2017 (UTC)

You are right, this is an unsolved issue, if the bicycle lane is not part of a vehicle lane and of significant width like shown in the example. Cause to change an existing tag is no prefered solution, I guess we need a new picture for small width bicycle lanes, as part of vehicle lanes, and a new example for separated bicycle lanes with full vehicle width. Have you ever thought about discussing this at tagging mailing list ? --Robybully (talk) 17:34, 25 September 2017 (UTC)
Ran into the chicken-egg problem there. Nobody wanted to work out the problem because nobody's tagging for completeness on lanes. Nobody's tagging for completeness on lanes because the wiki says specifically not to do so. Paul Johnson (talk) 18:25, 25 September 2017 (UTC)
Let's not act like this still isn't a problem. Instead of trying to make bicycles a special case, it's a lot, lot easier to include it in the standard tagging, and just use access:lanes=*, bicycle:lanes=* etc similar to how bus or HOV lanes are handled and include it in the usual lane counts. It makes for a far more complete total solution to the problem. Paul Johnson (talk) 06:23, 18 December 2017 (UTC)
A full solution of the problem would also have to cover sidewalks and parking lanes. You can have bicycles on either side of the parking lane, for example, so the tagging model needs to be able to distinguish those cases. If there's going to be two classes of "lanes" anyway (i.e. :lanes tagging plus the special cycleway/sidewalk/parking_lane/bus_bay lanes), I don't think moving cycle lanes from one category into the other helps much. --Tordanik 14:41, 23 December 2017 (UTC)
I didnt follow this discussion yet but was adding the small explaination for lanes=3 some months ago, after some discussion in german forum. It is actually a problem as described that bikes can have their own key (cycleway:right) and in some cases, like in the picture, they are included in the :lanes-subkey of the main highway but excluded in counting. This makes sense as lanes=3 is a key referring to highway=..., which can also be used by busses which then can also have their own lanes later on, but busses can not use the bike lanes (just for crossing). There wold also be no need for a lanes-count if it wouldnt be this one we use now, because every program can just count the amounts of |-signs in the :lanes-subkey to get the total number of lanes. And having an information two times in any digital system is a waste of ressources, why would i need lanes=3 if i can just count the |-signs. This idea was described somehow in the initial proposal and routing programs like osmand also use it exactly in this way. I personally dont see any need of changing this. Allowing a different count of lanes than describing is actually the needed extra-information to see how much lanes are from a highway and how much are not, no matter where the lanes are. I totally agree that there is a better solution but changing an existing and used scheme must be avoided. --ionr 12:44, 30 December 2017 utc
It wouldn't be changing the existing scheme, it'd simply be unbreaking the scheme for a special lane that currently doesn't get treated like every other special lane. And having a lanes=* count overall helps detect problems with the lanes:forward/backward/both_ways count.Paul Johnson (talk) 19:08, 30 December 2017 (UTC)

## Time of day

How can we tag turn lanes and lanes counts for each direction which change based on the time of day? Aharvey (talk) 12:59, 26 June 2017 (UTC)

Using Conditional restrictions should work for that, i.e. using the lanes:[forward/backward:]conditional and turn:lanes:[forward/backward:]conditional keys. --Tordanik 15:47, 27 June 2017 (UTC)

## Where to split

Where do we split a way when a lane is added? Sometimes before an intersection a turn lane is added on the side, but it doesn't get lane markings right away (although there might be a sign on the side of the road indicating which direction each lane goes). With respect to the lanes suffix, do we add the lane as soon as it is full-width, or do we wait until there are road markings separating it? And if we add it right away, is there a way to mark that the lane markings do not start right away? Germyb (talk) 03:03, 30 September 2017 (UTC)

## Need for a more holistic solution

The way I see it is this: it is usually desirable to map a road as a single way, but I think there are circumstances where the ability to represent lanes individually can be essential to accurate mapping. Complex junctions, toll plazas, freeways, and big-city urban arterials are examples where each lane has so many different independent properties, that it would be better to be able to map them separately. That allows us to use our existing system of access restrictions and turn controls to faithfully represent a roadway instead of having to use a very clunky specialized syntax which has to be re-invented for each property one wants to tag. A relation should be used to join the lanes together and indicate that they form the same base roadway. Separate lanes could also, in the future, be used to ascertain accurate traffic information, as lanes with different purposes often move at different speeds. With the prospect of consumer GPS units with 10cm accuracy on the horizon, this is a matter we need to seriously consider. --Ipatrol (talk) 02:36, 1 June 2018 (UTC)

Even if that is a good idea (I doubt that) please do not use highway=* for individual lanes Mateusz Konieczny (talk) 07:58, 1 June 2018 (UTC)

I am trying to edit the Motorway sample and include some new images but I cannot upload any new image because I received: ⧼apierror-permissiondenied⧽ How do I proceed? Thx javierpf (talk) 20:14, 5 April 2019 (UTC)

## Lane markings required?

It was disputed in several occasions that lane markings are required for the lanes tag. What could be an alternative criterion are "observable lanes", i.e. vehicles driving one behind the other, in a kind of lane.--Dieterdreist (talk) 13:35, 30 July 2019 (UTC)

I'm generally in favor of including the intended purpose of the lane instead of no marking when the marking is missing, as this is often clear to someone on the ground but not to an algorithm. Paul Johnson (talk) 23:25, 6 September 2019 (UTC)

## Use of through lane / bike lanes

Since the use of the trough lane is directly forbidden (DE:254) only in very rare cases and mandatory use of the bike lane is mostly due to indirect laws like keep right or DE:237,DE:240,DE:241. So, the through lane should neither be tagged "yes" or "no", but rather something like "use_sidepath; which in turn is not applicable here. Because of that, I propose to keep it empty: `bicycle:lanes=yes||designated|yes` --Hubert87 (talk) 13:04, 17 August 2019 (UTC)

use_sidepath would be for cycleway along road. But "no" is decent approximation here, at least for Poland - for straight lane and straight cycleway lane next to each other leading in the same direction there is nearly no chance that cyclist would be allowed to use car lane. So "no" is not perfect but much better than "yes" or missing data. Mateusz Konieczny (talk) 14:02, 17 August 2019 (UTC)
Might be ok for Poland, but in DE we have *a lot* of exception where you can diviate from using bike lane, even if it is mandatory. Using "no" would mean that you could not use the through lane even if there was a legal exception. (Same reason for introducing "use_sidepath" when cycleways are drawn seperatly).
While not perfect (we would need to adapt a new value for that situiation), in DE it is much better to use "yes".
You could do some logic where you'd say: use through lane, unless there is a "designated" lane. But vice versa, that is not possible. --Hubert87 (talk) 14:23, 17 August 2019 (UTC)
seems to be covered by "In other countries where use of bicycle lane is not fully obligatory for cyclists, like in Germany, tagging may be "bicycle:lanes=yes|yes|designated|yes"." Mateusz Konieczny (talk) 15:13, 17 August 2019 (UTC)
Ok, missed that. Thanks. --Hubert87 (talk) 15:40, 17 August 2019 (UTC)

## access:lanes combined with psv:lanes and bicycle:lanes

Should psv:lanes=designated, tram:lanes=designated or bicycle:lanes=designated be combined with access:lanes=no for that lane? I've noticed this combination in many places in my city. Rostaman (talk) 01:22, 29 August 2020 (UTC)

Yes. As with regular access tags, the access:lanes=no tag provides the default access (you can't use this lane) for the corresponding lane, while more specific access tags, like bicycle:lanes=designated says "except for bicycles, for which this lane is designated". Baloo Uriza (talk) 01:40, 29 August 2020 (UTC)
Makes sense now, thanks. Rostaman (talk) 01:42, 29 August 2020 (UTC)
Especially as lane may be designated for some vehicle type and still available for other Mateusz Konieczny (talk) 18:38, 29 August 2020 (UTC)
Note embedded_rails:lanes=* type of tagging, seems more popular than tram:lanes=* Mateusz Konieczny (talk) 18:38, 29 August 2020 (UTC)

In Ireland it is common for some roads / bridges to be too narrow to allow traffic to enter a section of road if there is already a vehicle coming the other direction. In the UK (and possibly other countries), road layouts have been adjust to force this yielding behaviour as a road calming measure.

How should this be mapped? lanes=1, width=* and possibly maxwidth=* makes sense but how does one express that yielding is required?

--Dónal (talk) 21:41, 16 December 2020 (UTC)

priority=* of direction if priority-controlled; oneway=alternating if signalized. ---- Kovposch (talk) 03:00, 17 December 2020 (UTC)

Thanks for the pointer. I've added to the talk page of priority=* because it doesn't cover the use case of equal priority. Dónal (talk) 09:50, 17 December 2020 (UTC)

I also add narrow=yes and usually lane_markings=no is also appropriate in these cases. Rostaman (talk) 10:43, 17 December 2020 (UTC)

## Were horses forgotten in vehicle:lanes

Myself, did not even notice but was horse=* forgotten since the first version of the bicycle:lanes=* example in (2014) by @Imagic:? I use the more general access:lanes=* in my region for exclusive cycle and bus lanes but that might be depending on the country. Fun fact, the examples and the JOSM style from the same user do only include access:lanes=*. --Skyper (talk) 13:47, 2 February 2023 (UTC)

Can you link affected example? Is it present in the current page version? @Skyper: Mateusz Konieczny (talk) 12:32, 2 December 2023 (UTC)