<div dir="ltr"><div>Putting aside the discussion about type for a moment, this topic relates to a discussion I'm having with a user about tags and multipolygons, specifically where the tags go, so I believe it fits into this discussion. I removed the tags from the ways for a section of the Trans Alaska Pipeline (TAP) because those same tags were on the relation itself. The user asked in a changeset comment why I had done that. I replied that IMO, any tags that applied to the pipeline as a whole belong on the relation and need not, indeed should not, be repeated on each way. The TAP is 1300 km long, has countless bridges and sections where it is underground and then overground. The only tags that should appear on the ways themselves are attributes of those ways, for example, location=overground or location=underground, and tags for bridge and layer. Everything else, Wikidata, substance=oil, man_made=pipeline, etc, should appear only on the relation. The folks who added the pipeline mostly via Tiger imports many years ago tagged both. When I would occasionally add or replace a section, I was always careful to copy all the tags from a neighboring section to the new section. Now, I think that is incorrect.<br></div><div><br></div><div>If those tags appear on each way in addition to the relation, maintaining any consistency in the tagging on this beast would be almost impossible. I have done quite a bit of re-aligning of the TAP over the years as our available imagery improves but have always been tentative about removing those redundant tags thinking I would get around to it someday. In fact, it seems apparent that this is one major reason relations were invented, especially for objects like routes — to ensure tagging consistency and connectedness between the many individual member ways that comprise the whole.<br></div><div><br></div><div>So, what is the correct and accepted way to tag something like the TAP?</div><div><br></div><div>Dave<br></div></div><br><div class="gmail_quote"><div dir="ltr">On Sat, Oct 13, 2018 at 7:17 AM Kevin Kenny <<a href="mailto:kevin.b.kenny@gmail.com">kevin.b.kenny@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="auto"><div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">why not a multipolygon? I agree that you don’t need additional tags for a group relation, just type=group, a name and the members, but for a site you would need something that describes the site, a tag for a group of water areas, so as long as all the members are areas (or parts), a multipolygon would be better.<br></blockquote></div></div><div dir="auto"><br></div><div dir="auto">When the lakes themselves are complex multipolygons with many islands, repeating that data for the group is likely to be a maintenance nightmare. (I know this from curating boundary=protected_area relations that include partial shorelines on such lakes. It's especially fun when the boundary splits islands.)</div><div dir="auto"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
</blockquote></div></div></div>
_______________________________________________<br>
Tagging mailing list<br>
<a href="mailto:Tagging@openstreetmap.org" target="_blank">Tagging@openstreetmap.org</a><br>
<a href="https://lists.openstreetmap.org/listinfo/tagging" rel="noreferrer" target="_blank">https://lists.openstreetmap.org/listinfo/tagging</a><br>
</blockquote></div><br clear="all"><br>-- <br><div dir="ltr" class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr">Dave Swarthout<br>Homer, Alaska<br>Chiang Mai, Thailand<br>Travel Blog at <a href="http://dswarthout.blogspot.com" target="_blank">http://dswarthout.blogspot.com</a></div></div>