Simple areas are mapped in OSM by creating one circular way and tag it with something that suggests an area rather than a circular way. For example, a circular way tagged landuse=forest will be assumed to be an area, while a circular way tagged junction=roundabout will not.

However, this model only works for areas the outline of which consists of one single way, and which do not have holes. Any area that is more complex than that (e.g., because its outline consists of several ways joined together, or because the area consists of multiple disjunct parts, or has holes) requires a multipolygon relation.

It is suggested to also use type=multipolygon (and not type=boundary) for boundary relations if you want applications to use area-building rules (i.e., connecting outers to form rings, excluding enclaves, etc.) A boundary relation is easily spotted by its boundary=* tag; no need to use type=boundary.

In short, a multipolygon relation can have any number of ways in the role outer (the outline) and any number of ways in the role inner (the holes), and these must somehow form valid rings to build a multipolygon from.

Usage

The intended use of multipolygons is this:

Tags describing the multipolygon (e.g., landuse=forest) should go on the relation. The outer way(s) should be left untagged, unless they describe something in their own right. For example, a forest could be delineated by naturereserve-border, in which case the outline would be tagged with the naturereserve tag, because the lake inside the forest belongs to the naturereserve, but not to the forest.

If the inner way represents something in itself (e.g., a forest with a hole where the hole is a lake), then the inner way may be tagged as such.

Otherwise the inner way(s) should be left untagged.

The direction of the ways does not matter.

The order of the relation members does not matter (but properly sorted member lists can help human editors to verify completeness).

Generally, the multipolygon relation can be used to build multipolygons in compliance with the OGC Simple Feature standard (http://www.opengeospatial.org/standards/sfs). Anything that is not a valid multipolygon according to this standard (e.g., polygons with intersecting rings) should also be considered an invalid multipolygon relation, with the notable exception of touching inner rings (see below).

Examples

One outer and one inner ring

The old-style, widely used multipolygon relation allowed only one outer ring and any number of inner rings; rings had to consist of one single closed way only. This type of polygon (not really a multipolygon but more multi-way) is of course still supported but the rules have been relaxed so that this is just a special case of the more general multipolygon relation.

Multiple ways forming a ring

The advanced multipolygon schema allows any inner or outer ring to consist of more than one way. This is useful for multipolygons encompassing very large areas (e.g., Lago di/Lake Garda, Lake Constance/Bodensee), where it would be impractical to have one way run around the whole of it. It's also used for boundary=administrative:

A construct like this would previously have required different multipolygon relations, one with way 1 being outer and way 2 being inner, as well as one with way 2 being outer and way 3 being inner. Such cascading is still recommended when the "island" in the middle is something else than the area on the outside, but where the "island" is the same stuff it can just be made a hole in the hole.

Figure 7: Island within a hole

Touching inner rings

Some mappers use the current "multipolygon" relation for combining touching inner rings:

An implementation of advanced multipolygons should attempt to render these as if the touching rings were indeed one ring. This is the one case where OpenStreetMap use deviates from standard OGC Simple Features. In Simple Features, touching inner rings are not supported because they are unnecessary (why make two inner rings when you could combine them into one). In OpenStreetMap, they sometimes make sense if tagged individually, for example a forest with a clearing which is half occupied by a lake and half by farmland - you would have two "holes" in the forest, one being tagged as natural=water and the other as landuse=farmland. This is a convenience shortcut; requiring of mappers to create only one hole in the forest, and then create individual polygons for lake and farmland, would be too much work for them.

Avoid building multipolygons where an inner ring touches an outer ring though.

Figure 8: Touching inner rings

More examples

Tagging dispute

There is a big disput in german-forum about using multipolygons.
Some mapper use multipolygons to create simple areas (without holes), uses highways to form an area/multipolygon and/or using multiple ways to form an outer/inner-ring.
This is correct by following the rules from this page. On the other hand there are many users who think the scheme is to lax. They want using multipolygons only for areas with holes and split the outer/inner-ring only for really huge areas and administrative-borders and don't use highways to form the outer/inner-rings.
Some of their arguments are:

difficult to edit, espacially for new users

less computing power (multipolygons need much more computing power than simple areas)

view in editors are too complicated

OSM-rule KISS - Keep it simple stupid

Helping tools

Here are some tools that may help you to edit areas and multipolygons:

Follow line: F-Key

ConturMerge Plugin (JOSM)

Tagging

It is suggested to apply all tags which describe the area to the relation, and not to the ways. In many cases this may result in completely untagged ways.

Implementation for compatibility (only for software developers):

Drawing style is taken from the tagging of the relation itself.

If relation is not tagged, the drawing style of outer ways is used.

If the outer styles mismatch or no style is found it is considered an error.

Potlatch example

Potlatch example

In Potlatch, roles for a multipolygon relation should be assigned to the relation member itself, and not as separate tags. When in edit mode, select the relation member and put inner or outer in the box on the same line as where it says multipolygon.