Gerd,
I am not establishing a NEW tagging system for pipelines, I'm merely trying tag it the way that's most meaningful and most correct. The Wiki is quite clear about it, IMO. The concepts apply to ALL relations, not just pipelines. How it looks has nothing to do with it. Nor does sorting.
I've provided two sections of the Wiki that support my argument. Several commenters agreed with my arguments on the thread in the Tagging list. Can you show me any text that says what I did was wrong?

Actually, if a way has a name in the Iditarod Trail route, it's a named road and as such the name would stay on that piece only. Also, those ways might be a track, path, or service road, and have surface=gravel, ground, or ice as well. I repeat, those characteristics belong on the ways and definitly not on the relation. Obviously, the entire Trail is not on gravel service roads, nor is it all on frozen rivers but all those pieces are grouped together under the umbrella of the Iditarod route relation

My removal of the tags on the TAPS follows the same reasoning. Each of its many sections gets it's own tagging, just as do the various different pieces of the Iditarod, except that the only thing that varies is location (under- or overground, and bridges). There is always a pipeline and the tag for it belongs in the relation, along with the operator, the various alternative names, and etc.

I already mentioned the relevant piece of the Wiki in one of my many posts in that thread. Check out the first paragraph under Usage on this page: osm.wiki/Relation:multipolygon
Also, see a similar statement under the heading Islands on the riverbank page:
waterway=riverbank
They both say not to tag the ways except when they have different attributes. Which is exactly what I'm saying.

I think the reason there is no code to handle relations tagged the way I've done it is because people have been doing it incorrectly for many years. Rather than saying what I'm doing is a "exception" let's try to get mkgmap to a state where tagging like this can be dealt with properly.
Best,
Dave

I don't agree. Yuu quoted the Wiki earlier when you stated that the ways should have the same tags as the relation but I found a different place in the Wiki where it agrees with my contention that ways should only have tags when the characteristic or attributes of the way differ from one another. I believe this is not only correct but immensely more efficient.
Feel free to add those tags back but I'm going to continue to map such objects the correct way. I added the entire Iditarod Trail as a route relation and as soon as I have time I'm going to remove the redundant tags from it. Seriously, I'm convinced this method is better. A side note: OSM doesn't render the pipeline even with man_made=pipeline on the ways, however, mkgmap will if you have a matching style. Whether mkgmap would render it if the pipeline tag were only on the relation is a question that you would be able to answer

I think a relation is definitely needed. I doubt it could be feasibly mapped (and maintained) any other format. This thing is 1300 km long, has countless bridges and many sections that are underground or overground — something changes every few miles, and that requires breaking those ways so they can be tagged. Trying to obtain consistent tagging on every one of those myriad pieces would be impossible. But if you use a relation, the tags inside the relation apply to every piece of it.
In fact, this is my interpretation of the reasoning behind having relations for things like routes in the first place. Any tag that applies to every member way goes in the top level relation tag space. Particular characteristics of the individual segments (ways) are tagged only on the way itself. For example, variable characteristics like surface, lanes, or in this case, location or bridge, that might change every few miles get those specific tags on that segment.

Anyway, this is an excellent discussion about an important concept that I'm still trying to fully understand. I want to bring it to the tagging group and get a discussion going.
Best,
Dave

In taking another look, I see that I removed the man_made=pipeline tag from the way but did not add it to the relation. My bad. I just added it to the relation.

Would this solve the issue for you?

I cannot find the part in the Wiki you're referring to. Could you point me to it?

Let me ask in the tagging list. I'm learning a lot about relations there but this question hasn't come up yet.

Actually, I only responded to this because I was browsing recent changesets in the U.S and when I saw the TAP mentioned added some of my personal knowledge. The only editing I did was to remove redundant tags from the pipeline way, tags that are more properly placed on the relation itself.

Hi Gerd,
Yes, I removed the ones that duplicated the tags on the relation, except for the location=underground, which changes frequently. I'm under the impression that the only tags that should be found on ways are ones that cannot be placed inside the relation.
I've done a lot of work on the pipeline, relocating and determining where it's overground or underground but never thought to remove the redundant tags before. I do think that's the new procedure for tagging relations but maybe I'm wrong.

The boundary of the Arctic National Wildlife Refuge generally follows the west bank of the Canning River. I used the riverbank as the boundary in order to reduce redundancy because I believe the small discrepancies observed are not critically important in OSM.

As far as I know, that is the case. There is a gravel surfaced service road that parallels the entire TAP. Also, I believe the correct tag for pipelines when underground is location=underground or if above ground location=overground

Questions:
Why did you not continue way:608707568 or way:60870730 to their obvious intersection with 2050?

Also, way:608707338 just stops when there are many more streets south of where you ended it. It would have been nice to see a connection made to those residential streets, which after you quit your session, offer no access whatsoever. In addition, that way continues south to connect with way:442378722. But you did not continue it. Why?

Some questions, I'm curious as to
why did you not continue way:608703080 to its obvious intersection with way:458940712?
Why did you not continue way:608703018 to its obvious intersection with way:53830086?

Why did you not connect these two sections of what is obviously the same residential street, way:608703079 and way:458940714?

Why did you not extend service road id:458940930 to its obvious intersection with way:458940715?

Hi,
You have tagged a feature (id=529818369) using 1493 nodes as natural=water but much of it it appears to be wetland. The DigitalGlobe-Premium imagery you used clearly shows this. I'm confused.

I'm mapping in the area of Fox, Alaska, and have come across some of your work. Thanks for your effort in Alaska but I am curious about how you draw your lakes and streams. It seems to me that many objects you've drawn use far too many points. A small pond with a 3 mile long shoreline contains 846 points (id:530770840) and a 6 mile long section of Goldstream Creek (id:530770823) contains 1407. It seems a waste of space to store all these points to represent such simple objects. I simplified the way defining the pond and 179 points shows it well enough IMO. (I did not upload the simplified way. I undid my changes.).
So how do you do it? And why do you use so many points?
Respectfully,
Dave

Hi,
What did you change to fix this multipolygon? There is an ongoing discussion about tagging groups of lakes in the Tagging list right now. I thought these "Twin Claderas" might be a similar example but noticed that you had edited it just after I mapped them. I cannot tell from the history what it was that you changed.

Cheers, Dave

Another source is
Surface Waters of the Seward Peninsula, Smith & Brooks, 1913

Hi,
I assume you added this tourism=attraction node and that it refers to the Krakauer story about McCandless but you gave no indication of the source of your information. Could you put that information in a note perhaps?

I also assume that the "FCTS #142" you included in the name is that source but I have no idea what that notation refers to.

Thanks,
Dave

Hi again,
After reviewing the newest imagery, I do not see any section having 5 lanes in Delta Junction. There are short sections of dual carriageway on both Alaska & Rich Hwys where they meet south of the main run through town but those are very short, and are legitimately tagged the way they are. But just north of that junction the two highways merge into one and it becomes a 4-lane highway through town. The tagging then should be lanes=4, lanes:backward=2, lanes:forward=2

First off, let me welcome you to OSM. We desperately need more OSMers in Alaska and I was happy to notice some other stuff you have mapped. Hetting back to the question at hand:

There is some precedent for tagging the way you chose to do it but generally, if a highway doesn't have a divider, a grass strip or concrete barrier of some sort then it is not a dual carriageway. Google shows that section of the Richardson as a dual carriageway but I think that's incorrect.

I would tag it as lanes=5, lanes:forward=2, lanes:backward=2, turn:lanes:forward=left (or backward). The forward or backward refers to the direction the OSM way is drawn.

I do a ton of work in Alaska (I live in Homer during the summer, and Thailand in the winter), and it's good to see someone else working in the state I love.

If you want me to help change that section to use the lanes scenario, let me know and I will do that.

Cheers,
Dave

Hi,
I'm interested in why you created a dual carriageway for the Richardson Hwy in Delta Junction. IIRC, it is not divided; the lanes are only separated by yellow lines.

AlaskaDave