Proposed features/Fire Hydrant Extensions

From OpenStreetMap Wiki
Jump to: navigation, search
Fire Hydrant Tagging Extensions
Status: Proposals without post-vote cleanup
Proposed by: nfgusedautoparts
Tagging: emergency=fire_hydrant
Applies to: Node
Definition: additional information for emergency=fire_hydrant
Drafted on: 2013-03-09
RFC start: 2017-06-17
Vote start: 2017-10-01
Vote end: 2017-10-15


Rationale

Projects are in progress which aim to use OpenStreetMap to support First Responders. These tags are intended to support those projects by providing details about hydrants above and beyond those which are captured by the existing tagging scheme. Some of the data may be discerned from a physical survey of individual hydrants, and other data may be available from public databases. The most likely scenarios for First Responder use of OSM data are "mutual assistance" calls, where a responder travels outside their normal area of responsibility and as such knows less about local conditions than normal.


Proposal

Some subtags in support of fire_hydrant are described. These tags contain detail about fire hydrants that have considerable value to First Responders. This proposal additionally proposes deprecating one value for fire_hydrant:type and adding two tags for fire_hydrant:type. Some new variations on fire_hydrant are included, as are new variations of colour. The meaning of colour as applied to fire_hydrants is formally defined, and additional colour subtags are proposed which cover common cases of hydrants painted in more than one colour.


New Tagging

Here is the new proposed tagging for a fire hydrant, for numeric values with units, see the guidelines: Map Features/Units

Proposed tags
Tag Description Valid values
fire_hydrant:class=* In the US, classification per American Waterworks Association. If fire_hydrant:class is present, flow_rate=* is redundant. AA, A, B, C
flow_rate=* Nominal flow capacity. If fire_hydrant:class=* is present, this is redundant. numeric value with unit, in International System standard unit is m3/s. But for hydrants are preferable l/min (liters per minute), gpm (gallons per minute), or m3/h (cubic meter per hour). e.g.: flow_rate=600 l/min.
water_source=* The water source for the hydrant. main, pond, stream, water_tank, swimming_pool, groundwater (this is for water wells)
water_volume=* Volume of the water reserve, applicable only to water tanks and swimming pools. # in m3. If another unit of measure is used, specify it
pressure=* Pressure at which the water is supposed to flow through the hydrant. If the hydrant is connected to a pond/stream/tank/pool and a pump is needed to get water pressure=suction # in bar, or suction if a pump is needed to get water
survey:date=* Date of the last site survey without a functional check (this tag is not specific to fire hydrants). yyyy-mm-dd
colour=* The colour of the hydrant. Unless otherwise specified, the entire hydrant is this colour. blue, green, yellow and red are the valid values in the AWWA scheme, but many jurisdictions do other things
bonnet:colour=* Colour of the top section ("bonnet") of the fire hydrant if different from the colour tag value. blue, green, yellow and red are the valid values in the AWWA scheme, but many jurisdictions do other things
cap:colour=* Colour of the caps of the fire hydrant if different from the colour tag value. The caps are the covers over the hose openings. blue, green, yellow and red are the valid values in the AWWA scheme, but many jurisdictions do other things. If caps are painted in more than one colour, list all colours separated by semicolons
reflective:colour=* Colour of reflective material, if any (commonly stripes or bands around the barrel).
couplings=* Number of couplings. #
couplings:type=* Coupling standard. Baionetta, Barcelona, Guillemin, Klaue, Sprawny, Storz, UNI

More types are described at: https://en.wikipedia.org/wiki/Hose_coupling

couplings:diameters=* Each coupling diameter, separated by semicolons. #;#;# Always specify the unit of measure, normally use mm. For inches use ". In some countries characters A, B, C are used to specify the connector (Austria)

e.g.: taken this image & guessing diameters, this could result in: couplings:diameters=45 mm;45 mm;110 mm

pillar:type=* See below for description dry_barrel, wet_barrel
manufacturer=* To retreive information from manufacturers' documentation (this tag is not specific to fire hydrants).
model=* To retreive information from manufacturers' documentation (this tag is not specific to fire hydrants).

American Water Works Association colour scheme

Wet Hydrants are generally fed by water mains in urban and suburban areas. The dimensions of the mains vary greatly, and so the flow capacity of the hydrants can vary substantially. The location of hydrants is the first requirement in a mutual assistance call; the second most important piece of information is the flow capacity. Some jurisdictions in the United States have adapted a colour scheme specified by the American Water Works Association. In these jurisdictions, flow capacity may be determined simply by examining the colour of the bonnet and caps of a fire hydrant. In other cases, finding out the capacity may be more difficult.

Flow Capacities and AWWA Colour Scheme
Class Flow Capacity Bonnet & Caps Colour
AA more than 1500 gpm Light Blue
A between 1500 and 1000 gpm Green
B between 1000 and 500 gpm Yellow
C less than 500 gpm Red

Adding pillar:type=* for pillar type hydrants

For better description of pillar hydrants, in addition to fire_hydrant=pillar you can add pillar:type=*

Values for pillar:type=*
Value Description
dry_barrel A style of pillar hydrant where the water shutoff valve is below ground, hopefully below the frost line. These are used on pressurized systems where freezing is a risk. They are occasionally used for dry hydrants when the water supply is higher in altitude than the hydrant. The type may be determined by inspecting the caps; they are usually arrayed at the same level as there is no corresponding valve inside the hydrant barrel.
Bethlehem 20130426 102052.JPG
wet_barrel A style of pillar hydrant where the barrel is pressurized at all times, with individual valves for each outlet. These are common in temperate climates, but not used wherever the temperatures may be consistently below freezing. The type may be determined by inspecting the caps; they are arrayed at different levels as each cap has a valve internal to the hydrant barrel.
Fire hydrant in Bonifacio Global City.jpg


Values to be replaced

Some pretty used tags should be carefully replaced like suggested below.
It's recommended to check the values of such tags and to not mass edit.

Obsolete tag Usage volumetry Obsolete Usage Used for New tag(s) to use New Usage
fire_hydrant:position=* 296 235 on 2017-08-04 Positioning the fire hydrant in its environment location=*
in_service=no 60 on 2017-08-04 Indicate that fire hydrant is out of service disused:emergency=fire_hydrant
fire_hydrant:type=* 619 746 on 2017-08-28 Type of the hydrant (pipe, pillar, wall, underground) fire_hydrant=*
fire_hydrant:pressure=#/suction 43 447 on 2017-09-03 Pressure in bar / "suction" for dry hydrants pressure=#/suction
fire_hydrant:diameter=* 395 133 on 2017-09-03 This is the diameter of the underground pipe that feeds the hydrant. In mm, inches or letters diameter=*

Migration from fire_hydrant:position=* to location=*

The key location=* is already used in other contexts and indicates the same concept. Therefore current values of fire_hydrant:position=* should go in location=*.
A new value, location=tunnel should be used for hydrants inside a tunnel.

Values for location=*
Value Description
lane on the side of a road lane (but not on a sidewalk)
parking_lot in a parking
sidewalk on a sidewalk
green on a green area
tunnel inside a tunnel

Migration from in_service=yes/no to disused:emergency=fire_hydrant

The prefix disused: is already used in other contexts and indicates the same concept. Therefore there is no need of the tag in_service=yes/no.
Hydrants are supposed to be in service by default.
If not, use the tag disused:emergency=fire_hydrant.

Revisions to fire_hydrant:type=* and migration to fire_hydrant=*

fire_hydrant:type=* in its current form improperly conflates two concepts, the water supply and the physical delivery mechanism.
fire_hydrant:type=pond will be deprecated because it will be replaced by water_source=pond.

fire_hydrant:type=* for the sake of simplicity will become just fire_hydrant=*.
A new value, fire_hydrant=pipe will be added.

Values for fire_hydrant=*
Value Description
pipe An hydrant consisting of a simple capped pipe.
Hydrants 20130326 112938.JPG
pillar A pillar type hydrant. If you want to be more specific, see pillar:type=* below.
Downtown Charlottesville fire hydrant 1.jpg
wall A wall-mounted fire hydrant.
Guentherscheid Tunnel Rescue4.jpg
underground A fire hydrant simple outlet located underneath a metal cap in Germany. Hard to know anything about couplings, whench or sizes without opening the cap
Berlin hydrant 20050211 p1000517.jpg


Examples

Surface fire hydrants

Photo Aerial view Tagging Note
Hydrants 20130326 112938.JPG
--

emergency=fire_hydrant
fire_hydrant=pipe
colour=red;white
wrench=pentagonal

A simple raising pipe serving as a fire hydrant outlet with a proper coupling hose at its end.
French hydrant water pond.jpg
-- On the fire hydrant as a node

emergency=fire_hydrant
fire_hydrant=pillar
pressure=suction

water_source=pond
colour=red
wrench=triangular

A standalone fire hydrant fed by a 20 m3 pond located just underneath the ground. It's not connected to water system but only to the pond.


Voting

Voting closed

Voting on this proposal has been closed.

It was rejected with 28 votes for and 21 votes against.

A post-vote revision of the proposal is here: Fire Hydrant Extensions (part 2)


  • I approve this proposal I approve this proposal. --Andrea Lattmann (talk) 10:26, 11 October 2017 (UTC)
  • I approve this proposal I approve this proposal. --Viking81 (talk) 09:58, 1 October 2017 (UTC)
  • I oppose this proposal I oppose this proposal. There are already millions of tags within the fire_hydrant:* name space. These have been used by hundreds of mappers. What we need is not a completely new scheme for hydrant tagging, but a well-written documentation of the existing tagging. Despite having more general keys not constraint to fire_hydrants, I can not see any improvement introduced with this proposal. Additionally, this proposal covers only a small subset of these existing tags - many will remain in the fire_hydrant name space causing a lot of confusion. --Mueschel (talk) 10:14, 1 October 2017 (UTC)
This is not a completely new scheme. We discussed for months to refine the existing scheme. This proposal covers the tags documented in the original fire hydrant page: Fanfouer already replied to you on discussion page. Further improvements can be discussed in the second part of the proposal. We splitted the proposal because it was becoming too big to handle all in one. --Viking81 (talk) 20:05, 2 October 2017 (UTC)
  • I approve this proposal I approve this proposal. Moving out fire_hydrant: namespace is a good point to make tags more usable and readable. This proposal is intended to stop the confusion of type/sources in fire_hydrant=* key. New key water_source=* is provided for this purpose too Fanfouer (talk) 11:01, 1 October 2017 (UTC)
  • I oppose this proposal I oppose this proposal. I appreciate the proposed replacement of in_use=no by disued:emergency=*. Unfortunately there are some unnecessary tag changes which are a dealbreaker for my personal decision.
This proposal tries to deprecate fire_hydrant:position=* in favour of location=* which is much in use. I don't see any benefit from changing the key. You can already use the generic tunnel=yes to indicate that a hydrant is in a tunnel.
The proposal does not give reasons why it wants to deprecate fire_hydrant:pressure=* in favour of pressure=* and fire_hydrant:diameter=* in favour of diameter=*.
The suggested changes pollute the main namespace and will lead to a location=* which is used in different fields of interest.
Such changes of keys (1) require to change all software which works with hydrant data from OSM and (2) invite mappers to mechanical or pseudo-mechanical edits although your proposal asks to check the values of such tags and to not mass edit.
I appreciate the proposed replacement of in_use=no by disued:emergency=*. --Nakaner (talk) 20:45, 1 October 2017 (UTC)
We discussed for months on discussion page and on tagging mailing list: why didn't you partecipate? You would have found many responses to your doubts.
Since some tags already exist without fire_hydrant: namespace but indicates the same concept, we have choosen the simplest ones (location=*, diameter=*). tunnel=yes according to the wiki applies to ways, not nodes. pressure=* is a tag that can be used also for other features, there is no reason to use it only on hydrant in the form fire_hydrant:pressure=*
A change in software is quite easy, once the tags are documented.
--Viking81 (talk) 20:46, 2 October 2017 (UTC)
See my user diary entry for my response and even more. --Nakaner (talk) 22:19, 12 October 2017 (UTC)
  • I approve this proposal I approve this proposal. --wambacher (talk) 23:53, 1 October 2017 (UTC)
  • I approve this proposal I approve this proposal.Crochet.david (talk) 05:35, 2 October 2017 (UTC)
  • I oppose this proposal I oppose this proposal. see comment Nakaner and also Mueschel User 5359 (talk) 05:42, 2 October 2017 (UTC)
We discussed for months on discussion page and on tagging mailing list: why didn't you partecipate? --Viking81 (talk) 21:03, 2 October 2017 (UTC)
  • I oppose this proposal I oppose this proposal. The proposal is changing widely used tags (like fire_hydrant:position) without benefit --chris66 (talk)
We discussed for months on discussion page and on tagging mailing list: why didn't you partecipate? The benefits are more universal and readable tags, some new tags and at the end of the work a detailed wiki page. People who discussed for months reached an agreement on this. --Viking81 (talk) 21:03, 2 October 2017 (UTC)
  • I oppose this proposal I oppose this proposal. Changing fire_hydrant:type=* to fire_hydrant=* when the usage numbers are 630000:107 without real benefit is not a good idea in my eyes. See reasons from Nakaner and Mueschel too. --Klumbumbus (talk) 08:58, 2 October 2017 (UTC)
We discussed for months on discussion page and on tagging mailing list: why didn't you partecipate? The benefits are more universal and readable tags, some new tags and at the end of the work a detailed wiki page. --Viking81 (talk) 21:03, 2 October 2017 (UTC)
I didn't notice the previous discussions. --Klumbumbus (talk) 15:09, 6 October 2017 (UTC)
  • I oppose this proposal I oppose this proposal. See comment from Nakaner --CMartin (talk) 09:23, 2 October 2017 (UTC)
We discussed for months on discussion page and on tagging mailing list: why didn't you partecipate? --Viking81 (talk) 21:03, 2 October 2017 (UTC)
  • I oppose this proposal I oppose this proposal. Sorry for coming up with this late, but: I also dislike the movement into global namespace, which may be even wrong at some points, e.g. the diameter of the hydrant is usually a type dependent fixed value for pillars, and may be much smaller than the underlying pipe (at least for Germany). Maybe this should be split into the additions and in_use replacement, which should easily get the required vote, and the remaining part which obviously needs further discussion. --Dakon (talk) 09:36, 2 October 2017 (UTC)
fire_hydrant: namespace is useless for tags that already exist and/or can be applied to other features. Then for consistency, after months of discussions, we have choosen to remove completely fire_hydrant: namespace from all documented tags.
The nominal diameter of an hydrant is printed on it, and indicates the diameter of its flanged connection to the underlying pipe.
--Viking81 (talk) 21:30, 2 October 2017 (UTC)
  • I oppose this proposal I oppose this proposal. First: Hydrants and suction points are different things and should be given different emergency-Tags. It doesn't matter whether the suction point has a connecting tube or not. Second: See comment from mueschel and Nakaner --streckenkundler (talk) 10:43, 2 October 2017 (UTC)
We discussed for months on discussion page and on tagging mailing list: why didn't you partecipate? For months we tried to have two different tags for hydrants and suction points, but we concluded that it is not possible because in some countries hydrants and "suction hydrants" are visually indistinguishable. So the shared solution is to tag as hydrant and then distinguish with pressure when more detailed data is available. Suction points are, as in the current definition on wiki page, preferred PLACES to take water, they are not the DEVICE to which connect the fire engine.--Viking81 (talk) 21:30, 2 October 2017 (UTC)
Forget this definition, this is not a definition. That does not correspond to reality! Functionally, suction points and hydrants are completely different. A pump is always required for a suction point. Whether the suction point has a connecting pipe or not is completely secondary. Suction points can be rivers, lakes or artificial ponds. Some artificial ponds have a connecting pipe, but not always! A suction point can also be a simple ground water extraction, then it is a simple connection pipe... You don't need a pump for fire hydrants. Hydrants and suction points have to be differentiated in the main key!! --streckenkundler (talk) 23:05, 2 October 2017 (UTC)
I was of your opinion too. If you had followed the discussion on tagging mailing list, you would understand why it hasn't been possible to do that. The solution found is to tag suction points the palces where you can take water. If there is also a a connecting pipe, tag it as hydrant with pressure=suction. This is a good compromise according to many, including me. --Viking81 (talk) 22:34, 2 October 2017 (UTC)
For this topic, the discussion between RFC and vote was far too short. I particularly missed the idea of the proposal in other active communities. For me it is important: 1. Clear separation of basic and already existing properties as well as new properties to be added. 2. No change of keys (this is very important: change of Keys brings chaos!!!) 3. Clear separation of hydrants and suction points in the base key (first key level!!) (whether they have a connecting pipe or not) --streckenkundler (talk) 20:54, 12 October 2017 (UTC)
  • I approve this proposal I approve this proposal. --Miche101 (talk) 11:02, 2 October 2017 (UTC)
  • I approve this proposal I approve this proposal. --Martin minheim (talk) 11:04, 2 October 2017 (UTC)
  • I approve this proposal I approve this proposal. --JB (talk) 11:52, 2 October 2017 (UTC) Although I really don't like the diameter key, that does not represent the diameter of the object, but of the underground pipe.
Yes, but the same was with the tag fire_hydrant:diameter=*. --Viking81 (talk) 22:48, 2 October 2017 (UTC)
  • I oppose this proposal I oppose this proposal. see comment Nakaner and also Mueschel --ToniE (talk) 16:07, 2 October 2017 (UTC)
We discussed for months on discussion page and on tagging mailing list: why didn't you partecipate? --Viking81 (talk) 21:30, 2 October 2017 (UTC)
  • I approve this proposal I approve this proposal. these improvements are useful, the number of objects concerned must not be a brake on improvement Marc CH (talk) 17:23, 2 October 2017 (UTC)
  • I oppose this proposal I oppose this proposal. The tagging scheme is too complex and in parts only applicable by specialists (with insider knowledge). Please simplify the scheme and divide it into a basic and an advanced tagging section. Furthermore is a clear (and intuitive) tag for suction points missing.--Toc-rox (talk) 06:47, 3 October 2017 (UTC)
Yes, in the final wiki page we can point out basic and advanced tags. You don't need to use all of them if you do not know the data. emergency=fire_hydrant + fire_hydrant=pillar is enough to tag an hydrant for a casual mapper. Then firefighters as me can add other tags when known. The advanced tags are very useful for firefighters. --Viking81 (talk) 09:59, 5 October 2017 (UTC)
fire hydrant mapping is generally a specialist field, I don't take issue with the tags being in part made for specialists (if they describe what they want to tag). You can still apply less detail if you don't know or are not interested. IMHO this is not an argument to reject the proposal. --Dieterdreist (talk) 11:44, 5 October 2017 (UTC)
"is too complex and in parts only applicable by specialists (with insider knowledge)" There are plenty of things in OSM which are for specialists, like tagging of sea marks, lighthouses etc, and railing signals. Let the fire fighters have their details. Rorym (talk) 08:20, 13 October 2017 (UTC)
  • I oppose this proposal I oppose this proposal. See the comment aboveǃ--redrace
As said above, it hasn't much sense to do not partecipate to discussions and then oppose a proposal that required many efforts to reach this compromise. --Viking81 (talk) 09:59, 5 October 2017 (UTC)
  • I approve this proposal I approve this proposal. --MoritzM (talk) 11:46, 5 October 2017 (UTC)
  • I approve this proposal I approve this proposal. --Władysław Komorek (talk) 12:53, 5 October 2017 (UTC)
  • I approve this proposal I approve this proposal. --Geri-oc (talk) 15:00, 5 October 2017 (UTC)
  • I oppose this proposal I oppose this proposal. see comments above! --Geodreieck4711 (talk) 15:55, 5 October 2017 (UTC)
  • I approve this proposal I approve this proposal. I'm not sure if I'm allowed to vote, but the proposal makes much sense to me. --SelfishSeahorse (talk) 17:47, 5 October 2017 (UTC)
  • I approve this proposal I approve this proposal. An excellent proposal. Although it makes it possible to map hydrants in greater detail than I need, I'm using portions of the new tagging structure already. AlaskaDave (talk) 01:51, 6 October 2017 (UTC)
  • I oppose this proposal I oppose this proposal. because fire_hydrant:class=* is a americacentric tag. you should make it fire_hydrant:AWWA_class=*, so people that from Not-America could do something similar with their local classification. Also, this proposal does not really convince me that this make over is a good thing. I tent to agree with the reasons from Nakaner and Mueschel on this subject --De vries (talk) 09:24, 6 October 2017 (UTC)
Sure we can develop your idea to solve the americancentric problem. fire_hydrant:class=* was proposed years ago, and since no one opposed till now, it remained unchanged. You could have joined the discussions during RFC period. Anyway we can still change it, if there is general consensus. But if you and many other oppose this proposal it will be stopped together with all other improvements and we will go nowhere. Please be cooperative, not obstructionist. --Viking81 (talk) 21:08, 13 October 2017 (UTC)
  • I approve this proposal I approve this proposal. It is an improvement. Philip.jacobs (talk) 13:05, 6 October 2017‎ (UTC)
  • I oppose this proposal I oppose this proposal. overcomplicates and fractures the namespace resulting in confusion --Brianboru (talk) 14:34, 6 October 2017 (UTC)
  • I oppose this proposal I oppose this proposal. Replacing well-used tags is a bad idea, as time as shown multiple times. This is particularly true in this case where I don't see a valid reason for replacing these values. In my opinion namespaces are a good thing, we should use them even more. --scai (talk) 16:10, 6 October 2017 (UTC)
diameter=* already exists and it is used for pipelines. pressure=* already exists and it is used for pipelines, location=* already exists and it's used in other contexts. --Viking81 (talk) 21:08, 13 October 2017 (UTC)
  • I approve this proposal I approve this proposal. But as said by De vries the fire_hydrant:class=* is too americacentric --R2d (talk) 18:52, 7 October 2017 (UTC)
  • I oppose this proposal I oppose this proposal. --Soldier Boy (talk) 20:55, 7 October 2017 (UTC)
  • I approve this proposal I approve this proposal. --Vincent 95 (talk) 09:03, 9 October 2017 (UTC)
  • I approve this proposal I approve this proposal. --Exe (talk) 15:02, 9 October 2017 (UTC)
  • I approve this proposal I approve this proposal. it's very useful --SMStuff (talk) 17:49, 9 October 2017 (UTC)
  • I oppose this proposal I oppose this proposal. Replacing well-used tags is unnecessary and it seems to be very US-centric --Zartbitter (talk) 13:03, 10 October 2017 (UTC)
diameter=* already exists and it is used for pipelines. pressure=* already exists and it is used for pipelines, location=* already exists and it's used in other contexts. For us-centric, we can solve, BUT we must change one of the "well-used tag" fire_hydrant:class=*--Viking81 (talk) 20:46, 13 October 2017 (UTC)
  • I approve this proposal I approve this proposal. --Zonta72 (talk) 20:32, 10 October 2017 (UTC)
  • I approve this proposal I approve this proposal. Good luck!--niubii (talk) 20:37, 10 October 2017 (UTC)
  • I approve this proposal I approve this proposal. --damjang (talk) 21:54, 10 October 2017 (UTC)
  • I approve this proposal I approve this proposal. --NonnEmilia (talk) 05:30, 11 October 2017 (UTC)
  • I approve this proposal I approve this proposal. --Jrachi (talk) 9:48, 11 October 2017 (UTC)
  • I approve this proposal I approve this proposal. --Bubix (talk) 11:42, 12 October 2017 (UTC)
  • I approve this proposal I approve this proposal. --Nospam2005 (talk) 19:06, 12 October 2017 (UTC)
  • I oppose this proposal I oppose this proposal. Replacing well-used tags is unnecessary, keep using of namespace is a good thing. --Roman H (talk) 22:12, 12 October 2017 (UTC)
diameter=* already exists and it is used for pipelines. pressure=* already exists and it is used for pipelines, location=* already exists and it's used in other contexts. --Viking81 (talk) 20:46, 13 October 2017 (UTC)
  • I oppose this proposal I oppose this proposal. There is no reason to replace fire_hydrant namespace tags by generic tags. Using generic tags could trigger side effects. --Christopher (talk) 06:01, 13 October 2017 (UTC)
All the existing tools for fire_hydrant needs an update if the tags will changes. The is a lot of work for all developers.--Christopher (talk) 06:06, 13 October 2017 (UTC)
diameter=* already exists and it is used for pipelines. pressure=* already exists and it is used for pipelines, location=* already exists and it's used in other contexts. --Viking81 (talk) 20:46, 13 October 2017 (UTC)
  • I oppose this proposal I oppose this proposal., because of 2 issues which can be easily corrected. The fire_hydrant:class=* seems too american, why not use the US: prefix on the value, e.g. fire_hydrant:class=US:AA, making the value clearer and (I presume) easier to use on a global level. Country prefixes like this are used in other places. The other problem is more serious, and easily fixed. "Gallon" is an ambiguous unit in English! A US and UK gallon are very different. 1 gallon is 1.2 US gallons. An hydrant with a AWWA class of "AA" has a flow rate of more than 1250 gallons, or more than 1500 US gallons, but this spec says "more than 1500 gallons". This spec seems to use "gallon" to mean "us gallon". What is the gpm (gallons per minute) value? Gallons or US gallons? I suggest using usgalpm or usgal/min or similar to make this clear and unambiguous. Rorym (talk) 08:14, 13 October 2017 (UTC)
Sure, we can develop your idea. Simply we didn't think to it. But if you and many other vote against this proposal, it will be stopped together with all other improvements. Please be cooperative, not obstructionist. --Viking81 (talk) 20:32, 13 October 2017 (UTC)
Perhaps I was unclear, I'm only voting no because of the ambiguity of the gallon tag, if that's resolved with some clear docs, my objection would be solved. Rorym (talk) 08:27, 16 October 2017 (UTC)
  • I approve this proposal I approve this proposal. --Kazing (talk) 10:18, 13 October 2017 (UTC)
  • I approve this proposal I approve this proposal. --Axelr (talk) 11:37, 13 October 2017 (UTC)
  • I oppose this proposal I oppose this proposal. Why change well used tagging for no benefit --Omegatherion (talk) 11:11, 14 October 2017 (UTC)