<div dir="ltr"><div>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.<br></div><div><br></div><div>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.</div><div><br></div><div>Respectfully,</div><div>Dave<br></div></div><br><div class="gmail_quote"><div dir="ltr">On Fri, Nov 2, 2018 at 8:44 AM Allan Mustard <<a href="mailto:allan@mustard.net">allan@mustard.net</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div text="#000000" bgcolor="#FFFFFF">
<p><font face="Helvetica, Arial, sans-serif">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.</font></p>
<p><font face="Helvetica, Arial, sans-serif">Please don't go to the
Turkmenistan map and delete all my hand-entered tags on the
highways!</font></p>
<p><font face="Helvetica, Arial, sans-serif">Allan Mustard</font><br>
</p>
<br>
<div class="m_-5602228081709250477moz-cite-prefix">On 11/2/2018 5:04 AM, Dave Swarthout
wrote:<br>
</div>
<blockquote type="cite">
<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" target="_blank">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="m_-5602228081709250477gmail_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>
<br>
<fieldset class="m_-5602228081709250477mimeAttachmentHeader"></fieldset>
<br>
<pre>_______________________________________________
Tagging mailing list
<a class="m_-5602228081709250477moz-txt-link-abbreviated" href="mailto:Tagging@openstreetmap.org" target="_blank">Tagging@openstreetmap.org</a>
<a class="m_-5602228081709250477moz-txt-link-freetext" href="https://lists.openstreetmap.org/listinfo/tagging" target="_blank">https://lists.openstreetmap.org/listinfo/tagging</a>
</pre>
</blockquote>
<br>
</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>