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.

The ways themselves can be left untagged, if they're just an arbitrary boundary of some sort. But often, boundaries correspond to physical objects, such as fences, or rivers, or roads. In the parts of Scotts Valley that I converted to using relations, I found it very helpful to start mapping fences, just because once you've put a fence down, it's very natural to say, "This area over here is one thing. One of its edges is defined by this fence... and over on the OTHER side of the fence there's a different area with one of its edges defined by the fence."

A few implementation notes, at least in JOSM (using the latest stable, version 2255):
- In the relations panel, any relation that is marked with a * isn't fully closed, or is closed but has a tail sticking off.

- If the area doesn't have a name, it's useful to add a note describing what the area is for. Names and notes on a relation show up in the relation panel, which helps a lot when there are many relations in the vicinity.

- When editing a relation, there's a 'linked' column in the members area. I haven't a damned clue what that's for, or why it matters. =)

- As far as I can tell, the order of the members doesn't really matter, so all those buttons that dictate where a new member will be inserted aren't that important. I'm sure the order can help make for good bookkeeping when you have a very large relation, though.

That's pretty much all I have. Like I said at the outset, I hope it adds clarity, not confusion. I'll definitely be looking into using the other "type=*" tags for relations in the future.

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.
http://wiki.openstreetmap.org/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.

I'm a programmer, and would be willing to try it myself, but since I currently know nothing about OSM's API, and relatively little about it's standard practices, the potential for me to mess it up is a little intimidating. Is there a sandbox to play in? For that matter, what's a good algorithm for calculating if two ways are 'close', favoring longer ways, and strongly favoring groups of ways which are close to the shapefile data AND which are connected to each other.

Better yet, does anyone else want to take the data and run with it? Please reply/comment!