>
> 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
> source.
>
I get your point. However, I don't think that switching the namespace is a
good solution since it breaks encapsulation. Interesting, you didn't make
this remark about "water_source=potable", though it's similar. Anyway, what
about adding
water_source:water_property = sparkling,
and allow a combination similar to multiple highway lanes, e.g.
"water_source:water_property = sparkling | radioactive" ?
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.
>
Sorry, I think I expressed myself badly by having mixed alternatives and
levels. "needs boiling" should explain the value "conditional", not
"why-non-potable". Similarly, your data about concentration and type of the
contamination would explain the value "potable=no"
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.
>
Clear. However what if another top-level tag is missing? One could use
water_source alone (if I understand correctly, OSM doesn't enforce any
combination of tags). Therefore it should be possible to write all
properties within this tag. But of course, the software can help the mapper
by adding the reasonable tags when the user chooses amenity=fountain.
It looks like we have covered most of the necessary topics. I still see one
gap: what about water drinkable for animals but unsuitable for humans? I
suggest adding another value like "water_source=conditional +
water_source:conditional=animals_only". However I suggest discussing the
remaining questions during voting and or later. The main conclusions I
propose to vote on are:
- deprecate the tag "amenity=drinking_water"
- introduce new top-level key "water_source"
- the values will be "potable", "nonpotable", "yes" (for unknown potability)
- introduce the optional subkey "water_source:potable" with the values
"yes", "conditional"
- introduce the optional subkey "water_source:water_properties" with the
combinable values "sparkling", "radioactive", "contaminated"
- introduce the optional subkey "water_source:type" with the values "well",
"tap", "spring" etc. Its use is discouraged in case another top-level tag
is used, which sufficiently defines the type of the water source
(water_well, fountain etc.).
Further subtags and values may be added as needed.
- keep in use the tags:
natural=spring
natural=water
amenity=water_point
man_made=water_well
waterway=water_point
and recommend to amend them with water_source if appropriate.
Unless there are serious objections (I'll wait a couple of days), I suggest
to start the voting, and we can discuss additional subkeys and values
later, once the key is introduced. During voting, we can also clarify some
things on the main proposal, by removing/replacing some values and wording.
cheers,
Kotya
_______________________________________________
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging
