From OpenStreetMap Wiki
Jump to: navigation, search

Dump of what was said on ''

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)


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 - 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)

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)
Silly lane count.jpg

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 Fi-bussikaista.jpg. 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: Fi-psv-part-time-hgv-part.png. 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 Fi-bussikaista-7-9-15-18.png. 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 - -- 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 (talkcontribs) 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)


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
Slip road nonlane of origin.png
, 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)

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)