Proposal:Lanes as Relations
| This proposal has been obsoleted by Lanes. |
| Lanes as Relations | |
|---|---|
| Proposal status: | Obsoleted (inactive) |
| Proposed by: | Tordanik |
| Tagging: | type=lane |
| Applies to: | 
|
| Definition: | turn lanes, cycle lanes and sidewalks in a highway |
| Statistics: |
|
| Rendered as: | lane separators and textures in 2D and 3D renderings, lane assistants for navigation, ... |
| Draft started: | 2011-10-09 |
Despite years of discussion, there is no convincing standard for mapping lanes in OSM. It is time to change this.
Mapping a lane
Each lane is mapped as a relation with type=lane. This relation contains one or more highway ways as members, not unlike the established route relation. The only required attribute is lane=* for the type of the lane.
| type | lane | required | |
| lane | vehicle / bus / psv / hgv / bicycle / sidewalk | required | type of the lane |
| highway |  (one or more)
|
required | Sequence of highway sections where this lane starts, continues, and ends. |
Additional lane attributes
With the basics above you can only indicate that a lane exists. To provide more information about the lane, add additional tags.
| lane:turnleft | yes | optional | this is a lane for turning left. Can be combined with lane:through. |
| lane:turnright | yes | optional | this is a lane for turning right. Can be combined with lane:through. |
| lane:through | yes | optional | this is a through lane. Can be combined with lane:turnleft or lane:turnright. |
| lane:merge | yes | optional | this is a lane for merging. |
| lane:direction | forward / backward | optional | direction of traffic on the lane. Implicitly defined for lanes on oneway roads. |
| width / surface / ... | optional | many existing tags can be used for lanes as well |
Lane ordering
In many cases, lane arrangement is obvious and does not need to be explicitly specified. For non-standard road layouts, you can add the following members to a lane relation:
| left_neighbour | yes | optional | Any lane that is to the left of this lane relative to way direction. Usually, but not necessarily, the immediate neighbour. |
| right_neighbour | yes | optional | Any lane that is to the right of this lane relative to way direction. Usually, but not necessarily, the immediate neighbour. |
The advantage of this approach is that it avoids absolute lane numbers ("third lane"). So if one lane starts or ends, you do not need to interrupt the other lanes.
Higher levels of detail / Future extensions
Some mappers like to map certain types of lanes as separate ways (see discussions related to footway=sidewalk). Others map the areas covered by the lanes. These ideas can be seamlessly integrated with this proposal: Add ways or areas as members to the lane relation, with the roles "way" and "area", respectively. Doing so solves the open question how these lanes-as-a-way are associated with the road they belong to, while allowing those data users who are not interested in this level of detail to safely ignore them.
Generally, being able to add arbitrary attributes and members to each lane makes extensions painless.
Comparison with other proposals
Unlike other suggestions which often focus on a small set of use cases and are hard to extend, this this proposal is designed for flexibility and allows for mapping with different levels of detail.
Compared with the Turn Lanes proposal in particular, Lanes as Relations ...
- supports attributes for lanes (e.g. widths and surfaces)
- can distinguish whether a lane is interrupted at a junction node (a new relation starts) or continues uninterrupted (way before and after junction are members of the lane relation)
- lets you add ways and/or areas for lanes
- can be extended to support separators between lines in a straightforward manner
Debate
This proposal is only a draft, but feedback is already welcome.
Comments
Please use the talk page.
Voting
Not yet started.