[Tagging] Feature Proposal - RFC - Water tap

Martin Koppenhoefer dieterdreist at gmail.com
Wed Dec 3 13:30:46 UTC 2014

2014-12-02 21:50 GMT+01:00 Kotya Karapetyan <kotya.lists at gmail.com>:

> On Tue, Nov 18, 2014 at 11:11 AM, Martin Koppenhoefer <
> dieterdreist at gmail.com> wrote:
> I see hierarchy and encapsulation of tags as the means to achieve these
> three goals. That's why I also would like to avoid going "outside" the tag
> by using water:* and stick to water_source:*
>>> water_source:sparkling=yes | no | unknown
>> in analogy: "water:effervescent" (or ~:sparkling)
> I don't mind using the word "effervescent"; however: is there any
> recommendation that we should use as "simple" words as possible, to achieve
> the above goals 1 and 3? I know this for scientific papers and am trying to
> stick to it in all inherently international situations.

I believe that "water_source:sparkling" is not the same as
"water:sparkling", because it is the water that is sparkling, not the water

>>> water_source:nonpotable=compromised | designated
>> could maybe be integrated in the quality-tag?
> Could you give an example?

yes, you'd have
"water:quality" and values potable | mineral | DE:heilwasser | nonpotable |
compromised | biohazard etc.
(values for illustrational purposes and not well thought through)
I agree, if you want to say why you think that the water is not potable
(i.e. your source, what you want to express with "designated") than this
scheme doesn't work, unless you'd have another tag for this, like

> Again, I'd like to go level-wise:
> what is it? water source is it potable? yes/no/conditional why is it
> non-potable? compromised/designated why conditional? needs boiling etc.

"needs boiling" is not the next sublevel of
1 potable=no
2 why-non-potable=compromised

it is another way of looking at this ("how can the water be made potable")

3 would be something like: what is the concentration of the contamination,
what type of contamination is there, etc.

In principle, details regarding the kind of water source could be provided
>> here as well, to free up the top level a bit and help data users:
>> water_source:type = tap | fountain | well | spring
> or have this inherited from the main tag (e.g. amenity=fountain,
> man_made=water_tap, natural=spring, man_made=water_well

I agree in general, but I do not know how inheritance works in OSM. Where
can I read about it?

it doesn't "work in OSM", it works at the data consumer side by
interpretating the data, when there is an object "amenity=fountain" than it
is clear that the water_source:type is a fountain, no need to duplicate
this information in a nested water_source sub-tag.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstreetmap.org/pipermail/tagging/attachments/20141203/6f239d92/attachment.html>

More information about the Tagging mailing list