User:Kubahaha/brudnopis/Proposed features/Grandstand Supporters
| Grandstand supporters - Key:supporters | |
|---|---|
| Proposal status: | Draft (under way) |
| Proposed by: | kubahahaha |
| Tagging: | supporters=* |
| Applies to: | 
|
| Definition: | Mark parts of building=grandstand designated for diffrent supporters groups (ultras, families, woman) during most events. |
| Statistics: |
|
| Rendered as: | That is non critical feature, that can improve rendering, but it's not requested in this proposal. |
| Draft started: | 2022-03-28 |
Proposal
This proposal adds key supportters=* and introduces following tags:
- supporters=yes
- supporters=families
- supporters=guests
- supporters=ultras
- supporters=woman
Rationale
In many stadiums there are designated parts for supporters of guest team, ultras (most engaged supporters), families, woman etc. This features are hard to find in other sources and combined with ref=* (A1) and name=* (eg. VIP) would be usefull if used widely.
Examples
Big stadiums are mostly divided into sectors that arephisically separated from each other. During most events same sectors are occupied by host supporters and guests. That rule may sometimes may be extended into "family sector", "organised supporters sector", "designated for woman" (I believe it happens in South America).
Sectors without strong bias can be tagged as supporters=yes.
That is often defined in football clubs deals with football asociacions.
Tagging
The proposal intrduces new tag supporters=*.
In proposal I define 5 possible values, but community may extend it if I forgot something. There is no usage of proposed tag in database as of 28.03.2022.
Bridge key: ways and relations
| Tag | Comment | Photo |
|---|---|---|
| supporters=yes | General tag, no strong bias during most events. May be mostly occupied by host supporters. | 
|
| supporters=families | Part of TRYBUNY desugnated for families. | |
| supporters=guests | Part of TRYBUNY desugnated for guest team supporters. | 
|
| supporters=ultras | Part of TRYBUNY desugnated for most organised host team supporters. See Ultras on Wikipedia. | 
|
| supporters=woman | Part of TRYBUNY desugnated for woman. | .jpg)
|
| disabled | ||
| vip |
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. --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 oppose this proposal. Because it is orthogonal to Relations/Proposed/Bridges and Tunnels. --LordOfMaps (talk) 16:48, 24 October 2013 (UTC)