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.