Proposal talk:Fire Hydrant Extensions

From OpenStreetMap Wiki
Jump to navigation Jump to search

dry_barrel vs wet_barrel

Resolved

How would a surveyor know the difference between dry_barrel and wet_barrel? And also how would you handle the other types of the fire_hydrant:type - underground? In the draft there is no such thing, but firefighters have to find the fire_hydrant if they don't know how what to look for how will they find it? --Krzyk (talk) 18:51, 4 July 2017 (UTC)

  • the difference may be determined by looking at the configuration of the bolts. a dry barrel hydrant has a bolt head on top, connecting to a shaft that runs down to the valve at the water main. a wet barrel hydrant has individual bolts behind each of the outlets which are not present on dry barrel hydrants. --Nfgusedautoparts (talk) 20:30, 4 July 2017 (UTC)
    • So basically we would need a picture for both types on the future wiki page
      • And that's easy to do. I have some i can contribute. --Nfgusedautoparts (talk) 12:34, 5 July 2017 (UTC)
        • Nfgusedautoparts, please put them also in the proposal page, so it's more clear. --Viking81 (talk) 17:55, 5 July 2017 (UTC)

Underground hydrants

Resolved
  • in terms of finding underground hydrants, my understanding is that in the UK there is a standard way of marking their location so the firefighters know where to look. --Nfgusedautoparts (talk) 20:35, 4 July 2017 (UTC)
    • But the same you can say about almost any information regarding the hydrant (and other OSM tags), generally in some (most?) countries in Europe each hydrant has to have a label with information about it, so why put all that information into OSM? :) I think we still need a way to tag undeground hydrants. --Krzyk (talk) 09:37, 5 July 2017 (UTC)
      • For underground hydrants, fire_hidrant:type=underground is still valid, because the proposal doesn't deprecate it. In Italy there is no information on hydrants' labels. In any case, it's useful to have information about hydrants on a map, because you know the diameter, pressure, etc, before reaching them: you can save time going directly to the most efficient one in the neighborhood.--Viking81 (talk) 17:55, 5 July 2017 (UTC)

Additional wrench type and cap vs bonnet

Resolved

AlaskaDave (talk) 21:07, 28 July 2017 (UTC) I like the proposal but would like clarification on a couple of points: you do not include "hexagonal" in the "fire_hydrant:wrench" choices, perhaps because there are none using that type of bolt head, even though it is a "standard" bolt type in other applications. Also, the proposal does not attempt to differentiate between a "cap" and a "bonnet" . Thanks for your effort on this. - Dave

  • I have no objection to having Hexagonal on the list, but i'm not aware that they're actually used. Cap and Bonnet are standard terminology, i can add descriptions. Nfgusedautoparts (talk) 21:13, 28 July 2017 (UTC)
    • i have added a note on colour:cap. The description of Bonnet was already sufficient. Nfgusedautoparts (talk) 22:37, 28 July 2017 (UTC)

More location values

Resolved

Using the location=* key opens up a vast namespace of different values to us and it's great.
We may need to add indoor (inside a building), wall (outside but stuck into a wall) or tunnel (inside a tunnel), don't we? Fanfouer (talk) 19:55, 4 August 2017 (UTC)

Do NOT use location=wall and location=underground. fire_hydrant:type=wall is still valid because it denotes a different shape of hydrant, not only its location. The same for fire_hydrant:type=underground.
For indoor it's better to use the existing tag indoor=yes.
For tunnels, yes, location=tunnel can be useful and it's already used for other objects. --Viking81 (talk) 20:38, 15 August 2017 (UTC)
Tag location=* is Ok for me. It will be simpler to use, isn't specific and the level of information is unchanged Gendy54 (talk) 00:08, 24 August 2017 (UTC)

fire_hydrant vs suction_point

Resolved

To my mind water_source=* is not needed because a hydrant is always connected to the municipal water system - at least that's the definition of a hydrant here in Germany. If the water_source would be pond then it should be emergency=fire_water_pond, for stream it could be emergency=suction_point. I suggest to tag things only as hydrants which are really connected to the water system. --MoritzM (talk) 19:08, 11 August 2017 (UTC)

French hydrant water pond.jpg
I got the point but respectably disagree.
emergency=fire_water_pond is intended for the pond itself, not for the connected hydrant(s).
Then it's recommended to map at least two different features : the pond as an area and the hydrant as a node. It's usefull to give the information than a given hydrant is fed by a pond and not by the (pressurized) water system.
It's the same for emergency=suction_point : it's the point where the water is got, not relative to the hydrant itself which can be meters away.
It may be good to clarify this particular point in the proposal as to not confuse those 3 different features Fanfouer (talk) 20:52, 11 August 2017 (UTC)
I never saw it this way, but with emergency=fire_water_pond you are right. Should be the water reservoir itself. For emergency=suction_point I disagree. I my eyes it is not the point where the pipe is going into the reservoir but where the firefighters can attach there fire engine to pump water. So it would be the end of the pipe.
For me as a firefighter there is a second point why to distinguish between hydrant and other suction points: from a hydrant I get pressurized water so I do not need a fire engine or pump. Whereas at a suction point I've to pump the water from a deeper level. Like the pipe picture in the proposal or the pond picture you added here. Maybe emergency=suction_point is not the best tag for this, but it fits better to something where to suck water from then a hydrant. I agree in this point with http://www.thefreedictionary.com/hydrant where a hydrant is a thing where to get water from a water main (not a pond or lake or stream).
The point isn't to make a distinguish at all, but to put this difference in water_source=* and not in the emergency=* key.
Since the object name can't handle all the criterias as to not be too extended, we choose to put this information in another key.
A suction point is a place, and fire hydrant is a kind of device which may or not be present at suction points to end the pipe. Then it will be useful to have both on the map, depending of what anyone is looking for.
If we differentiate network fed hydrants and other sources in the emergency=* key, there will be a lot of errors I think since they can share the same appearance.
Finally, there are about 4k of suction_points and 150k of emergency=fire_hydrant + a source indication Fanfouer (talk) 15:31, 12 August 2017 (UTC)
Just a question which comes into my mind when thinking about your argument that emergency=suction_point is the point where the water is got: how figure out where exactly the end of the pipe goes into the water? It can be really hard to determine.
Water agencies survey water intakes. This information can be found in public databases in some countries. Fanfouer (talk) 15:31, 12 August 2017 (UTC)
The other question is: which value does this information have for the emergency services? The firefighters are only interested in the end of the pipe where to connect their pump.
Because there is a third thing to distinguish: not a real suction_point an no hydrant but a well to get ground water from, I started a proposal for a fire water well: https://wiki.openstreetmap.org/wiki/Proposed_features/Fire_water_well --MoritzM (talk) 09:47, 12 August 2017 (UTC)
Not only firefighters are interested but public planners, biologists, fishermen and so on to know where an amount of water can occasionally be took.
That's why I'm not so keen on emergency=* tag because such infrastructure can also be a concern for a large amount of people.
And that's why we should map fire hydrants with sources and places for firefighters and water intakes for other people. Fanfouer (talk) 15:31, 12 August 2017 (UTC)
I agree. What about giving the real position of the suction point the tag emergency=suction_point and the other end in the water another tag like suction_point=water_intake? --MoritzM (talk) 07:32, 14 August 2017 (UTC)
+1 --MoritzM (talk) 14:18, 16 August 2017 (UTC)
Nope, even if wells provide pressurized water, they are still wells. Fire hydrants are by definition connected to the water main, not to the ground water. Thus water wells with pump should also be emergency=suction_point with additional tags i.e. suction_point:type=fire_water_well fire_water_well:type=electric_pump--MoritzM (talk) 14:18, 16 August 2017 (UTC)
Not exactly. Hydrants that serve factories or shopping centers often are not connected to the public water main: instead they are connected to a private local water network fed by pumps that suck water from the ground. So these local water networks and their hydrants are fed by what we can call water wells.
The fundamental distinction for firefighters is: hydrants provide pressurized water; suction points provide water but you need your pump and equipment to suck it out. --Viking81 (talk) 22:09, 16 August 2017 (UTC)
Suction points aren't devices like hydrants but are places. In France we totally have hydrants without any pressure but they look like pressurized hydrants except they are painted in blue. Then we can't arrange hydrants and suction points in the same category since one is an equipment/device and the second is a place and they can fit together.
fire_hydrant:pressure=* may be renamed in a simpler pressure=* and take the value 0 when hydrant isn't pressurized.
You get the same taxonomy with benches vs parks : a park may contains benches but benches can be seen in a ton of different places. (park is the suction point and bench is hydrants inside) Fanfouer (talk) 23:11, 16 August 2017 (UTC)
Suction points aren't devices like hydrants but are places: is this the common accepted definition? Then it must be written in the suction point page.
In this case, emergency=fire_hydrant will include all devices to whom firefighters can connect, pressurized or not. And the only way to distinguish between them is fire_hydrant:pressure=*. Is this right? --Viking81 (talk) 08:57, 17 August 2017 (UTC)
It's only my point of view, but I hope to make a consensus :) Ok to distinguish dry vs pressurized with any pressure key Fanfouer (talk) 17:07, 17 August 2017 (UTC)

After a long discussion in mailing list, we go back to this solution:
emergency=fire_hydrant will include all devices to whom firefighters can connect, pressurized or not. fire_hydrant:pressure=* will be used to distinguish pressurized or not.
emergency=suction_point is a place near where you can park the fire engine and you put down your pump and hoses to suck water from a not pressurized water reserve.
water_source=* is again useful both for emergency=fire_hydrant and for emergency=suction_point.
--Viking81 (talk) 10:22, 3 September 2017 (UTC)

Flow and pipes capacity

Resolved

After a discussion on French mailing list regarding fire_hydrant:flow_capacity=*, we'd may be better using capacity=* namespace.
We could consider 2 keys :

  • capacity:flow=* to know how much water the hydrant can provide during a given time range (l/m, m3/s, m3/h and so on)
  • capacity:pipes=* to know how much outlets the hydrant have to connect pipes.

This tagging schema can also serve the adjacent Dry riser inlet proposal.
Not to mention capacity:flow=* will be usefull for drains, culverts, pipelines (instead of simple capacity=*).
How do you feel about that ? Fanfouer (talk) 11:44, 23 August 2017 (UTC)

2 Keys are Ok for me rather than fire_hydrant:flow_capacity=* which is really too specific and can't be used outside the context of fire_hydrants Gendy54 (talk) 00:00, 24 August 2017 (UTC)
Currently in the tagging mailing list we are going towards flow_rate=*, that is probably the most correct English term.
For the number of connections, in the proposal there is already fire_hydrant:couplings_size=* that has a certain consensus and that will list all diameters separated by semicolons (i.e. fire_hydrant:couplings_size=45;70;70). This because very often there are couplings with different diameters and only the number of them isn't enough. Anyway we can change fire_hydrant:couplings_size=* => couplings_diameters=* --Viking81 (talk) 19:25, 28 August 2017 (UTC)
flow_rate=* and capacity:flow=* may give two different information : firefighters look for minimum flow rate and capacity is the maximum reachable flow, don't you ?
Regarding couplings, a semicolon separated list is hard to process. I have two ideas to improve the description a bit :
- Add manufacturer=* and model=* to tagging as to retreive information from manufacturers' documentation. In France we have only 3 or 4 different companies building hydrants.
- Consider introduction of couplings:big=*, couplings:big:diameter=*, couplings:medium=*, couplings:medium:diameter=* and couplings:small=*, couplings:small:diameter=* because you'll only have 2 or 3 different coupling size/types on a given hydrant.
Let me know how do you feel about that, this is what is intended on Power transformers and windings=* key Fanfouer (talk) 23:00, 30 August 2017 (UTC)
- flow_rate=* and capacity:flow=*: -1 It is misleading to have two similar tags. Only one for me as mapper and as firefighter is enough. Normally water companies declare only one value, and it should be the nominal flow rate. Nominal flow rate is enough for firefightening purposes. Let's try to keep this proposal as simpler as possible.
- manufacturer=* and model=*: I think that this is micromapping.
- couplings:big:diameter=*, etc: -1 It is too complicated. We have just removed fire_hydrant: namespace for the sake of simplicity and this goes in the opposite direction. The use of semicolon separated values is commonly accepted in other tags. It isn't hard to handle if it is well documented on the wiki. --Viking81 (talk) 20:36, 31 August 2017 (UTC)
Don't get me wrong, knowing model + manufacturer allows us to get other information like couplings in public documentation instead of openning each hydrant. Semicolon values go messy along time because anyone will arrange the list on its own understanding. Values like couplings_diameters=50;50;200 will match OAPI statement ["couplings_diameters"~"20"] (should I write "(^|;)20(;|$)"?). Then I know the solution with couplings:big:*=* wasn't the best one, but here namespace is used to differentiate part of the feature (and serve as a guide to mappers) and won't be used to group keys in a restricting category which is actually different. Removing fire_hydrant: namespace was a really good choice but it doesn't prevent us to use this tool when appropriate.
Won't you appreciate a solution to give standalone values regarding couplings instead of lists ? Fanfouer (talk) 21:01, 31 August 2017 (UTC)
I continue to prefer a list. Your solution with couplings:big:*=* would introduce additional new tags and namespaces. To bypass the problem of "looking for 20 and finding 200", we can make compulsory the units of measure. Moreover, millimeters or inches aren't standard units in I.S. (because standard is meter), so it makes sense to specify them. It would become couplings_diameters=50 mm;50 mm;200 mm--Viking81 (talk) 22:02, 31 August 2017 (UTC)
Understood for couplings_diameter=*. Would you mind adding couplings=* to give the total amount of couplings please ? Because you can't filter hydrants with the list length. It will ease QA tools to detect possible mistakes Fanfouer (talk) 21:15, 4 September 2017 (UTC)
Ok updated with couplings=*, manufacturer=* and model=*. --Viking81 (talk) 22:51, 5 September 2017 (UTC)

Pipe Diameter

Resolved

In Australia, New South Wales, the pipe diameter is stated in mm rather than flow rate. Most urban hydrants are underground and have above ground signs with the information on them, see https://www.rfs.nsw.gov.au/__data/assets/pdf_file/0015/23532/Bush-Fire-Bulletin-LIFTOUT-HydrantMarkers.pdf Warin61 (talk) 00:27, 1 September 2017 (UTC)

Ok, currently pipe diameter will go in fire_hydrant:diameter=# --Viking81 (talk) 20:58, 1 September 2017 (UTC)

Bonnet

Resolved

We talk about the color of the bonnet. Can not we also put bonnet=yes/no or fire_hydrant:bonnet=yes/no because some fire_hydrants have bonnet and others not. He seems to be an interesting infomation. Gendy54 (talk) 23:36, 23 August 2017 (UTC)

I think that this is micromapping. As a firefighter, I don't have the necessity to have this information. Personally, I wouldn't add another tag. --Viking81 (talk) 19:19, 31 August 2017 (UTC)
Moreover, every pillar type hydrant has a sort of bonnet, intended as upper part of the hydrant. But only some hydrants have it of a different colour, and that's the reason of bonnet:colour=*. --Viking81 (talk) 22:51, 5 September 2017 (UTC)

Remove fire_hydrant: namespace from keys

Resolved: Proposal updated

As discussed on @tagging ML, several users think it's better to remove fire_hydrant: and suction_point: namespaces from keys name.
Here is a list of what is wished :

Many of those keys aren't special to fire hydrants and may be useful to other objects.Fanfouer (talk) 15:34, 25 August 2017 (UTC)

OK. But currently in ML we are going towards fire_hydrant:flow_capacity=* => flow_rate=*. And for fire_hydrant:couplings_size=* maybe it's more clear couplings_diameters=*. I'll update the proposal.--Viking81 (talk) 19:30, 28 August 2017 (UTC)
Really nice of you to take care of this. It looks really great, thank you Fanfouer (talk) 09:23, 30 August 2017 (UTC)
Some of these tags are really established and used thousand and even tens of thousands of times. Who is going to change this established scheme, all of the existing nodes, and convinces the >1000 mappers who used these tags so far to change to your scheme? --Mueschel (talk) 11:27, 11 September 2017 (UTC)
This is long term change. We aim to provide a more versatile and universal tagging scheme for sake of simplicity. Wiki, tools and renders will progressively be encouraged to use the new tags. It's the only way to make things better. Using universal tagging prior to specific keys should always be a goal. Fanfouer (talk) 12:34, 11 September 2017 (UTC)
I only see advantages of using a dedicated namespace. Likewise, what is the purpose of replacing fire_hydrant:type by fire_hydrant and fire_hydrant:diameter by diameter on 600.000 and 400.000 objects *by hand*? If it has a real advantage, I'm fine with such changes, but not in a case like this where it just looks nicer at best. --Mueschel (talk) 12:54, 11 September 2017 (UTC)
Using a dedicated namespace prevent other part of comunity to use in other fields of knowledge the work you've done. It's more efficient to collaborate on the diameter=* formalism than on dedicated keys. It's a huge advantage since we're all part of the same community.
Furthermore, :type subkeys are semantically meaningless and encourage a mess in possible types list like we saw with pond case in the middle of physical appearance related values. Such subkeys encourage the definition of other subkeys aside while it's not needed. We only propose to replace values by hand because automatic edits aren't possible and shouldn't be done since it's a unique occasion to check if data is right. Be sure QA tools, editors, validators, checks, crowdsourcing apps will help to do this change.
It has already be successfully done with power=sub_station to more correct power=substation. Even if the old tag hasn't disappeared from DB yet, the new one had been adopted more widely and faster than the old one. Having a simpler and more meaningful tagging scheme encourage people to map, that's all Fanfouer (talk) 13:10, 11 September 2017 (UTC)
What is the plan with all the other tags existing in the fire_hydrant namespace? If some are moved to the new keys and others stay in the existing namespace it will be a mess. There should be a list with all the replacements. --Mueschel (talk) 18:42, 11 September 2017 (UTC)
There is a list here : https://wiki.openstreetmap.org/wiki/Proposed_features/Fire_Hydrant_Extensions#Values_to_be_replaced
Only reviewed/approved keys are planed to be replaced. Others aren't covered by this proposal and can find an transparent equivalent (fire_hydrant:operator=* => operator=*)
Do you see any miss in the list ? Fanfouer (talk) 19:22, 11 September 2017 (UTC)
Several... fh:couplings (which is _not_ replaced by couplings). fh:street, fh:city, fh:housenumber (which is not a case of addr:*). There are 73 subkeys in use according to Taginfo. --Mueschel (talk)
I can't find any description of those keys. That's why this proposal deals with reviewed keys only. Look, fire_hydrant:street=* redirects to a page... without any mention of fire_hydrant:street :(
Can you give us more information please ? Fanfouer (talk) 20:24, 11 September 2017 (UTC)
I don't know details, but these tags are in use thousands of times and should not be ignored by any new tagging scheme. A mixture of old and new is the worst thing that could happen because it's extremely confusing. --Mueschel (talk) 23:26, 11 September 2017 (UTC)
Actually, the thousand times used tags are covered by this proposal. About 3/4 of fire_hydrant:* tags are used less than 1000 occurrences and aren't documented. Unless a better documentation, we won't be able to add such tags to this proposal Fanfouer (talk) 09:15, 12 September 2017 (UTC)

Since we removed fire_hydrant: prefix, now we can use : for other purposes.
So in accordance with other tags (like cap:colour=*, bonnet:colour=*, survey:date=*):
couplings_type=* becomes couplings:type=*
couplings_diameters=* becomes couplings:diameters=*
--Viking81 (talk) 12:44, 18 September 2017 (UTC)

survey_date <> survey:date

Resolved

instead of survey_date, it would be better to use the more common tag survey:date=*

OK Updated --Viking81 (talk) 22:26, 5 September 2017 (UTC)

request for a split

Resolved

we are adding more and more tags... maybe it's time to split the proposal in 2, one with :
change fire_hydrant:position=* to location=*
change fire_hydrant:type=* to fire_hydrant=*
change in_service=yes/no to disused:emergency=fire_hydrant
pillar:type=*
fire_hydrant:class=*
flow_rate=*
water_source=*
pressure=*
survey:date=*
colour=*
bonnet:colour=*
cap:colour=*
reflective:colour=*
couplings=*
couplings_type=*
wrench=*
other tags that are recent or for which it is doubt should be put in a separate proposal in order to allow to discuss it without blocking the first modifications. it is already a HUGE proposal that affect nearly all hydrant. IMHO we need to validate a first release, allowing app/tools to be updated (with a transition phase requiring management of old and new tags)

As soon as possible we will split the proposal, so we can vote the approved tags. --Viking81 (talk) 21:57, 13 September 2017 (UTC)
Proposal splitted: new tags in Fire Hydrant Extensions (part 3). --Viking81 (talk) 17:08, 16 September 2017 (UTC)

"gallon" is ambiguous

I mentioned this on the voting page: "Gallon" is an ambiguous unit in English! A US and UK gallon are very different. 1 gallon is 1.2 US gallons. There's about 20% in it! 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? (In keeping with OSM usage, I am using British English, hence "gallon" = "uk gallon" = 4.546090 litres. A US gallon is 3.785412 litres.)

If the specificiation was left like this, then someone should, using OSM convention, interpret "gpm" as "gallons per minute", and go around and change all the hydrants in the USA to use (UK) gallons. I suspect that's not what you want.

I suggest using usgalpm or usgal/min or similar to make this clear and unambiguous.

Rorym (talk) 11:18, 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:26, 13 October 2017 (UTC)
"Simply we didn't think to it." Perfectly understandable.
Your proposal is not up to standards and shouldn't be approved in it's current form. So please don't call those cooperating with constructive criticism obstructionist. --De vries (talk) 14:55, 16 October 2017 (UTC)
Why not use liter instead of gallons. Liter is an ISO derivative unit of measure. The ISO best unit of measure is cubic meter per second but I think it's too big. Liter per minutes is acceptable. A table for conversion in gallons (US and/or UK) could be inserted into wiki page.--Miox (talk) 06:29, 17 October 2017 (UTC)
Because in USA someone could use gallons anyway. So it is better to define them from now. usgal/min is used in Fire Hydrant Extensions (part 2) --Viking81 (talk) 20:17, 17 October 2017 (UTC)
Retrieved from "https://wiki.openstreetmap.org/w/index.php?title=Proposal_talk:Fire_Hydrant_Extensions&oldid=2513900"