Talk:Key:lanes

Contents 1 Dump of what was said on 'talk@openstreetmap.org' 1.1 Simon Wood said: 1.2 Andy Robinson said: 1.3 Paul Hurley said: 1.4 Simon Wood said: 2 Few thoughts about lanes 3 Bus lanes, breakdown lanes,... 4 A few throughts from VidTheKid 4.1 Transient Lanes 4.2 Each or Both? 4.3 Rendering Issues 5 Parking Lanes 6 Railways? 7 No centerline - one or two lanes? 8 Any way to view lanes? 9 Amount of physical lanes 10 More examples

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

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

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)