Proposal talk:Fire Hydrant Extensions (part 2)

Survey date

In the explanation for survey_date you wrote "Date of the last site survey without a functional check". I assume you mean "Date of the last site survey since a functional check", or simply, "Date of the last functional check". To me, the way it's written now makes it difficult to understand. AlaskaDave (talk) 23:46, 18 October 2017 (UTC)

No, the definition is right. Because someone noted that survey:date=* in general means that someone was there and saw the hydrant. But it doesn't mean that he tried it. Another tag is necessary to denote the date of a functional check. check_date=* was proposed here: Proposed features/Fire Hydrant Extensions (part 3) but at the moment it hasn't received consensus yet. --Viking81 (talk) 20:12, 19 October 2017 (UTC)

If that's what you mean, It would make more sense to leave out the words "functional check" entirely. Simply say "The date last surveyed" or "date of last ground survey" which will be less confusing and closer to the meaning of the existing tag, which, as you point out, is used elsewhere. Such a survey has nothing to do with a functional check. It merely means I was there on this date and saw a fire_hydrant at this location.

"Without a functional check" has been specified because when it will be added another tag for the functional check, the two tags will be clearly distinguishable. Anyway I added a sentence fur further of explanation. --Viking81 (talk) 12:32, 20 October 2017 (UTC)

After your explanation, I'm still sure that the words "without a functional check" are misleading. If you intend for some future tag to clarify the meaning of this on that's all the more reason to remove those words from this definition. If you are trying to indicate a survey date that did not involve a functional check, in other words, a simple ground check, your wording only confuses the meaning of the tag. If that is not what you mean, then I recommend that you find another way to say it. AlaskaDave (talk) 23:20, 21 October 2017 (UTC)

Ok, I removed those words and I tried to say it in other words. --Viking81 (talk) 08:08, 22 October 2017 (UTC)

Much better. Thanks. Also the grammar in this sentence, "This means that someone saw the hydrant there on the ground but it doesn't necessary means that he/she tested it." would be better written as "Someone observed the hydrant at this location on this date. This does not imply that a functional check was done at that time." AlaskaDave (talk) 13:00, 23 October 2017 (UTC)

Ok, updated. Thanks for suggestions. --Viking81 (talk) 22:46, 23 October 2017 (UTC)

Some additional information

• the A,B,C(,D,F)-system of naming the couplings is the same in Austria and Germany, and AFAICT the couplings and diameters are the same in both countries
• the underground hydrants are also the same in Austria and Germany. Inside is no normal coupling, but a special type of claw where the standpipe is locked in. This is the same for all hydrants everywhere in the country. It's also the same for all wsh-type hydrants, I don't know if both have the same claws. So it's not necessary to open such a hydrant, what's in there is always the same.
• it is however necessary to carefully look on the cap. There are other types of objects hidden below such caps in some places like measuring points (e.g. labelled "GWM") or natural gas (labelled "Gas"). Hydrants are of course labelled "HYDRANT".
• all "public" pillar hydrants (i.e. those not located inside a special industrial area with their own water supply) in Germany are dry barrel, even if the couplings are on different levels. They look like [1] this, in this case 2 C couplings at the top and B at the front, others have the same form but B couplings at the top and A at the front. (Dakon (talk) 20:44, 23 October 2017 (UTC))

Thank you. I've tried to implement your information. --Viking81 (talk) 22:42, 23 October 2017 (UTC)

diameter

In the disapproved proposal you were trying to replace fire_hydrant:diameter=* by diameter=* which a lot of people disliked. I presume that you were trying to harmonize this with man_made=pipeline where diameter is used in global namespace and refers to the pipeline diameter.

Why don't you try it the other way around:

old	new
fire_hydrant:diameter=* (used with emergency=fire_hydrant)	pipeline:diameter=*
diameter=* (used with man_made=pipeline)

And maybe analogue pipeline:pressure=*. I'd think this will serve a lot of applications where pipelines are connected to other features, including but not limited to fire hydrants. --Cmuelle8 (talk) 10:05, 26 October 2017 (UTC)

It also does not redefine "old" usage of the tags, so the migration may happen gradually, as is usually done. The old tags can be documented deprecated in favor of the new ones and mappers and users alike have the chance to pick up the change made for a very long time (just as was done for public transport v1 v2 transition). --Cmuelle8 (talk) 10:13, 26 October 2017 (UTC)

If I think of heating pipelines that have thick insulation, it'd be actually more correct to let pipeline:diameter=* measure the diameter of the pipe, and diameter=* measure the diameter of the whole object (e.g. from insulation or housing end to end). (So even just within the realm of pipeline objects this prefix is not strictly redundant, although for most pipelines pipeline:diameter == object diameter). --Cmuelle8 (talk) 10:21, 26 October 2017 (UTC)

Many people were against the migration because it would involve a big number of objects, presets and applications. I don't want to have this problem again in this proposal, because first of all we need to approve the other tags. So in this proposal I will not try to change fire_hydrant:diameter=* any more. I proposed a gradual migration too, but people opposed to it anyway.

If you want you can start a discussion in tagging mailing list and open a new proposal. Anyway currently diameter=* refers to the nominal diameter. Personally I would prefer diameter=* to pipeline:diameter=*. --Viking81 (talk) 18:42, 28 October 2017 (UTC)

Type leads to confusion

The use of 'type' leads to people adding values that can be a different concept. Best avoided? The present values look to be 'mounts' so why not use fire_hydrant:mount=pillar/underground/* ? This also means the older tag can be left in place while the new style changes over. Warin61 (talk) 01:51, 29 October 2017 (UTC)

This would change an existing tag. Due to the past voting issues I will not semantically change any existing tag in this proposal. If you want, a change in fire_hydrant:type (but also fire_hydrant:diameter, fire_hydrant:pressure, fire_hydrant:position) can be discussed in a new proposal (e.g. Fire Hydrant Extensions (part 4)). --Viking81 (talk) 11:15, 29 October 2017 (UTC)

Definition of water_source=* values

• What means water_source=main?

> 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.

Simply speaking water_source=main means a hydrant connected to a pipe which is fed by the local distribution network.

See https://www.thefreedictionary.com/water+main --MoritzM (talk) 16:31, 29 October 2017 (UTC)

OK; I wasn't aware of this meaning. I think "...connected to a pipe which is fed by the local distribution network" or similar should be added as explanation of this value to the proposal. --Klumbumbus (talk) 16:41, 29 October 2017 (UTC)

Explanation added. --Viking81 (talk) 19:29, 29 October 2017 (UTC)

• There is only water_source=stream. How to tag hydrants with water sources from the other waterway classes (river, canal, drain, ditch)? Use water_source=river,... or replace stream by a general water_source=waterway for all classes?

--Klumbumbus (talk) 13:16, 29 October 2017 (UTC)

The list may not be exhaustive. As a rule of thumb you should repeat the tag used on the water source itself. I've added explanation for this too.

We don't want to group different sources in invented general tags, because we can lose information. It is different if you take water from a river, that is supposed to have always water, rather than from a ditch, that sometimes may be dry. --Viking81 (talk) 19:29, 29 October 2017 (UTC)

hydrant vs suction point

I don't see any real and clear difference between the hydrant and the suction point.

Main difference: At a suction point a pump is required, not at the hydrant. It is irrelevant how the suction point is built.

Suction points and hydrants need a differentiation in the base key. Suction points need a pump. Hydrants do not.

At the first it is irrelevant whether a suction point is sucked from a river, lake or from a pipe (= groundwater).

In the end, this also has practical reasons. Water is not always removed from the hydrant to extinguish the fire. It can also be taken from water for other things. With a tube and and water meter. It is quite fatal if the user is into a fire hydrant, which is in fact a suction point.

I am in favour of clear, clean and unique definitions. I still miss that.--streckenkundler (talk) 20:32, 29 October 2017 (UTC)

The point is that until now the tag emergency=fire_hydrant has been used both for pressurized devices (=hydrants) and not pressurized devices (=what you call suction points), and they are distinguished by fire_hydrant:pressure=*. Hydrant has been intended as any device that can look like an hydrant (and people that doesn't have enough knowledge can confuse the two types).

This proposal will NOT change that definition, because this would create other problems and many people opposed to it. If you want to change the definition of emergency=fire_hydrant, please create a separate proposal and discuss it.

This proposal is focused on the additional tags and we would like to approve them. STOP. --Viking81 (talk) 23:12, 29 October 2017 (UTC)

Defects in this tagging scheme

This proposal has a couple of oddities/defects that should have been fixed before it was even considered for voting: - the English word for the local distribution network is "mains" not "main" - use of capitalized values for coupling:type is contrary to existing practice and should be fixed

SimonPoole (talk) 15:48, 28 December 2018 (UTC)

Current usage is clearly with capitalized values, I agree no caps would be better for these. Anyway, this proposal was approved more than a year ago and there isn’t yet a tag page for coupling:type=* where this would normally be documented. What do you suggest? —Dieterdreist (talk) 16:17, 28 December 2018 (UTC)

About main/mains: current widely used value is "main" and according to dictionaries, it can be singular or plural, see https://www.collinsdictionary.com/dictionary/english/main at point 5. In my understanding "mains" means the whole distribution network, while a "main" is a principal pipe of the distribution network. So in my understanding the singular form is not completely wrong and anyway it would be hard to change a widely used and accepted tag.

About capital letters in coupling:type, we have thousands of values with capital letters: I don't know how to fix it easily and how to persuade all mappers that the use of lowercase letters brings real benefits at this point. --Viking81 (talk) 21:50, 28 December 2018 (UTC)

There are capitalized letters in free form values (names, brands, operators, etc.) but we generally do not use them in fields with a predefined vocabulary. --Dieterdreist (talk) 21:58, 28 December 2018 (UTC)