Relation:multipolygon

Relations of type multipolygon are used to represent areas with holes. Such relations have been automatically created wherever there was an "area with a hole" in the 0.4 data, modelled as one way with two rings of segments.

In short, an area with holes consists of an outer polygon tagged like a usual area, and several inner polygons as the marker for the inner edge of the area. Do not copy tags from outer polygon to inner polygons.

Please see the section "Suggestion for advanced multipolygons" on the discussion page for an extended but backwards compatible way of modelling more complex polygons that is now in the process of being used and implemented.

Tags

Key	Value	Discussion
type	multipolygon

Members

Way or Node	Role	Recurrence?	Explanation
	outer	one	The outer ring of the area. Future work may permit more than one outer way. See advanced polygons on the talk page.
	inner	one or more	An inner ring of an area (Example: an island in water)
	none	one or more	If no role is given outer is assumed (see Notes below)

Notes

The intended use of multipolygons is this:

• Tags describing the multipolygon should go on the outer way.
• 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.
• If there is no role given outer is assumed, this makes defining boundaries easier as no explicit outer role is needed for all the elements (which can be in the hundreds). But to avoid ambiguity the role should be set in case there are inner elements.
• "name" tags of the relation are rendered by mapnik but not by osmarender.

As of 2008-12-25 in mapnik renderings it does matter in which direction the ways go - it works if the inner and outer way go in different directions. For example the outer one goes clockwise and the inner ones go counterclockwise. As of 2009-02-17 it appears Mapnik will not render holes if those ways have tags (including 'created_by=Potlatch') on them.

Step by Step guide

JOSM

A summary of the steps to create this relation using JOSM based on a list from Jon Burgess.

1. Create the outer ring (direction does not matter), and tag it according to the area (e.g. natural=water).
2. Create the inner ring (direction does not matter). Do not tag it.
3. Make sure you have the 'Relations' information open by enabling the relation icon (the bottom on the list down the left hand side).
4. Select all the ways needed for your relation.
5. In the relation box click 'New'.
6. A new window appears. Click 'Add Selected' to add the selected ways into the relation.
7. In the top half of the 'Relations' window, click on the blank box below key and enter 'type'. Under value add 'multipolygon'.
8. Then you need to define the 'role' for each way. Click on each of the ways, and use the 'Select' button in the dialog to highlight this in the main map window.
9. Set the 'role' value for each inner ring to 'inner', and for the outside ring set the role to 'outer'.

• There is a German screencast showing these steps (TODO: Verify whether screencast still has obsolete references to direction and tagging the inner ring like the outer.

Merkaartor

1. Open the area you want to edit. (File -> Download from web -> ...)
2. Select all ways you need in the relation (hold Ctrl and mark/select the ways with mouse)
3. Select from the program menu Create -> Relation
4. Now there is a table with the fields Role (unfilled) and Member (filled with data of selected ways)
5. Type the word "outer" for the outer way and "inner" for all inner ways.

If you don't know which way is inner or outer, select the outer way and remember the last few digits of the way ID of this way. Start again. Now type in "outer" for the way with that number. All other ways should be logical "inner" ways.

Potlatch

1. Create the outer way (direction does not matter). Tag it as appropriate (e.g. natural=water).
2. Create the inner (hole) way(s) (direction does not matter). Do not tag them.
3. Select the outer way and click on the second symbol on the right side, which looks like two chain segments.
4. "Create a new relation" should be selected; click "Ok".
5. Type in the word "type" in the first field (key) and "multipolygon" in the second field (value) and click "ok".
6. Now there is a additional field which looks different from the other key/value input fields. This field describes the "role" of the way. Type in the word "outer" for your outer way.
7. Select one of the inner ways and click on the "chain link"-symbol. Do not select "Create a new relation", but instead, select your created relation in the dropdown menu. This should be the one with the highest number in the list. Click "Ok" to add the way to the selected relation.
8. In the field near the word "multipolygon" type in the word "inner" to mark an inner way.
9. Repeat steps 7 and 8 for every other inner way.

Helping Tools

• Relation Check

Advanced multipolygons

There are some problems with the existing usage of the multipolygon relation, most notably that you cannot have multiple outer rings, and you cannot have rings consisting of more than one way. Both of these properties would be required if you were to use a multipolygon to describe a national boundary for example, which may have enclaves/exclaves and also be longer than could sensibly be modelled in one way.

A logical way to implement such constructs would involve cascading relations: You would create one relation for the whole country, and the members of that relation would represent the individual polygons (e.g. the mainland plus a few islands), and the members of these would then be ways - or maybe even again relations that group several ways into one long one.

However, such a three or even four level scheme would be complex to maintain and to evaluate, and it would also not be compatible with existing multipolygons.

For these reasons, the following "advanced multipolygon" relation is suggested, which uses only one relation even for complex areas. It is not a new type of relation, just an enhancement of the existing multipolygon relation. Existing multipolygon relations need not be changed to work with this enhanced definition.

Existing uses
The current and already widely used "multipolygon" relation allows exactly one outer ring and any number of inner rings. Rings must always consist of one single closed way only: <relation id="1"> <tag k="type" v="multipolygon" /> <member type="way" id="1" role="outer" /> <member type="way" id="2" role="inner" /> </relation> The current multipolygon relation is kind of a misnomer because in geometry, a multipolygon may consist of a series of disjunct polygons, and the relation does not allow this.
The existing multipolgyon relations allow any number of 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>
New use: Multiple ways forming a ring
The advanced multipolygon schema will allow 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>
New use: More than one (disjunct) outer ring
Unlike existing 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>
New uses combined
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>
This example shows a complex combination of all advanced features, a figure with 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>
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.
Touching 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.

One thing that multipolygons do not support is overlapping/intersecting inner or outer rings. All rings must be fully disjunct.

Details

• If the role is empty, it should be interpreted as "outer". This should normally not be used, especially not if there are inner and outer ways.

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 take 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 (old method)
   the inner style should be handled as empty.

Detailed tagging

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:

a) Any number (including zero) segments have no tags at all, but all others have the same tags

Valid data, take the tags from the tagged segements and apply them to the complete "outer" way. It is up to discussion if only one segment should be tagged or all should be tagged. I would prefer only one segment beeing tagged as this avoids duplicate and/or inconsistent data.

b) Some segments have a subset of the tags of the other ways.

While it might be possible to find the segment with the largest set of tags this adds complexity to the software and therefore should be avoided. Software doesn't have to support this kind of tagging and can chose any segment with non-empty tags.

c) Some segments have completely different tags.

This is obviously wrong tagging. The interpretation is UNDEFINED. Software can do anything it likes.

Of course the best way to tag the "outer" ways is by tagging the relation instead of the way. But this will require a lot of changes to existing software and therefore the intermediate solution of tagging the ways probably will be used for some time.

• There is more than one "inner" way:

a) 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.

b) Different closed ways with different tags.

Each "hole" is rendered on it's own according to its tags.

c) 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 behavior is UNDEFINED. (Like for "outer" ways.)

Note: Segment is used to denote ways in the relation that have to be combined to form a closed way. It does NOT refer to segments from older API versions.

Rendering

• JOSM is able to render these advanced multipolygons since revision 1203
• A patch for Osmarender (T@H) is available in Trac-Ticket #1435.