From OpenStreetMap Wiki
(Redirected from Relations/Multipolygon)
Jump to: navigation, search
Available languages — Relation:multipolygon
· Afrikaans · Alemannisch · aragonés · asturianu · azərbaycanca · Bahasa Indonesia · Bahasa Melayu · Bân-lâm-gú · Basa Jawa · Basa Sunda · Baso Minangkabau · bosanski · brezhoneg · català · čeština · corsu · dansk · Deutsch · eesti · English · español · Esperanto · estremeñu · euskara · français · Frysk · Gaeilge · Gàidhlig · galego · Hausa · hrvatski · Igbo · interlingua · Interlingue · isiXhosa · isiZulu · íslenska · italiano · Kiswahili · Kreyòl ayisyen · kréyòl gwadloupéyen · Kurdî · latviešu · Lëtzebuergesch · lietuvių · magyar · Malagasy · Malti · Nederlands · Nedersaksies · norsk bokmål · norsk nynorsk · occitan · Oromoo · oʻzbekcha/ўзбекча · Plattdüütsch · polski · português · română · shqip · slovenčina · slovenščina · Soomaaliga · suomi · svenska · Tiếng Việt · Türkçe · Vahcuengh · vèneto · Wolof · Yorùbá · Zazaki · српски / srpski · беларуская · български · қазақша · македонски · монгол · русский · тоҷикӣ · українська · Ελληνικά · Հայերեն · ქართული · नेपाली · मराठी · हिन्दी · भोजपुरी · অসমীয়া · বাংলা · ਪੰਜਾਬੀ · ગુજરાતી · ଓଡ଼ିଆ · தமிழ் · తెలుగు · ಕನ್ನಡ · മലയാളം · සිංහල · བོད་ཡིག · ไทย · မြန်မာဘာသာ · ລາວ · ភាសាខ្មែរ · ⵜⴰⵎⴰⵣⵉⵖⵜ · አማርኛ · 한국어 · 日本語 · 中文(简体)‎ · 吴语 · 粵語 · 中文(繁體)‎ · ייִדיש · עברית · اردو · العربية · پښتو · سنڌي · فارسی · ދިވެހިބަސް
Public-images-osm logo.svg multipolygon
Multipolygon Illustration 6.svg
The multipolygon relation is used to represent complex areas.
Group: Properties

  • Way - outer
  • Way - inner
Status: De facto

Relations of type multipolygon are used to represent complex areas.

Simple areas are mapped in OSM by creating one circular way and tagging 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.

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.

Mainly in Germany type=multipolygon has also been used instead of type=boundary for boundary relations. This method was not widely accepted and should be considered deprecated.


Key Value Explanation
type multipolygon Tells applications to use area-building rules on the members.
... ... Any tags describing the multipolygon (names, landuses, ...)


Way or Node Role Recurrence? Explanation
Way outer one or more The ways making up the outer ring(s) of the area.
Way inner zero or more The ways making up the inner ring(s) of the area.
Way none Don't use, deprecated. Tools may handle this as outer.


The intended use of multipolygons is this:

  • Tags describing the multipolygon (e.g., landuse=forest) always 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 fences, in which case the four ways would be tagged with the barrier tag, but could still be used as "outer" members of the forest 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 must 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).

Legacy Data

Note that in the past, some multipolygons were also allowed to have their tags on the outer way (if there was only one such way) while keeping the respective multipolygon-relation untagged. This tagging scheme is now considered deprecated. But when consuming OSM data, it's still possible to find (and potentially necessary to handle) such old style multipolygons, too.

Valid Multipolygon conditions

Generally, the multipolygon relation can be used to build multipolygons in compliance with the OGC Simple Feature standard (Graphical examples of OGC validity). 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).

We define a valid (closed) polygon as the combination of a subset of member ways which, when their endpoints are joined, form a closed polygon.

We define an unclosed way as a combination of nodes in which the first node is different than the last node.

The conditions to form a valid multipolygon relation are the following:

  • Member ways of a multipolygon relation MUST form one or more closed polygon(s). When the ways belonging to the relation are combined they must form one or more closed chains. [[1]]
  • Exactly two unclosed ways, and no more should share an endpoint (e.g. the most extreme nodes of a way represented by the black dot in the images).
    • If an endpoint is shared by less than two unclosed ways, the polygon can't be closed and is ill formed. invalid example 1
    • If an endpoint is shared by more than two unclosed ways, it's ill formed and a closed polygon can't be reconstructed unambiguously. invalid example 2 (Exception - points shared by an even number of unclosed ways might be part of touching inner rings which is ok.)
  • Inner polygons must not overlap with outer polygons or touch them. Overlapping can be avoided completely by reshaping.


One outer and one inner ring

The simplest and most often used case is one outer ring and one (or more) inner rings consisting of single closed ways.
<relation id="1">
  <tag k="type" v="multipolygon" />
  <member type="way" id="1" role="outer" />
  <member type="way" id="2" role="inner" />
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" />
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" />
Figure 3: Multiple ways forming a ring

Two disjunct outer rings

Unlike simple multipolygons, the advanced multipolygon relation allows any number of outer rings and thus is 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" />
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" />
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" />
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" />

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 needed 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:
<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" />

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, saving a step.

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

There is some discussion about this section on the talk page.

Figure 8: Touching inner rings

Invalid examples

Some examples of invalid multipolygon relations to illustrate what should NOT be done

Unclosed polygons

This is an example of an invalid multipolygon as way #2 and way #3 are not connected.
Figure 9: invalid Unclosed polygon

Overlapping, unclosed member ways belonging to the same role

This is an example of an invalid multipolygon as way #2 and way #3 endpoints share more than two ways.
Figure 9: invalid ambiguous multipolygon relation

More examples


  • 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.

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 ring (consisting of one or more ways) has no tags but another one has tags.
    The ring without tags is rendered as a hole, the ring with tags is rendered according to its tags.
    Different rings with different tags.
    Each hole is rendered on its own according to its tags.
    One ring (consisting of two or more ways) where the ways have different tags.
    If some ways have no tags at all just use the tags from the other ways. If the ways have different tags, then the behaviour is undefined (the same as for "outer" ways).


  • JOSM is able to render these advanced multipolygons since revision 1203
  • Layers on the OSM website - depends on use of the osm2pgsql "--multi-geometry" flag, which varies by layer. For more information see this blog entry by Paul Norman [2] and this openstreetmap-carto github issue [3]
  • 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.

Mapping Style, best practice

Multipolygons open up the possibility to create geometrically identical objects in different styles: as ways or as multipolygons, using closed or open ways, or with shared or unshared ways.

This raises the question of which mapping style to use. Some styles have advantages over others, and should be regarded as good practice. For others, the choice is more of a matter of preference, or whether one is an experienced or an inexperienced mapper.

Most generally when large areas share the same tag, they can be represented either by a large number of small multipolygons or closed ways, or by a smaller number of large multipolygons. For multipolygons themselves, two possible mapping styles are:

Method A
Inner and outer rings are created from closed ways whenever possible, except when these ways become very large (on the order of 2000 nodes). Ways are usually not shared by different multipolygons
Method B
Every border between two multipolygons is represented by a unique way which is then shared by the adjacent multipolygons. Consequently the multipolygon rings are often composed of several open ways

The question of best practice for multipolygons has been discussed intensively over the years, see Talk:Relation:multipolygon and the forums. A final consensus hasn't emerged yet, but the following observations apply:

  • Mapping simple closed areas as multipolygons instead of ways increases the number of database objects and increases rendering time. This additional overhead of complexity should be avoided.
  • Sharing way segments between multipolygons (method B) offers a representational efficiency by avoiding redundant representations of overlapping ways.
  • Multipolygons consisting of non-closed ways (method B) are harder to handle by inexperienced users, and simple editors such as Potlatch 2. This has often led to the accidental destruction of such multipolygons by unsuspecting users.
  • Many experienced users have expressed their discomfort with method B, especially when the multipolygons are very large.
  • Huge multipolygons cause a slowdown of the rendering process.
  • Editing complex geometries in JOSM is easier, faster and less error-prone with method A. This is because method B requires deletion, creation and insertion of several way segments into the correct multipolygon relations.

So far there are no official restrictions on how to use multipolygons as long as they are geometrically valid. However adopting a considerate mapping style will help to keep the database clean and keep editing easy for every user.

Potlatch 2 example

Here's a grassy area within some woodland:
Potlatch 2 Multipolygon example - before

Click on the outer way:
Potlatch 2 Multipolygon example - after clicking on outer

Control-Click on the inner way:
Potlatch 2 Multipolygon example - after control-clicking on inner

Note how a "doughnut" icon has now appeared in the toolbox:
Potlatch 2 Multipolygon example - doughnut icon appears

Click it:
Potlatch 2 Multipolygon example - click doughnut

To see the actual tags that have been added, click advanced:
Potlatch 2 Multipolygon example - click advanced

The multipolygon has been created:
Potlatch 2 Multipolygon example - multipolygon

Helping Tools

See also