Allan, I'm not about to remove any tags from the highways in Turkmenistan. This isn't about an edit war. It's about trying to do things in the most efficient way possible. Using your highway as an example, let's say it has dozens of segments, each tagged with ref and other items as you indicated. Now let's say the ref changes. Someone must go in and retag every piece of your highway system; every bridge, every tunnel and every section that has a different number of lanes, a different maxspeed, or a different "local" name. It's a tricky operation at best and easily avoided. Because if that ref tag appears only in the relation, changing it involves only one edit, that of the ref tag inside the relation. The tags you're using on individual pieces of the highway are fine. I'm not saying you shouldn't continue to do what you have been doing. I'm only asking what is the correct way.
Also, whether the relation renders the way one desires or not shouldn't be part of this discussion. We all want the stuff we map to be visible on the map products we use. But if certain relations aren't showing up on maps it's the map products that need to be fixed rather than our tagging methodology. Respectfully, Dave On Fri, Nov 2, 2018 at 8:44 AM Allan Mustard <al...@mustard.net> wrote: > 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> > 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 >> https://lists.openstreetmap.org/listinfo/tagging >> > > > -- > Dave Swarthout > Homer, Alaska > Chiang Mai, Thailand > Travel Blog at http://dswarthout.blogspot.com > > > _______________________________________________ > Tagging mailing > listTagging@openstreetmap.orghttps://lists.openstreetmap.org/listinfo/tagging > > > _______________________________________________ > Tagging mailing list > 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
