Talk:Key:lanes

Dump of what was said on 'talk@openstreetmap.org'

Simon Wood said

...have a question about passing/slow lanes.

By passing lane, I mean a section of non-segregated road which has an additional lane in one direction. This is often on an up-hill section where larger traffic would slow...

The same situation can occur where you have turn left/right turn lanes at junctions, which is very common here.

Andy Robinson said

To annotate the physical: Break the way at the start and end of each passing section and tag with lanes=2 for the normal sections (assuming its normally a two lane undivided highway) and lanes=3 where the way includes the passing lane.

This doesn't deal with solid white line restrictions that might be present along sections of the way, but then we don't really attempt to get to that level of detail for normal roads at the moment anyway.

Paul Hurley said

Would it be too forward to suggest a Proposed features/lanes page. My proposal would be that lanes is the total number of lanes on the way, so ;

Two Way residential road with one lane in either direction: lanes=2 One way road: lanes=1 individual carriageway for three lane motorway: lanes=3

With a rationale that this would then clear up confusion, and help with recording information such as single lane width restrictions, passing places etc.

I then assume that some of the highway tags could then assume a lanes value (residential, unclassified, tertiary: lanes=2)

Simon Wood said

I would agree with this 'proposal', seems to handle all situations even covering 'traffic calming' techniques where a lane is deliberately obstructed and traffic needs to wait for a break in oncoming traffic.

The one area it doesn't cover is the merging of lanes I mentioned earlier, as I have seen it describing lane counting from the 'slow' lane. In a non-segregated road I suppose you could count from the slow lane in the direction of the way, but then we're back to the switch directions problems.

• I totally agree with Paul Hurley's description, and it's obvious that the number of lanes refer to the way when you come to a 1 lane street ... IMHO 2 is a good default for all highways (motor vehicles ones)... but as long as the lanes tag doesn't affect the rendering of the way, it doesn't add a lot of value to the data ... --PhilippeP 14:44, 19 March 2008 (UTC)

It's about time the renderers takes this into account, it would be very helpful --PhilippeP 07:40, 12 June 2008 (UTC)

Few thoughts about lanes

This is not set yet as the renderers do not yet cares about lanes. (maybe whe should have an additionnal proposal for this)

Every highways should have a default (if not specified) number of lanes of 2. Except for footway,cycleway,bridleway,track,path which should default to 1.

Rendering would then adapt the width of the highway when lanes is different from default. We could add a lanes_shift=left/center(default)/right which should help place the lanes as in the reel world (needs mockup to be clear)...

--PhilippeP 07:06, 18 June 2008 (UTC)

Bus lanes, bus & taxi lanes, breakdown lanes,...

Hi all, how are we to count bus lanes (in Vienna e.g. this means access=no, psv=yes, sometimes bicycle=yes)? Shall they be counted? They must not be used by normal cars… The same is true with breakdown/emergency lanes on highway=motorway. Shall they be counted? On itself it would be a useful information (access for emergency cars, routing to next emergency bay (de) if no breakdown lane is present,…). But shall the amount of lanes be based on this as well? -- MapFlea 08:43, 19 November 2008 (UTC)

Sounds to me like those bus lanes (and any other special-use lanes) can really only be mapped if they are separate ways. If that's the case, those lanes definitely shouldn't be counted in the lanes tag for the main roadway. Even if the bus lanes aren't mapped separately, I wouldn't count them — but I think that may be up for debate. Vid the Kid 08:10, 20 April 2009 (UTC)

To make decision harder, we have similar bus/psv lanes that may and shall be used just prior to turning right, and which either a) allow all traffic outside the working hours and/or b) allow vans and trucks outside rush hours. It can be a normal lane part of the day, so we've used, for a long time already, any of lanes:psv=*, lanes:bus=*, lanes:psv:forward=* etc. and do count them in the total number of lanes - Key:lanes has been described as "physical amount of travel lanes" from the start. (We even have some lanes:psv:times=* entered.) Another approach which doesn't suit our situation is described at Key:busway. Alv 14:33, 12 January 2011 (UTC)

In Belgium, near Brussels, we have a motorway E411 with the right lane reserved for both buses and taxis. What to do with this case? Cordialement, gerdami 11:35, 15 August 2012 (BST)

You should use lanes=x with x equal the number of all lanes (including the one reserved for buses and taxis) and lanes:psv=1 for the number of lanes for buses and taxis. --Imagic 16:22, 16 August 2012 (BST)

OK, thanks.--Cordialement, gerdami 12:05, 18 August 2012 (BST)

How to indicate the bus/psv lane position -left/centre/right- ? --Cordialement, gerdami 12:05, 18 August 2012 (BST)

The layout of lanes as well as any lane-specific property can be tagged with the :lanes-extension. Example: if the right-most lane of a road with three lanes is designated to public service vehicles, simply use: psv:lanes=yes|yes|designated . --Imagic 14:47, 18 August 2012 (BST)

A few throughts from VidTheKid

Transient Lanes

To me, it seems to make more sense to only count lanes used for through traffic. Short passing or turning lanes don't really need to be included, at least until we start doing separate ways for each lane. I think in some situations with many intersections, including turning lanes could even be misleading because they might start to look like additional through lanes. Vid the Kid 08:06, 20 April 2009 (UTC)

IMO they should be counted eventually, but they're often last in line when deciding what to improve. From the very start lanes=* was described as "the number of physical lanes", and changing that would diminish the validity of existing tagging. We just take for granted that often they're just not yet mapped. Alv 11:23, 16 September 2011 (BST)

Each or Both?

I guess it makes sense, especially from a rendering point of view, to count the total number of lanes for both directions of a two-way road. But from a routing / planning point of view, I think it would be of greater interest to know the number of through lanes in each direction. (I thought that's what I read about the lanes key in the past...) The number of through lanes in each direction, coupled with the type of road, speed limit, and nearby landuse info, could influence estimated speed. I suppose that could be deduced by dividing by two if the road is two-way, but that would either require every way to have a oneway=yes/no or to have consistent agreement about what types of roads are implied to be one way or two way, unless otherwise tagged. (That Cloudmade Maps routing thing [1] that was just featured on the Main Page doesn't appear to assume motorways are one way, yet Tag:highway=motorway suggests that the oneway=yes is implied.) Vid the Kid 08:06, 20 April 2009 (UTC)

Rendering Issues

If the renderers are going to vary the width of the highway lines based on the lanes key, I think they'll have to do some fancy intersection effects for things like major motorway branches, or else the result could look rather bad. On trying to illustrate this, my graphics editor crashed, so I'll just have to describe what I mean. Let's say there's a section of motorway that's three lanes wide. The right lane splits off, leaving two lanes on the motorway. If the renderer renders the lines with widths proportional to the number of lanes, then the line will appear to get suddenly narrower where the 3-lane way ends, and the 1-lane and 2-lane ways begin, because those ways will all meet at the same point and therefore, until the 1-lane way gets sufficiently away from the 2-lane way, the two lines will overlap and not produce a line as wide as the 3-lane way. I can imagine some algorithms the renderer can use to compensate for this, but they're not simple, and invariably require the renderer to abandon the common system of simply overlaying lines of differing widths. Or, the ways could be drawn differently in the data so as to minimize this rendering issue, and by some standards actually represent the roadway centerlines better, but that would produce strange right-angles that could confuse routing algorithms. (Perhaps the renderer could do this as a preprocessing task; actually, that's probably the best solution!) On the other hand, when we start doing separate ways for each lane, this shouldn't be an issue at all. Vid the Kid 08:06, 20 April 2009 (UTC)

Parking Lanes

What about those highways that have parking lanes on the left and/or the right side? Should they be counted? Also, is there a tag used to map those lanes?

See Proposed_features/parking_lane for a proposal and discussion for a more straightforward way. parking:both=inline seems to make sense. Alv 14:43, 30 December 2009 (UTC)

Currently that's parking:lane:both=parallel. Alv 11:30, 16 September 2011 (BST)

---

Railways?

It would be helpful if key:railways could also be tagged in similar fashion, as most have one for each direction (and sometimes two for each). --MattGPS 01:47, 28 July 2009 (UTC)

This might be more appropriate - Proposed_features/Multiple_Tracks --Pobice 22:40, 2 August 2009 (UTC)

No centerline / unmarked lanes - one or two lanes?

Should a narrow two-way residential road with no centerline be tagged as lanes=1 or 2? --NE2 21:44, 21 January 2010 (UTC)

As much as referring to law text in everyday issues can look geeky: at least here the traffic law defines a lane as (a marked strip or) "a strip of road wide enough for traffic". Also, not having a painted line on two lane unpaved roads doesn't make those wide unpaved roads one lane roads. Why would a paved road of equal width have a different number of lanes? Most cases are clear, it's either wide enough for two, or two cars can not pass each other (except at junctions or built passing places).

This does lead to border line cases, when the road is wide enough for two motorcars (width no more than 2 m) to pass comfortably, but two oncoming buses or trucks (width 2.5 m) would either have to slow down to crawling speed or even reverse/wait at wider spots. Add to that busy roadside parking (partially blocking the "lane") and then a single lanes tag gets even less descriptive. (And just wait till it snows and the piles of snow make it narrower still.) Oneway streets don't have the problem. I and several others have identified some border cases as lanes=1.5, for now, where there are no marked lanes and two cars can just barely fit side-by-side. Alv 08:39, 22 January 2010 (UTC)

In german law there is a difference between a centerline or none: Without a centerline you have to drive so slowly, that you can stop at the half way that you see! With a center line, you have to stop at the full way that you see. I think this is similar in other countries (by logic). So I think (on paved roads) the centerline is the indicator for the line-tag. For the width there is a seperate tag. --MasiMaster (talk) 12:24, 23 April 2013 (UTC)

Please specify where or which authority claims that; the "Auf Fahrbahnen, die so schmal sind, dass dort entgegenkommende Fahrzeuge gefährdet werden könnten, muss jedoch so langsam gefahren werden, dass mindestens innerhalb der Hälfte der übersehbaren Strecke gehalten werden kann." only reads "so narrow that oncoming vehicles could be endangered". That is a different attribute from paint or no paint. There's a correlation, but they are not universally equal. Alv (talk) 12:36, 23 April 2013 (UTC)

Ok, it seems that german law depends on the vehicle width. Vehicles must be narrower than 2.55m (agricultural/forestry vehicles >= 3.00m). With some space between the passing vehicles and to the edge of the road, the road width must be around 5.50m (if the own vehicle is 2.00m width). Apart from this special german rigths, there is no logical rule that say at which wide we add lanes=1 or 2, or more accurate: why lanes depens only by width? I think this is not a good solution. Why we don't use lanes only for marked lanes (maybe additional for lane-signs at unpaved roads?), and width only for the width of the road? What is the advantage of lanes=2 at width>=4m? --HalverHahn (talk) 18:50, 22 March 2016 (UTC) (aka MasiMaster)

The rules about lane markings and stopping distances are similar in New Zealand. "A driver must not drive a vehicle on a road that is not marked in lanes at such a speed that the driver is unable to stop in half the length of roadway that is visible to the driver." Clause 5.9 (2) Land Transport (Road User) Rule 2004. Since this road rule is very similar to the German road rule it probably means the rule is applicable in most countries. I think this also means that the road has a single traffic lane, no matter how wide the road is. Often, New Zealand roads are surveyed to be 20 metres wide from property boundary to property boundary but often more than two thirds of the road reserve is taken up with footpaths, parking, grass berms, decorative trees, utility poles and the like, leaving a carriageway that is barely wide enough for 2 vehicles to pass, so it makes sense to be able to stop in half the visible roadway, if no lanes are marked, because any oncoming vehicle is probably travelling in the middle of the carriageway. What this means is that the tag "lanes=2" indicates the carriageway has a marked centreline and is wide enough to allow opposing vehicles to pass each other safely, without needing to slow down and be able to stop in half the available roadway. Omitting the lanes tag indicates that there are no lane markings or the state of lane markings are unknown and indicates that the above rule might apply. However, giving lanes a value of less than 2 means the above rule could apply, even though lanes are known to be marked. A value of lanes=1 would be advised when it is known that only ONE traffic lane is marked or available on the road, and oncoming traffic is unable to pass and may have to give way at or even reverse to a passing place depending on the width of the road and the size of the vehicles. This is likely to apply to one lane bridges and tunnels, service lanes and alleyways, as well as to narrow roads on steep hillsides or those traversing cliff-faces. On footpaths it would mean people could only travel single file and have to wait for the path to clear, e.g. a ladder or narrow staircase. - Huttite (talk) 22:19, 7 January 2017 (UTC)

Well, the law in our country (Czech Republic) does define the lane as part of the road which allows the vehicles to drive in one stream. Marked or unmarked it is still a line if it is wide enough. Therefore I would mark the way as lanes=2.

I have reverted the last change of this page. As it marked this example with lanes=1. Which is obviously wrong. Chrabros (talk) 07:41, 10 February 2017 (UTC)

In the Wiki there were examples with small roads without marked lanes, where lanes = 2 was recommended. The number of lanes is presumed to be estimated on the basis of the road width. This causes the following problems:

• By doing this, there are two keys for the width: width (exact) and lanes (derived from width). Lanes offers no additional benefits compared to width.

• There is no more key for the number of marked lanes.

• There is no objective criterion when to use 1 or 2. Vehicles have very different widths (trucks <> smart). How many vehicles fit next to each other, therefore, can only be reliably stated with width in conjunction with the vehicle widths (especially relevant for truck routing).

• There are confusion in extra width lanes, where two cars can drive side by side, but cars and trucks not. In traffic planning, an extra width lane is treated as one lane; in OSM, according to the previous wiki, this is a subjective decision.

• The "motorised traffic wider than a motor cycle" criterion does not work on multi-lane cycle tracks.

There was a longer discussion in the forum. Result: "The conclusion is that lanes is only used for the number of marked lanes and not as a crutch for the width of the road to be tagged with width."

Therefore, I have adapted the examples in the wiki accordingly.--Jo (talk) 23:09, 10 February 2017 (UTC)

OK. I have no problems with changing this tag to marked lanes only. But then in the example you change was to lanes=1 but there are no lanes marked. So there should be no lanes tag at all. Chrabros (talk) 08:47, 13 February 2017 (UTC)

I see the key is documented as "specify the total number of marked lanes of a road." and the example updated to reflect that. Similar to how you can use oneway=no to be explicit, how about lanes=none to distinguish where lanes hasn't been surveyed/added to OSM and lanes has been checked and there are no marked lanes. Aharvey (talk) 23:16, 19 April 2018 (UTC)

The topic was discussed on the tagging mailing list in June 2019. I initially also argued in favour of having the lanes-key only refer to marked lanes and use something like lanes=none to mark unmarked roads. However, the outcome was that it turned out that people have been tagging physical (de-facto) and not necessarily marked lanes in the past and still are. Examples from different countries were given that suggest that in many places around the world, but even in Europe, there exist roads beyond narrow "1.5 lane" roads that are not marked. Rewriting the wiki to only include marked lanes would be a redefinition of the tag. This is strongly discouraged, as the wiki should primarily document the real usage of tags.

In any case, the necessity to distinguish unmarked roads from marked roads was recognized in the mailing list discussion and the the solution proposed there was simply to add a second tag like lane_markings=no, lanes:markings=no or similar.

I will add a title in the wiki page to reflect the outcome of the mailing list discussion --Westnordost (talk) 12:24, 16 June 2019 (UTC)

Any way to view lanes?

Is there any service that currently renders lanes, so I can make sure I didn't screw any up? --NE2 03:31, 9 February 2010 (UTC)

Though I haven't tried it yet, it appears Kothic, a Python renderer, can show lanes. -- Joshdoe 18:33, 11 May 2011 (BST)

Yes. You can use the ITO Map 'highway lanes' view here. PeterIto 23:20, 11 May 2011 (BST)

Amount of physical lanes

From 2006 the key has been precisely defined as the "amount of physical travel lanes". (the word "physical" added a bit later) Only lately some have argued that some physical travel lanes shouldn't be counted into that figure. Excluding some turning lanes runs to vague cases, where the person editing (nor the data consumers) can't know if a single turning lane should be included or not, especially when a short turning lane for the next intersection is the lane where drivers joined to from the previous one. Or on motorways where an onramp lane continues as the rightmost lane for several hundred meters before finally departing as a offramp of the next junction. Also, data consumers can work better if they have the total number of lanes at their disposal, from "take the right lane" to favoring the road with turning lanes when two otherwise identical roads are available - turning traffic impedes the traffic flow less on roads with turning lanes. Old comments on this page, on the talk list and on the irc channel confirm that the physical amount is the only consistent way to use the lanes=* key. We just think it's at this time missing data, that people can add once they're working on their favourite areas more extensively. Alv 14:15, 17 September 2011 (BST)

Old comments on this page show that there is no consensus. I think it's stupid to tag a four-lane road as lanes=6 because it has continuous right turn lanes. --NE2 17:22, 17 September 2011 (BST)

Huh? The consensus predates the misconceptions of one user on this talk page. Your road does have 6 lanes', even if you would "call it" a four lane road. Tags are not natural language, but rather describe physical properties. Alv 23:14, 17 September 2011 (BST)

Unless you can provide any conditions on how mappers can identify which turning lanes or other lanes should not be included in the value, it doesn't make sense to introduce vagueness and ambiguous statements in the existing, properly documented tags. Even then you should propose a new key for such a lane count. The "no agreement" part is just disrupting the documentation and invalidating the lanes=* values in the whole database. Alv 12:46, 18 September 2011 (BST)

There are many tags that are not precisely defined. For example, landuse=residential is "dedicated to, or having predominantly residential houses or apartment buildings". --NE2 13:11, 18 September 2011 (BST)

Focus, please. Residential landuse has nothing to do with the lanes tag. Alv 14:48, 18 September 2011 (BST)

Focus on what you said, which is that "it doesn't make sense to introduce vagueness and ambiguous statements in the existing, properly documented tags". The truth is that the database already has such ambiguity, and saying on the lanes page that there is only one way of tagging lanes gives users a misleading view of our data. --NE2 15:26, 18 September 2011 (BST)

If such edits exist, they should be fixed once the next editor notices it. Also, you rejected the version which acknowledged that some users might have used the key in ways that are incompatible with the rest of the world and the older, logical usage. An analogy: we don't document highway=unclassified as "some use this for roads that need a better classification" but rather "should not be used to tag roads that need classification". The data will heal eventually, but only if the documentation isn't left to turn into a wishy-washy "some-this some-that nobody knows" list of open issues. Alv 16:08, 18 September 2011 (BST)

Here we see what your method would produce at every major intersection on a suburban arterial. No thanks. --NE2 16:20, 18 September 2011 (BST)

Quite contrary, that's the way it will be in the future. Nothing silly about it, you'll end up splitting ways for other properties, too. Alv 16:25, 18 September 2011 (BST)

That's not how it will be in Orlando in the future if I have anything to say about it. --NE2 16:40, 18 September 2011 (BST)

Uh, so how would you be able to map any meaningful information about the lane layout? Regardless whether a section with x lanes, y of which are turn lanes, is mapped as (key names invented for purposes of this example only) lanes=x + turn_lanes=y or lanes=x-y + turn_lanes=y, you will have to split the way (or, of course, create individual ways for each lane). A single continuous way just won't work. --Tordanik 20:00, 18 September 2011 (BST)

I question the statement that it's "meaningful" to map the small pieces of (total) 4 lanes as separate from those with a center turn lane. --NE2 11:42, 19 September 2011 (BST)

Opposition to "small pieces" is one big downside of the introduction of the way datatype. As a result some people now want to so much hang on continuous ways (usually for the ease of editing) that any splitting for whatever reason is no longer ok according to them (although I kind of understand this as the current editors certainly won't be helping you once the way is in small segments but that should really be fixed in the editing tools rather than using some data kludge). Ij 13:03, 22 September 2011 (BST)

Please note that nobody is there to force you to actually do the work of splitting and tagging them anywhere (your area included), especially as most people are, well, volunteers. Ij 10:51, 26 September 2011 (BST)

More examples

I have recently created a few more examples: User:Martinq/Lane examples

Should I merge them with the existing examples -- or is better to create a dedicated example page (to avoid the key page get too long)? --Martinq 20:24, 4 May 2012 (BST)

Great examples! I guess it would be better to create a dedicated example page and add there all possible tags, i.e. not only "lanes", but e.g. parking, shoulders, tram tracks, cycleways, etc. I was planning to do this in the next weeks but obviously you got there first. --Imagic 20:18, 5 May 2012 (BST)

Speed limits per lane

On the E411 motorway between Wavre and Brussels (Belgium), the right lane is reserved for buses and taxi (PSV) but speed lane is limited to 50 km/h. Any proposal for this?--Cordialement, gerdami 20:22, 3 September 2012 (BST)

It should be possible to map that using the syntax described on Lanes. --Tordanik 20:28, 3 September 2012 (BST)

Thanks. Didn't know that page. Why do we have 2 pages on same topic? --Cordialement, gerdami 19:50, 6 September 2012 (BST)

Because these are two distinct topics: the key lanes=* is used for the number of lanes (for motorised traffic), the :lanes-extension is used to specify lane-dependent properties. But we should add a link to Lanes on this page just like there is a link to lanes=* on the Lanes-page. I'll do that today. --Imagic 06:51, 7 September 2012 (BST)

If I understand you correct the right lane is reserved for psv and the speed limit for this lane is 50 km/h. This could easily be mapped a follows (assuming three lanes):

vehicle:lanes=yes|yes|no *
psv:lanes=yes|yes|designated **
maxspeed=xxx ***
maxspeed:lanes=||50 ****

* first ban all vehicles from the right-most lane

** then specify the right-most lane as a designated psv-lane

*** specify the general speed limit as xxx km/h (mainly for compatibility issues)

**** and override this speed limit for the right-most lane with 50 km/h. Please note, that the lane-values for the first two lanes are left empty, i.e. the the general speed limit applies.

Hope this helps. --Imagic 07:35, 4 September 2012 (BST)

Thanks. Will map accordingly. --Cordialement, gerdami 19:50, 6 September 2012 (BST)

psv lanes for certain times of day

Can someone add detailed to this page about how one should tag time and date constraints that relate to a psv lane? PeterIto 20:29, 29 October 2012 (UTC)

What exactly do you have in mind? A lane that is usually accessible for general traffic but from xx:xx to yy:yy it is a designated psv lane? Or something different? --Imagic 07:47, 30 October 2012 (UTC)

That's correct. 'bus lane between 7am and 10m mon-fri' etc. PeterIto 17:14, 30 October 2012 (UTC)

Our way from way back is lanes:bus=1 lanes:bus:times=Mo-Fr 07:00-10:00. With the new conditional values, as approved, it would be lanes:bus:conditional=1 @ Mo-Fr 07:00-10:00. It gets harder to tag, when (a real life case)

• Everybody can use said lane on sundays, Mo-Fr nighttime 18-07 and Sa 00-09 + 15-24,
• and everybody may use it for turning right always, and cyclists always.
• Only buses and taxis (psv's) Mo-Fr 07-18 and Sa 09-15; but
• Also hgv's and goods vehicles Mo-Sa 09-15.

I believe it's a country level decision (law) if bus lanes may/must be used for turning right, when they are the rightmost lane of a road, so tagging does not necessarily need to be explicit about that. Alv 21:04, 30 October 2012 (UTC)

Sounds good. Could you add something to that effect to the page? Currently there is no mention of times and dates? Happy to do so in due course, but may be better for someone who actually knows what they are doing to make the addition! PeterIto 06:50, 31 October 2012 (UTC)

I'm searching for a photo to illustrate the example. As soon as I found one I'll add an example. --Imagic 09:51, 31 October 2012 (UTC)

I'll added an example now. --Imagic 10:21, 31 October 2012 (UTC)

There's now also another example photo here . This is above a the single lane Alv 10:24, 31 October 2012 (UTC) I described above. Text below describes the next picture: Alv 17:20, 31 October 2012 (UTC)

Photo of another kind of time limited lane; buses and taxis always (+ bicycles), hgv's on saturdays and sundays, and also Mo-Fr 09:00-15:00, and 18:00-07:00.

Duh... are the fines high in Finland for taking the wrong lane? Even with your explanation the sign isn't clear to me. I would read this sign as a lane that is designated to bus+taxi from 7:00-18:00 and on weekends from 09:00-15:00, and hgvs from 09:00-15:00. --Imagic 14:05, 31 October 2012 (UTC)

The description was for the next image, kind of my bad. That's one way to say it, yes. Took a while to find out, apparently the fine is a fixed 50 euros for ignoring most of the traffic signs. Alv 17:20, 31 October 2012 (UTC)

+ Everybody must use it if turning right at the next intersection, always: . Alv 10:43, 31 October 2012 (UTC)

I'm not sure if we can tag that at the moment this way. --Imagic 14:05, 31 October 2012 (UTC)

Somebody proposed a solution with a time limited lane dependent turn restriction relation (with restriction:lanes=||only_right_turn), which excludes those allowed to drive straight on the lane. But it gets quite ... verbose. Oh, it was you and the case was a bit different. I haven't thought it through after that, if it could work here, too. Alv 17:25, 31 October 2012 (UTC)

It would definitively work with a time restricted, lane dependent turning restriction: at that times when general traffic may only use the lane for turning right 1) allow general traffic at that lane, and 2) add a only_right restriction for that lane and that time. But - and that's are real big "but" - this is getting awfully "verbose" (as you called it). And also very fragile. I guess(!) it would be more readable if we could express the turning restriction with a tag on the way. This would result in:

motor_vehicles:lanes:conditional=yes|yes @ (...time...)
turn:restriction:lanes:conditional=none|only_right @ (...time...)

Now all conditions are back on the way and not hidden in some relation. But I doubt that we could find a functioning definition of such a turn:restriction-tag so that's all very theoretically. --Imagic 19:42, 31 October 2012 (UTC)

Just to be thorough, the simple case of a lane reserved only for psv's within a limited timeframe; Mo-Fr 07-09 and 15-18 . Alv 13:40, 31 October 2012 (UTC)

This is (more or less) like the example already added. --Imagic 14:05, 31 October 2012 (UTC)

Barrier machines and variable lane counts

A few highways employ barrier machines to adjust the number of lanes. The total number of lanes is always the same, but the number of lanes in either direction can be changed by the barrier machine transferring the barrier laterally across the highway. Has anyone come up with a good scheme for tagging these? Does the convention of mapping out these highways as dual carriageways still apply here? I'm tempted to call them "reversible," but I thought that was reserved for highways where all lanes are either in one direction or the other, not both. —Larry Gilbert (talk) 19:21, 31 January 2013 (UTC)

We've got a similar system in Sydney, Australia. A good example of how the lane count remains the same, but allocation in each direction is changed (morning vs. afternoon peak hour) is shown in this video - https://www.youtube.com/watch?v=OXwcBZjU71I -- Kru (talk) 07:57, 20 June 2014 (UTC)

UK has the Aston Expressway comprising 7 lanes where the 'barrier' is simply an empty lane. Normally 3 lanes forward and three lanes backward, the barrier lane can be 'moved' merely by changes to the variable signage over each lane. The system is referred to 'tidal flow' management.

—Preceding unsigned comment added by Pmailkeey001 (talk • contribs) 10:38, 29 November 2015

An even more complicated case: I-30 east from Dallas, Texas. Normally there are two carriageways with 3 lanes each, but in the morning rush a barrier machine "subtracts" one lane from the eastbound (low-volume) to create a westbound HOV lane, and in the evening rush it does the opposite. Currently, I have a single reversible HOV way in the middle (probably should be two) with the appropriate access/time restrictions, so routing is mostly correct, but the number of lanes on one of the general purpose ways is still wrong during that period. How do I tag this scenario correctly? StephenTX (talk) 16:18, 5 October 2016 (UTC)

Hi Stephen, it might indeed be better to use four ways to map the situation. How about tagging the two normal ways of the dual carriage way with lanes:conditional=*?. Example: lanes=3 + lanes:conditional=2 @ (06:00-10:00). --Biff (talk) 09:14, 19 October 2016 (UTC)

Called a reversible lane or tidal flow they are well described at https://en.wikipedia.org/wiki/Reversible_lane. I've been mapping them on one way roads as lanes:conditional=* and two way roads as lanes:forward:conditional=* + lanes:backward:conditional=*. --Aharvey (talk) 23:59, 14 March 2022 (UTC)

lanes:hov

The page mentions using lanes:hov=*, however Taginfo shows no use of this tag. [2] note:lanes=* often describes HOV lanes. [3] Mrwojo (talk) 23:45, 15 February 2013 (UTC)

That's interesting, I wasn't aware of this rather widely used key - but unfortunately it's not very machine readable. The notes=* key is explicitly intended for communication with other mappers only. The best representation for this data would be hov:lanes, using the Lanes syntax - it also allows you to define which lanes are hov lanes and would therefore be able to represent all the information in these notes. --Tordanik 18:01, 23 February 2013 (UTC)

I have to agree with Tordanik on this. A simple hov:lanes=...|designated|... could hold all the information hidden in the note:lanes=* currently. --Imagic (talk) 20:25, 24 February 2013 (UTC)

better description for "Minor slip roads" that don't get counted

As it is written now, it can be easily misinterpreted; it took me a second reading to see that the bullet point meant the case a) in the drawing on the right

, right? In that case the distance between carriageway edges (solid lines) gets to a width of three lanes for a puny fraction of the length, but the _link road "covers" that additional tarmac width. Whereas in the regular case (b), the deceleration lane (3) is a part of the road, before the actual _link way begins. Alv (talk) 23:48, 30 July 2013 (UTC)

Sorry, I don't quite understand you. What part of the text exactly is misleading in your opinion? (Your examples are correct: a -> lanes=2 , b -> lanes=3) --Imagic (talk) 07:04, 31 July 2013 (UTC)

From the previous discussions I took part in about counting the lanes, I'd say it's too easy for many to consider also a deceleration lane as "by virtue of intersecting road" - without the intersecting road, there would not be that lane. Also, a "major" slip road might have just that kind of small piece of asphalt. The start "minor slip roads" easily first makes the reader think of "all less important slip roads", even those with a deceleration lane, and only the end then narrows it down. In fact, on the web people usually scan just the two first words to decide if they'll read the whole sentence, or not, especially when the page already has a lot of information. I just want this to be as really, really, really explicit about the situation, without being too long or using sentence constructs that a novice English learner could stumble on when reading. If we get the sentence closer to "Simple English", the meaning might become more exact to other foreign readers. Some sraft suggestions/ideas to work on:

1. "Minor, wider parts where the slip road begins without a deceleration lane."
2. "Surface presented with other ways and which is used only for that other direction."
3. "Driving surface only required for transition to other ways, that is, to slip roads without a deceleration lane."

Btw, did the need for this addition come up in some discussion/question? Alv (talk) 17:52, 31 July 2013 (UTC)

Better now?

By "addition" do you mean the mentioning of "minor slip roads"? --Imagic (talk) 08:17, 1 August 2013 (UTC)

Yes, I think it's better now. And yes, I meant the mentioning of minor slip roads. Alv (talk) 09:07, 1 August 2013 (UTC)

Yes, it came up in some discussion and please don't remind me of that discussion again. ;-) --Imagic (talk) 09:49, 1 August 2013 (UTC)

New Key: Lanes:direction=

A request to officially recognise new key: Lanes:direction=*

Usage: to specify the direction of the lanes on the carriageway (i.e. whether forward or backward)

For example, the normal UK situation is:

Lanes=2 Lanes:direction=forward|backward

Occasionally, one finds:

Lanes=2 Lanes:direction=backward|forward

Example: 339070833 where the norm is reversed due to an unusual junction at its North East end.

Doesn't driving_side=* cover this already? --Tordanik 13:39, 1 December 2015 (UTC)

Yes, driving_side=* does already cover this! --Biff (talk) 06:47, 12 July 2016 (UTC)

I have added the correct tag to the example given by the original poster. --Biff (talk) 06:53, 12 July 2016 (UTC)

driving_side=* doesn't cover the situation where multiple lanes in the same direction are separated by a lane(s) in the other direction. For example there are a couple of streets in my city that are two-way with multiple lanes, and also have two lanes of tram tracks on one side of the street, which are also drivable by certain classes of motor vehicles (non-rail), so it might look like lanes:direction=forward|backward|forward|forward|backward. Rostaman (talk) 23:55, 7 November 2020 (UTC)

True, that situation would be too complex for driving_side=*. Proposed features/driving direction could be useful here. (The proposed key driving_direction:lanes would be a better choice than lanes:direction because 1. the standard is that :lanes is appended at the end of the key and, 2. direction=* by itself already means far too many different things (imo). --Tordanik 19:01, 25 January 2021 (UTC)

Thanks, that proposal sounds much better indeed. Hopefully it will be implemented! Rostaman (talk) 13:31, 26 January 2021 (UTC)

Conversion of lanes=x;y

The database contains thousands of instances where the lanes tag contains values with an "x;y" format, e.g. lanes=2;1 (taginfo}. I suppose that this format is based on the abandoned proposal Proposed_features/Lanes_ex. This conflicts with the widely accepted format of lanes=*. I think that an agreed set of conversion rules is needed for taggers who find such "strange" tags and want to make them readable according to the common format definition. Here's a proposal:

• The value should be converted to the normal lanes format by counting the total number of lanes, e.g. lanes=3.
• The lane segmentation information should be saved by moving it to a separate key. I would recommend the change:lanes=* tag which is also not an accepted proposal but quite widely used and doesn't create conflicts. An automatic conversion of the example would likely lead to the value change:lanes=yes|not_right|no which may or may not represent the actual situation. Therefore any conversions should rather be done manually and consider the lines that actually exists on the road.

Any comments? --Biff (talk) 08:06, 12 July 2016 (UTC)

Slight update: Only hundreds of instances appear to fit the above description. In thousands of cases the lanes tag with a strange format is used by the turnlanes relation, see Relations/Proposed/turn_lanes, which also appears to be mostly abandoned because turn:lanes=* is now more widely used. --Biff (talk) 08:22, 12 July 2016 (UTC)

lanes = -1

Several thousand ways are currently tagged with lanes=-1 (taginfo). Most of these ways are located in Canada and I suppose that in this case the invalid value is due to a known issue with CanVec, see CanVec#CanVec_10. --Biff (talk) 12:18, 12 July 2016 (UTC)

Counting bicycle lanes

Hello, this wiki has been changed to "Bicycle lanes. Use the tag cycleway=lane for those as well." A few weeks ago. This is super-confusing as it is conflicting with the use of cycleway=lane. Usage of cycleway=lane is an extra key which already says: Theres also a cyclewaylane. If there would be a cycle lane outside of the highway lanes and a cycle lane inside it would be the same tagging. Lane=xxx counts lanes of a highway, not the cycleway. Is there any discussion or decission why this has been changed? --ionr 08:57, 24. Sep. 2017 (UTC)

Why not both? The two do not conflict, and bike lanes that are physically part of the same road (not offset on their own cycleway like on modern Dutch cycletracks) are typical in the US. Additionally, there may be any combination of bike lanes, multiple bike lanes in the same direction. There's even a street by work that has four shared bike lanes, and two dedicated bike lanes. There's no way to map this if you don't map all the lanes, as lanes. Additionally, other restricted lanes are mapped as lanes, with their access mapped by mode as well. And dedicated cycleways are increasingly having their own multiple marked lanes. Why treat bicycle facilities differently? Paul Johnson (talk) 23:51, 19 April 2018 (UTC)

Lanes inferred from markings

We are tagging "how many marked traffic lanes there are on a highway", but do these markings have to be continuous? Once a lane is divided into two by markings, if the lane markings disappear for a time, do we reduce the number of lanes for that stretch of road even if the traffic does not actually merge? Similarly, if a lane doubles in width close to an intersection in preparation for an added turn lane before the lane markings actually begin, do we split the lane when it reaches full width or when the lane markings begin? Germyb (talk) 02:38, 25 September 2017 (UTC)

shared lanes

I have this Problem (It's about lanes=, lannes:forward= and lanes:backward=):

TLDR: Currently there is no way (of which I know) to map the red area. My suggestion is to map lanes that are for more than one direction with lanes:shared=<int>

Most of the example is pretty easy to map.
The streets left and right, up and down with 2 lanes can be tagged using lanes=2. The single lane ways where the road splits is lanes=1
The section outside the red area is also pretty easy to tag with lanes=3, lanes:forward=2, lanes:backward=1, turn:lanes:forward=left|through;right (or the other way round for forward and backward, depending on the way direction).
The red section however does not have a proper way to tag it which I would know about. lanes=3 is correct, but also not really since turn:lanes:forward=left|through;right and turn:lanes:backward=left|through;right would imply lanes=4.
My suggestion for this would be to tag this section with lanes:shared=1. This would just mean that lanes=3 would be lanes=4 or lanes=2+0.5+0.5 for the calculating program.
If you know of any other way that already exists please let me know!
--TBKMrt (talk) 09:03, 25 May 2018 (UTC)

I believe you may be looking for lanes:both_ways, see Proposed features/Suffix both ways. --Tordanik 16:45, 25 May 2018 (UTC)

Marked or unmarked lanes

The requirement that lanes be marked looks to have come from discussion on the German forum. While that may suit their area of the world it looks to be causing problems in other parts of the world where lane markings may be not existent but traffic uses 'lanes' despite the lack of marking. I would ignore the requirement of lanes being marked in those areas of the world where it is the usual practice. Warin61 (talk) 23:05, 16 June 2019 (UTC)

The topic has already been discussed extensively. The result is that width and lane should not describe the same thing. This is not a regional problem but one of the clear demarcation of information for data consumers.

The problems that derive from lanes based on "common vehicle widths" are described above (section "No centerline - one or two lanes"). Are there any new aspects to this?

PS: I think you are free to ignore the requirement, especially if the situation is clear (eg highway) and it is common in your country. But that should not be recommended in the wiki, because even in your country there will be roads where it is not clear how many lanes they have.

--Jo (talk) 06:18, 17 June 2019 (UTC)

The information is marked or unmarked lanes. Having section just on this topic rather than having it as part of 'marked centre line' topic could be helpfull to those who do not want to search through all the topics that might apply. The conclusion at this point in time is: If the locals use unmarked lanes and it is judged normal then map them. If the local forum has some 'rule' then use that. If you don't know then don't tag it, use the width=* to map what you know and see. Warin61 (talk) 07:05, 17 June 2019 (UTC)

This is understandable for me. If thereare no lines, lanes may be tagged depending on the road width and common vehicle widths.

Not understandable for me is the following:

In the examples here is an approximately 5m wide street listed, on which one lane was marked with white paint (left example)

The wiki said there were no marked lanes. This is m.e. obviously wrong, that's why I changed that. My change was reversed without discussion by Mateusz Konieczny.

For me, only the right example is without lane markings. The left example has lane markings of one wide lane, although the width would have been enough for two very narrow lanes.

white lane markings	for comparison: without lane markings
Wiki now: Two-way road without marked lanes lanes=2 Right is in my opinion: Two-way road with one marked wide lane lanes=1 lanes_marked=yes	Wiki now: width=4 source:width=estimated A narrow two-way road without marked lanes and with an estimated width of four metres. That is correct, in my opinion

I do not like such editing wars. That's why I put this up for discussion here https://forum.openstreetmap.org/viewtopic.php?pid=763371.

"on which one lane was marked with white paint" are you sure that it is marking of lanes? I am pretty sure that it is marking of sides of a road, to aid drivers during night Mateusz Konieczny (talk) 11:19, 29 September 2019 (UTC)

It's both. The lines mark the lane and the side of the road.

Actually, there are three different questions here:

1) Is it possible to tag lanes=1 together with lanes_marked=yes if there are white lines on the side (I mean yes)

2) If so, it stays at lanes=1, even if the marked lane is very wide (I mean yes)

3) From when can lanes=2 be tagged, if there are no lines on the road (I mean from about 5.2m)

To 1): A single lane is marked by white lines on both sides (see example here). Roadway sides are also marked by two white lines on both sides. If there are white lines on both sides, there is always a lane marked. That's why lanes_marked=no is not in the left example above for me. Otherwise there should never be a lanes=1 together with lanes_marked=yes.

To 2): In the example the road authority has then intentionally marked only one lane for both directions, e.g. to lower the speed. That's why,

• If there were only lines on the sides of the road then for me the following would be appropriate:
  lanes_marked=yes; lanes=1; lanes:both_ways=1

• If there was a center line, the following would be correct:
  lanes_marked=yes; lanes=2; lanes:forward=1; lanes:backward=1;

• If there were no lines, the following would be good:
  lanes_marked=no; if desired one can add lanes=1 or lanes=2, depending on the width of the road (see 3))

To 3): In the EU vehicles may be a maximum of 2.55m wide, in other regions it is similar. Everything under 5.10m + minimal Distance does not allow passing without leaving the road. Therefore, I would not recommend tagging streets under 5.2m with lanes=2 if there are no lines on the road ore only lines on the sides of the road.

--Jo (talk) 22:25, 2 October 2019 (UTC)

"If there are white lines on both sides, there is always a lane marked." Citation needed. Note that in forum thread that you started multiple people disagree with this conclusion Mateusz Konieczny (talk) 11:14, 3 October 2019 (UTC)

I only know the situation in Germany. Here are drawn between lanes dashed line ("Leitlinie", sign 340) or solid line ("Sperrlinie", sign 295). The side line is also the "Sperrlinie" (solid line, sign 295). Thus, solid lines nr 295 on both sides can mark a lane.

What I have just learned: The marking of the lanes is optional in Germany. By law, "lanes are merely the part of a lane that a car/truck needs for unhindered driving along the lane" (§7 StVO). So you're right that two white lines do not mean it just has to be one lane. I was wrong.

So your description of the left (German) image would be correct if two vehicles can pass unhindered. Vehicles may be up to 2.55m wide in Europe. The minimum distance when passing is according to the jurisdiction in Germany 1m ( see wikipedia), real is it 0.25-0,5m. The road would have to be well over 5m wide for lanes=2.

The German road in the left picture is, according to meassuring from the aerial view, only 4.5m wide. This is not enough for the unhindered passing of two permissible wide vehicles. Therefore, I do not consider this as a good example for 'lanes=2'.

--Jo (talk) 22:34, 3 October 2019 (UTC)

Lanes are sometimes narrower than maximum legal vehicle width Mateusz Konieczny (talk) 20:29, 4 October 2019 (UTC)

Here is an example where the marked lanes are not wider than a motorcycle. Without a center line, the lane would be lane=1. Strictly according to the wiki text "traffic lanes suitable for vehicles wider than a motorbike." there should be no lanes=2 even with the marking. But there are 2 lanes marked there.

--Jo (talk) 23:11, 7 September 2021 (UTC)

@JochenB: This reminds me of the standard sign in California that turns a two-lane road into a one-lane road for trucks and buses only. [4] – Minh Nguyễn ^💬 09:32, 8 September 2021 (UTC)

Resolved: Mateusz Konieczny (talk) 23:00, 16 May 2022 (UTC)

Wikidata

I'm having trouble seeing what the issue with linking to "lane" on Wikidata:Q3222002 is. Doesn't it match (enough) more or less the counterpart in OpenStreetMap? (Maybe it's a linguistic one.) --Chris2map (talk) 07:56, 3 May 2020 (UTC)

The wikidata item is a "division of the carriageway within a road designated to be used by a single line of vehicles", but this tag is added to a highway=* feature to count the "total number of traffic lanes available for motorised traffic". That's quite different, in the way that "number of houses in a town" is different than "a residence", both because the OpenStreetMap tag is limited to motorised traffic (yet a lane can before buses or bikes under Wikidata:Q3222002), and because we are talking about "how many things are in some larger thing" rather than the thing itself. --Jeisenbe (talk) 16:16, 3 May 2020 (UTC)

OK. But the wikidata item is a general description of the term lane, isn't it, independent of singular and plural? Sure, the OpenStreetMap key is the total of lanes, that's right. Would the link with the subkey Lanes be more precise? — Regarding motorized traffic and bus, I find different statements and examples: Key:lanes#Description says "The following lanes should be included: * General purpose traffic lanes suitable for vehicles wider than a motorbike. * Bus lanes, ...". And Key:lanes#Examples lists "highway=cycleway / lanes=2 / A cycleway with two marked lanes". Therefore also busses and bicycles. --Chris2map (talk) 20:16, 3 May 2020 (UTC)

Resolved: wikidata are now linked from data items and not linked from OSM Wiki Mateusz Konieczny (talk) 22:59, 16 May 2022 (UTC)

width vs. width:carriageway

width=* is mentioned several times in the article, particularly as an alternative to lanes=* on narrower and unmarked roads. To indicate the width of the carriageway, currently also width:carriageway=* is increasingly used (background infos see here) – is there anything against mentioning this in the article next to width=*? --Supaplex030 (talk) 08:09, 14 July 2021 (UTC)

Should be OK to mention. BTW, width tagging is also useful on roads with well marked lanes to detect ones designed for high speed car traffic (wider lanes) and for other purposes (see AB Street)Mateusz Konieczny (talk) 18:58, 22 July 2021 (UTC)

Single-lane Carriageways

In rural Australia, it is common for low-traffic arterial roads to be sealed single-lane carriageways with unsealed shoulders, where one or both vehicles are expected to have at least one set of wheels on the shoulder when passing.

Single-lane carriageway with road train route

Would the correct tagging for this be:
lane_markings=no
and optionally:
width=4
source:width=estimated
shoulder=yes
shoulder:surface=unpaved

IMHO this sounds like a reasonable tagging. --Schoschi (talk) 14:38, 11 October 2021 (UTC)

Inclusion of turn lanes

This article currently states:

Turning lanes for minor roads are not normally included.

Before 2012, it was more permissive, describing the inclusion of turn lanes as an option. I propose to revise this passage to affirm that turn lanes are typically included but not guaranteed to be included.

While I don't doubt that some mappers don't always bother to increment lanes=* on every way that has a turn lane, this is clearly not the norm. Here are a few basic lane configurations:

Inclusion of turn lanes in lanes:*=*

turn:lanes:*=*	Excludes turn lanes	Includes turn lanes	Query
	2	45,113	[5]
	0	47,017	[6]
	1	198,070	[7]
	0	3,407	[8]
	0	6,801	[9]
	155	27,939	[10]
	0	1,209	[11]
	13	4,855	[12]
	2,226	191,188	[13]
	203	32,327	[14]

 – Minh Nguyễn ^💬 21:58, 16 May 2022 (UTC)

Oh yeah, this is definitely a wrong claim (I mean the sentence in the wiki page, not yours). --Westnordost (talk) 22:09, 16 May 2022 (UTC)

Edited to "Turning lanes for minor roads are sometimes not included, but it is preferable to include them in a lane count.". I think that not including them in lane count should be considered and described as a mistake, and I think that it is already treated this way Mateusz Konieczny (talk) 22:58, 16 May 2022 (UTC)

Lanes that are primarily spots for buses to stop

Lanes on a highway where buses stop. I guess technically it's a bus lane but is there a way to indicate there are many bus stops (like a parking lane for cars)? Or is bus lane with the stops marked good enough? --Dónal (talk) 22:10, 14 August 2022 (UTC)

A bus stop is not a bus lane. Other vehicles can usually pass through bus stop box. --- Kovposch (talk) 02:27, 15 August 2022 (UTC)

To be clear. The lane is restricted to buses (stopped or not). I tagged it with busway:left=lane. --Dónal (talk) 06:05, 15 August 2022 (UTC)

"Slip-roads"?

The text says "Longer slip-roads, for example on motorways and other fast major roads" but I'm not even clear on what a slip road is, even after reading https://en.wikipedia.org/wiki/Slip_lane

Likewise "Minor slip roads without a deceleration/acceleration lane, i.e. the main road is wider only because of the intersecting road" could really use an illustration. Brightj (talk) 19:33, 11 July 2023 (UTC)