I don't see a problem with duplicating a tag in both the relation and sections of the object. In my case I have been mapping the national highway network of Turkmenistan the last few months. I have created relations so that all segments belong to one or more highways (P-1 from Ashgabat to Koneurgench, for example). However, most map renderers will not indicate that, plus the road is known to locals in most areas by that name, so I have also added it to the name=* and ref=* tags. Too much data? I don't think so. Each tag serves a slightly different purpose, and the relation serves a wholly different purpose and is not visible in most map products.
Please don't go to the Turkmenistan map and delete all my hand-entered tags on the highways! Allan Mustard On 11/2/2018 5:04 AM, Dave Swarthout wrote: > 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. > > 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. > > So, what is the correct and accepted way to tag something like the TAP? > > Dave > > On Sat, Oct 13, 2018 at 7:17 AM Kevin Kenny <kevin.b.ke...@gmail.com > <mailto:kevin.b.ke...@gmail.com>> wrote: > > 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. > > > 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.) > > _______________________________________________ > Tagging mailing list > Tagging@openstreetmap.org <mailto:Tagging@openstreetmap.org> > https://lists.openstreetmap.org/listinfo/tagging > > > > -- > Dave Swarthout > Homer, Alaska > Chiang Mai, Thailand > Travel Blog at http://dswarthout.blogspot.com > > > _______________________________________________ > Tagging mailing list > Tagging@openstreetmap.org > https://lists.openstreetmap.org/listinfo/tagging
_______________________________________________ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
