[Tagging] Feature Proposal - RFC - Water tap
dieterdreist at gmail.com
Mon Oct 20 10:41:57 UTC 2014
2014-10-18 23:20 GMT+02:00 Konstantin Karapetyan <kotya.lists at gmail.com>:
> I have already corrected the proposal from man_made to amenity following
> the suggestion at
> So this is fixed.
IMHO this doesn't fix it, because it now becomes incompatible to be tagged
on a node with amenity=drinking_water. If the value shall remain a generic
"water_tap" I'd stick to man_made to keep these compatible (see also
man_made=water_well for instance, which is a similar feature somehow).
Please note that amenity=drinking_water is highly introduced and used by
many data consumers. This is an established tag that is used for almost
seven years now.
> As for the clash with amenity=drinking_water: I see it, but I think there
> is an advantage of having yet another tag:
> - amenity=drinking_water can be used as an attribute where the presence
> thereof is non-obvious. E.g., for amenity=toilets. A water_tap is a
> separate object, and a combination amenity=water_tap + drinkable=yes would
> provide for a more specific mapping, where appropriate.
you can't use amenity=* as an attribute to something different with a tag
You could use drinkable=yes as an attribute, but this will be strange on
toilets and is redundant on drinking_water.
> - The combination drinking_water + drinkable=no is indeed quite confusing
> and has already caused a few discussions (
> water_tap would help clarify.
yes, it is not only confusing, I'd call it "wrong". It shouts out for
problems. Its similar to amenity=toilets with access=private (but worse, in
short, it is contradictive).
> - amenity=drinking_water is not always a tap, it can be a fountain, a
> well, a tap in a WC again; it can be used quite generally, without
> additional thinking.
most cases I am aware of are indeed taps, because fountains are in the
amenity namespace as well and will likely be tagged as such with
drinkable=yes, a well would be man_made=water_well and could have
amenity=drinking_water as combination (but there would be no need to
clarify, it would already be clear that it is a well).
> In some cases, there may exist uncertainty as to how to tag a feature, but
> it's certain that potable water is available there. This tag fits well in
> such situations. water_tap provides similar clarity when the object is
> clearly there but the mapper doesn't know the type of water.
for my main usecase it will not be clear if water_tap applies. I am talking
about structures like these:
that's basically a water_tap in a cast iron enclosure. Typically you'd need
a special key to get access to the valve, but sometimes they are open. Some
do not provide constant flow but require you to operated a turning valve or
a push button. Also fountains typically do have some closing measures,
typically not publicly accessible.
> It may be difficult to imagine the abundance of such situations for the
> West Europeans and Americans; but I come from Russia, where this situation
> is very typical. I've met it in other developing countries as well.
> Especially in the warm countries it is important not to confuse a source of
> water with potable water. Quite a few people I know from developed
> countries have suffered badly because they didn't realise there was a
I do agree here. You could add drinkable=unknown. My suggestion would be a
generic tag for a water source that is either unknown to be drinkable to
known not to be drinkable. (e.g. "raw_water_tap" or similar), could be
combined with drinkable=unknown.
> - Map software often simply shows an icon without giving access to
> additional attributes. In that case a user may have no chance of seeing
> drinkable=no for drinking_water. The symbol for drinking_water —
> — is very clear, and the contradiction may lead to quite unfortunate
yes, we should generally agree on not using A=B and C=D where those are not
compatible. Subtagging is to used to refine something, not to change the
meaning of other tags.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Tagging