Water tap present should tag amenity=drinking_water instead of drinking_water=yes if tap supplies drinking water

[osmuser63783]

Try mapping a tap that supplies drinking water, there are a least two relevant presets: the water tap preset (man_made=water_tap) and the drinking water preset (amenity=drinking_water).

The water tap preset asks if the water is drinkable and sets drinking_water=yes if it is, and =no if it isn't. I would suggest that it should tag amenity=drinking_water instead of drinking_water=yes, if it is drinking water. (It can continue to set drinking_water=no if it isn't.) The fact that the amenity=drinking_water is a tap can be tagged by combining amenity=drinking_water with man_made=water_tap.

Reasons in favour:

• a lot of data consumers expect any drinking water source to have the tag amenity=drinking_water: of the six featured layers on osm.org, five will only show the tap if it has amenity=drinking_water. Only one layer (CyclOSM) will show a man_made=water_tap with drinking_water=yes
• this leads to counterintuitive results: a mapper who used iD to add a water tap that supplies drinking water and used the man_made=water_tap preset, was understandably surprised why their tap didn't show on the map (example)
• in the data, there are 18 916 combinations of man_made=water_tap with amenity=drinking_water and only 7 739 combinations of man_made=water_tap with drinking_water=yes. So amenity=drinking_water seems to be the preferred way of tagging a tap with drinking water
• the amenity=drinking_water Wiki page is clear that a tap that supplies drinking water fits the definition, and the examples show the combination of amenity=drinking_water and man_made=water_tap of amenity=drinking_water. The water_tap page is less clear but in all the tagging examples, when the tag supplies drinking water it always has amenity=drinking_water (sometimes in addition to drinking_water=yes)

Reasons against:

• the only real reason I can think of would be if there's a semantic difference between a "source of drinking water that is a tap" (amenity=drinking_water man_made=water_tap) and a "tap that supplies drinking water" (man_made=water_tap drinking_water=yes), but that seems rather tenuous

I asked the question in the community forum and although there were voices on both sides of the argument, only one person tried to make the argument that the two are semantically different, but no else one agreed with them. Most people agreed the current situation is less than ideal.

[tordans]

I don't think the current schema supports this mapping, does it?

Maybe we could use the deprecation rules as a work around to rework the "wrong" tags after they where added by the field?

[osmuser63783]

The current schema supports adding an amenity=drinking_water but it doesn't ask what the drinking water is from (water fountain, tap, well, spring..)

[tordans]

I just read about the replacement key that might be a solution for this issue.
Maybe someone can try to set this up that man_made=water_tap+ drinking_water=yes triggers the replacement for a new, unsearchable preset of man_made=water_tap+amenity=drinking_water (that would be the desired tagging, yes?)?

[osmuser63783]

Some more discussion shows that it's unfortunately more complicated than I thought at first. Some people are keen to make a distinction between a water tap whose main function is to provide drinking water (amenity=drinking_water) and one whose main function is something else (e.g. watering flowers) but where the water happens to be potable (drinking_water=yes). This is also reflected in the justification for closing the StreetComplete issue I created.

I have my doubts that this distinction is being consistently followed by mappers, but anyway.. would it make sense for the preset to enable mappers to tag either amenity=drinking_water or drinking_water=yes, effectively offering a three-way choice between those two and drinking_water=no?

This would still solve the fundamental issue where people tag drinking_water=yes when what they really meant was amenity=drinking_water.

(I can't comment on how this would be technically feasible as I am not really familiar with deprecation rules, the replacement key etc.)

[tordans]

Hey @osmuser63783 can you link to the SC issue as well, please.

I have to say, I am a bit lost on what we want to achieve here, now.
I am assuming you want to modify existing presets and maybe improve search terms?

Could you share the usecase, you want to optimize and the screenshots that users see now … vs. was should happen.
Eg. User searches for X in iD, sees Y but should also see Z. Selects Y but has no field A…

[osmuser63783]

I think what happens is the following

1. Mapper sees a tap for drinking water
2. Mapper types either “tap” or "water" into the search in iD
3. Mapper selects the "water tap" preset and maybe also ticks the box for "drinkable"
4. Mapper gets confused why most maps don’t show their tap (that's because most maps only show amenity=drinking_water)

Of course you can say that (4) is just a rendering problem: maps could just show man_made=water_tap drinking_water=yes the way they show amenity=drinking_water. But even then the presets are poorly differentiated. It's not clear to the casual iD user that amenity=drinking_water is the better preset for taps that supply drinking water, at least when that is the tap's main purpose. The drinking water preset is barely visible in the search unless you literally type "drinking". (I haven't tested it in other languages but suspect it's similar.)

The SC issue is here: streetcomplete/StreetComplete#5701

[tordans]

Thanks for the details!

It sounds to me, that we should try to get the search priorities sorted. I am not super familiar with this, but I suggest to start a PR and do some testing with the preview that will be generated.

For easy access: The prests:

• man_made=water_tab with field drinking_water=yes|no
• amenity=drinking_water

Things you could try:

• Add aliases https://github.com/ideditor/schema-builder?tab=readme-ov-file#aliases
• Improve the terms https://github.com/ideditor/schema-builder?tab=readme-ov-file#terms
• As a last resort, fiddle with the matchScore https://github.com/ideditor/schema-builder?tab=readme-ov-file#matchscore (but this will have side effects that are harder to fix than adding keywords)