[Tagging] RFC #2: Lake, pond, and reservoir proposal

Kevin Kenny kevin.b.kenny at gmail.com
Mon Jan 3 16:06:25 UTC 2022


I'm all in favor of deprecating landuse=reservoir in favor of natural=water
water=reservoir. There is often not a clear distinction between the two.
Even the presence of a man-made dam is not an entirely reliable indication
around here, since many natural water bodies have had their water levels
slightly raised or stabilized by human intervention.

I recall that back when I joined the project, there was quite a controversy
stemming from a claim that natural=water could be applied only to 'natural'
water, that is, water that would have been where it is without human
intervention, and a different tag _must_ be used for 'artificial' water.

As a mapper, I'm still not enough of a Platonist to appreciate that
argument, and I'm glad that we've made a fair start at moving beyond it. I
should surely be able to see with my own eyes, "there is water here" and be
able to map the water that I see without needing to do further research
into its provenance. I recall hearing one mapper argue, "If you don't know
the answer to that, don't map it!"  That's tricky: even if I spot an
earthen dam in aerials, I don't always know whether it's the work of Homo
sapiens or Castor canadensis - and it may be both. The woods about here
have many abandoned logging ponds that are gradually returning to nature,
and the beavers adopt some of them. I've seen beavers making repairs to an
earthen dam originally installed by lumbermen.

As a data consumer, I think of 'landuse=reservoir' as a weird case. In one
rendering that I do, I have a catch-all rendering for 'other land uses'
that's handy for 'a mapper has tagged a land use here, but my renderer
doesn't recognize it." I need a special case for `reservoir` among others
to be able to denote 'this is actually a water feature, not a land feature
at all.'  I have a strong preference for a tag schema that allows
general-purpose maps to work off high-level tags without needing to plunge
into fine distinctions. A highway map would probably find it useful to have
'natural=water' mean, "paint it blue"; a highway map user almost certainly
doesn't care whether the water is fresh or salt, or how it came to be
there. A hiking map may find it useful to indicate salt or brackish water,
or water with chemical contaminants, differently. A canoe map local to me
might need to indicate whether the water is natural or impounded, since
there are some subtle legalities surrounding navigation. But I have real
trouble coming up with any use where the first distinction to be made isn't
"this is dry land; that is water" (Yes, I know that there may be wetlands
in between; Nature seems to disfavor sharp boundaries).

There may be a more-or-less important and more-or-less fuzzy distinction to
be drawn among 'lake', 'pond' and 'reservoir', but for many of my uses, I
don't need to draw that distinction. If permanently submerged areas are all
'natural=water', I don't need to care about a distinction that is important
only to someone other than the user of a map I'm making.

I know that the 'landuse=reservoir' tag will be with us for quite a while
yet, but let's at least move things in the right direction.

On Mon, Dec 13, 2021 at 11:10 PM Brian M. Sperlongano <zelonewolf at gmail.com>
wrote:

> Hello,
>
> I am re-starting an RFC for my proposal[1] for lakes, ponds, and
> reservoirs.  This proposal deprecates landuse=reservoir in favor of
> natural=water + water=reservoir, and adopts improved definitions for lake,
> pond, and reservoir.  This proposal was first proposed[2] around this time
> last year, in which I received and incorporated significant feedback.
> Given the large gap in time since this was last discussed, I am opening a
> second RFC period in order to allow for any renewed discussion.
>
> [1] https://wiki.openstreetmap.org/wiki/Proposed_features/Reservoir
> [2]
> https://lists.openstreetmap.org/pipermail/tagging/2020-December/057073.html
> _______________________________________________
> Tagging mailing list
> Tagging at openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging
>


-- 
73 de ke9tv/2, Kevin
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstreetmap.org/pipermail/tagging/attachments/20220103/6d1d2f94/attachment.htm>


More information about the Tagging mailing list