Relation:multipolygon
 multipolygon
|
|
| Description |
| The multipolygon relation is used to represent complex areas. |
| Group |
| Properties |
| Members help |
|
| Statistics |
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.
Tags
| Key | Value | Explanation |
|---|---|---|
| type | multipolygon | Tells applications to use area-building rules on the members. |
Members
| Way or Node | Role | Recurrence? | Explanation |
|---|---|---|---|
|
outer | one or more | The ways making up the outer ring(s) of the area. |
|
|
inner | zero or more | The ways making up the inner ring(s) of the area. |
|
|
none | Don't use, probably ignored or handled as outer (for compatibility reasons). |
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 four roads, in which case the four ways would be tagged with the highway tag, but could still be used as "outer" members of the forest relation.
- If you have one closed way making up the outer ring and it does not describe something in its own right, you may also put these tags on the outer ring and leave the relation untagged. If you have more than one outer way (see "Advanced Multipolygons" below), then this does not make sense. Therefore it is suggested (for consistency) to always put the multipolygon tags on the relation.
- 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.
<relation id="1"> <tag k="type" v="multipolygon" /> <member type="way" id="1" role="outer" /> <member type="way" id="2" role="inner" /> </relation> |
 Figure 1: One outer and one inner ring |
One outer and two inner rings
<relation id="1"> <tag k="type" v="multipolygon" /> <member type="way" id="1" role="outer" /> <member type="way" id="2" role="inner" /> <member type="way" id="3" role="inner" /> </relation> |
 Figure 2: One outer and two inner rings |
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, where it would be impractical to have one way run around the whole of it:
<relation id="1"> <tag k="type" v="multipolygon" /> <member type="way" id="1" role="outer" /> <member type="way" id="2" role="outer" /> <member type="way" id="3" role="inner" /> </relation> |
 Figure 3: Multiple ways forming a ring |
Two disjunct outer rings
Unlike old-style multipolygons, the advanced multipolygon relation will also allow any number of outer rings and thus be a true multipolygon:
<relation id="1"> <tag k="type" v="multipolygon" /> <member type="way" id="1" role="outer" /> <member type="way" id="2" role="outer" /> </relation> |
 Figure 4: Two disjunct outer rings |
Two disjunct outer rings and multiple ways forming a ring
The ability to combine a ring from individual ways is not limited to outer rings, it can also be used for inner rings:
<relation id="1"> <tag k="type" v="multipolygon" /> <member type="way" id="1" role="outer" /> <member type="way" id="2" role="inner" /> <member type="way" id="3" role="inner" /> <member type="way" id="4" role="outer" /> <member type="way" id="5" role="inner" /> </relation> |
 Figure 5: Two disjunct outer rings and multiple ways forming a ring |
Complex combination of all advanced features
This example shows a complex combination of all advanced features: three outer rings, two of which have one or more inner rings, and plenty of them consisting of more than one way.
<relation id="1"> <tag k="type" v="multipolygon" /> <member type="way" id="1" role="outer" /> <member type="way" id="2" role="outer" /> <member type="way" id="3" role="outer" /> <member type="way" id="4" role="outer" /> <member type="way" id="5" role="inner" /> <member type="way" id="6" role="inner" /> <member type="way" id="7" role="inner" /> <member type="way" id="8" role="inner" /> <member type="way" id="9" role="inner" /> <member type="way" id="10" role="inner" /> <member type="way" id="11" role="inner" /> <member type="way" id="12" role="outer" /> <member type="way" id="13" role="outer" /> <member type="way" id="14" role="outer" /> <member type="way" id="15" role="outer" /> <member type="way" id="16" role="inner" /> <member type="way" id="17" role="inner" /> <member type="way" id="18" role="inner" /> <member type="way" id="19" role="inner" /> <member type="way" id="20" role="outer" /> </relation> |
Figure 6: Complex combination of all advanced features |
Island within a hole
From the possibility of having multiple outer rings in one relation, it also follows that you can easily model "islands" within a hole:
<relation id="1"> <tag k="type" v="multipolygon" /> <member type="way" id="1" role="outer" /> <member type="way" id="2" role="inner" /> <member type="way" id="3" role="outer" /> </relation> 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 innner. 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 or outer rings:
<relation id="1"> <tag k="type" v="multipolygon" /> <member type="way" id="1" role="outer" /> <member type="way" id="2" role="inner" /> <member type="way" id="3" role="inner" /> </relation> 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. 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 create too much work for them. |
 Figure 8: Touching inner rings |
Holes in holes (in holes...)
It is possible to have holes in the holes of a multipolygon (think: A forest with a clearing, but a patch of trees in the middle of the clearing).
Example pending. This is achieved, in compliance with the OGC Simple Features specification, by alternatingly creating outer and inner rings; in our example, the forest outline and the patch of trees would be "outer" rings, and the clearing would be an "inner" ring. This can continue to arbitrary depths but it is suggested to keep complexity down for the benefit of other mappers. Having holes in holes is also something that may not be supported by all editors and renderers. |
Illustration pending. |
More examples
More examples are on the page Multipolygon_Examples.
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:
- 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.
- Inner tagging leads to inner drawing. If inner tagging style equals outer style (an old method) the inner style should be handled as empty.
Detailed tagging
This section is for software developers, users should add tags always to relation and not to outer ways!
The tagging for this multipolygon relation can be done in quite a few ways. Here is a list of cases, problems and proposed solutions:
- There is more than one outer way:
- The relation has tags
- Use the relation tagging. Ignore anything on the ways.
- The relation has no tags, but one or more constituting outer ways have an identical set of tags
- Valid data, take the tags from the tagged segments and apply them to the complete outer way.
- The relation has no tags, and constituting outer ways are tagged differently
- This is a problem situation with undefined results.
- There is more than one inner way:
- One closed way (consisting of one or more segments) has no tags but another one has tags.
- The way without tags is rendered as a hole, the way with tags according to its tags.
- Different closed ways with different tags.
- Each hole is rendered on its own according to its tags.
- One closed way (consisting of two or more segments) where the segments have different tags.
- If some segments have no tags at all just use the tags from the other segments. If the segments have different behaviour is undefined (as for "outer" ways).
Rendering
- JOSM is able to render these advanced multipolygons since revision 1203
- Osmarender (T@H) supports advanced multipolygons
- The mapnik rendering configuration at www.openstreetmap.org does not fully support "advanced multipolygons" (But mostly)
- Fully supported by mkgmap since revision 1497
- [GpsMid] supports at least a great majority of advanced multipolygon features
- There is a suggested Algorithm for processing multipolygons.
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.
Helping Tools
- Relation Check
- OSM Inspector has support for multipolygon checks
See also
- See The Future of Areas for some discussions on how to improved area handling in OSM.
