[Tagging] RFC - More sensible values for fountain=*

[Davidoskky]

On 11/10/22 10:19, Martin Koppenhoefer wrote:
> this is not a redefinition, it is already like this. 
> man_made=water_tap describes a water tap.

man_made=water_tap is de facto being used to describe larger structures 
that contain a water tap. This wouldn't be a problem if there was a way 
to actually describe those features.


> a feature for washing clothes for me is not a "fountain", it is a 
> lavoir, a laundry sink, or something similar.
Some are indistinguishable from drinking fountains, some have drinking 
water and can be used to wash clothes as well.


> I do not understand what "fountains to clean people" are, could you 
> give an example?
I had a walk the other day, you may look at these two pictures I took.

https://commons.wikimedia.org/wiki/File:Water_fountain_with_water_basin_near_Santiago_de_Compostela.jpg

https://commons.wikimedia.org/wiki/File:Water_fountain_without_tap_near_Santiago_de_Compostela.jpg


> the word "style", if used in opposition to "type", suggests something 
> like "fashion" to me, or art/architectural epoche style (e.g. art 
> deco, modern, post-modern, renaissance, barocco, etc.)
Agreed, style is not a good name for such key.


>> Introduction of the key tap=yes, used to describe if the flow of a
>> fountain can be controlled by the user.
> is already introduced
Not really, tap=yes has 347 uses and it's used only regionally in 
Dominican Republic to tag the presence of taps in a building.

- It is not used to mark the presence of a tap in a fountain

- It is not approved

- It is not documented on the wiki.

Refer here: 
https://lists.openstreetmap.org/pipermail/tagging/2022-October/065939.html


> it is already introduced, 953 instances as of now, but actually it may 
> create problems for example in the case of a "decorative drinking 
> fountain", and because "decorative" is not clearly defined. Maybe this 
> situation could be improved.
Sure, I meant documenting it in the wiki and finding solutions for these 
edge cases. If my idea was already a perfect full blown proposal I would 
have published the proposal already.


> yet another generic type, even more generic then "drinking"?
fountain=drinking is not generic enough, since there are types of non 
decorative fountains that cannot be tagged in any way.

Refer here: 
https://lists.openstreetmap.org/pipermail/tagging/2022-October/065936.html


> my suggestion would be to have other generic values, but slightly more 
> specific than "utility", to cover the cases that are not yet covered 
> by the documented values.
I do agree, and that is also my objective; but I do like the idea of 
having a very generic value you can fall back to when no other value 
applies.


> this alternative tagging is just a temporary hickup which will wash 
> out automatically I guess, but we could try to speed it up.
Sure, but I see no reason for showing it on the wiki.


> On the other hand, people using the same tag for (also only slightly) 
> different things, is a huge problem and leads to ambiguity and cannot 
> be solved automatically, all instances have to looked at again
I understand the problem, but I do not wish to start looking at all 
possible existing fountain types in the world to make an exhaustive 
list. Especially when people here start fighting about the specific name 
of a fountain meant for drinking.


> no it cannot. There are many fountains made of stone, but not all them 
> are instances of "stone block".
The value is ambiguous: it is described as any fountain that consists 
mostly of a stone block. It may be a decorative fountain or a drinking 
fountain or another type of fountain.


As you said:

> using the same tag for (also only slightly) different things, is a 
> huge problem

> Regarding the proposal: I would not make a big proposal package which 
> aims at changing all the things you mention, rather I would suggest to 
> make distinct proposals for each of these changes.
I think I will follow your advice. I'm currently thinking of two 
separate proposals: one for introducing the fountains model (or whatever 
new key we decide to introduce) and another one to introduce tap=* as a 
way to describe the presence of a tap in a fountain. (Please, discuss 
about these things in the thread wherever it is and not here)