<div dir="ltr"><div>To my way of thinking, a tag in the relation implicitly applies to every member of the relation. It's not "visible" to us mappers but it's there nonetheless. It's my belief that tagging every way with the identical tags  present on the relation is to ensure that the object will render. If our software isn't clever enough to understand that each way in a pipeline route relation should actually be treated (rendered) as though it had the tag man_made=pipeline, that's a limitation of the software doing the interpretation. IMO, due to those limitations, people chose an easy workaround. They applied tags they consider important to each member way. That practice has become the de facto standard. I've done it myself. Yesterday Gerd showed me that even <span class="m_6382372498132881096m_-5466910749228953004gmail-gr_ m_6382372498132881096m_-5466910749228953004gmail-gr_1258 m_6382372498132881096m_-5466910749228953004gmail-gr-alert m_6382372498132881096m_-5466910749228953004gmail-gr_spell m_6382372498132881096m_-5466910749228953004gmail-gr_inline_cards m_6382372498132881096m_-5466910749228953004gmail-gr_disable_anim_appear m_6382372498132881096m_-5466910749228953004gmail-ContextualSpelling" id="m_6382372498132881096m_-5466910749228953004gmail-1258">mkgmap</span> can be persuaded to render a pipeline as such even if the ways are untagged (the original cause for this discussion) but it involves a trick. A directive in the style sheet sets the man_made=pipeline tag on every way in order to force it to render. Thus, the software uses the same approach as most OSM mappers have used over the years.<br></div><div><br></div><div>Yves advises me to keep it simple. That is exactly what I'm trying to do. Having 280 ways all with the same tags as the top level relation of which they are members is complicated and totally unnecessary. Keeping the tags that apply to the entire route, be it a pipeline or a bicycle route, on the relation and not on every way, is simple and more efficient. Database developers avoid the sort of data replication we see on the TAPS (and many other relations) like poison. That's because keeping all those tags synchronized is arduous and error-prone. Those developers devised schemes to store data in such a way that no data is duplicated.</div><div><br></div><div>If you can bear with me, let's take as an example a database containing a table of names and addresses. Now we want to include their children in the database. So we add a table containing a list of those persons' children. That table must somehow be able to show which child has which parent. The deceptively simple approach would be to include the parent's name with each of the children's records. And that approach does work, for a while. But then a parent remarries and acquires a different surname. The database maintainer must now find each child record that contains the outdated last name and edit it. Instead, every database uses a special field called an index, a number, that gets assigned to each parent. Every child in the database is linked to her parents via this ID, which never changes. Now, when a parent's surname changes the maintainer only need to change it in her record. Her children are still connected to her through her ID.  This is the reasoning behind the "relational database" of which there are countless examples. OSM "relations" (do any of you think the name "relation" for this data structure was an accident?) are almost exactly the same sort of thing and, I believe, serve the same purpose. The relation is the master of all, the top level data structure for a pipeline or railroad, what have you. It tells us that all of its members are related in some way, sort of like the ID in the top-level table, and it also offers an elegant way maintain the relationship between itself and its members. Adding tags to every way is exactly the same as adding the parent's name to each child's record. It's messy, error-prone, and unnecessary.</div><div><br></div><div>Another part of the problem is the Wiki that we treat as our bible. Unfortunately, it doesn't offer us much guidance on topics like this.  Fragments about relations and multipolygons are scattered here and there, some written fairly well, others not. OSMers aren't technical writers, and there is no overriding authority to make sure things are written clearly and concisely. It's written in English, which is a problem for those who aren't native English speakers. Gerd started a second thread about pipeline routes yesterday and provided two references to check. Reading through them leaves me wondering just what was meant.<br></div><div><br></div><div>(1) <a href="https://wiki.openstreetmap.org/wiki/Tag:route%3Dpipeline" rel="noreferrer" target="_blank">https://wiki.openstreetmap.org/wiki/Tag:route%3Dpipeline</a><br>(2) <a href="https://wiki.openstreetmap.org/wiki/Relation:route" rel="noreferrer" target="_blank">https://wiki.openstreetmap.org/wiki/Relation:route</a>

</div><div><br></div><div>Neither of those references is very specific or very clearly written. Under the heading How to Map in reference [1] is the following:<br><br>Create a relation of the type route and add the tag route=pipeline.<br>You can add additional tags which are used together with man_made=pipeline.<br><br>It says "you can add additional tags which are used together with man_made=pipeline".<br>Additional tags can be added where? The writer doesn't say. And the tag man_made=pipeline. Where does that go?<br><div>I reckon it's up to you. The writer doesn't say.</div><div><br></div><div>Reference [2] is also, not very clearly written and certainly not definitive in any way. In the section under Route Types the writer gives in the Comment column as examples for route=pipeline these three:</div><div>pipelines, pipeline markers, and pipeline stations. The first one is obvious but the second and third? What would a route of pipeline markers be? What about a route of pipeline stations? One wonders where these examples came from. An email list? Or are they just reasonable guesses made by someone who was pressed for time and wasn't very thorough in vetting the choices he left us?</div><div><br></div><div>It's no wonder we're confused about pipeline routes. <br></div><div><br></div><div>That said, I need to get back to my mapping projects. I've tried everything I can think of to justify my actions and it's wearing me out. I promise not to change any of your previously tagged ways on relations. You guys can continue to tag the ways on relations if you wish. I'll wait patiently for the day when map products fully understand what a relation is and can render it properly without tagging each and every member way.</div><div><br></div><div>Respectfully,</div><div>Dave<br></div><div><br></div>

</div></div><br><div class="gmail_quote"><div dir="ltr">On Thu, Nov 8, 2018 at 3:55 AM Paul Johnson <<a href="mailto:baloo@ursamundi.org" target="_blank">baloo@ursamundi.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_quote"><div dir="ltr">On Wed, Nov 7, 2018 at 2:07 PM Yves <<a href="mailto:yvecai@mailbox.org" target="_blank">yvecai@mailbox.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div>Agreed with Martin here, I would be amazed that the name of a pipeline would contradict the name of one of its section being something else than a pipeline.<div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0pt 0pt 0pt 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div></div></div></blockquote></div></div></blockquote><div><br></div><div> I'm not super familiar with them compared to railroads, but similar naming conventions exist.  Branches and trunks often have differing names while being part of the same overall pipeline.</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_6382372498132881096m_-5466910749228953004m_-1133999141480264148gmail_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>