Talk:Proposed features/Bridge types
In Australia "causeway" and "ford" Key:ford are often used in the same way in conversation and on some maps. Anyone used to this terminology should stick to using Key:ford on OSM, for water crossings where the water washes over the road, or indeed where the crossing is just the bed of the waterway. --JSmart 09:31, 26 February 2012 (UTC)
- I've amended the proposal to make that clear. (In the US, I'm used to "causeway" being used for an embankment built across a body of water.) Choess 00:58, 22 May 2012 (BST)
- Shouldn't covered and cantilever be in the second list? You can, at least in theory, have a covered swing bridge, for example. (I'm also not sure what the difference between cantilever and beam is.)
- A truss can further be subdivided into through, pony, or deck.
- Finally, "drawbridge" is commonly used as a synonym for any moveable bridge, and should probably be avoided. --NE2 03:09, 11 January 2013 (UTC)
- Beam bridges are supported at both ends (most run-of-the-mill road bridges are beam bridges, I would assume), while a cantilever is supported at only one end. I thought hard about the placement of cantilever, but according to Mallery, the suspended span between the cantilever arms (cf. Wikipedia) can be either truss or arch, and placing cantilever in the "bridge" tag lets you tag both facts simultaneously. Ditto for "covered": all covered bridges will be taggable with a "bridge_type" (almost all beam and truss), and I think it's more important to keep those clear of each other than to keep "covered" clear of "swing".
- There's a *lot* of variation in trusses and probably multiple co-existing systems of classification. I think that might be best left for the bridge enthusiasts to work out under a "bridge:truss" or "truss" tag. I'm not prepared to tackle it right now.
- I'm uncomfortably aware of the use and misuse of "drawbridge", but what, if anything, would you suggest to describe the type of bridge I've presented under that name? Choess 02:08, 12 January 2013 (UTC)
I'm not happy about tagging bridge supports using the bridge=* tag since these supports are not bridges just details of bridges. It also conflicts with the widespread (although maybe improper) use of bridge=* on nodes representing complete bridges. According to Taginfo bridge=* is used more than 11000 times on nodes, almost all of them with the value "yes". A key like bridge:support=pier would avoid this conflict and be clearer to the mapper. Furthermore I would like to see further values for bridge supports especially pylon for use with suspension bridges as such pylons are very significant landmarks. --polderrunner 18:27, 11 January 2013 (UTC)
- That sounds reasonable to me. If you look at the "Applies to" section, I acknowledge the case of tagging single nodes as "bridge=yes". I added piers in large part because this proposal would let you exactly mark up, in a movable bridge, which parts are the approach spans and which span moves, and marking piers is a logical extension of that. I haven't fully thought out the possible values for bridge supports, and they aren't very heavily tagged at present anyway, so perhaps we should spin off the bridge supports as a separate proposal? Choess 02:08, 12 January 2013 (UTC)
- No need to spin off bridge:support as a separate proposal. A proposal may comprise multiple related tags that together form a tagging scheme for a given feature. --polderrunner 08:03, 12 January 2013 (UTC)
Railwaybridge in Berlin + Shop in arch
DE: Die gezeigten Viadukte sind Beispiele in Berlin und Dresden. In den Bückenbögen sind Läden untergebracht, daher haben diese Brücken auch die Funktion eines Gebäudes. Braucht man dafür noch einen neuen Key?
Hinweis: Gegen Korrekturen meines englichen Textes gibt es keine Einwände... --Reneman 09:56, 26 January 2013 (UTC)
Applies to: relation
I assume this would also apply to relations if the bridge is mapped as a bridge relation because multiple highways or railways are running across it? If so, this should be mentioned in the template and the "Applies to" section. --Tordanik (talk) 12:14, 31 January 2013 (UTC)
Mailing list discussions on bridge classification
Questions to resolve
I see the following as significant issues raised at the January RFC which need to be settled.
1. What keys do we use for structure and typology? Right now, "bridge" is used for typology (covered, viaduct, low_water_crossing, etc.) while "bridge_type" is used for structure (arch, truss, etc.). It has a relatively low use (547 instances), outnumbered by "bridge=suspension" (1505 instances) which needs to be moved to the structure category. Should we use "bridge" and "bridge: structure" for typology and structure, or should we separate them both into new tags as "bridge:type" and "bridge:structure"? The latter approach would require converting "bridge=viaduct" (26 825 instances) to "bridge:type", plus a few other sundries, but it would mean that future changes to bridge typology wouldn't require changes in the downstream renderer/consumer (because they would all have "bridge=yes"). Or should we include "bridge=movable" as a possible value? (If not, we'd have to tag as "bridge=yes", "bridge:type=movable" and "bridge:movable=bascule", for instance, which seems like a bit of overkill.)
2. Should culverts be included in this proposal? Culverts are included in the Humanitarian Data Model, with which I've tried to maintain compatibility, but the prevailing OSM practice seems to be to use "tunnel=culvert" or "culvert=yes" on the way through the culvert, rather than the way over it.
3. Should we use "bridge:movable=drawbridge"? As NE2 pointed out, it's likely that this tag will be misused to describe bascule bridges; it's an attractive nuisance. But what alternative value can be used to represent this type of bridge?
The following are concepts I have deliberately left outside the scope of this proposal to keep it focused:
Naming of bridges (as distinct from the ways they carry). Representation of the physical area of bridges or bridges carrying multiple ways. Representing buildings in bridges. The material composition of bridges (wood, stone, iron, etc.) Representing proposed, damaged, unused, and removed bridges. Subtypes of truss bridges. Choess (talk) 15:47, 8 May 2013 (UTC)
- I'd intended that each could be a separate line segment. So the approaches to a swing bridge might be tagged "bridge=trestle", while the swing span would be tagged "bridge=movable" and "bridge:movable=swing". In general, it makes sense to be able to map spans separately. Choess (talk) 05:55, 24 September 2013 (UTC)
- Could you, please, add some refinement about this theme to page of proposal? I'm afraid, that in the future opinion, that bridge=movable should be put just to whole bridge and can not be put only to movable section (if bridge is relatively big and can be divided to stable sections and movable sections), can exist. Dinamik (talk) 16:07, 26 September 2013 (UTC)
How it is proposed to tag stable point of movable section to bridge? Rougly say, if we are near the bridge, section can be lifted up to the left and to the right. Dinamik (talk) 16:09, 26 September 2013 (UTC)
- I think that might be covered by "bridge:support=pivot_pier", if I understand the question correctly. This is the support on which the bridge pivots to clear the channel, either sideways or up, depending on the bridge type. I edited the guidance on "bridge=movable" to make it clear that should only apply to the movable span. Choess (talk) 13:15, 28 September 2013 (UTC)