[Tagging] cave_entrance. ref and name

Kevin Kenny kevin.b.kenny+osm at gmail.com
Mon Aug 29 18:25:28 UTC 2016

On Mon, Aug 29, 2016 at 11:20 AM, Martin Koppenhoefer <
dieterdreist at gmail.com> wrote:

> > Why? Is there a new trend to avoid relations at all cost?
> it's actually an old rule. Relations, being expensive, should be avoided
> where not necessary. They are also less reliable, because you can easily
> add tags for the cave to the entrance without finding the cave object, but
> to add them to a cave relation you will have to find the relation first
> > I would be delighted if we could do that with landcover multipolygons..
> and maybe we should?
> it's up to you. Landuse and landcover should IMHO be mapped as small as
> reasonable, inner members are usually not necessary when you split stuff
> into small pieces. Those are more lightweight and easier to modify/improve.
> On the other hand there's still use for MPs to avoid overlapping edges:
> every landuse will have a neighboring landuse, in hilly terrain (e.g.)
> those can have a lot of nodes.

I'd argue that in the last few years, the relation management in tools such
as JOSM and Meerkartor has improved to the point where "relations are less
reliable" is a rule suitable only for the rawest of beginners or the
simplest of meshes. Perhaps my experience has been different from most,
because I live and recreate in just those hilly areas.

I find, where I've been working, that landcover sometimes, but not always,
follows landuse; and landuse sometimes, but not always, follows cadastre
(boundary=national_park, boundary=protected_area) Moreover, leisure=park
and leisure=nature_reserve and similar things intersect with those in
complex ways. I find that I wind up creating multipolygons for my own
sanity, even where I could create a compact polygon by tracing adjacent
ways. I'm much more comfortable splitting a shared way than I am tracing an
adjoining polygon that shares hundreds of nodes, and find the process LESS
error-prone, because I'm not going to skip a node inadvertently.

Then again, I've just come off a project that involved tidying the topology
of complex administrative boundaries like
http://www.openstreetmap.org/relation/6362702 - so I suspect that my
experience isn't typical. Don't blame me for the resulting mess: I didn't
draft the administrative boundaries. The complex topology is enfolded in
equally complex issues of public policy.

Don't get me wrong. I'll use a polygon where a polygon will do the job (
http://www.openstreetmap.org/way/422887495) - but in the areas where I'm
working, simple topologoes like that are relatively rare. Even where they
exist, more often than not they share line strings with lovely topologies
like the one on the other side of the reservoir:
http://www.openstreetmap.org/relation/6364894. Physical features tend to
have that level of complexity (waterways have bays and islands; mountain
ridges run in complex branches, and so on). I tend to assume that cadastre
will be equally complex, land use nearly as complex, and land cover highly
variable (trees and beavers are no respecters of property lines).

This leads to some pretty odd overlapping multipolygons at times:
http://www.openstreetmap.org/relation/6385235. If I'm going to preserve the
fact that Crary Mills State Forest is a single administrative unit, all
managed for forestry, with pubic access for recreation (but with varying
actual landcover, since there are marshes, scrub lands, power and
transportation corridors within it), I'm going to wind up with something
that's tricky to edit. It's surely untidy, but that's the world I inhabit.
I map what I find, and I use the features that I think most accurately
represent it.

Incidentally, I have a very strong preference NOT to share ways between
land cover and land use, unless the land cover very obviously follows the
formal boundary (and often not even then). It makes the common case where a
natural feature crosses a property line much easier to deal with if I don't
have to interrupt the natural feature at the administrative boundary.

No doubt I'm doing it all wrong.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstreetmap.org/pipermail/tagging/attachments/20160829/7e8a6454/attachment.html>

More information about the Tagging mailing list