[Tagging] How to tag named group of named water areas?
kevin.b.kenny at gmail.com
Thu Nov 8 19:09:44 UTC 2018
On Thu, Nov 8, 2018 at 5:38 AM Dave Swarthout <daveswarthout at gmail.com>
> Also agreed.
> I'm not saying anything about the route tag. We're talking about tags
> other than route or type, which actually set up the relation. The
> additional tags that describe the route or multipolygon either go on the
> relation or the ways depending on their scope, but not both.
Rather than 'depending on their scope', depending on the object to which
Your choice of 'operator' as an example is a good one. Here's one where,
if I had chosen to tag operators, I'd have three different operators, one
for an underlying way and one for each of two relations.
First, there's the way: https://www.openstreetmap.org/way/20165067 .
That's where 'highway=secondary surface=asphalt etc.' goes: on the physical
way. The routers and renderers depend on this. Also, because of various
issues with data modeling, 'ref=*' sort of has to be there, but that's a
whole other discussion. If I were to put an operator=* on the way, I'd put
Schoharie County Highway Department. That's who plows the snow, paints the
lines and fixes the potholes.
Next, there's the road route relation:
https://www.openstreetmap.org/relation/411906 . That's a road route. It
gets "network", "ref", "symbol" and there's a Wikipedia entry for it. If I
were to put an operator on it (I haven't) it would be "New York State
Department of Transportation." That's who established that numbered route,
and that's who allocates money for the county to maintain it, and that's
who establishes the standards for a third-class state reference route.
Finally, there's a piece of trail there.
https://www.openstreetmap.org/relation/6198493 (I know for certain that
it's mismapped, the on-road section is shorter than what's on the map, but
I haven't been able to make time to get up there and fix it, and that's not
the point! By the way, the guidebook is also wrong.) The trail is simply on
the paved shoulder of the road at that point. If I'd tagged the operator of
that route, it would be the New York/New Jersey Trail Conference. That's
whom to get in touch with if there's a problem with visibility of waymarks,
or a higher-level problem with the routing. (Which there definitely is,
that's a dangerous place to have the trail, and the operator is trying to
fix it, but negotiations with the landowners proceed at a snail's pace.)
For convenience, that relation is in turn part of a larger route relation
https://www.openstreetmap.org/relation/919642 - this may be a mild abuse,
having a route as a member of a route, but the renderers such as Waymarked
Trails consume it happily. This breakdown is done because the route is
highly fragmented, and having hundreds or thousands of ways in a single
route relation is pretty unmanageable. All of the member relations
duplicate the full tagging of the parent, so that if a data consumer cannot
handle hierarchical nesting of routes, everything will still work, and the
route will simply be 'Long Path (Schoharie County)' instead of 'Long Path'.
So -- a physical attribute (highway=*, surface=*, building=*, bridge=*,
whatever...) always goes on a physical object (a node, way, or
multipolygon). Relations other than multipolygons are not physical objects,
but conceptual groupings. They get the attributes that belong to the
groupings - name, operator, contact information, network, reference,
Wikipedia, website, .... They do not get attributes of the physical objects
that compose them - those attributes belong to the objects and are not
generally understood to be inherited from the relation.
I think you you may have been confused because multipolygons are such a
powerful concept once you 'get it' - and physical tags on multipolygons are
Just Fine since multipolygons are physical objects. But multipolygons are a
special case among relations. (The older scheme for tagging riverbanks is
another special case, but I consider it to be a legacy, and do not use it
for new mapping work.)
Specific types of relations may have further constraints. I can't speak to
public transport ones (since I don't map them). The only relations I use
are multipolygon, route (road, walking, hiking, horse, bicycle, ski,
snowmobile), boundary, and very occasionally a group (which I realize has
no recognized rendering but I don't know how else to tag the things). I do
waterways as multipolygons (one of several recognized ways to do them). I
don't do the networks for rail, power, or pipeline infrastructure - I map
the physical objects when I come across them in the field and consider them
significant landmarks, but don't try hard to tie them into the networks -
I'll leave that for someone else. I don't map complex traffic regulations
at all. For this reason, I can't speak to the specialized relations that
are used in these things, but I strongly suspect that they follow similar
rules of 'physical tags only on the physical objects and relations tagged
with only those attributes that conceptually belong to the collection.'
To the best of my knowledge, no data consumer presumes that all attributes
are inherited from general relations onto the components. (Multipolygons,
of course, are a beast unto themselves.)
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Tagging