Deprecate water_volume in favour of water_tank:volume?

The key water_tank:volume has been introduced in 2012 and is used in combination with emergency=water_tank. The iD preset for emergency=water_tank proposes the use of water:tank_volume to be entered in litres. There was no wiki page for it until 2023 but usage has increased steadily up to some 15K until today.

The key water_volume has been introduced as additional tag to emergency=water_tank again, being a part of Fire Hydrant Extension Part 2 Proposal, probably because the author was not aware of the already existing water:tank_volume. The proposal recommends to enter the volume in m3. There was no wiki page for this tag as well, it got created at the same day as the one for water_tank:volume, but there are merely 450 uses of this tag until today.

Both tags have the same meaning, both are mentioned on the wiki page for emergency=water_tank, and the list of values of both keys is a mess of figures representing m3, litres, litres per minute, gallons and the like - whereby most of these values do not specify the unit explicitely so one has to guess.

Does that make sense? Would it not be better to deprecate on of these keys - preferably water_volume in favour of water_tank:volume as the latter is much longer and 30 times more often in use, and also preset in iD editor already?

1 Like

Did you contact the author of the Fire Hydrant Extension Part 2 Proposal yet?

Personally, I would think: manually check of the 450 water_volume tags, and where possible add the appropriate water_tank:volume tag. If all have been checked, then start thinking of removing the old tag. No deprecation needed in this case, is my opinion. If all has been cleaned up, you can simply refer wiki readers to the newer tag.

If I am going to check 450 water tanks manually what benefit do you expect from adding a redundant key to the existing one instead of replacing it straight ahead?

I contacted and invited him to comment here, although at present he has no yet established an account here as far as I can see.

Avoiding the deprecation issue for the moment, so you can add your preferred tag immediately.

Ok I see, but this is not my concern. I just stumbled over this key doublet by chance and believe it does not make sense and it does not make our data better. Deprecating one would make tagging more consistent. That’s all.

Hello, I’m the proposer of Fire Hydrant Extension Part 2 Proposal.

The proposal was aimed to add tags to emergency=fire_hydrant and not explicitly to emergency=water_tank. In fact this should be an accessory tag to an hydrant when it is alimented by a water tank (or similar), so you know immediately how much water you have available.

After the original proposal of 2017, things changed and in fact on August 27, 2020 the page emergency=fire_hydrant was modified by Jengelh: since then that page recommends the usage water_tank:volume=* and it has no more reference to water_volume=*.

There is still a reference to water_volume=* in emergency=water_tank page, but I have not participated in its development.

Anyway, I agree that a unique tag is better and that it should be the most commonly used one, so according to me you can deprecate the usage water_volume=*, explaining and documenting the choice on the wiki.

Regarding the unit of measurement, it is preferrable to specify it explicitly, otherwise m3 should be the default. This according to Map_features/Units.

2 Likes

Would a form of tags along the lines of;

emergency=tank + tank:contents=water + tank:volume= 1000000 (as litres)

be more generally flexible for other tank uses? Gas tanks and so on in non-emergency uses are still tanks.

Is getting to the point where usable volume < empty volume a bit to technical to involve?

Hello Adrian,

your reasoning would have sense if the tags were brand new and not yet used.

But now changing a tag that has 15000+ uses is not a good idea.

1 Like

Fair enough.

Is 15000 a lot in terms of the amount of times the tags are consumed by clients?

Don’t know about that, but it would call for a full rfc/cfv procedure. Solving this minor two-tag issue shouldn’t wait for that, I think.

1 Like

Hello

I’d like to mention capacity=* which is recommended in combination with man_made=storage_tank

Water is a substance, it would be great to not duplicate it in the key intended to store a volume.

3 Likes

Yes, I have noted that, too - and it is mentioned as third option on the wiki page for emergency=water_tank also.

It has been used in a slightly different way for tanks which may hold different unknown quantitiy of water, could be anything between empty up to full whereas an emergency water tank is more understood as a permanent water resource of a certain quantity.

Not much difference in my eyes but I was afraid to make things more complicated by bringing that up for discussion additionally to the other 2 keys. Getting rid of a duplicate key in OSM is quite difficult enough - trying to eliminate 2 at the same time becomes a real task.

So the first point is to deprecate water_volume in favour of water_tank:volume and I understand there is some support for this step.

The next question would be if water_tank:volume should be deprecated in favour of capacity which is the more generic and much more used key (3.2 million). No objection from my side.

Hello @Map_HeRo

I don’t understand to what it refers in your sentence. Are you saying that water_tank:volume is intended to state the actual volume in the tank in [0; capacity] interval? (I guess not but just to be sure)

We could process the two semantics questions here and take necessary according actions in replacement afterwards, depending on where the consensus is.

Missing the opportunity to use the existing generic key is also costly for the future.

capacity related to a tank has been used to express “This is a tank being capable of holding xx m³ of anything”. It could be empty or full or anything in between.

water_tank:volume related to emergency=water_tank has been used to express “Here is a water reservoir with xx m³ of water for emergency purposes”.

This is just what I understand out of the usage of those keys, it is not defined or documented anywhere. And I have not been the one to introduce these keys, so I am just guessing.

The more different keys are affected and the more often these keys have been used the more difficult it is to achieve a consensus. I am the first one to vote for cleanup of duplicate keys and if it would be my decision alone I would eliminate both water_tank:volume and water_volume in favour of capacity without hesitation but I still believe the politics of the small steps causes less resistance than putting a lot of issues in one basket.

To me, these are the same sentences from capacity perspective. The guarantee to find the tank filled comes from the emergency class. In developed countries, these tanks are regularly visited and sometimes refilled to ensure of their availability when needed.

It’s a poor idea (not your idea but the possible usage you mention) to infer criteria in one tag that comes from another one.

This said, even if water_volume has been used to state an availability for crisis management purpose, this information won’t be lost in case of a replacement by capacity. It will still live in emergency=water_tank and it’s a way better tag to state it.

This is a supplementary reason to advocate for a global replacement, in my opinion.