|bind all parts of a street together and everything else that belongs to it|
|Status: in use|
|Tools for this tag|
|This draft is currently being worked on. Existing tags in the database are based on an older proposal. The new draft is backward compatible.|
Street relations provide an explicit connection between all infrastructure elements of a street, including a driveable area and the outline of a street. The goal is easier data consumption by routers, as outlined here.
Note that this relation is not established and unsupported by some applications. It has also not been approved by vote. You can still use it, but you should not delete existing tagging in its favor.
This relation type was used in the past as just a variant of the extremely popular associatedStreet relation.
This relation supports two different types of data models, shape-based outlines of a street and reference-based logical connections. Both models don't exclude each other, but can be used together.
All parts of the main road shall be added as street members to the relation. A detailed outline of the street is tagged with area=street and added as area member(s). Everything inside this area(s) will be considered part of the street. If elements outside of the area(s) exist but can be considered part of the street (like lamp posts behind a wall, which marks the end of the street), they can be added as members to the street relation.
If there are no detailed outlines of the street available, all elements of the street should be added as members.
The driveable_area (also called driveable space) can be marked with additional area shape(s), to allow for easy routing of emergency vehicles as well as oversize ones. Parking spaces and other temporary occupied areas shall not be added as driveable_area but added as parking spots.
- Streets need to be converted as a whole. While it's backwards compatible, as that no data consumer needs to be able to interprete the relation to use the OSM-Data, a data consumer which supports this relation will assume that the shape is complete (if added), that all intersections are properly outlined, and that all elements of the main road are present as 'street'-members.
- Barriers and separators need to be mapped either as ways or as tags - a data consumer will otherwise assume the certain defaults, like that the main road ends with a curb - which might not reflect the reality.
- Explicit connections between sidewalks, cycleways, barriers, etc of a street, which helps data consumption and routing based on this. There's no need to draw lines between a separately mapped sidewalk, which is part of the street - since the data consumer can check if there's any barrier between the ways - while the default assumption before was: Ways need to be interconnected to allow routing between them.
|type||street||Defines that this is a Relation of the type 'street'.|
|street||one or more||The ways that are part of the main street - not adjacent lanes, cycleways, or sidewalks mapped individually.|
|area||zero or more||A shape that outlines the edges of a street, including bike lanes, sidewalks, and other street infrastructure. The shape shall not include intersections.|
|intersection||zero or more||A shape that outlines one intersection at a time. If there's more infrastructure to an intersection, like signs, traffic lights, etc. it makes sense to create a relation with type intersection and add the area to it. An intersection area/relation shall be part of every street relation which is part of the intersection.|
|cycleway||zero or more||All bike lanes that are part of the street (along a street with the same name; can be separated by e.g. barriers or grass stripes)|
|pedestrian||zero or more||All sidewalks or similar pedestrian tracks that are part of the street (along a street with the same name; can be separated by e.g. barriers or grass stripes). Not applicable for highway=pedestrian, because they are the main street.|
|lane||zero or more||A lane which doesn't fit the roles of pedestrian or cyclelane, usually separated by a physical barrier but still part of the street, like a bus lane with a curb or a grass stripe separating it from the regular street.|
|public_transport||zero or more||A public transport relation (like a bus stop) which can be considered part of the street. If the public transport relation spans over multiple streets, the way of the platform adjacent to the street shall be referenced instead.|
|traffic_signals||zero or more||Traffic signals shall be placed on their physical positions. A 2-node way shall be used to connect the physical position with the virtual position (tag on the traffic_signals: position=physical, tag on the way: ?). The two-node way shall be referenced with this role. This avoids that traffic_signals are placed as nodes within the street-way with a direction tag. (TBD)|
|sign||zero or more||Signs shall be placed on their physical positions. A 2-node way shall be used to connect the physical position with the virtual position (tag on the sign: position=physical, tag on the way: ?). The two-node way shall be referenced with this role. This avoids that signs are placed as nodes within the street-way with a direction tag. (TBD)|
|island||zero or more||A traffic island. The surrounding barrier can be added as an individual barrier-way.|
|separator||zero or more||A physical separator of counterflow traffic in the center of the street or between lanes spanning over a large stretch of the road and should not be considered passable by any means of transportation. This shall not be used for small barriers (see barrier) nor traffic islands (see island). A separator might be a ditch, a fence, a wall or a hedge.|
|barrier||zero or more||A barrier that is part of the structure of the street, but can be passed by some modes of transportation. A barrier might be a curb or a line of bollards.|
|crossing_railway||zero or more||The railways which cross on a simple intersection area (for simple railway crosses street intersections).|
|railway||zero or more||The railways which run through the street/intersection area - which are not simple crossings - like a tram.|
|tree_row||zero or more||For tree-lined roads, the associated tree rows can be added to the relation. If there are individual trees mapped in the tree rows as points, they shall not be added to the relation.|
|tree||zero or more||For single tree which can be considered part of the street, not to be used for tree-lined roads which shall use tree_row.|
|driveable_area||zero or more||A shape that outlines the edge of the street which can be considered driveable for a car. Curbs, grass stripes, barriers, and utility/light poles shall be considered as not driveable and mark the edge of the driveable area. Keep the shape simple - not overly detailed. For example, if there are light poles in a row in the street, the driveable area shall not extend between them wider.
The main use-case is to mark the area which can be used by emergency vehicles and oversize vehicles, without having to drive over a curb or remove permanent infrastructure. If there are barriers like poles on the road, the driveable area shape should end and a new one should start on the other side. The barrier infrastructure should be part of the outline of both driveable areas - with additional details if the barriers could be removed by the fire brigade for example.
Parking spaces and other temporary occupied areas shall not be added as driveable_area but added as parking spots.
|associatedStreet||zero or one||The associatedStreet relation of this street.|
|associated / others...||zero or more||Anything else that belongs to the street, but doesn't contain an address and doesn't fit any other role.|