[Tagging] Feature Proposal - RFC - Water tap
kotya.lists at gmail.com
Tue Dec 2 20:50:40 UTC 2014
On Tue, Nov 18, 2014 at 11:11 AM, Martin Koppenhoefer <
dieterdreist at gmail.com> wrote:
> 2014-11-17 23:26 GMT+01:00 Kotya Karapetyan <kotya.lists at gmail.com>:
>> What about introducing a name space:
>> water_source:potable=designated | mineral | heilwasser (I failed to find
>> a good English-language analogue, could someone help please?)
> I'd make this "water:quality" and values potable | mineral | de:heilwasser
> (or an English correspondent if available, or DE:heilwasser because it
> refers to German legislation)
> maybe also add "toxic" / "contaminated"(?), "non-potable"
> not sure about "radioactive"?
If we agree for a change, I would like to make the new tags
- as easy as possible to map: if only minimum information is available,
it's still mappable;
- as easy as possible to use: even if information is limited, it's still
clear; programs would have something meaningful to show in any case;
- as difficult as possible to make mistakes: no unclear information for
users, tag logic clear for mappers.
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.
>> water_source:nonpotable=compromised | designated
> could maybe be integrated in the quality-tag?
Could you give an example? 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
Thereby everyone will find the water (useful at least to wash a car / water
the flowers, but also could usually be drunk after proper treatment). Then
we clearly indicate the most critical parameter. And we go on. If at any
level the data is not available or the data user cannot use it, integrity
is not violated. Basically, it's the XML approach, and it seems to work
>> 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?
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Tagging