This is really just a cut and paste from an email I wrote, but I figured I should toss it up here in case others would find it interesting (or be able to correct/clarify!):

Re: Relations

Focusing just on 'type=multipolygon' relations (because I haven't worked with the other types yet), here's a quick primer that will hopefully cause more clarity than confusion.

Think of a regular closed way, the sort we use all the time to mark where a school is, or a park, or whatever. This closed way has three major limitations:

1. You can't split the way into shorter ways. If you do, it's no longer a closed way, and it no longer represents an area.
2. You can't punch holes in it. If something different is inside the area, you have to count on the renderer to overlap them in a sane way.
3. You can't easily share a border with other areas.

A multipolygon relation is best thought of as an area, exactly like closed ways are. However, they remove the requirement that the area be defined by just one (closed) way. Now, the boundary can be built up of many non-closed ways, so long as all of the ways together form a closed path. Each way that is part of the outer edge of the area should be set to have an 'outer' role (and are 'outer' members of the relation).

Multipolygon relations also allow you to punch holes in an area. Just like the outer edge of the area, you can describe the hole with a single closed way, or several unclosed ways that, together, make up the edge of the hole. Ways that are being used to mark holes are set to have an 'inner' role (and are 'inner' members of the relation).

Since the area is described by the relation, you should put all the tags that describe the area on the relation, not on the ways.

… See full entry

In my neck of the woods, there's a lot of landuse tags that were mapped using closed ways. Since most landuses butt up against something, be it roads, other landuses, or buildings, we ended up with a lot of closely spaced, parallel ways. A while ago I took a shot at merging nodes, accepting that multiple ways would overlap (share nodes). This cleaned up some of the clutter in the database and helped avoid unsightly gaps in the rendering, but was pretty hard to maintain. None of the editors have much support for overlapping ways.

More recently (today!) I tore out a swath of the map and redid it using relations. So far, this seems to be a pretty workable approach. JOSM, at least, seems to have quite good support for working with relations, but I haven't tried to see how manageable they are in Potlatch. No rendering issues, either.

A few random notes and questions:
I did everything as multipolygon relations, using multiple, short ways as outer members. Are there any other 'supported' relation types that I should consider using?

I put landuse tags on the relation, not on its outer members. Doing otherwise would just be missing the point.

I started feeling a lot better about the approach once I started adding barrier=wall and barrier=fence ways. Once those are added to the map, it's very natural to use them as outer members of relations. In cases where there was no physical barrier or road between landuses, I would add a short untagged way. This felt odd the first few times, but I quickly got over it. Once some relations are utilizing an untagged way, it's reason for existing becomes obvious.

If you consider the intersection of Mt. Hermon Road and Scotts Valley Dr. to be the center of town, I've done the SW corner and a little of the NW corner so far (in Scotts Valley, CA, USA).

For non-Americans, or non-hikers, the Pacific Crest Trail (PCT) is a trail that runs from the Mexico border in California all the way up to the Canadian border in Washington. It's 2,650 miles (4,265 km) long, and as far as I can tell, only exists on the OSM in fragments here and there.

So here's the interesting part, there's a pretty high detail ShapeFile for the whole thing at the US Forest Service page devoted to the trail:

http://www.fs.fed.us/pct/
http://www.fs.fed.us/pct/downloads/PCT_shapefile.zip

If you use the Merkaartor editor, you can easily import, view, and (I think) apply the shapefile to the OSM. As far as I can tell, the data is already broken into subpaths, so it wouldn't come in as one gigantically long path. It would overlap existing ways, however.

So here's a question for your collective wisdom, dear readers: should I add it?
If so, how?

Here's the issues as I see them. First, the PCT is clearly a relation, not just a path. But all we have is the data of where it goes, not what roads, tracks, and paths it's following. Second, the shapefile doesn't give hint of what type of road/track/path it is, so in sections where the road/track/path is missing and needs to be added to the OSM, we can't do any better than using a highway=road tag.
osm.wiki/Tag:highway%3Droad

I think the proper solution is probably to write a script that creates a relation, then traverses the PCT looking for existing 'highway' tagged ways nearby, adding them to the relation if found. If no appropriate way is found nearby, then create a highway=road tagged way from the shapefile data.

… See full entry