Proposed features/lanes General Extension/ProposalPreVoting
This is the complete, unchanged version of the proposal, before it was reworked for the voting.
- 1 Rationale
- 2 Tagging
- 3 Additional features (optional)
- 4 Examples for additional features
- 5 Problems
- 6 Comments
- 7 See also
There is still no accepted, general way of specifying properties for the lanes of a way. This raises the problem that some feature can't be mapped at all or only by splitting ways which introduces additional problems. The need for lane properties comes mostly from routing applications, which need informations like which lane is a turn lane, on which lane a specific vehicle (hgv, bicycle, tram) is allowed to drive, and so on. But also specialized renderers could use it to show the lanes on very high zoom levels.
This proposal tries to solve these problems by an extension to already existing tags. Its main properties are:
- Every existing and future key can be used to either tag the value for the whole way or for each lane of the way
- Easy to identify: look at the street and you know the tags and vice versa
- Relations only where needed: relations are often hard to identify and understand and therefore are only used to connect the lanes from one way to another and only if the connection is not obvious.
- No need to map lanes as separate ways.
- No restriction to the layout of lanes
- Backward compatible as far as existing tags are not "redefined" in any way
- Completely open for extensions
This is a scheme for recoding facts about individual lanes on a road by reusing existing notation. It is applicable to any existing
<key>=<value> tag pair. Lane-specific information can be expressed on a way by suffixing the key with
:lanes. In such case, the value of that key then contains the values for each lane separated by a | (vertical bar) in left-to-right order as viewed in the respective driving direction of those lanes (resp. in the osm-way direction for the reversibles - see below). A simple example with
maxspeed on a one-way street:
This would be a road with three lanes and with a
maxspeed of 80 on the leftmost lane and 50 on all other lanes.
In the common case of two driving directions we need to use the already existing
lanes=6 lanes:forward=3 hgv:lanes:forward=no|yes|yes hgv:lanes:backward=no|yes|yes
This is a road with three lanes in each direction and heavy good vehicles are prohibited on the leftmost lane.
This is already the main part of the proposal. Nothing fancy. Everything that follows now adds additional features like turn-lanes, reversibles, strange lanes layout, lane connectivity and so on. These are not the core of this proposal but I add them anyway to demonstrate, that a complete tagging scheme is possible with this proposal.
Additional features (optional)
In this section I will show how to solve some common problems using this tagging scheme. For some of the problems new features are necessary. They are completely independent from the
:lanes extension and may or may not be in the final proposal. You may vote on the discussions page which features should be included in the final proposal. Please do so - thanks.
The new features will use the following tags:
For lanes running in both directions:
For all center turn lanes and passing lanes:
For turn and merge lanes:
For very complex lane layouts an extension to the direction key:
direction=[forward|both_ways|backward|.. existing values ..]
Turn lanes are one of the main reasons why openstreetmap needs lane tagging. Everyone who ever used a navigation device with lane guidance knows how convenient exact instructions can be. I suggest a new key
turn for this:
|left||left turn (only)|
|slight_left||slight left turn (only)|
|sharp_left||sharp left turn (only)|
|through||going straight through (only)|
|right||right turn (only)|
|slight_right||slight right turn (only)|
|sharp_right||sharp right turn (only)|
|merge_to_left||this lane merges with the lane to the left of it (only)|
|merge_to_right||this lane merges with the lane to the right of it (only)|
|none||there are no turn indications on this lane.
Used especially for better readability in case of many lanes
turn key is used on the way segment from the first indication via road markings, signposts or similar indications to the junction or completion of merge. Lanes without explicit indications should not be tagged by a
An example of a three-lane road, with one left-turn, one through, and one right-turn lane:
What about if the rightmost lane is also a through lane? No problem. In openstreetmap there is already the convention to allow more than one value for a key using semicolon as separator. So let's do that:
As the past has shown, no proposal will ever be approved if it doesn't consider bicycle lanes, so let's make an example with one of those (on a one-way):
This is a road with five lanes, two of them for bicycles. The two leftmost lanes are for left-turn (one motorized, one for bicycles) and the two rightmost lanes are for right-turn and through (again: one motorized and one for bicycles).
You may ask: "Where's the lanes=* key in the last example?" See the problems section for this.
Note: there seems to be a (dead?) proposal for this key, which is very similar to the way presented here.
In some countries lanes may travel in either direction depending on some conditions (see wiki). After some thoughts this is pretty straightforward and can be done without any new keys. Here an example with a time restriction.
lanes=3 opening_hours:lanes:forward=24/7|18-10|no opening_hours:lanes:backward=no|10-18|24/7
Please note, that we do not specify
lanes:backward, as these has no constant value in this situation.
opening_hours is not very intuitive in this case another way to specify time-dependent values would be preferable. Currently there is a proposal which introduces a way to do so (and others). The proposed
:lanes extension could also be used on this conditional tags.
Center/median turn lanes
In some countries there exist center turn lanes, which allows traffic from both directions to pull to make a left turn. This needs another extension, because these lanes are neither forward nor backward but for both directions.
lanes=3 lanes:forward=1 lanes:backward=1 lanes:both_ways=1 reversible:both_ways=median
For this example we need the extension
:both_ways, which corresponds to lanes which allow traffic for both directions and we need the new key reversible, which specifies which kind of reversible the lane is. For the
reversible key I suggest the following (see the wikipedia link above for details):
|median||Median/center turn lane|
Difficult lane layout
The only lane layouts that will cause problems with this scheme are ones, where the directions of the lanes are not somehow separated. Let's assume a four lane road, where motorized vehicles can go forward on the leftmost two lanes and on the rightmost lane and in the middle a bicycle lane for both directions exist. My first idea was this:
Big problem here! If the way is reversed the direction information is destroyed. So how about this:
Problem solved. Not too elegant but I guess this won't be needed too often and in most cases it would be much wiser to split this way. Please note, that this introduces an extension to the direction key:
direction=[forward|both_ways|backward|.. existing values ..]
According to taginfo the values forward and backward are already used, so actually only
both_ways would be a new value.
If you are missing the lanes=* tag in the examples, see the problem sections.
This extension to the direction key might also solve the 'oneway' issue for railways. For this we need traffic-related direction, e.g.:
direction:tram=both_ways direction:bus=forward direction:bicycle=both_ways
If we use this together with the
:lanes extension we could tag the following situation (assuming osm-way from front to back):
lanes=3 (maybe these are four lanes, but I am not sure about this) turn:lanes=none|left|none railway:lanes=|tram|tram direction:lanes:forward=backward|backward|forward direction:tram:lanes:forward=|both_ways|both_ways|
This would be the shortest way to tag this. If you only want to use the direction key for the tram traffic, you could also tag this the following way:
lanes=3 lanes:backward=2 turn:lanes:backward=left|none railway:lanes:backward=tram| railway:forward=tram direction:tram:lanes:backward=both_ways| direction:tram:forward=both_ways
This is longer, but for the non-tram-lanes it is more readable, at least in my opinion.
oneway=reversible<--> Intended to be handled by
reversible, but no full equivalence with new key
oneway:moped=...(in the wiki) <-->
direction:moped=...(of course also for
So actually we wouldn't need any new kew or value at all if we just use
oneway. At least in my opinion
direction is much more intuitive in this context and therefore I will leave this issue up for discussion (and out of the voting). Thanks for pointing this out.
Lane connectivity describes the connection of the lanes from one way to the lanes of another way. This is usually needed by routing applications. As more than one way is involved this can only be solved by a relation. Note that you will only need the relation if the connectivity is not obvious! There is no need to use a relation to specify that the only existing right-turn lane connects to the only lane present in the way going right. ;-)
I suggest the following relation, whereas its members (from, to, via) are the same as for the restriction relation.
|type||connectivity||Marks that this is a connectivity relation.|
|from||numbers||Numbers of lanes on the from way. If more than one lane should be connected, the key would change to |
|to||numbers||Numbers of lanes in the to way. If more than one lane in the to way is connected to a lane in the from way, than (as usually) use semicolon to separate them. In such case, the first to lane given, should be interpreted as the "straight" lane.|
|kind of traffic||Which kind of traffic this connectivity applies. See the description of access for possible values. Example: |
||This should be used on Y- or T-shaped junctions, to specify that this is the "main direction" of the road. This should solve the bifurcation problem of routing applications.|
day_on / etc.
|see restriction relation|
Numbers are used to specify lanes, starting from the outermost lane with number 1.
- Furthermore theoretically a lane reference could be used for better readability, but 1) needs additional tagging on each way and 2) would introduce a new key, which contains some arbitrary reference, which is not represented by any existing object and therefore contradicts the usual openstreetmap policy. Nonetheless I will show some examples using this approach for demonstration purpose and would like everyone to comment on this issue here.
lane_refwill most likely not be included in the voting!
The relation specifys that the
from lanes of the
from way connect to the
to lanes of the
to way. If the connection is only valid for certain kinds of traffic, this will be given in the
applies_to key. Additional restrictions are given in the same way as for the restriction relation.
If not only one group of lanes should be specified in the relation, the
:lanes suffix is added and the groups are as usually separated by a vertical bar.
This relation is only used for connection of lanes, which are not obvious. So applications should first consider default lane connections (as given by traffic rules and laws) and afterwards use the information from this relation to adjust those connections.
Note: as one can specify an arbitrary number of connections within a single relation, there should be no need for more than a single relation for a pair of ways.
In the following example the outermost lane (number 1) connects to the inner lane (number 2) of the following way:
type=connectivity from=1 to=2
If you want to connect more than one lane to the lanes of the following way, use the
type=connectivity from:lanes=1|2 to:lanes=2|3
In this example lane 1 of the originating way connected to lane 2 of the following way and lane 2 of the originating way connected to lane 3 of the following way.
This example demonstrates the use of a reference for each lane using the
lane_ref key (on oneways). First we specify lane references for the first way
lanes=2 name=Hintertupfinger Oberallee lane_ref:lanes=way1lane2|way1lane1
And now the references for the second way:
lanes=3 name=Kuckuckshof lane_ref:lanes=way2lane3|way2lane2|way2lane1
Now we connect those lanes:
type=connectivity from=way1lane2|way1lane1 to:lanes=way2lane3|way2lane2
So we connect the two leftmost lanes (way1lane1 and way1lane2) of the originating way ("Hintertupfinger Oberallee" with two lanes) to the two leftmost lanes (way2lane2 and way2lane3) of the following way "Kuckuckshof". The default connection (by traffic rules) would have been to connect way1lane1 with way2lane1 and way2lane2 with way2lane2. Both were overridden by the relation and now from way1 there is no lane connection to the rightmost lane of way2 (lane2way1).
If one lane connects to more than one lane in the following way, we use semicolon to separate the lanes in that way:
type=connectivity from=1|2 to=1;2|3;4
So lane 1 connects to lane 1 and 2 of the following way and lane 1 from the originating way connects to lane 3 and 4 of the following way.
And finally an example with a lane connection only valid for buses:
type=connectivity from=4 to=1 applies_to=bus
This tells us, that lane 4 of the originating way is connected to lane 1 of the following way, but this connection is only valid for buses.
To reduce the need for the
connectivity relation, I guess it would be wise to define some rules, which connections are "obvious" and need not to be mapped. The rules should be very simple, intuitive and generally recognized. In my opinion the following rules should cover many case (I use way A for the originating way and way B for the following way and only consider one direction):
|A and B have the same number of lanes||Every lane of A connects to the same lane of B (i.e. lane 1 connects to lane 1, 2 to 2, ...)|
|B has more lanes and no
||Every lane already present in A connects to the same lane in B and the additional lanes of B are added on the inner side by default. If turn lane(s) not present in A appear on the outer side in B, the additional lanes are placed on the outer side instead.|
|B has more lanes and the outermost lane(s) is/are
||The same rule as right before, but the merge lanes are ignored.|
|A has a merge lane and B has one lane less||Lanes outer of the merge lane are connected 1:1 from A to B. The merge lane together with the lane it merges with connect to the next lane of B. All following lanes are connected 1:1 from A to B. (This is pretty complicated to describe, but if you think of it: how else should they connect?)|
Please comment on this and/or provide additional "obvious" connections.
Turning restrictions for lanes
The current restriction relation can be extended to support turning restrictions for lanes just like any other tag/relation by adding
:lanes to the
For example if the rightmost lane is a right turn lane, but allows to go straight for buses, this could be tagged like this (I assume a way with two lanes):
type=restriction restriction:lanes=|only_right_turn except=bus
As existing applications don't know the
restriction:lanes key they will ignore this restriction (as they should).
It would be easy to specify some kind of default value for all lanes and then override the value only for specific lanes. Consider the first example:
This could also be tagged as:
lanes=3 maxspeed=50 maxspeed:lanes=80||
This might be the preferred way for existing osm-keys, because it provides at least some value to applications, that are not lanes-aware.
Examples for additional features
I already gave some example throughout this proposal. In this section I want to show some example for the (optional) additional features.
The tags for the parts (from left to right) would be:
lanes=4 turn:lanes=left|through|through|merge_to_left lanes=3 turn:lanes=through|through|merge_to_left
lanes=7 * lanes:forward=4 * lanes:backward=3 * turn:lanes:forward=left;through|left;through|through|right;through|right cycleway:lanes:forward=lane|no|no|no|no ** cycleway:lanes:backward=lane|no|no|no **
* Those tags are for compatibility with existing applications. They only count the lanes for motorized traffic as described in lanes=*. See the problem section for this and discuss about this on the Discussion page.
** I added the
no for better readability.
Center/median turn lanes
An example for a median turn lane (or center turn lane) on an image from wikipedia:
lanes=3 lanes:forward=1 lanes:backward=1 lanes:both_ways=1 (actually this is not necessary) reversible:both_ways=median
Consider the following junction:
For a navigational device it would be nearly impossible to determine which of the upper two roads is "straight through" and therefore it doesn't know if it has to advise you to "keep left", "keep right" or don't give any advise at all (aka the bifurcation problem). Assuming the "left" one is to be considered "through" we could tag this with the proposed
connectivity relation. We connect the rightmost lane to both lanes of the way going "right" and specify that this is not the preferred direction.
type=connectivity from=1 to=1;2 preferred=no
The issues with the lanes tag
In some examples I did not use the lanes=* tag. The reason for this is that the current definition of the lanes=* tag has several ambiguities and shortcomings. For example the english wiki page states, that
lanes only means lanes for motorized traffic. In the same sentence it links to a wikipedia article listing bicycle lanes. In the german wiki page motorized traffic is nowhere mentioned and it seems to include all kind of lanes. There was also a short discussion here.
For this reason I decided not to make any assumptions or links to this proposal. The
lanes key will not be redefined in any way and should continue to be used for what it was used up to now: only for lanes with motorized traffic. This of course will lead to the situation, that the number of lanes in a
:lanes extended key might be different, than the number mentioned in the
lanes key. But if we redefine the existing
lanes key we will break compatibility with existing applications and don't gain anything in return.
You may comment on this on here.
One problem of this proposal is the missing information about left-hand/right-hand traffic. Without this knowledge the exact lane layout is unknown, because one doesn't know if
:forward is left or right from
Without this information routing is possible, but rendering (of the lanes) is not. One solution for this would be to tag the kind of traffic on (e.g.) the administrative borders and - if necessary for example near the borders - on the ways itself.
Merging ways by lanes-unaware editor
Editors, which are not aware of
:lanes, might destroy
:lanes tags when ways are merged, simply by appending the value of one way to the value of the second way, separated by a semi-colon.
Need for new keys
Everything that can be mapped now for a single way can with this scheme be mapped for a single lane. But this doesn't mean that in some circumstances tagging might not get ugly. Assume a road with three lanes and the rightmost lane is only for buses and bicycles. With the current keys this has to be mapped as:
lanes=3 access:lanes=||no bus:lanes=||yes cycleway:lanes=||lane
Although this is perfectly correct, that's a lot of tags! But currently it can't be tagged differently (please note: actually this is not a problem of this scheme, but more of the existing tags). If we assume a single new key that gives us the possibility to tag the vehicle restrictions with one tag instead of three it will look like this:
Again please: this is not a problem of the tagging scheme presented in this proposal.
Please use the Discussion page for this.
- Experimental map showing lanes on motorways for a limited region from Soldier Boy
- Comparison of different lane tagging approaches
- Proposed features/Lane_group
- Proposed features/Turn_Lanes
- Proposed features/turn_lanes
- Proposed features/lane directions
- Proposed features/lane:x:direction
- Proposed features/lane and lane group
- Proposed features/Lanes as Relations
- Proposed features/Lanes ex
- Proposed features/Divider
- Relations/Proposed/turn lanes