Proposal:Bridge types
| Bridge Types - Key:bridge, Key:bridge:structure, Key:bridge:movable, Key:bridge:support | |
|---|---|
| Proposal status: | Approved (active) |
| Proposed by: | choess |
| Tagging: | bridge, bridge:structure, bridge:movable, bridge:support=* |
| Applies to: |  ,  , 
|
| Definition: | This proposal is orthogonal to Relations/Proposed/Bridges and Tunnels. |
| Statistics: |
|
| Rendered as: | Except for those values indicating that a bridge no longer exists, these bridges should be rendered in a fashion similar to "bridge=yes". |
| Draft started: | 2012-02-04 |
| RFC start: | 2013-01-10 |
| Vote start: | 2013-09-22 |
| Vote end: | 2013-10-06 |
Proposal
This proposal adds additional values to the "bridge" key and introduces the "bridge:structure" key (replacing the "bridge_type" key) to allow a more extended description of the load-bearing form and other notable characteristics of bridges, including covered bridges and various types of movable bridges.
Rationale
Many mappers would like to enter additional information about the bridges they map, particularly the architecture, material, and function of the bridge. This additional information is often of utility to consumers of the map. For instance, covered bridges are widely regarded as picturesque, and are often of historic importance. Being able to identify these bridges may be of interest both to tourists and preservationists. Movable bridges are potentially of significance in routing, both for water traffic passing beneath and surface traffic which may be interrupted by their opening.
While taginfo reveals that ad hoc tagging schemes exist for some of this information, they are relatively unsystematic. Only a few of these tags have been officially documented, and the alternative values are not supported by common renderers. By presenting a regularized scheme of common bridge information, this proposal should make it easier to store data on the majority of bridges while providing proper rendering support.
Examples
There are about 1.7 million bridges currently mapped throughout the world, most of which are simply tagged "bridge=yes". This proposal would probably regularize the alternate values for about 1,500 bridges, but it would also allow adding additional information to many of the 1.7 million. While generic beam bridges and culverts are unlikely to be tagged, this provides a structured way to add information about more unusual and charismatic bridge types. Bridgehunter.com currently tracks about 38500 bridges in the United States, and does not claim to provide complete coverage, to give an idea of the number of bridges that might be annotated with type information.
Tagging
The new values proposed are divided among 3 keys: bridge, bridge:structure, and bridge:support. The "bridge_type" key has already been used in mapping bridges in Haiti, consistent with the Humanitarian OSM Tags/Humanitarian Data Model. Its values (arch, beam, suspension, etc.) refer strictly to the load-bearing architecture of the bridge. This proposal will replace this key with "bridge:structure" (as "type" might more appropriately refer to viaducts, covered bridges, etc. than to the load-bearing structure) and extend its use of the key, adding additional types of load-bearing architecture. Sources drawn on to provide the different bridge values include: current taginfo, the Bridge and Trestle Handbook, 4th ed., by Paul Mallery, and the English Wikipedia and Wikimedia Commons category systems for bridges.
It may be asked why the additional "bridge:structure" key is necessary, rather than simply making use of the "bridge" key. This is because some of the values to be used with the "bridge" key, such as "covered", may be compatible with more than one type of load-bearing architecture. For example, a swing bridge may be a girder (beam) bridge or a truss bridge; both "beam" and "truss" are currently-used values of "bridge_type". Using two keys allows information about both functions to be preserved without overloading a single key with combinations. The principal adverse consequence of this decision is that it requires converting the current "bridge=suspension" (1740 instances) to "bridge:structure=suspension".
Bridge key: ways and relations
| Key | Value | Comment | Photo |
|---|---|---|---|
| bridge | covered | A covered bridge has a roof and fully or partly enclosed sides, usually to protect the bridge deck from deterioration. | 
|
| bridge | movable | Movable bridges contain a span that can be moved up or to the side, often to provide greater clearance for traffic moving beneath the bridge. All such spans should be tagged with "bridge=movable". Further information may be provided using the "bridge:movable" key, discussed below. The fixed spans should be tagged separately, to make clear which part of the bridge is and is not movable. | 
|
| bridge | viaduct | A bridge composed of a series of short spans. The spans may be arches, girders supported by piers, etc. | 
|
| bridge | trestle | A type of viaduct where each span is supported by a rigid frame, usually called a "bent" rather than a pier. | 
|
| bridge | low_water_crossing | Also known as an "Irish bridge", this is a low bridge which is engineered to carry vehicles above water at low flow levels and survive submersion at high flow levels. | 
|
| bridge | cantilever | A bridge where a span is supported at one end only. Usually, the free ends of two spans are fastened to one another, giving a longer clear span between supports. | 
|
| bridge | boardwalk | A plank walkway over wet or otherwise difficult terrain, usually low to the ground and supported by posts. | 
|
Bridge:movable key: ways and relations
Note that this key may be used without tagging "bridge=movable" to indicate a formerly movable bridge that has been fixed shut. Movable bridges typically have traffic barriers which should be tagged as well, e.g., "barrier=lift_gate". "Access:conditional" and "maxheight:conditional" can be used to tag the bridge's way and the waterway beneath, respectively, if a regular scheme exists for opening and closing the bridge.
| Key | Value | Comment | Photo |
|---|---|---|---|
| bridge:movable | swing | A type of movable bridge, a swing bridge contains a span supported by a pivot resting on a pier, either at the center or towards one end of the span. Rotating the span on the pivot opens or closes the bridge. | 
|
| bridge:movable | lift | A type of movable bridge, a lift bridge contains a span which rises vertically while remaining parallel to its closed position. The span is suspended between lift towers at each end when open. | 
|
| bridge:movable | bascule | A type of movable bridge, a bascule bridge contains one or two spans, one end of which is free and swings upwards. A counterweight at the pivoting end of the span or spans balances the weight as the free end rises. Although sometimes called a "drawbridge", that term is applied more strictly in this scheme (see below). | 
|
| bridge:movable | drawbridge | A type of movable bridge similar to the bascule, as one end of the bridge is free and swings upwards. However, this type of bridge is raised by chains attached at the free end. | 
|
| bridge:movable | transporter | A bridge where a segment of roadway or footway is suspended from cables and carried back and forth like a gondola. | 
|
Bridge:structure key: ways and relations
The bridge:structure key is used to describe the load-bearing architecture of individual bridge spans.
| Key | Value | Comment | Photo |
|---|---|---|---|
| bridge:structure | arch | In an arch bridge, the span is supported by a curved arch, which transfers some of its weight into horizontal thrust against the abutments. | 
|
| bridge:structure | beam | In a beam bridge, the load is transferred entirely to a span resting on a support at either end, without additional reinforcement. | 
|
| bridge:structure | truss | In a truss bridge, the span consists of a series of interlocking triangular units which bear the load. | 
|
| bridge:structure | floating | A bridge whose load is supported by floating on water, rather than resting on fixed supports. Typically a pontoon bridge. | 
|
| bridge:structure | suspension | A bridge where the load is supported from a cable under tension, attached to anchorages at each end of the bridge. In most, but not all, suspension bridges, the cables are suspended between towers near each end of the bridge. | 
|
| bridge:structure | cable-stayed | A bridge where the load is supported by cables radiating from the tops of towers resting on supports along the line of the bridge. | 
|
Bridge:support key: nodes
| Key | Value | Comment | Photo |
|---|---|---|---|
| bridge:support | pier | An intermediate, upright support beneath a bridge. Known as a "bent" in trestle bridges. | 
|
| bridge:support | abutment | A support for one end of a bridge. | 
|
| bridge:support | lift_pier | A support for a lift bridge over which one of the lift towers stands. | 
|
| bridge:support | pivot_pier | A support for a movable bridge on which the bridge pivots, either horizontally (as a swing bridge) or vertically (as a bascule or drawbridge). | 
|
Deprecated bridge key values
- bridge=causeway: If water normally passes over the causeway, it should be tagged as "ford=yes". If water runs over it only at high water (Australian usage), it should be tagged as "bridge=low_water_crossing". If the causeway is built above water, it should be replaced with "embankment=yes", showing a short culvert or bridge at the point(s) where water passes beneath it.
- bridge=suspension: Moved to "bridge:structure=suspension".
Applies to
Most of the tags are intended to be applied to ways or to relations (used to indicate multiple ways crossing the same bridge structure), although they might be applied to a node when detail is lacking to properly map the bridge. The exceptions are "bridge:support=pier", "bridge:support=lift_pier", "bridge:support=pivot_pier", and "bridge:support=abutment", which are intended to be applied to single nodes.
Rendering
In general, these proposed values should be mapped in the same way as "bridge=yes", the current generic bridge rendering. Possible refinements might include connecting the sides at the ends of "bridge=covered", making it appear as a rectangle rather than a pair of parallel lines.
Features/Pages affected
The Key:bridge page will be affected; the new values will need to be added to the "Values" section, and a number of the proposed values under "Proposals" will be removed. It may also be useful to create a few examples showing the use of, e.g., "bridge=movable", "bridge:movable=bascule", "bridge:structure=truss", "bridge:support=pier" and "bridge:support=pivot_pier" to create a detailed representation of a movable bridge. New Key:bridge:structure, Key:bridge:movable and Key:bridge:support pages will need to be created to cover those tags.
Comments
Please add comments on the proposal here.
This comes almost exactly a year after similar discussion on tagging list ([Tagging] Chaos and uncertainty in "bridge"). I support the general idea of tagging types of bridges, but I do not like this particular tagging scheme - it's not clear what is the difference between the two proposed keys.
At that time my suggestion was this and I still agree with myself:
- bridge=[arch;suspension;cable_stayed;bascule;beam...] just like http://en.wikipedia.org/wiki/Bridge#Types_of_bridges
- The third would indeed deserve a separate tag, I suggest bridge:movable=[drawbridge;swing;lift;yes (moves in an unspecified way)]
--LM 1 06:06, 11 January 2013 (UTC)
+1 to the above. the two keys confuse me. Take bridge_type=culvert as an example: Is it a bridge that is tagged on the highway=* ... or is it a tunnel-structure tagged as part of the waterway? .. Having noted this: I would like to see a richer tagging scheme for bridges (.. which is why I looked into this; trying to search appropriate tagging scheme for causeways/"low_water_bridge"s. --JaakkoH 15:46, 11 January 2013 (UTC)
- I think some of these comments may be partly addressed in the "Tagging" section above, but I'll try to explain further here.
- Why use two keys ("bridge" and "bridge_type") when one would do? This wasn't what I originally planned when I started looking at Taginfo. However, what I soon realized was that some of the values in Taginfo might need to be applied to the same bridge at the same time. Basically, "bridge_type" describes the load-bearing architecture of a span. (Ignoring some technicalities, a span is a part of a bridge from one support to another.) Terms like "truss", "beam", and "arch" can be applied not just to movable bridges, but to many other types. Covered bridges can be "truss" or "beam". Cantilever bridges typically have a "truss" or an "arch" suspended span. A viaduct could be made of "beam" spans or "arch" spans. As far as I know, the spans of any bridge can be given one of these "bridge_type" values, so I thought it made sense to separate it entirely, just as we separate "surface" or "tracktype" from "highway". Looking back at that earlier tagging-list discussion, "bridge_type" roughly corresponds to Martin's "structural system" and "bridge" corresponds to his "typology". So I think there is a good case to be made that the values in "bridge_type" should be kept separate from the miscellaneous ones in "bridge" because they will tend to collide with "bridge" values in general, not just movable. The list of values was taken from Humanitarian OSM Tags/Humanitarian Data Model, plus I added "cable-stayed" as even though it looks like a suspension bridge, it's very different from an engineering perspective. The list matched up pretty well with types described in Wikipedia and Mallery's Handbook, so I felt comfortable using it.
- OK, why did you call it "bridge_type" if it's really about structure, not type? What I found in Taginfo was that even though the Humanitarian Data Model wiki page says "bridge=beam", "bridge=arch", etc., the people using the model (Haiti disaster relief mapping) mostly used "bridge_type" instead of "bridge". I don't know if that was partly tagging for the renderer, or whether it's because that field is called "BridgeType" in the data model, but my impression is that "bridge_type" was preferred in practice for the Haiti work.
- So, in short, using the "bridge_type" key is already supported by a data model and by actual practice (in Haiti, anyway), and using it prevents conflict with many other values of "bridge". I know it is important to be simple--no one except the author likes long, complicated tagging schemes--but I think it is important to have two keys here. Look at the mess in "railway" to see what happens when too many values that are not mutually exclusive are put in one key. The number of tagged bridges in Haiti is not so terribly large, though; I am open to suggestions for a name change if people feel "bridge_type" is not very clear.
- I do like the suggestion of putting the different movable bridge types under bridge:movable. From a rendering and routing perspective, knowing that a bridge is movable is probably much more important than knowing whether it lifts, swings, etc. I think it would be a good idea to tag movable spans as "bridge=movable; bridge:movable=bascule" (or whatever subtype is appropriate, or "yes" if we don't know); it makes parsing by the renderer or router easier, which makes it more likely the information will actually be used!
- I included "culvert" etc. in the proposal because they are included Humanitarian Data Model mentioned above. I personally prefer to use "tunnel=culvert". The wiki page suggests there are multiple ways to tag them, but it is written confusingly. Taginfo suggests "tunnel=culvert" is by far most common (>44000 uses), "culvert=yes" is second (>3000 uses), and "bridge" and "bridge_type" together have only 290. If you think this would impede us standardizing on "tunnel=culvert", I'm OK with dropping "culvert", "culvert_round", and "culvert_box" from the list of values.
- I picked "low_water_bridge" because I though "Irish bridge" would be confusing, and while "causeway" may be used to describe them in Australia, in the US, a "causeway" is usually an artificial embankment, solid rather than open, and more or less permanently above water.
- I hope this explains some of my design choices in the proposal and welcome further comment. Choess 03:05, 12 January 2013 (UTC)
- And I now see, JaakkoH, that you know a great deal more about mapping in Haiti than I do, so if I've erred in interpreting the situation there, I'd appreciate it if you'd set me straight. Choess 03:41, 12 January 2013 (UTC)
- "bridge boardwalk" - is it really considered as a bridge? For me it seems better to handle it as "surface:boardwalk" Bulwersator (talk) 06:01, 23 September 2013 (UTC)
- I don't see the point of bridge=covered. There is covered=yes already, and it allows to describe if any type of bridge covered or not without the tag conflict. --Santacloud (talk) 12:11, 28 September 2013 (UTC)
Voting
Please use {{vote|yes}} or {{vote|no}} and give your reasons to oppose. Use ~~~~ to sign with your user name & date.
I approve this proposal. --Władysław Komorek (talk) 07:11, 23 September 2013 (UTC)- I approve this proposal. Janko (talk) 08:50, 23 September 2013 (UTC)
- I approve this proposal. --Tordanik 10:57, 23 September 2013 (UTC)
- I approve this proposal. Could you please add "pylon" or "tower" as bridge:support value? --polderrunner (talk) 11:12, 23 September 2013 (UTC)
- I approve this proposal. but only if you move bridge=viaduct/trestle/cantilever to bridge:structure=* and omit bridge=covered (this should be covered=yes or building=*). --Fkv (talk) 13:12, 24 September 2013 (UTC)
- I approve this proposal. --lutz 19:25, 25 September 2013 (UTC)
- I approve this proposal. --Bredy 16:58, 26 September 2013 (UTC)
- I approve this proposal. --Diomas 14:53, 26 September 2013 (UTC)
- I approve this proposal. --Felis Pimeja 8:20, 27 September 2013 (UTC)
- I approve this proposal. --OverQuantum (talk) 16:36, 27 September 2013 (UTC)
- I approve this proposal. --RSergei 20:28, 27 September 2013 (UTC)
I oppose this proposal. Different entities are mixed in a bridge=* key, e.g. overall construction of a bridge and specific properties (moveable, covered). The difference between bridge=* and bridge:structure=* in unapparent as well. Not all current bridge=* values are covered (for example, bridge=pontoon) --AMDmi3 (talk) 20:48, 27 September 2013 (UTC)- I oppose this proposal. How do you tag a covered viaduct? As above, this mixes different properties into the bridge key. Also, most or many boardwalks/duckboards aren't bridges (like this pic, nor the one in the proposal's pirture); some might be, but it needs to be guidelined beforehand. Alv (talk) 06:28, 28 September 2013 (UTC)
- I approve this proposal. --Fanfouer (talk) 13:57, 30 September 2013 (UTC)
- I approve this proposal. --4rch (talk) 15:22, 30 September 2013 (UTC)
- I approve this proposal. --EvanE (talk) 17:37, 7 October 2013 (UTC)
- I oppose this proposal. Because it is orthogonal to Relations/Proposed/Bridges and Tunnels. --LordOfMaps (talk) 16:48, 24 October 2013 (UTC)
