<div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div class="gmail_quote"><div dir="ltr">On Sat, Nov 3, 2018 at 9:45 AM Dave Swarthout <<a href="mailto:daveswarthout@gmail.com">daveswarthout@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div>(<b>BOLD TEXT</b> is my addition) This is exactly what I've been saying<b>. Member ways should be untagged unless they have a separate meaning on their own. </b><br></div><div><b><br></b></div><div>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.</div></div></blockquote><div><br></div><div>That's surely true of multipolygons.</div><div><br></div><div>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.</div><div><br></div><div>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.)</div><div><br></div><div>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 <a href="https://www.openstreetmap.org/relation/919642">https://www.openstreetmap.org/relation/919642</a> and the Appalachian Trail <a href="https://www.openstreetmap.org/relation/156553">https://www.openstreetmap.org/relation/156553</a> (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). </div></div></div></div></div></div>