User:Imagic/Status of lanes specification 20150117

Specifying properties for individual lanes: the suffix :lanes

In 2012 the suffix :lanes was introduced to allow the specification of properties of individual lanes. Analogous to the already existing suffixes :forward and :backward (and some more) it uses existing keys and changes the scope - but not the meaning - of their values.

Example 1: While maxspeed=50 specifies the speedlimit in both driving directions, the tag maxspeed:forward=30 only specifies the speedlimit in the "forward" direction (i.e. the driving direction is identical to the direction of the OSM way).

Example 2: With minspeed=80 a minimum speed of 80 is specified. If we want to specify a minimum speed limit of 80 for the left lane and 50 for the right lane, we would use minspeed:lanes=80|50.

Main properties of the suffix :lanes:

• Applicable to any existing <key>=<value> tag pair
• The values for each lane are separated by a | (vertical bar) in left-to-right order
  • Viewed in "forward" direction without suffix or with :forward and :both_ways
  • Viewed in "backward" direction with suffix :backward
• If the value of a specific lane is left blank, the (possibly assumed/implicit) value of the main key applies (the so called default value)
• Combinable with other suffixes like :forward, :backward, :both_ways, :conditional, etc.
• Combinable with keys without or different suffix(es); overrides values of more general suffixes
  • Example - overriding: minspeed=80 + minspeed:lanes=|50
  • Example - different suffixes: maxspeed:backward=100 + maxspeed:forward:lanes=70|40

Pay attention:

• The order of different suffixes may or may not matter:
  • If "layout" suffixes are mixed, the order doesn't matter, i.e. minspeed:lanes:forward=* has the same meaning as minspeed:forward:lanes=* (although the first is common and recommended).
  • When mixed with other suffixed, order usually matters, i.e. maxspeed:lanes:conditional=* needs different values than maxspeed:conditional:lanes=*
• The number of lane-dependent values of a key with :lanes-suffix may not be identical to the value of the key lanes=*, because of the limited defintion of the key lanes=*.
• Keys with the suffix :lanes consider all kind of lanes, i.e. no matter if a lane is for motorized or non-motorized traffic, if it is a full-width of half-width lane or if it is dedicated to PSV, buses, taxis, etc. Therefore one has to examine existing access tags closely to determine to what kind of traffic a lane is designated. Example: vehicle:lanes=yes|no|yes + bicycle:lanes=no|designated|yes

Keys specifically introduced for lanes

Turning indications with turn=*

The missing possibility to specify turning indications was the driving force of the introduction of the :lanes suffix, therefore the key turn=* was introduced at the same time. The turn=* key is used to specify the indicated direction in which a way or a lane will lead. It is used on the way segment from the first indication via road markings, signposts or similar indications to the junction or completion of merge. Attention: this key is not used for legal turning restrictions!

Examples:

• turn=right: All lanes of the way are for right-turning. This tag is usually used only on oneways with one lane.
• turn:backward=through: All lanes in backward direction are for driving straight through. This tag is usually used only with one lane.
• turn:lanes=none|through|slight_right: The leftmost lane has no turning indication, the middle lane is for driving straight through and the rightmost lane if for turning right. This should only be used on oneways.
• turn:lanes:forward=left|through|sharp_right: In forward direction the lanes have indications (viewed from left to right) for turning left, straight through and right.

A real world example:

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

Pay attention to the value of the lanes=* key. See the proposal of the :lanes extension for an explanation.

Allowed and forbidden lane changes with change=*

The key change is used to specify legally allowed and forbidden lane changes. The following example assumes that the OSM way runs from left to right.

 Part 1: change:lanes=yes|yes|yes
 Part 2: change:lanes=no|not_left|yes
 Part 3: change:lanes=yes|not_right|no
 Part 4: change:lanes=no|yes|no
 Part 5: change:lanes=yes|no|yes

Attention: On the leftmost lane of a road the value yes is equivalent to not_left, on the rightmost lane it is equivalent to not_right.

Direction of a road

The key destination=* is used to indicate the direction of a road by specifying the name(s) of the place(s) the road is leading to. In situations where no lane-specific information is available, this key might deliver enough information to guide one through even complex junctions. Besides the main tag, a few subkeys are proposed, which provide additional information:

• destination:ref=*: the reference of the target road; usually in the same format as in the key ref=*.
• destination:int_ref=*: the same as above, but the international reference.
• destination:country=*: provides the country code
• destination:symbol=*: one or more symbols or icons
• destination:lang=*: this can be used as destination:lang:<language code>, if the destination is written in more than one language

Examples:

Photo	Tags
	destination=Brno;Poysdorf;Mistelbach destination:ref=A5 destination:country=CZ
	destination=Λάρισα;Κοζάνη destination:lang:en=Larisa;Kozani destination:symbol=airport destination:ref=A 27 destination:int_ref=E 65

First step to lane connectivity: the key placement=*

Usually the OSM way of a road is drawn in the middle of that road. This often is not true when a road forks or another road joins and therefore the lane count changes. The key placement=* can be put on that part of a OSM way that is not in the middle of the road. Useful suffixes for this key are :forward, :backward, :start and :end.

Example:

No placement tag necessary. placement=transition placement=right_of:1 down only: placement=transition No placement tag necessary.

The OSM way of the motorway is drawn in the middle of the main lanes and in section 3 the OSM way is tagged with placement=right_of:1 to indicate to the consumer that the OSM way is at the right end of lane 1. In section 2 the OSM way has to be tagged with placement=transition if the beginning of the exit lane is important for the consumer (in many situations this might be irrelevant). In section 4 only the exit lane has to be tagged with placement=transition. The OSM way of the motorway does not have to be split between section 4 and 5 and no special tagging has to be applied.

Besides providing the layout of lanes, the key placement=* can also be used to get a better estimation of the connection of lanes between different OSM ways. For example, if a section tagged with lanes=2 connects to another section with lanes=3, one does not know where the third lane is added. If we now add placement=right_of:2 to the section with three lanes, it is very likely, that the third lane was added on the left side of the road. This is still a guess, but in many situations this information is enough to guess correct. When using this key to estimate lane connectivity, one must be sure to consider the width of the road resp. lanes!

Open issues

The following section presents a few open issues related to the specification of lanes. When discussing possible solutions to these issues, one has to keep in mind the following:

• OpenStreetMap is not a controlled or confined environment
• Mappers usually work for free, are not paid, just for fun
• Mappers won't accept orders, maybe not even recommendations, they work as they like (editors!)
• In order to get much data in an acceptable quality, it must be easy and intuitive to provide such data
• Mappers must be motivated; the result of their work must be quickly visible
• Mappers are not a homogeneous group, so multiple approaches to one, single problem ensure maximum participation
• If something is difficult to map, all mappers all over the world have to manage this problem all the time
• If something is difficult to process, all consumers all over the world has to solve this problem once

Lane connectivity

Currently no concept exists to specify how lanes are linked to each other between different road segments. The key placement=* can be used to make better guesses, but it does not provide accurate information. The most obvious solution (from a data-point-of-view) would be a relation like in the proposal of the lane_link relation. The example on the right would need one relation with two members ("from" and "to") and the following tags:

 type=lane_link
 link:forward=1
 link:lanes:backward=2|3

We assume, that both OSM ways run upwards.

The main problem with a relation is usually that it is a relation, i.e. the acceptance in the community is rather low.

At least for situations which involve only two OSM ways a simpler solution might yield higher acceptance. One possible solution could be a tag, that describes how a lane continues in the next road segment. In the previous example we could use transit:forward=new_on_right on the from-way and transit:lanes:backward=new_on_left|continue on the to-way. Besides better readability compared to the lane-numbers used in the relation, this wont force mappers to switch from tags to relation while editing lanes. As soon as more than two OSM ways connect, this tag is ambiguous, so we would need some rules to determine to which two ways the tag refers. One obvious approach would be: same name, same reference and smallest angle. From a data-point-of-view, the tag would be a very bad solution, but it might yield more data provided by the contributors.

(Potential) Sources of lane connections

When determining the connection of lanes between different road segments, one should consider the following information in the given order:

• the lane_link relation (exact definition)
• the transit tags (might involve guessing)
• The key placement=* (involves guessing)
• Tags with the suffix :lanes (involves heavy guessing)
• The key lanes=* (involves heavy guessing)

Junction area

In many situations it is necessary to know the extent of a junction, e.g. to determine exactly what streets enter and leave a junction in order to give more precise navigation instruction or what features belong to a single junction. The most obvious solution for this is an area and this is also proposed in the highway=junction proposal. This tagging scheme would not only provide information about the extent of the junction but also reduces the need of turning restrictions, i.e. less work for the mapper, more data for the consumer.

To map a junction, follow these steps:

• Draw each way exactly as you could follow it.
• If two ways intersect create a connecting node, if and only if you actually are legally allowed to change from one way to the other.
• Add turning restrictions for connecting nodes, where necessary.
• Create an area and completely cover the junction with it. Add the tag highway=junction to it. The area should also cover those nodes, where the ways of the junction are split up for the different driving directions.
• If the ways of the junction have a layer=* key specified, use the same layer for the area. If more than one layer is used - for example because of bridges or tunnels - split the area and set the layer tag accordingly.

Lane-dependent access restriction

Not a problem, but something consumers have to pay attention to: when processing lane-dependent access restrictions, one has to be aware that those restrictions usually do not apply to lane changes.

Example: A road with three lanes, the lane in the middle is a cycle lane and the rightmost lane is for turning right.

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

In this situation, cars are not allowed to drive on the middle lane, but they are obviously allowed to change from the leftmost to the rightmost lane, otherwise it would be impossible for them to turn right. If it would be really forbidden for cars to change from the leftmost lane to the lanes on the right, one should add another tag:

 change:lanes=no|...|...