[Tagging] How to tag named group of named water areas?

Kevin Kenny kevin.b.kenny at gmail.com
Sat Nov 3 14:34:02 UTC 2018

On Sat, Nov 3, 2018 at 9:45 AM Dave Swarthout <daveswarthout at gmail.com>

> (*BOLD TEXT* is my addition) This is exactly what I've been saying*.
> Member ways should be untagged unless they have a separate meaning on their
> own. *
> There you have it. It's a logical system of tagging and makes perfect
> sense both from an initial standpoint and for ease of maintenance later on.

That's surely true of multipolygons.

At this point, except for the margins of [multi]polygons, the data model
doesn't really contemplate ways that need to be broken up because of size,
so to some extent you're breaking new ground here. In the road network,
what everyone does is just to split the way and repeat the tagging. Then,
anything like marked routes gets added atop the split ways, with only the
tags that pertain to the route.  Those tags don't get repeated on the way.
(An exception is ref=*, which doesn't work correctly in many renderers if
it is not on the way.) A better description might be that 'if a tag
conceptually would have an independent meaning on the member ways, it goes
on the member; if it logically pertains only to the collection, it goes on
the relation." For multipolygons, this is obvious - everything belongs on
the relation unless the way is being used independently, for instance, if
two administrative regions are divided by a road or stream.

This does add complexity if you're trying to analyze a long chain of ways
that shares a common characteristic.  It's a little tricky to follow
'Broadway' from the Battery in New York City to Sleepy Hollow in the Hudson
Valley, because everything changes about the ways (Even the name is not
100% consistent; there are variants like 'Old Broadway', 'New Broadway',
'South Broadway', and so on.)

Even the 'tag the collection attributes only on the relation' rule has a
couple of exceptions, but they're rare. They relate to the fact that
support for site and group relations, and routes-inside-routes ranges from
uncommon to nonexistent. Long and complex routes with many hundreds of
constituent ways are typically broken up into routes-inside-routes, so that
there are no more than a few dozen to a few hundred ways in each piece.
Examples include the New York Long Path
https://www.openstreetmap.org/relation/919642 and the Appalachian Trail
https://www.openstreetmap.org/relation/156553 (which seems to have picked
up a few problems; the top-level relation isn't supposed to have any ways,
only the subrelations). Because of the difficulties with
route-inside-route, group and site, it's easiest on these beasts to repeat
the tagging that appears on the top relation on each of the member
relations as well.  Waymarked Trails understands this sort of structure,
and can do both rendering and elevation profiling if the structure is done
right (For instance, the 'forward' direction in each of the subrelations
must match, and the subrelations must also run 'end to end': on both the
trails I list as examples, they run south to north).
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstreetmap.org/pipermail/tagging/attachments/20181103/ceb89375/attachment-0001.html>

More information about the Tagging mailing list