Proposed features/lane link
|Proposal status:||Abandoned (inactive)|
|Definition:||Specify which lanes from one OSM way (physically) connect to which lanes from the following OSM way.|
|Rendered as:||Some renderers may show the lanes at very high zoom level, but the major target for this are navigation devices|
Lane links describe which lanes of one OSM way link/connect (physically) to which lanes of another OSM 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 (see below)! 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. ;-)
Create a relation containing one OSM way as from member and another OSM way as to member. If you want to specify the lane links for both direction, the forward direction would be from the from member to the to member and the backwards direction would be from the to member to the from member.
|type||lane_link||Marks that this relation specifies the links between the lanes of two OSM ways.|
See below for all possible variants.
|numbers||Specifiy the number of the lane in the to way which the lane from the the from way links to, whereby the lanes are numbered from left to right (viewed in the driving direction) and starting with 1 (one). The lane number 0 (zero) indicates that the lane is not linked to any lane of the to way; this might be useful on junctions. If more than one lane is present in the to way, the key would change to |
It is usually not necessary to specify more than one relation for one specific pair of ways. If deviating links are specified by two or more relations, it would be purely random which link is used in the end. Therefore relations with overlapping link definitions should be treated as data errors.
In order to reduce the need of this relation, some rules have to be specified which should cover most of the usual lane links between two OSM ways. The goal should be to have a set of 10 to 20 rules which cover at least 98% of all lane links. In order to specify such rules we would need a detailed analysis of what links are most common.
Many of the following examples should be covered by the rules for obvious links and therefore would not need this relation. But the examples are kept simple to make it easier too understand the relation.
1) This tag is not part of this proposal. Based on the idea in the through_route proposal this or a similar tag might be useful on any relation connecting two OSM ways, i.e. with exactly one from and one to member, to specify if this direction is the "main route" or if you would have to "turn" to follow the road.
Oh no - a relation! I hate relations!
Me too. But in this case we are specifying one property which applies to some specific pair of OSM ways. We don't have any other concept in OSM to specify such property. The rules for obvious links should keep the number of needed relations at a minimum.
- link : there is only one lane in the from way and the road is a one-way
- link:forward : there is only one lane in the from way in the forward direction
- link:backward : there is only one lane in the from way in the backward direction
- link:lanes : multiple lanes in the from way and the road is a one-way
- link:lanes:forward : multiple lanes in the from way in the forward direction
- link:lanes:backward : multiple lanes in the from way in the backward direction
Why do we specify link:lanes=1|2 in the example to the left and not link:lanes=1|2;3? Because in order to access the third lane we have to change from the second lane to the third lane. If one needs to change lanes, the lane from the from way is not linked to the lane in the to way. The tag link:lanes=1|2;3 would describe the example to the right - see the difference?
What about left-hand traffic?
Everything works the same. The only difference is that lane number 1 is now the outermost lane instead of an inner lane, but that doesn't change neither the tagging nor the meaning.
Are bicycle lanes covered?
Yes. As explained in the proposal of the :lanes extension, contrary to the key lanes=*, the lane-dependent values of tags ending on :lanes cover all lanes, independent of the kind of traffic they are designated to.
With some access tags or the turning restriction relation, but not with this relation. This relation (and the rules for obvious links) specifies how the lanes are linked on the ground. It does not provide any access or turning restrictions as there are already established concepts for these.
In some rare situations we would need lane-based turning restrictions. But to provide such information the turning restriction relation should be extended by the well-known :lanes concept, so that all turning restrictions are kept in one place. For example if one has to turn right if driving on the third lane, one could specify this with the tag restriction:lanes=||only_right_turn within a restriction relation.
Please use the Discussion page for this.