Relations/Proposed/Bridges and Tunnels
|Bridges and Tunnels|
|Status:||Proposals with undefined or invalid status (inactive)|
|Definition:||set of tags and members making a relation to represent a bridge or tunnel|
This is a proposal for a set of tags and members making a relation to represent a bridge or tunnel.
This does not deprecate the older methods such as bridge=*/tunnel=yes attached to a way which is still the simplest and easiest method to implicitly represent a bridge by adding a property to the way running over a bridge, but is an additional alternative for complex cases where the simple bridge as way or man_made=bridge area models are not deemed sufficient.
The bridge/tunnel relations:
- group together ways which share a common bridge: for example, a dual carriageway (divided highway) where both carriageways pass over the same bridge structure. In the absence of a bridge outline, a renderer would show bridge parapet symbols alongside only the outermost constituent ways.
- allow the possibility to mark arbitrary objects as beeing on a bridge/in a tunnel (see also Proposed features/Simplify man made=bridge mapping for a simpler possibility)
- allow the possibility that a bridge or tunnel may be independently named from the ways which it carries.
allows both the way(s) crossing the structure and those passing under it to be identified (river and most canals bridges only pass over the waterway, and using only the Way tag bridge=yes means that intersection tests would have to be used to determine the bridges; now we can associate the bridges with the waterway as well.
- allow for properties of the structure to be represented (e.g., clearance).
- optionally identify a way showing the outline or "footprint" of the bridge or tunnel. For example, some oblique crossings use a more orthogonal structure where the road crossing occupies only part of the surface of the structure; or where there are buildings on the bridge perhaps so the bridge is wider than the road (if any) it supports.
|type||bridge or tunnel||Indicates this relation represents a bridge/tunnel.|
|bridge||any valid value of bridge=*||Bridge type as found in Key:bridge#Values. This should be the "overall type" of the bridge, can be left empty if bridge consists of more sections with conflicting types or if the value would be "yes".|
|bridge:movable||any valid value of bridge:movable=*||Type of movable bridge if bridge:type=moveble|
|bridge:structure||any valid value of bridge:structure=*||Bridge structure|
|layer||layer (number -5..+5)||The layer of the bridge. In rare complex cases a single bridge may be partitioned in several sections with different layers in which case this field would be probably best left empty as the individual ways ought to be mapped correctly anyway.|
|name||a name||The bridge or tunnel is known by this name (e.g., "Tower Bridge")|
|ref||a reference||Bridges are sometimes numbered (e.g., along UK canals)|
|height||height in meters||Bridge height measured from ground to top (usually derived from a signpost on the bridge or its side)|
|length||length in meters|
|operator||operator name||The party responsible for the bridge; e.g., "Network Rail".|
|Way or node||Role||Recurrence?||Discussion|
|across / through||zero or more||the ways supported by (on top of) a bridge / passing through a tunnel. Members without a role should be treated as across / through.|
|zero||the ways passing under a bridge. This does not in any any way obviate the need to use layer=* correctly and seems useless if not harmful at this point.|
|outline||optionally one||a way forming the outline "footprint" of a bridge or tunnel|
|edge||zero or more||alternative to outline, a set of ways which form the edges. Rather than drawing an area, a renderer could then draw the parapet marks as now along these ways. The interior of the bridge should be on the right of these ways (so if we were modelling a simple bridge using this technique, there would be two ways running in opposite directions parallel to and either side of the road-way which passes across the bridge; but this is generalisable to more complex cases: for example, consider a bridge which has a meeting of three ways on top). If neither outline nor edge is given, the "across"/"through" ways would be used to derive a nominal outline for rendering purposes for example.|
|on_bridge||zero or more||additional objects located on the bridge, those should be additionally tagged with location=bridge and layer as described here.|
|in_tunnel||zero or more||additional objects located in the tunnel.|
Please discuss in the talk-section