On Thu, Nov 8, 2018 at 5:38 AM Dave Swarthout <daveswarth...@gmail.com> wrote:
> 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 they belong. 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.)
_______________________________________________ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging