Talk:Relation:multipolygon

Allowed roles?

Please clarify if other roles than "inner" and "outer" are allowed. For MPs used as boundaries roles "admin_centre" and "sub_area" should be allowed, Otherwise MPs are not a fully replacement for boundary relations. --chris66 16:35, 21 February 2011 (UTC)

Need for "inner" role?

Is there really a need for an "inner" role? If the "outer" member is defined, by definition any other members must be "inner". --SiliconFiend 21:36, 3 November 2007 (UTC)

"inner" should be explicitly used, just in case we come up with some additional roles in the future. --Breki 16:26, 20 January 2008 (UTC)

And: What if there is a way which not belong to this relation, but is inner of the outer way? So inner ways must be explicite be defined. --Bahnpirat 19:51, 24 March 2008 (UTC)

If there's a way inside of the outer way and doesn't belong to the relation, than there's no problem, because it doesn't belong to the relation. But anyway it's better to define the inner members, because of the mentioned reason. Maybe there's more than one way defining the outer limit. --MasterMG 20:17, 3 August 2008 (UTC)

I think this discussion concluded that inner was required. ways that intersect with the relation but which are not part of the relation are not added to the relation. PeterIto 07:16, 29 August 2008 (UTC)

A polygon-relation without inner ways could be any reservoir with the outer ways having more than 2000 nodes. -- Malenki 16:17, 12 January 2011 (UTC)

Naming and orientation

moved from main article Robx 11:21, 4 March 2008 (UTC)

This relation should perhaps be renamed area-with-hole as traditionally a multipolygon is a number of separate, not concentric, areas.

• However, since GIS-style 'multipolygons' are disparate areas, it's possible that they should just be represented with a more general 'grouping' relationship.

Why not support multi-polygons by having several areas marked as outer

Please make outer rings go clockwise and inner rings anticlockwise - i.e. fill colour on the right. This provides compatibility with certain renderers. --Rjmunro 15:42, 20 December 2007 (UTC)

The conversation is being carried on the the section 'More than one way for "outer" role?' below.PeterIto 07:16, 29 August 2008 (UTC)

Questions

If you think about the data model, this is inconsistent. It would be consequent to give the semantics for the water to the relation. To explain let's imagine water with an island. The geometry of the water is not the outer way but the relation which describes the polygon with a hole. Ergo: The relation should be tagged with natural=water. The forest itself is the inner way of the relation and to tag it with natural=water, too, is all but logical. The inconsequence of tagging the outer way will show if you extract waters from a database and find ways which COULD BE part of a relation which cuts out islands. To get the right geometry in a GIS I have to make a lookup in the relation_member table if the way is part of a multipolygon. Questions:

• Why is the outer way tagged instead of the relation?
• Why must the inner way tagged with same tags like the outer way?

In the end of the day, the common practice should be changed to get the data consistent. MapDeliverer 18:10, 15 May 2009 (UTC)

compacted since I've been talking to myself --Robx 11:23, 4 March 2008 (UTC)

Why do holes have to be tagged the same as the outer way? That requires creating duplicate inner ways to tag things like, say, a marsh inside a forest area, that's supposed to be both a hole in the forest and an area in its own right. Is this a limitation with a renderer, or is there a real reason I'm missing? Robx 09:35, 26 February 2008 (UTC)

Two suggestions regarding orientation (area on the right):

• the editors should indicate this rule to the users, say by shading a few pixels to the right of ways tagged as areas
• there should be an additional role=inner_reverse or similar to address the problem I mentioned above so as not to require duplicate ways for holes

Robx 09:22, 27 February 2008 (UTC)

Addressing my complaints above, I've whipped up an alternative to multipolygon at Relations/Proposed/Area_with_holes. I'd be happy to hear if there's any problems with the approach, and if people like it. Maybe I'm missing the rationale behind the current multipolygon relation? Robx 09:39, 3 March 2008 (UTC)

In relation to making the direction of the way significant, I note that where there is a 3 level relationship (eg a lake on an island in a lake) then the middle way would not be able to be both directions at the same time (ie both the inner element of the 'island in a big lake' relation and also the outer element of the 'lake on the island' relation).

I believe that the conclusion of above tagging conversation was that 'inner' ways should be tagged appropriately for the content of the inner element (not a duplicate of the outer element). So an island in a lake would be tagged as 'land' and related with the role 'inner' to the lake relation. The concepts described in the 'alternative approach' referred to here have been incorporated into this relation (see rewrite section below). The issue of direction (clockwise/anticlockwise) as not be incorporated. The current text states that direction does not matter.PeterIto 07:16, 29 August 2008 (UTC)

Inner tags

Thomas Wood changed the step by step to state that the inner should be left untagged. I think the inner needs to be tagged with the matching tag to the outer to render properly. It also makes sense to me to tag it to help understand what is being marked. For example: in a body of water the relation outer could have a tag natural=water. This marks the boundary to the water. Islands too have a boundary to the water. The fact that it is also an inner in the relation determines how it is used and rendered. The island (inner) should also be tagged with natural=water. Comments? -- Chillly 16:20, 24 May 2008 (UTC)

I agree that the inner should be left untagged. For one, tagging the inner ways the same as the outer is an unnecessary duplication of data. Secondly, it adds unnecessary work for the mapper: For the common case of one area within another, you have to create duplicate ways to create, say, a natural=scrub clearing in a natural=wood. And it seems very intuitive that you should be able to view such a natural=scrub as a hole in a woodland multipolygon. Robx 16:05, 25 May 2008 (UTC)

I disagree. The inner in your example marks the inner edge of the wood, so should be tagged as natural=wood. The scrub could then either share the way or have a new way perhaps sharing the nodes, but that's another argument. In the case of an island in water which bears no other tag, the way carries no tags at all and just looks like an error. In reality the renderers drive this and at the moment it seems that Mapnik needs the inner to match the outer. Chillly 17:20, 27 May 2008 (UTC)

Why do you think that it "looks like an error"? The way for the island may have no tags but it has a role in the relation. Nhoffm 08:05, 24 June 2008 (UTC)

It looks like an error because it has no tags. Any way with no tags looks like it has been accidentally left untagged - as things stand. Chillly 12:13, 24 June 2008 (UTC)

I would take it one step further. Why must the outer way be tagged at all? What defines the area is the relation, not one of its ways. If we want to stop "mapping for the renderers", we should add the key to the relation and remove it from the outers and the inners. Nhoffm 07:55, 24 June 2008 (UTC)

I think tagging relations is interesting. For example, I think that a relation to create a dual carriageway could have the ref tag at least on the relation rather than the way. This is the method the route relation uses. There is due to be a relation workshop at SOTM next month. I hope the idea of tagging relations is discussed (I can't be there to raise the point). Tagging relations will be talked down because it is too hard for beginners to understand. I don't like this dumbing down - if people use the multipolygon relation then they will read up how to use it and tag things accordingly. In the meantime though it makes sense that if the outer is tagged as the limit of the area then the inner should be tagged as the inner limit. Chillly 12:13, 24 June 2008 (UTC)

could you give some concrete examples of how you would use this ability to add tags to the relation?PeterIto 07:16, 29 August 2008 (UTC)

I believe that this conversation did not reach a conclusion, however it was also discussed in July at the SOTM 'relations' workshop. The specification for this relation currently states that the outer way should be tagged according to the contents of the outer element, and that the inner way can optionally be tagged according to the contents of that inner element if required. The current documentation states that all other tags should be associated with the way and not be associated with the relation. This conversation will be treated as closed unless the issues are raised again.PeterIto 07:16, 29 August 2008 (UTC)

Sorry to bring this up and beat a dead horse...from discussions on the dev mailing list 7/19/09 it appears that the "new" consensus is to prefer tagging area features on the relation itself, rather than on the ways, to:

• Prevent ambiguity between conflicting tags on outer ways making up the multipolygon and
• Reduce data duplication.
• Prevent ambiguity as to whether holes are positive or negative space.

On this last point, there probably does exist a spec for multi-polygon that allows holes to be tagged with the property of the relationship without anarchy breaking out, but such a spec would at best be really complex and puts a burden on anyone trying to do programmatic interpretation of the data. In the meantime, it requires mappers to put more tags down. The only advantage of tagging the inner ring with the properties of the "feature" is to make it slightly more obvious what's going on while editing, but by the time of this writing, JOSM and potlatch show you relationship data in a very easy-to-understand way. --Bsupnik 19:31, 19 July 2009 (UTC)

More than one way for "outer" role?

Is it possible to have several ways building the outer ring instead of just a single way? Of course these ways have to be connected and have to define a single area. This could be used e.g. for very large rivers. Maybe there's the same question for ways building inner rings. --MasterMG 20:06, 3 August 2008 (UTC)

I agree. This is both useful for very large features (such as the great lakes), and also for small features such as urban parks where much of their boundary is along existing features such as roads. Note that the 'inner' element could be defined using a way or alternatively another of these relations: http://lists.openstreetmap.org/pipermail/talk/2008-August/028802.html PeterIto 14:58, 21 August 2008 (UTC)

From a consistency point of view, I think we should use the same method for compound inner rings as for compound outer rings. --Schuetzm 09:16, 29 August 2008 (UTC)

As background information here are some other projects that use the term 'multipolygon:

• OpenLayers using Multipolygons http://dev.openlayers.org/docs/files/OpenLayers/Geometry/MultiPolygon-js.html
• GML 2.0 using Multipolygons (called MultiSurface in 3.0) http://www.arcwebservices.com/openlsconnector/gmlmultipolygon.htm
• PostGIS references to Multipolygons http://postgis.refractions.net/documentation/manual-1.3/ch04.html#RefObject

We seem to have two options here. We can either use multiple 'outers' to identify multiple non-interconnecting polygons (as per an earlier discussion on this page about the correct interpretation of the term 'multipolygon') or to optionally define more than one element that makes up the edge of the outer polygon. An example of the first would be to indicate that 'all these buildings as being part of a particular university'. An example of the second would be to say 'this park is bounded by these three roads and this hedge' or that 'this huge river is made up of these sections of riverbank'. Both of the above are valid and useful, however this relation can only do one of these jobs. I suggest that we allow multiple outers to be defined to make up a single boundary which solves a serious current problem with very large lakes and long wide rivers. I suggested that we use a general 'group' relation for defining multipolygons as has already been proposed. Finally I also suggest we rename this relation 'polygon' to avoid conflict with the accepted understanding of this term in the GIS community. PeterIto 06:23, 29 August 2008 (UTC)

I believe that this conversation is still openPeterIto 07:16, 29 August 2008 (UTC)

map features update

it would be nice then (if this is agreed upon) to update http://wiki.openstreetmap.org/index.php/Map_Features#Natural - currently it says :

"Land that exists within another area, such as a lake. (i.e an island). Keep water on the right and land on the left side in relation to sequence of nodes in the Way. Layering may also be required. See Relations/Multipolygon for islands in lakes". This seems to contradict best practice and suggestions on this page in several ways - it tells to tag inner ways. it refers to way direction as required and suggests using layers (which, if i'm not mistaken, should be discouraged in this case).

Multiple outer elements

Currently the text states, that only one outer element is allowed.

This should be modified to multiple elements as long as they form 1 outline. E.g. for large lakes using coastline the outer form is broken into multiple ways, but nevertheless is should be possible to use the same multipolygon relation for these as well (especially for naming purposes, ...).

So the suggested modifications are:

• Allow multiple outer ways as long as they build up to one closed way when joined
• Allow multiple splitted inner ways also (there is nowhere stated it is not allowed, but it should be explicit)

--Stoecker 08:05, 9 October 2008 (UTC)

This would be addressed by the #Suggestion for advanced multipolygons, below. --achadwick 11:07, 27 November 2008 (UTC)

Enclaves inside Exclaves inside Country

We should specify how outher-polygons are to be handled that are completely inside inner polygons. --MarcusWolschon 07:30, 14 November 2008 (UTC)

I also recommend to make it clear that intersecting and incomplete polygons are not only broken but should be completely ignored. This way we don't end up with some tools trying to fail more gracefully then other tools and users not noticing that they broke something. If possible in the respective tool broken polygons should be prevented from being written to file/uploaded at all. --MarcusWolschon 07:30, 14 November 2008 (UTC)

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.	fig. 1
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>	fig. 2
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> It is suggested to order the members of such a relation so that way(s) forming the first outer ring come first, then any way(s) making inner rings inside that, then the way(s) of the second outer ring and so on. However, processing software should make an attempt to bring members into the correct order if they are mixed up, which is computationally possible, just a bit tedious.	fig. 3
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>	fig. 4
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>	fig. 5
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>	fig. 6
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.	fig. 7

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

If OSM should one day be enhanced with a native "area" data type, then these advanced multipolygons could easily be changed into the new area type. -- User:Frederik Ramm 19:47, November 14, 2008; moved here from the main page

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.	fig. 8
The following example shows touching outer rings, a practice used historically, when we did not have other "hole" modelling: <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> In such a case the inner polygon might not even be required, the whole area is already completely defined by the outer polygons alone. But then we have the strange situation, that the outer polygons can also define an inner ring. <relation id="1"> <tag k="type" v="multipolygon" /> <member type="way" id="1" role="outer" /> <member type="way" id="2" role="outer" /> </relation> The ideal algorithm would probably construct the outer polygon from only thouse segments that are used by exactly one polygon.	fig. 9

--De muur 09:43, 9 February 2009 (UTC) // wording changed --Frederik Ramm 18:49, 16 February 2009 (UTC) // some changes did not comply with my intentions --De muur 09:02, 20 March 2009 (UTC)

The touching rings are not only a matter of backwards compatability, the mappers will still expect these from the multipolygon relations in the future.

The example case is a forest with a lake and a beach inside. The mapper wants to enter the beach and the lake each as a single way, thus the forest relation would be as in illustration number 8. If this approach is wouldn't be support any more, the user would be forced to create for both the lake and the beach own multipolygon relations just for the definition of the inner ring of the forest. I don't think, such an approach would be accepted by the community.

And I don't see any reason, why illustration numer 9 should not be recommended. It is just a second way of "hole" modelling with multipolygon relations. It is not harder to implement, so I think both both ways can coexist next to each other without any problems.

--De muur 08:04, 17 February 2009 (UTC)

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. -- User:Frederik Ramm 19:47, November 14, 2008; moved here from the main page

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. -- User:Frederik Ramm 19:47, November 14, 2008; moved here from the main page
• Implementation for Compatibility: --Stoecker 15:50, 29 December 2008 (UTC)

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

-- FWIW it makes a lot more sense to me from a data model standpoint to tag the outer area's way and not the Relation. Feature Relations are a different level of abstraction from on-the-ground coordinates. Relations are meta-features concerned with database keys (outer way=way ID 12345, inner way=ID 12346), while area boundary tags connect real-world ground coordinates tagged to real-world trees. i.e. don't mix the computer-level and the real-world stratas, keep the relation meta-tags at the same level of conceptual abstraction, and don't fragment area tags into special case exceptions when there is really no reason to. Or am I missing something? --Hamish 04:33, 13 April 2010 (UTC)

Think about boundary multipolygons. The same way can be part of multiple boundaries. This cannot be tagged on the outer ways. I expect that there are other examples with non boundary multipolygons. (And tagging the multipolygon makes it MUCH easier to implement.) --WanMil 19:17, 15 April 2010 (UTC)

I suggest that if there are "normal" multipolygons with one usage to tag the ways, not the relations. I would hate to see all countryside full of empty parts of ways (please try to imagine) which only join up in different multipolygons to landuses. Keep It Simple! -- Malenki 16:25, 12 January 2011 (UTC)

I agree with Malenki. If something can be tagged in a simple way, do so. Use multipolygons or tagging on the relation only for very large or complex objects where it is necessary. Otherwise, you just needlessly confuse mappers or scare them away. --Nop 17:36, 12 January 2011 (UTC)

Any part of a multipolygon way can describe other features not related to the MP as well. Like a simple parking area can additionally carry barrier=fence to describe the fence around, something like that can apply to any inner or outer way of the multipolygon as well. I would suggest to handle that using a dialog window like when joining two already-tagged ways to one in JOSM: three columns: keep at outer, keep at inner, mp relation only; with every possible combination allowed. --Jongleur 17:54, 12 January 2011 (UTC)

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) the relation has tags

Use the relation tagging. Ignore anything on the ways.

I'd disagree with this; this means that if someone adds a single tag to a relation, all the (matching) tags from the outer ways are blown away. Wouldn't it be better to apply the other rules, and then take the relation tags and add (overwrite) them at the end? (I haven't made any change to the page) --EoghanM (talk) 10:30, 6 June 2016 (UTC)

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

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

The Lago di Garda is a good example of multipolygon that should bear different tags on its ways. If the tag natural=water is on the relation, some ways could bear the tag natural=cliff (I know that JOSM warns that cliffs shoud be areas, but I know lot of cliffs that are realy vertical). The cliff is physicaly the limit of the lake and the way representing it should be part of the relation of the lake, unlike a river that is conventionnaly a boundary. So it is interressing that ways shoud have different sets of tags, if the relation is well tagged. FrViPofm 08:36, 28 April 2009 (UTC)

I don't think its reasonable to use the same way for the lake limit as for the cliff.

It is very often the case, that a forest is limited by a road. Today it is common practice to use two ways in such a case, one for the road and a second one for the forest polygon. Should all these case changed to multipolygon relations so that we can use a single way?

We also draw two ways, when two area polygons are touching each other. Should we also convert all this polygons into multipolygon relations so that we can use single ways on the boundaries? --De muur 07:48, 5 May 2009 (UTC)

I agree. A continuous way marking a road or a cliff and a seperate, closed way marking a forest or a lake is easy to understand, easy to edit and easy to render. Breaking this apart in arbitrary segments and rejoining them with a complex multipolygon would produce something confusing, error-prone and hard to process. It is far better to keep to the current practical approach. --Nop 09:01, 5 May 2009 (UTC)

c) Some segments have completely different tags.

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

I disagree; sometimes someone comes along and creates a multipolygon relation to show that two ways are part of the same entity, e.g. version #1 of http://www.openstreetmap.org/relation/4007477/history I think we need a policy on what to do in this case (maybe treat it as if the relation didn't exist) --EoghanM (talk) 10:15, 6 June 2016 (UTC)

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 proably will be used for some time.

This is only true for the simple case of one relation membership. As soon as a way is a member of several relations and they all have tags, there can be conflicts/race conditions between multiple values for the same key. --Nop 09:01, 5 May 2009 (UTC)

• 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. --R2D2 19:02, 3 January 2009 (UTC)

Ordering of relation members

In the text above it is stated that relation members should be ordered. However the current API doesn't support ordered relations. It is anyways required that the processing software sorts the ways, because some might be in the wrong direction, etc. So I would propose to drop this requirement. It just puts a burden on the users and doesn't give much benefits. It might instead be a good idea to write a general preprocessor that converts the multipolygon relations to a better machine readable form. --R2D2 19:16, 3 January 2009 (UTC)

It is obvious that software will have to try and work with "bad" relations but I'd like to stick to the "Be liberal in what you accept, and conservative in what you send." principle. We should make an attempt to properly order data in the data base. Clients should nevertheless make an attempt to work with data even if it is not ordered. --Frederik Ramm 01:26, 23 January 2009 (UTC)

Rendering

• Are the advanced multipolygons rendered? I have problems with it here. --Cohan 00:34, 24 December 2008 (UTC)
• JOSM is able to render these advanced multipolygons since revision 1203 --Stoecker 23:14, 1 January 2009 (UTC)
• A patch for Osmarender (T@H) is available in Trac-Ticket #1435. --R2D2 19:02, 3 January 2009 (UTC)

Using 'advanced' multi-polygons (commentary)

Advances multi-polygons are going to be very useful. If tool-makers are wanting to check real life uses of these advnaced multiploygons then here are some places where they are tested (add other examples to the list):

• Heislerville Wildlife Management Area
• Lohjanjärvi at http://www.openstreetmap.org/?lat=60.224&lon=23.968&zoom=11&layers=B000FTF
• Large Russian lakes use multipolygon together with coastlines
• large forest areas in southern black forest
• more?

-- User:PeterIto 14:30, November 23, 2008

I disagree. Isn't this advanced multipolygon needlessly complicated? I can see the merit of the first use cases, but starting with multiple, seperate out rings it appears to me that two relations, each handling one outer ring and its contents would not only be much simpler to implement technically, it would also be much easier to understand and handle for mappers. I find many of the more complicated use cases very far-fetched and confusing and can see no real application that couldn't be drawn in a much simpler and readily understandable way.

Not everything that is technically possible is necessarily a good idea. Humans need to be able to understand it, too, to use it. I would prefer simple constellations that don't need a lot of background knowledge and that are available in most tools/renderers in the same way than complex constructs you cannot rely on. --Nop 16:57, 24 February 2009 (UTC)

I also think, that these advanced multipolygons are far too complex. They should not only be computer readable but also human readable. I therefore would suggest to implement two new relation types: 'polyline'[1] and 'group'. The first is for combining short ways to very long ways or areas formed out of multiple ways. 'group' would combine nodes/ways/relations which belong together. If then multipolygons could also carry relations not only ways, things would be very easy again. Only disadvantage would be a higher number of needed relations, but I think the advantages preponderance. -- Andre68 09:21, 25 March 2009 (UTC)

Experiments with multi-polygons

Today I experimented with multipolygon relations and inmho its a good solution in some cases and they are quite easy to handel with the latest version of Josm. I write this because there are multiple open ends in this discussion/talk.

I am going to try to explain what I did, but best look for yourself first http://www.openstreetmap.org/browse/relation/189527. I used the relation as a kind of polyline to combine serveral ways to a closed line. Most of the ways already existed and they define the border between different areas with different landuses (forest/residential/industrial). Those ways in the relation are tagged with outer, are not sorted and dont run in the same direction, so that even ways tagged as oneway=yes can be used. Even closed ways with the tag inner are used. The name and landuse tags are in the relation, cause the "area" consists of multiple different ways and editing is easy this way. Ways that would be normally only tagged with landuse=* are empty, but thats not a problem, they might be tagged with a kind of landuse=border tag or left empty.

There are two other possibiltys to gain the same result:

First I used the same nodes for the way and the two areas with the different landuses. The problem is that it is quite hard to edit such a constellation of ways, cause there are a way an two areas lieing on each other. When I put another node in the bordering way I need to put nodes in the two areas too. Then I need to combine the three new nodes and reposition it. If the areas are made up of the multipolygon relations and the way is in either of that relations there are not such problems. The areas inherit the new node because the way is part of the relations.

The second possibility is to draw the areas next (close) to the way, but then the rendering is dirty and the editing is nearly as complex as above.

As far as I can see the relations are rendered correctly in Mapnik and Osmarender http://www.openstreetmap.org/?lat=51.45308&lon=7.93995&zoom=16&layers=B000FTF. In my opinion this is a good way to solve the problems described above.

--Hillhome 19. August 2009

Advanced Multipolygons are not backward compatible [solved]

The sentence at the top of the page is Please see the section "Advanced multipolygons" for an extended but backwards compatible. I do not agree with this statement, and it looks to me this has contributed a lot to the type=boundary dispute, it's creating problems in usage, and using the data becomes more difficult.

I don't say the concept of advanced multipolygon is bad, I would even say it's much better and much logicial and more extensible that the former (basic) multipolygon. But there is a big difference (or else I've missed something) about the properties of the modeled object and it's inheritence to members of the relation.

For (basic) multipolygon we have Tags describing the multipolygon should go on the outer way For Advanced-multipolygon we have It is suggested to apply all tags which describe the area to the relation, and not to the ways

The more logical approach to me seams to put properties in the relation, if we suppose a forest made of 10 outer rings, it looks duplicate work to tag landuse=forest + name=xxx + wood=coniferous on every 10 members forming the outer way.

BUT ! yes, but, we have a conflict, type=multipolygon is used for both cases.

• 1) Either advanced multipolygon users sends their legions to flood (basic) relations
• 2) or we programmaticaly consider that if there is at least one tag in the relation then it is a (basic) multipolygon (explanation of the created_by bug presence ?)
• 3) or we define a type=advanced_multipolygon to make every thing clear
• 4) or, what we are doing now (connecting to 2) ), we let basic multipolygon die on their own being slowly replaced by advanced one, and, having, during the mean time, continuous wars for nothing, rendering problem, osm edit wars, disputes, duplicates like type=boundary (that are true advanced multipolygon but with different words)

sletuffe 14:57, 31 August 2009 (UTC)

One problem with compatibility is that the description of advanced multipolygons (and the API 0.6 limit of 2000 tags) encourages usage of multipolygon which breaks existing functionality for ordinary closed polygons. An example is natural=water as a closed way around a lake (the traditional way documented on the wiki page, saying the way must be closed, i.e. a ring), but when the new usage model of multipolygons (allowing for non-closed ways as part of a multipolygon) breaks compatibility with the old model of representing lakes. See http://wiki.openstreetmap.org/wiki/Talk:Relation:multipolygon#Multipolygon_should_consist_of_polygons_rather_than_ways for a more extensive text with a suggestion on how to put big lakes on OSM with a way that retains compatibility with old natural=water polygons. --Jkp 11:46, 3 May 2010 (UTC)

I think the case is solved using my solution number 4. Description of "old-style" or "basic" multipolygon in the wiki page has been removed, and a lot of multiploygons have been converted to new style with tags on the relation (beside source=* in some cases where the source of outer ways is not the same for the entire multypolygon). sletuffe 23:31, 22 January 2012 (UTC)

Advanced multipolygon and pyramidal construction (aka super-relation)

Could it be interessting to add the possibility for relation (advanced) multipolygon to have other relations as members ?

what ever their type=* are, the members relations will have their ways and relations's ways (and relation's relations's.... ways) added to the "calling" relation ? in a pyramidal constructed manner.

properties of the called relations will be ignored in the construction of the calling relation and properties of the calling relation are not sent to the members relations.

I know that no tools support this for now, but, as ever, tagging comes first. That would be especially good in boundary relations. I know nothing however of the complexity to implement in data processors tools (osm2pgsql) sletuffe 15:10, 31 August 2009 (UTC)

tagging the advanced multipolygon model "inner" polygon case

Following a discussion on tagging list :

Emilie said :

> Landuse should be exclusive by definition. As

> someone pointed out before in a separate message, this is trying to be a

> work around the fact that to some extent landuse is broken in some cases.

> We would like to avoid having two super imposed landuse as much as possible.

That is to say : using more multipolygon relation to model "holes" or, in this case, landuse included in landuse.

I've been a great fan for a few time of those (advanced) multipolygon for solving the hole case. (Hole case which was, remember, the first solved problem by multipolygon relation)

At that time (I think ?) it was created because holes where nothing, but as more and more landuse/natural/... tags are created, we could imagine an osm database where not even a single area is "nothing".

In the holes continuity, it as been proposed that an area representing something inside another area would still be part of a multipolygon relation but with it's own tags.

this sounds great, requesting the surface of the big area is strait forward, rendering become easy (no "which one is over which one"), such a puzzle makes it easy to find problems, etc.

But, this becomes harder and harder for the mapper. A big forest containing thousands lakes ? a landuse=residential containing park, cimetary, etc. ?

I fear not every one is gone a make the effort.

Emilie :

>Anyway some of the comments you are making are making sense but it is just

>relying on the renderer to get it right.

+ somewhere else on talk or dev or I don't remember : "we don't want to create priority hierarchies among landuse/natural"

And after all, is it at all needed ?

In the "area inside area case" (not the partially overlapping areas case) We can resonably imagine that if a mapper has added such an area inside another, then either : - they can be both (a military area and a forest) - they can't be both (a lake and a forest)

Maybe if we just define/explain/(do our best not to create same key incompatibility, juste like this boundary=military propose to replace the ambiguous landuse=military for some cases) Same for natural, then what we've left ?

A lake inside a forest, is not a forest A cimetary inside a residential is not a residential etc.

Let's put the burden on computer programs and free mappers : why not, instead of the layer=* "tag for the rendering" patch, consider that any area inside another should be automatically not considered as part of the overlapping area (thus automatically constructing "holes") ?

(and then)

My point was to stop or not to stop harrassing mappers that do not include inner polygons. and/or not updating the wiki acordingly, giving the choice, mentionning that solution. We could let decide, but give clues about what's for what. sletuffe 16:13, 15 October 2009 (UTC)

From notes :

The page used to have : Plea: if tagging riverbanks in hi-resolution areas the areas should be optimized to a small size since loading in the editors takes too long and slows down editing!

This note seams to suggest decreasing quality of riverbank that are available in hi-resolution, I think that the better source we have, the better we should map, and if it's too big to load in editors, then create a multipolygon relation and cut outer ring in more and smaller part sletuffe 08:57, 24 November 2009 (UTC)

Lake Champlain still not correct

I can see nothing wrong with the relataion, but T@H does not seem to be able to render it. Also Opencyclemaps does not render this area correctly.

Changing the multipolygon from natural=mater to natural=coastline seems to have solved the problem. It does not seem that oceantiles had anything to do with the problem, as most of the lake is marked as land. Hopefully this will also solve the problem with opencyclemaps.

It looks like it's finally working without any workarounds (tagged as natural=water) --Marko Knöbl 11:31, 6 October 2010 (BST)

Explain please

As ways have a direction, why don't we just state left or right for a relation.

Then you just add the relation and mark it as left or right of the way.

The only down side would be if you have a lake and some of the ways are clockwise and some are not. This would not effect the renderer, but might become confusing for mappers.

I think it's just that it's less intuitive for mappers. The nice thing about it though is that it would allow a renderer to correctly render the portion of a multipolygon within a bounding box given only the ways in that box, rather than needing every way. --Hai-Etlik 21:12, 14 March 2010 (UTC)

Holes in holes (in holes...)

In the article there is the point holes in holes with the comment "no picture yet". But if i see correctly this is exactly the same as the island-thing more upwards.

Not sure if I should correct this or if it is intended. --NobodysNightmare 08:13, 23 March 2010 (UTC)

Multipolygon should consist of polygons rather than ways

Here's my take on and against using non-closed ways as parts of a multipolygon relations, even though I may be somewhat (too) late into the discussion.

It seems usage of non-closed ways as parts of multipolygon relations outer's is relatively common nowadays. I think this has problems. Pedantically, these don't sound like multipolygons to me - rather this sounds to me like a "multiway relation forming a polygon", or "multiway" relation. According to the wiki "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."

However reading further on the multipolygon wiki page, there is the "Use case: Multiple ways forming a ring" - I think this is unwise, as it forces everyone and everything (every map rendering software for example) to know about multipolygons. A practical example is lakes, originally closed areas bounded with natural=water. Now that people have started using these "new-style" multipolygons, that practice has changed what a normal polygon is and how it works, and lakes have started disappearing from the maps of renderers which are not aware of multipolygons.

Since API 0.6's limit of 2000 points for a way, big lakes (like Saimaa in Finland, just one part of which can be seen via http://betaplace.emaitie.de/webapps.relation-analyzer/analyze.jsp?relationId=405925 or http://www.openstreetmap.org/browse/relation/405925 ) can't be drawn with just one way for the outer ring.

However, rather than trash the "closed rings" requirement which breaks lake rendering for every software which doesn't learn multipolygons, I think a much better solution is to use several adjacent normal polygons to define the lake parts, i.e. to divide a big lake to several parts each being a closed natural=water ring, and then combine them to a multipolygon relation with touching outer rings, like the 506925 relation linked above has. This way of representing lakes works fine with for example GpsMid, which currently doesn't grok multipolygon relations. Depending on rendering style there might be some trouble, like lines in the middle of the lake, for example, if the shoreline has a different color than the lake. But these can be eliminated by adding the support for multipolygons or adding support to recognize adjacent polygons.

However, on the wiki page there's the following passage:

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

I first thought touching polygons are not intersecting, but the above wording seems to imply the OGC Simple Feature standard says otherwise, thus it would seem touching is intersecting. However, if there's an exception for touching in inner polygons of a multipolygon, I propose an exception created also for outer polygons to make big lakes possible without forcing the world to be aware of multipolygon relations.

There's also wording on the wiki page which would apply fine with touching outer 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. 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. " - in addition to the individual tagging, also the API 0.6 limitation of 2000 points has created the case where adjacent polygons part of a multipolygon relation make sense. --Jkp 09:06, 3 May 2010 (UTC)

I've been thinking about both approaches a few time : "A big lake is a sum of ways for it's outlines, or is a sum of surfaces for it's full surface". I finally decided against the puzzle thing, has I find it having more flaws than "the ways forming outlines approache".

• In the puzzle case, the consistency checks are harder to create, if a puzzle piece is missing/not closed/broken, then the whole will have a hole and will be broken for it's area and shape. (in a 3 puzzle pieces lake, it doesn't makes much difference, but in the boundary case of France, a 36600 pieces puzzle has greate chances of beeing broken all the time). And because we need one consistent tagging I don't feel well having 2 relations construction methods
• In the puzzle case, the "old style" renderer you are talking about will still need to know where to put the lake's name label, giving a name to every pieces is a duplicate effort and doesn't help rendering much. So you'll have to process the relation consisting of all pieces, and I feel, (but I haven't developped that) that it will be easier to process ways and connect start and end node, than merge a lot of surfaces to construct the final shape. sletuffe 10:49, 18 May 2010 (UTC)

I've checked the lake you are talking about to see how you constructed it, and I see a few flaws in your method :

• Suppose I want to add it's english name (name:en=XXX) I'll have to navigate thru all puzzle pieces of your lake to copy the name dozen times
• Suppose I'm re-drawing a shore with high quality image resolution, If I go over the way point limit, I'll need to cut the lake in even more pieces
• Suppose I then when to add a meta-information on that shore and give a source, or a note different from the one the big pieces has, then I'm not able to do that so it's harder to know wich part has been done with Hi-res images and which hasn't yet sletuffe 12:48, 18 May 2010 (UTC)

Issues rendering adjacent multipolygon relations in large lakes, proposal for solution

In Finland, there are big lakes consisting of several adjacent multipolygons. Mapnik has some issues with drawing these.

Issue one - some tiles have problems. See for example the triangle at http://www.openstreetmap.org/?lat=62.8399&lon=27.741&zoom=14 - I suspect the issue is that Mapnik assumes the empty triangle in the north-west corner of the tile is land because it's limited by a water multipolygon. In reality the corner triangle is water as it belongs to another lake&island multipolygon.

Issue two - there's a fine line separating the different multipolygons - you can see this also at the same location http://www.openstreetmap.org/?lat=62.8399&lon=27.741&zoom=14

It might not be easy to render these adjacent multipolygons properly without some additional data in the relation. One possibility to mark multipolygons as adjacent would be to mark the "imaginary" (which should not show on map) borders as a separate role, i.e. role outer_glue. Then rendering software could remove the artificial/ imaginary borders when rendering the mape, and rendering artifacts would not be seen on the map. Alternatively, the bunch of adjacent multipolygons could be combined to form one big multipolygon when rendering with the help of the outer_glue marks. A requirement would perhaps be that the outer_glue paths be marked with one way which is common to both relations - this could also be used as a link to the adjacent multipolygon(s). --Jkp 14:32, 17 May 2010 (UTC)

Don't tag for the renderer ;-) Creating artificial "outer_glue" way that are nothing in order to help one renderer is going into the wrong direction to me. See my previous comment sletuffe 10:56, 18 May 2010 (UTC)

id vs. ref

The examples on the article page use the "id" attribute within "member" elements. Doesn't the "ref" attribute make more sense, and wouldn't a realistic example use much larger and non-repeated values than the repeated 1, 2, 3, ...? Jose X 06:41, 22 April 2012 (BST)

The "ref" attribute is what the .osm format actually uses, so I'm not sure why the examples use "id". Unless someone can explain this, I suggest changing it. As for the values, a realistic relation would of course have much larger values, but this would make mentally following some of the examples (such as File:Multipolygon_Illustration_6.svg) pretty difficult. So I think that using the unrealistic values is appropriate from a practical point of view. --Tordanik 14:24, 22 April 2012 (BST)

special case of touching outer (or inner) rings on one or more non consecutive points

Is it agreed that such a tagging : is a valid way of tagging a multipolygon relation according to this wiki description ? (i.e one type=multipolygon relation with touching outer or inner rings on point(s) only ? )

• If the answer is yes, could I add this example as beeing specifically valid so that mappers are more aware of such border cases ? sletuffe 19:07, 4 May 2012 (BST)

'outer' and 'inner' should be "closed lines" (areas)

I would like to edit the wiki-page in following subjects:
1. 'outer' and 'inner' should be "closed lines" (areas)
Exception: only boundary=administrative should be mapped as lines.
And huge areas/polygons can also be mapped as lines
(A few people from this talk-page has the same opinion.)

2. area-tags (i.e. landuse, leisure, building) only belong to the relation, not to the 'outer'

We had a short discussion about "using multipolygons" on German Forum.
Some arguments for 1. are:

• lower resources needed (because less multipolygons)
• view in editors is clearly arranged
• less errors: especially (but not only) new mapper have problems with multipolygons
• correct MP-errors is easier with "closed rings"
  

against:

• need more data, because touching areas link to the same nodes
• editing is complicated
• if lines upon each other, choose "right" line is difficult
  

against-against:

• a relation also need space (id, timestamp, uid, version, changeset, etc.)
• with "follow" (Key: F) and/or with ContourMerge Plugin it is easier.
• choosing "right" line with middle-mousekey/wheel
  

-- MasiMaster 17:49, 7 May 2012 (BST)

I don't understand what you mean in your 1. Isn't it allready the case ? The wiki page says : outer : "The ways making up the outer ring(s) of the area." So is is allready said that the sum of outer ways should form one or more closed rings. Is this what you want to make clearer ? sletuffe 13:53, 8 May 2012 (BST)

I want not allowed 'outer' with several (more than one) lines (see exception). There are 2 cases: First, areas should not transform into multipolygons. There are roads, tracks & borders, which are splitted, and parts of it form an 'outer'-MP-ring. A seperate closed line (using the same nodes) works well and is more simple. (You don't need a MP.)
Second, if you need a MP, the 'outer' should be a ring consisting of ONE (closed) line. -> I mean: don't split the 'outer' into several lines, which together form the 'outer' (like this). It is to complicated to edit this for the most user. -- MasiMaster 14:57, 8 May 2012 (BST)

Ok, I understand what you meant now, and I oppose this amendment to the wiki because that's how MP have always been, and I find many advantages to this. Superposing ways with the same nodes is still possible however, but both method can co-exists and both have advantages and drawbacks sletuffe 15:04, 8 May 2012 (BST)

I think MP starts with "areas" as 'outer' and 'inner'. Then, only to create huge areas/polygons, it was allowed to split areas into "connecting lines". In this situation, both methods have more pros than cons. But transform everything into a MP, which using "connecting lines" (like the example-link in my last post), it is definitively not editable friendly. -- MasiMaster 18:35, 11 May 2012 (BST)

@sletuffe: It's indeed not true that multipolygon relations have always allowed non-closed members. Back in 2009 that was still an extension called "advanced multipolygon". Note that the reason given for allowing non-closed members was "This is useful for multipolygons encompassing very large areas". So MasiMaster's suggestion is actually true to the original documented intent. --Tordanik 01:04, 14 May 2012 (BST)

My mistake. I forgot what MP were in the begining of OSM (One only outer way with tags on the way and not on the relation). Still, I like the new way of doing and both method can coexit (one or more) sletuffe 20:40, 14 May 2012 (BST)

I'm not sure if I am right or wrong about this matter, but what I think is that we are too few to discuss that matter here, and a 2 vs 2 (User:Willi2006 shows he is not agreeing to this change) is not clearly showing that this proposed change to the wiki's multipolygon page should be done now so quickly. I propose to stand by what the page was before the change, and ask for more users on the tagging list (I'm sending the email). I'm reverting the page to what it was, and suggest we should gather more view point before applying such a change which clearly ask mappers not to use multipolygons like lot of examples are shown. sletuffe 16:11, 7 June 2012 (BST)

I think the change is not acceptable. Multipolygons are designed to work with arbitrary numbers of ways. (We used to have "simple multipolygons" and "advanced multipolygons" but nowadays we only have the advanced form; it is possible that you stumble across old wiki pages that only described the simple variant.) What you can do is put in a sentence that says "ways used for inner and outer rings will normally be closed ways unless there are practical reasons to split them up". Otherwise, people will stop re-using e.g. a road that delinates a forest boundary, and instead draw a second way for the forest that uses all the same nodes as the road, which is bad practice. Also, software authors must be aware that they need to support arbitrary numbers of ways forming the rings. This is not a "niche use". --Frederik Ramm 21:21, 7 June 2012 (BST)

It seems we disagree on what constitutes good practice. I think that "ways used for inner and outer rings should normally be closed ways unless there are strong practical reasons to split them up". Some people may consider it "practical" to turn adjacent closed ways into multipolygons just to avoid, say, 10 sequential shared nodes, and I clearly don't agree with that assesment. Relation editing is less intuitive than basically any other editing operation in OSM and is therefore rarely the best choice if there is an alternative. While these relations might be somewhat easy for an experienced mapper to create, they are not even remotely beginner-friendly. --Tordanik 22:32, 7 June 2012 (BST)

I also strongly disagree on what is good practice. Complex multipolygons are a niche use, as they are not understood by casual mappers and not even supported by the main editor Potlatch. They can only be used by a few dedicated experts which makes them niche. I believe this is becoming a problem as this excludes the majority of mappers from adding to or changing the complex constructs. This frustrates new and casual mappers and cuts off OSM from the majority of support and new data in those areas. Techically, complex multipolygons are a workaround. The API and data structure of OSM ist not designed for multipolygons, which makes them so difficult to understand and cumbersome to handle. Until multipolyons are supported by the API, it would be great if we could agree to use the current workaround only for huge structures where it is definitely necessary and describe simple things in terms which all mappers can use. --Nop 08:40, 9 June 2012 (BST)

OK, revert is ok for me (for now). There are some reasons, why i tried to change this page: I think, non-closed ways forming an outer was (only?) imported to create areas which use more than 2000 Nodes. I don't found a voting about using also for small areas. So I tried only to correct (not to edit the meaning of) the page. In german-Forum most of the users (maybe 70-80% ?) also think, outer-rings should be closed. (Right, Germany is only a part of the (mapping-)world.) I miss them speaking here. Right, multipolygons has developed itself further, but i think it is allowed, to question: "is it going the right/good way". -- MasiMaster 21:19, 8 June 2012 (BST)

I take and accept these as personal opinions. But to me it sounds strange to (mis)use the term "good practise" in favor of personal taste. Are there any figures that only a few dedicated experts can handle them and new and casual mappers are frustated by them? These claims have been made over and over in the German forum without any proof. Why is it a workaround? And if someone thinks so it's up to him to come up with a better approach and implement it himself or convince someone to do that. OSM was and is a result of doing not of complaining. The fact that there are only few restrictions has and still allows creative usage when mapping and processing the data. Neither on a mailing list nor on a forum I saw similar complaints about multipolygons from someone who is developing or operating the OSM database or any of the major applications like Mapnik, mkgmap, Maperitive, free worldwide routeable Garmin maps.

Haven't the definitions in this wiki page been around for years and been understood and accepted by many mappers? Isn't it a matter of fact that not all people are the same? I never saw an organisation neither a voluntary nor a profit-oriented one where all members did or could do the same. Instead the principles were: Each person at the right place. And newbies start with simple tasks.

Willi2006 09:58, 9 June 2012 (BST)

Or the edge of the forest could be mapped on its actual edge with the road mapped on its cetre line, which is good practice. Andrew 14:34, 9 June 2012 (BST)

Discussions about multipolygons are recurring on the forum Germany again and again, e.g. Verwendungszweck and Multipolygonwahnsinn without consens and I'm quite sure there will never be one. Anyhow it was proposed at least two times to simply change this wiki page in favor of one's opinion. E.g. changing the fact that multipolygons can consist of more than one way. A fact which is written there for years without complaint and understood and used by many mappers. Each time there was objection against the intended change.

The change was performed. I reverted it and I think it's not necessary to discuss a revert of a change which is done despite strong opposition. Unfortunatetely I just added to the German thread but forgot to mention this fact in the revert.

Willi2006 02:59, 9 June 2012 (BST)

Recent change about validity of a multipolygon relation

Where was the discussion leading to this : [2] ? I'd like to participate in the discussion of what should be considered "a valid multipolygon relation" because I find this change at least unclear/incomplete or partly wrong. However, I do agree that what is "a valid multipolygon relation" should be made clearer, with examples. Let's discuss that ?sletuffe 15:53, 13 October 2012 (BST)

Where was the discussion leading to the 13 changes of October 13th? And today again already 6 changes.Willi2006 03:46, 14 October 2012 (BST)

Nowhere. See my previous messages over there, I've been asking to clarify things for long, but I guess few people are really interested in what "validity of multipolygon" in OSM context really means, and seams like not every one agrees on what must, what should, and what may. Looks like some are more incline to discuss that on the mailing lists, and I've sent an email yesterday on tagging (even if discussion seams to start on [dev] instead ) sletuffe 14:32, 14 October 2012 (BST)

New attempt at listing several cases and demonstrate validity and invalidity of multipolygon relations : Relation:multipolygon/validity sletuffe 18:29, 14 October 2012 (BST)

Another question is: Why is this chapter at the begin of the article? It doesn't make sense to explain the validity of something if the something itself is not yet described thoroughly, does it? In my opinion this would be better suited after the "Examples" chapter, or outsourced to its own wiki page (maybe together with the examples of invalid MPs). --Tyr 21:52, 14 October 2012 (BST)

agreed. sletuffe 22:00, 14 October 2012 (BST)

Definition of a "Closed Way"?

Hi! When is a way (or a chain of ways) considered to be "closed"?

1. The last node's position is the same position as that of the first node: the coordinates are the same.

2. The last node object is identical to the first node object: the node ids are the same.

What is the necessary prerequisite for a "closed way"? Marqqs (talk) 14:33, 28 November 2015 (UTC)

As I understand it, a "way" is considered closed when its first node's id is the same as its last node id. sletuffe (talk) 15:25, 28 November 2015 (UTC)

Touching inner rings

There are good reasons as to why boundary edges of a single multipolygon should not touch/intersect. Who/when/where ever claimed that touching inner rings are a valid multipolygon in OSM? As to my knowledge there has never been a vote on this. Why is this case claimed consent for? Certainly not because it may be part of the database, because any invalid multipolygon may be part of the database, as server-side validity of multipolygons is not checked at all. I'd move this case to the "invalid examples" sections if there are no dependable references inserted as to why this ought to be valid in osm. Most people, in the osm community and outside alike, use tools that were written based on the OGC norm, so a multipolygon is valid, if it can be assembled into a geometry that is an OGC multipolygon, period.. That's the only validity test we need to depend on, after all the types are not named the same by coincidence. If we, as a community wanted to have something different, or something almost like a multipolygon, we should have chosen "type=almost_a_multipolygon" or "type=osm_multipolygon" or "type=multipolygon_unlike_same-named_OGC_type" --Cmuelle8 (talk) 19:35, 15 January 2016 (UTC)

It also leads to the absurd situation that "boundary" segments become part of the area definition that have "outside" on both sides, and hence, are not boundaries. So we should not even discuss if that may or not be part of one or the other norm, but rather, if it may represent what's on ground: And a multipolygon with touching inner ring edges represents something we cannot find on ground. For any area on ground, all boundary segments of the area will have the inside on either one side or the other:

On ground we never include arbitrary boundaries to be bounds of an specific area, unless a boundary indeed has the inside of the area on exactly one of its two sides.

--Cmuelle8 (talk) 20:57, 15 January 2016 (UTC)

The multipolygon definition was designed, accepted and implemented in a long process. No vote required, as implementation is done by the tools and not by the users and the authors decide what they do. Touching inner rings are part of the specification from the very beginning of extended multipolygons and your theoretical assumptions are not enough reason to change this. If tools are not able to cope with this speciality they can transform them into OGC conforming multipolygons internally. --Stoecker (talk) 23:12, 15 January 2016 (UTC)

I've never used this acronym, but this could be a good starting point: *rofl* We now have yet another term to define: 'extended multipolygons' - thanks Dirk, but I'm not convinced at all. It rather looks like we should have had this community process at the very beginning, instead of excluding it. Someone supposedly misinterpreted the official OGC norm and the sole reason we still carry this in the trunk is the inability of that someone to admit a mistake. This is really poor standard for an open project. See, society has a common understanding of what an area is, our representation of it should not change that, and does not need to (the ancient greeks would turn in their graves seeing this) - even less so, if it's craftswork purely based on a devious joke by a small group of people in the project, not having been discussed or, worse, not an option for discussion and improvement. --Cmuelle8 (talk) 04:21, 16 January 2016 (UTC)

Btw, you are talking about a "specification", please enlighten the world as to where it can be found. A lot of people, including me, have trouble finding it. The fragments found so far, always seemed to be ripped from the OGC spec. --Cmuelle8 (talk) 04:26, 16 January 2016 (UTC)

For some time now in OpenStreetMap we have the "we are from GIS world we know better" attitude after we have been ignored as childlike before. This argument here is of that kind. OpenStreetMap has been born because the GIS world failed to fulfill the needs of people. The multipolygon definition of OSM has be born to solve the problems of OSM. We simply did not care about OGC much. The standard outside OSM is strict regarding geometry. The OSM multipolygon tries to be easy usable for users. The usual example for inner multipolygon is the wood with a lake inside which has a beach. In OSM that's three rings joined with a multipolygon relation. Without touching inners that's much more complex. Keep in mind that a multipolygon usually not only defines the area of the polygon itself, but also the inner areas. We did choose the solution which is easier for the users and let the software take care of the complexity. OGC has choosen the software-friendly version and leaves the complexity to the user. I think our approach is better. Nevertheless this wiki is not for wishful thinking, but it should document the reality. The multipolygon definition of OSM is there for years now. New software has to implement it as it is. And talking about standards and specification. Our documentation is the wiki. We are a community projects - that's the way it is done. And before you raise the typical wiki argument: If someone changes the wiki in an incompatible way, then it is changed back when detected. The fact that you don't know the term extented multipolygon shows me that you did not even take the time to understand the history and reasons of the current implementation - otherwise you would know that term. Neither is this discussion new nor do you bring any new argument - read the history and come back when you understand the OSM definition and have a valid argument. --Stoecker (talk) 10:28, 16 January 2016 (UTC)

Yes, exactly the point that this is not new should make you think whether these are justified arguments or theoretical assumptions as you downput it. We need a poll on this, the sooner the better.

Maybe the article on closures, boundaries and interior help to understand the problem. You claim that touching inner rings can be converted for tools not supporting them, but this is not true, as removing the boundary segments having an exterior to both sides leads to a different closure of the multipolygon, and hence a different subset of the topological space given by earth's surface, or unspecific: to a different area.

Having boundaries not enclosing the interior in a multipolygon simply does not make sense. It's fiction and OSM has a history of removing fictional data, for a reason. --Cmuelle8 (talk) 10:52, 16 January 2016 (UTC)

I'm not from the GIS world, but this simply is not something anything could be gained from having. It only wastes time and resources and I will not be the last one to raise this issue. You should not try to make this a personal thing, but the fact you do shows that having touching inner rings is an emotional thing. And to mediate on emotional things, voting has been invented. --Cmuelle8 (talk) 11:00, 16 January 2016 (UTC)

You're not an user's advocate when claiming that touching inner rings solve users problem. The opposite is true. There has been sooo much discussion on this in the past, because it creates rather than solves problem. And you seem to be just as ignorant about that as the GIS people you refer to. --Cmuelle8 (talk) 11:09, 16 January 2016 (UTC)

Luckily, computer pixels don't have an infinetisimal small size. So infinetisimal calculations (like closure calulation) don't apply to the computer world (at least not directly). Going away from the infinetisimal calculation, areas indeed have an interior and a boundary in the renderer. But for water, the boundary should never be rendered (as different water bodies can touch, and no border should appear there), unless special care is taken that the boundary is only rendered when there's exactly one boundary way there. That case would also solve boundary rendering with two touching inner rings. And the interior is no problem at all, that just stays the same whether you have one inner ring, or two touching rings. --Sanderd17 (talk) 11:25, 16 January 2016 (UTC)

Yes and No, the thing is that we (try very hard to) map what's on ground. It just does not make sense to explain to someone new, that we draw a boundary around an interior to map an area (which should be enough, always), but then there are "special" areas where this concept does not apply and boundary segments enclosing zero interior are added. In theory this adds up to addding 'a lot' of zero interior. If the boundary of a country or federal state is mapped, the community does not submit to such a flawed way to do it either. We do not include the inner boundaries of the nearest sublevel for a reason. I've written up something to cheer up this discussion a little, please do not take it too seriously, but it hits the core imho..

We make use of this concept called addition in osm, but unlike what you might have heared about addition in school or 'outside' of OSM, that might have made sense to you and others because it solved some problems, we use addition in a slightly different way. Addition outside of OSM is part of an evil GIS industry standard, let's not use that, as it's flawed from within. We're an open project based on participative principles, but our modifications to addition are very advanced and have long been thought through, so we took the short route and declare that a vote is not needed to introduce and make 'our' addition available to all of the community. After all, a bigger part of this community has been in great despair and long awaited this advanced addition to solve their problems in a better yet easier way.

Here are the rules and the 'specification' to use addition: Every valid addition according to how addition was defined in school or by this evil standard is also a valid addition in osm, but then we found if a>b it's beneficial to use a+b/2 as a result and for the addition of one and one let's use three as a result. These are the only notable exceptions, where an addition that is not an addition 'outside' of OSM is a valid addition 'inside' of OSM. Note that if you want to use addition objects outside of OSM, you can simply convert the objects by multiplying what they result in by a factor of 2.

Remember the golden rules of OSM: Have fun and do not copy evil industry standards without adding some more evil to them first. Sounds a little familiar? --Cmuelle8 (talk) 04:19, 17 January 2016 (UTC)

If for historical reasons this should be continued, it should at least be discouraged, imho, by portraying the three variants to handle the case and then let mappers choose. --Cmuelle8 (talk) 04:33, 17 January 2016 (UTC)

I think what Dirk refered to above was not "extended multipolygons", but "advanced" ones. I guess this is used interchangably then. --Cmuelle8 (talk) 04:46, 17 January 2016 (UTC)

In the majority of cases, a finer granularity of data sampling the reality is mapped at a later point in time, very possibly leading to some setup shown in the picture. If B and C were the only areas, with D and E added, then if A has been mapped using touching inner rings, D and E need to be added to the multipolygon definition of A - which is extra effort compared to methods that are valid in all three realms, osm+ogc+geojson.

Also, consider it is forgotten to update A after E has been mapped:

"A" will have a part as inside lying completely within an outside defined by touching "inner" rings, but _without_ that inside being defined as an "outer" ring in the multipolygon definition of "A". This is a mess, but considered valid by current JOSM, for instance.

In the meantime I've tried to find a truely open and free (read: PD licensed) document over at Open Geospatial Consortium and GeoJSON site containing definitions on the basic terms and math used. Something like a dependable, royalty-free to use and share glossary the least (e.g. something containing a dependable, disambiguous definition of the term "multipolygon"). Something that justifies title and mission of a "standard" document, something published to ensure interoperability of software operating on spatial data.

Ad hoc I was not able to find something like this, on either website. We (the osm community) do not have something like this either; we approximate a definition by giving examples and by refering to usage of the same term elsewhere (even though claiming not to care about how it is/was used elsewhere).

• Concerning OGC, the copyrighted standard SFA (Simple Features Access (Part 1)) (among possibly others like DE-9IM, WELL-KNOWN-BINARY (WKB), WELL-KNOWN-TEXT (WKT)) defines a thing called "multipolygon" in 6.1.14, but does not make use of an external glossary. This means the definition in that document is bound to the same license terms as the whole document (see page 2). The SFA-license grants, in short, free of charge usage and sharing, until the license is terminated. So the problem is, rights to use this standard is theoretically lost at a time X in the future, with X fully being determined by the OGC, citing from page 2 (LICENSOR is the OGC):
  "In addition, should the Intellectual Property, or the operation of the Intellectual Property, infringe, or in LICENSOR’s sole opinion be likely to infringe, any patent, copyright, trademark or other right of a third party, you agree that LICENSOR, in its sole discretion, may terminate this license without any compensation or liability to you, your licensees or any other party."

  I guess it's not impossible that someone claims patent/copyright/trademark rights on what a "multipolygon" is and/or how it is used in the SFA standard. This probably would force the OGC to use this license fragment to "terminate" usage rights for its licensees. This in turn might be the reason as to why some project members of OSM harshly and desperately want to keep touching inner rings considered a valid (despite the flawed math) multipolygon in the osm realm, because they might consider this as a way to say/indicate that a multipolygon in OSM is different than that defined in SFA standard.

  However, it is a much stronger argument that the concept of multipolygons will evolve anywhere areas are to be described, because it simply is a mathematically correct and fit way to describe an observable fragment of reality. Or, to use the analogy above: It simply cannot be proved that a culture or individual needs to be taught the concept of addition to find it.

• Concerning GeoJSON, copyrighted 2008 by its authors and licensed under a Creative Commons Attribution 3.0 United States License, "multipolygons" are defined in 2.1.7:
  For type "MultiPolygon", the "coordinates" member must be an array of Polygon coordinate arrays.

  This is a clear definition under a clear license statement, but since the terms "exterior" and "interior" are not defined sufficiently, a lot of geometry figures are declared valid that are either not needed or are unfit to represent observable fragments of reality / spatial data. This means, crossing or intersecting polygons within a multipolygon object are valid GeoJSON objects. This also means, that GeoJSON has yet another understanding of what a "multipolygon" is.

• Concerning the different ways the term "multipolygon" is defined or specified, within the (geo-)spatial data realm alone, leads to the conclusion that there is no "standard" wrt this term, but rather a set of different data formats using the same term for different geometry classes. However, as a mapper, if you want to be compatible to all of those, you can simply limit yourself to the intersection or "the least common denominator" representable by all of these different formats. At the time of this writing, this least common denominator is identical with how SFA uses the term "multipolygon".
  → This means if you want your data to be of maximal use to anyone, you should not use touching inner rings, even though some of the community consider them to be valid. --Cmuelle8 (talk) 20:15, 18 January 2016 (UTC)

A simple question: what do people see as a case to use touching rings?--Andrew (talk) 08:07, 19 January 2016 (UTC)

@Wynndale, an example is given right on the article page in the touching inner rings section. @cmuelle8, the term "multipolygon" is a misnomer (we use it for simple polygons also!), but please understand that it is not called "ogc_multipolygon" and therefore you cannot speculate about what might have been meant by it, or why it was not called "almost_multipolyogn" or so ;) if you have trouble working with touching inner rings, use one of the existing implementations that manage them fine. Don't try to re-define things that have been around for ages by claiming that nobody has never taken a vote on it. There are many things in OSM that nobody has ever voted on, that doesn't make them wrong. And there are many misnomers in OSM, beginning with the project name (we map much more than streets nowadays). This is not a license for someone like you to come along and argue that everything that is not a street should be declared off-topic. --Frederik Ramm (talk) 09:32, 19 January 2016 (UTC)

Valid variant to do touching inner rings according to geojson, osm and ogc understanding of "multipolygon"

This is claimed to be an additional way to do touching inner rings in osm, still conforming to geojson, but breaking ogc understanding of a "multipolygon"

@Andrew: It depends a little on your level of expertise. If you've mapped a very long time using multiple rings, you will find that, with the current osm multipolygon documentation (disputed here), some ground situations are ambiguous. This means you will (seemingly) have more than one way to use multipolygon relations to express the same setup on ground.

A typical example given is farmland adjoin a lake, both surrounded completely by a forest. There are four boundaries you can make out as a mapper: (1) The 'outer' boundary around all of the forest. (2) The boundary between farmland and forest. (3) The boundary between the lake and forest. and (4) the boundary between lake and farmland. With the current osm multipolygon documentation there are two undisputed ways to map this and one disputed one:

1. Draw ways representing 1 to 4. Add (2) and (4) to a MP for the lake, add (3) and (4) to a MP for the farmland, add (1) as outer and (3),(2) as inner to a MP for the forest.

Undisputed variant to do it, conforming to geojson, osm and ogc understanding of the term "multipolygon" (upper picture, right)

2. Draw a closed way over (2) and (4), tag it to be a lake. Draw a closed way over (3) and (4), tag it to be farmland. Draw a closed way over (1) and another over (3),(2) (overlapping parts of the closed ways already drawn), add the former closed way as outer, the latter as inner to a MP for the forest.

Undisputed variant to do it, conforming to geojson, osm and ogc understanding of the term "multipolygon" (without a picture)

3. Like last, but instead of drawing a closed way over (3),(2) add both closed ways ( the one over (2) and (4), the other over (3) and (4) ) as inner members to the MP for the forest

This is claimed to be an additional way to do it in osm, still conforming to geojson, but breaking ogc understanding of a "multipolygon" (lower picture)

@Frederik: First of all you seem to be making the same mistake as Dirk: I am not the only one arguing this way. You and Dirk should acknowledge the fact that this debate has been around for ages as well, and despite being muted to death the case did and does not have a reasonable basis to argue on - proven by the fact that it continuously pops up again and again (.. and again) and proven by the fact that the only two, repeated, arguments are:

• "it has been so for ages"
• "it simplifies mapping for users"

The first argument is true, but no justification to stick to it. You deliver an argument for this yourself: Just because OSM mapped just streets for a very long time, this was not a dogma when people started mapping buildings and other features as well.

The second argument has proven untrue. There is no dissent that it increases complexity on the programmers side. Dirks claim was that increased complexity on the software side, leads to easier mapping on the user side. This is not always true and it is not here. Adding touching inner rings to the wish list increases complexity on the mappers/users side as well. This is because it does not replace or simplify any of the allowed other cases, all of which already sufficient to express any ground case plausibly.

For the second argument to "work", increased software complexity must decrease the complexity on the user side. This is not the case here. Instead users are fooled to believe that an incorrect way to express a ground situation is a superior one. See the first picture on the right side of this section, this is where it will ultimately lead to: Having inner rings in the MP definition that are completely surrounded by other inner rings - for bigger MPs this will be a lot of extra data compared to other methods (that someone fooled by the current documentation might learn about or discover only long after having disputed with other of his fellow mappers). Failing to provide good documentation (which includes changing it, if we know better) leads to a chain of disputes by people consuming this documentation.

We consent on that a lot of features are documented without having held a vote - but this does not make them untouchable. If the community recognizes contradictions at a later point in time, a decision by voting and/or reasonable discussion by the people involved will establish a consensus later on. This is what might happen here, or be postponed irresponsibly once again to a time in the future. --Cmuelle8 (talk) 17:55, 19 January 2016 (UTC)

@Frederik: A dispute is a dispute, the banner does not make an implication of "how large" or "how small" it may be. It's just a banner with a hint, serving exactly this purpose, to draw attention to ongoing discussion (not started, but continued by me). --Cmuelle8 (talk) 19:51, 19 January 2016 (UTC)

cmuelle8, it is blatantly obvious that the upper of the two images is 'much' more work for the mapper than the lower. Still you claim that this has been "proven untrue". Please explain in one simple sentence why it would be easier for a mapper to create the situation in the upper image. Please stop talking of people "fooled" and so on, you sound like a politician. I don't see a "chain of disputes" either. I don't see that the lower picture is in any way an incorrect depicition of a ground situation - on the contrary, it is only incorrect if you have certain geometry models in your head, but for a non-technical mapper on the ground it is perfectly correct. It seems to me that you're on a crusade to make OSM easier for programmers (are you perhaps a programmer implementing multipolygon support somewhere?) and more difficult for mappers. Anyway, this wiki page describes how things are done and not how someone might like things to be done, and as such, if you put a banner on that saying "the factual accuracy is disputed", you are saying that things are 'not' done in the way described. That is wrong; what you want to achieve is that people change their behaviour. Which is a valid request to make, but claiming that "the factual accuracy of this section is disputed" is not the way to make this request. --Woodpeck (talk) 23:42, 19 January 2016 (UTC)

It is obvious that you did not gather enough experience from mapping various areas with different states of density yet, else you would not have blatantly judged on it like this. It seems to me that you try to protect a conservative state of something you've not yet fully understood. Of course I've made myself immediatly unpopular in your eyes having said this, but then I've been unpopular in your eyes before, so it does not really matter. Like Frederik and Dirk you do not strictly argue the case, but speculate on me being on a "personal" crusade on sth. Again, this is not a personal thing. For the most part I just repeat arguments from the past that have not had the proper attention needed. I vow what others bring up from time to time, but ultimately do not want to pursue against ignorance, which is why it has become easy to conserve, rather than develop some parts of osm.

Nevertheless, I have been patient before, so I will try to answer your question and deliver the sentence you asked for:

In dense areas it becomes crucial to map things topologically correct.

Having created the situation in the upper image you refer to, it is easier for us mappers to work on partial data afterwards. Your argument is static, you do not consider what will happen further down the road. Consider the first image in this section. It shows a state that might come about later, if we want to map the ground area in greater detail. Having used the method in the upper picture you can simply extend the data, even if only (4), the boundary between the farmland and the lake, has been in the bbox downloaded. You will not have to know or modify A, the forest data. This will be harder to do for devs and users alike in the disputed case. But you know, myself and others have written about this in great detail before, so you do not need me to read up on this, if you're truely interested in the implications. --Cmuelle8 (talk) 01:01, 20 January 2016 (UTC)

I've refered to the article about interior in Wikipedia above. You can use it to find, if you've truely mapped using kiss principles. Any MP defines boundaries around the interior, which means in turn that the interior should suffice to reconstruct its boundaries and a topologically identical MP using those. This is proven untrue for the disputed case: You will reconstruct less boundaries than those contained in the original MP (because there is no interior between touching edges). --Cmuelle8 (talk) 01:26, 20 January 2016 (UTC)

For the typical example given (and referred to by the pictures above) there is another simple observation everyone makes on ground:

The boundary between farmland and lake does not belong to the forest.

Mapping the forest of the typical example with a MP containing two touching closed ways as inner rings falsifies this observation. The boundary between farmland and lake is incorrectly added to the object representing the forest. This violates one of OSMs main principles, namely to strictly map what's on ground.

It introduces arbitrary fiction into the database and opens up a chain of disputes. Mappers currently can rely on the documentation to justify the topologically incorrect as well as the topologically correct cases to map such ground situations. That is only tolerable as long as it's not known any better. We could have known earlier if we had listened to and acknowledged some of the whispers explaining this before. --Cmuelle8 (talk) 20:59, 20 January 2016 (UTC)

Another popular belief seems to be, that software can currently deal with topologically incorrect multipolygons and distinct those declared valid by the documentation from those invalid. Take JOSM, it will render MPs with touching inner rings and the validator will not complain. But it will also render MPs with intersecting inner rings and the validator won't complain either. Of course, the validator should be fixed, but for this we need a clear understanding of what should be valid first. A validator validating against a broken specification/documentation is no good. As we've learned from discussions in the past, it's not easy to tell when a specification/documentation is broken, but a good starting point is to check, if it's in-line with some of OSMs main principles and/or objectives, see Good practice - Mapping what's on ground and Correcting errors are at the top of this wishlist; mapping topologically incorrect for doubtful convenience is not on the list. One feature, one OSM element from this list might be worth exploring as well. --Cmuelle8 (talk) 21:45, 20 January 2016 (UTC)

Two points to this. First, we don't have any numbers, but except for very few users mappers haven't used the "4 way" method, i.e. constructing the inner areas from separate edge parts with multipolygons, not because the "osm way" is allowed here on the wiki, but because it's harder and more work to do draw distinct ways and to create an extra relation from those, when drawing a closed way and adding tags to that suffices. Usability can be designed and improved by experts, but what counts more is what users do. Second, the "boundary between touching inner elements does not belong to the outer element" goes away when you approach this in another way: think you have three different coloured papers, and you cut smaller bits from two of them, and you glue them next to each other (touching) on the third, larger paper. What you now see of the background paper, i.e. the area around the union of smaller bits, is what you can interpret as the "osm multipolygon way". No need to consider closures or addition rules. Alv (talk) 17:40, 28 January 2016 (UTC)

This is bogus, and topologically incorrect: What you do in your example is overlaying areas. However the reality does not have the woods under the farmland or lake. To respect reality in your example you have to cut out the third paper as well and you will find that the border between the first two parts will not be in that hole. I agree that handling and usability of multipolygons can be better, but it's no justification to tell users topological incorrect data models are a 'good' thing. What users do is in part dependent of what software allows them to do (in the positive and in the negative sense). What experts should not do, is tell users that there is a simple way when it's incorrect. --Cmuelle8 (talk) 21:48, 1 February 2016 (UTC)

If a tree falls in the forest under the lake, but no one is there to hear it, does it make a sound? Alv (talk) 16:32, 2 February 2016 (UTC)

OT --Cmuelle8 (talk) 21:12, 2 February 2016 (UTC)

Touching inner rings forming hole

Touching inner rings forming a hole

As part of the effort to clean up old-style multipolygons and identify further problematic cases, the scenario shown on the right has come up. Two or more touching inner rings form a hole through which the outer area can be seen. This can occur when mappers refine large multipolygons. The innermost area is to be treated like a normal outer area (and may contain holes itself).

The result of the discussion, based on information from stoecker is that this

• is a valid case included in the definition of osm multipolygons with touching inner rings
• is supported by JOSM and other tools (it is also rendered correctly by Mapnik, either on purpose or simply due to z-order)
• should be documented with an example
• should be avoided by mappers.

It is recommended that mappers do not use this to prevent possible confusion and not further complicate multipolygons (for other mappers). This scenario can always be avoided by restructuring the multipolygon. However, mappers should expect to come across such situations occasionally, as restructuring may not always be performed (or the situation happened by accident, without the author being aware of it - such cases already exist).

If there aren't any objections, I'd suggest to update Relation:multipolygon accordingly (provided with an example picture in matching style, I can do it myself).--Wolfbert (talk) 18:57, 17 April 2017 (UTC)

I don't see why this should be avoided by mappers. This is the simplest way to map this. Every other approach would require at least 2 more OSM objects. In my experience, it's rather poorly written validators that get confused, not other mappers. --Fkv (talk) 20:03, 17 April 2017 (UTC)

Inner ring with multiple ways defining area?

In the section on detailed tagging, it says:

There is more than one inner way:
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.

This seems to imply that it is possible to define an area that has no corresponding database object (closed line or multipolygon). E.g. a forest multipolygon with an inner ring (consisting of multiple ways) tagged with "landuse=meadow" would define an area that is accessible only by assembling the enclosing multipolygon. This should be clarified, and I propose that multi-line inner rings are treated only as holes, but cannot define an area (without a separate multipolygon). Otherwise, a single multipolygon would describe multiple geometries with different tags.

Note: JOSM accepts this, but Mapnik completely fails to render the multipolygon (even though it's valid).--Wolfbert (talk) 10:18, 20 April 2017 (UTC)

Forget everything I said above, I was mistaken. I still like to believe that a multipolygon defines the area described by its tags, but it does not. It describes this area and all or parts of its holes. Case in point: a forest with lake and island (hole in a hole) will have a closed way with "natural=water" in the way table, but the island becomes only apparent after processing the multipolygon. As a consequence, all area processing requires an additional area table, and areas cannot reliably be processed from the database as-is.--Wolfbert (talk) 13:50, 20 April 2017 (UTC)

This is not wanted anymore. JOSMs code has not been reworked completely, but on next review we surely will drop all historic special cases. A multipolygon will then always only stand for itself (and the line style of involved ways). I'm not sure yet if we will support area styles on outer ways, but for sure an inner area style should not be defined by the multipolygon. --Stoecker (talk) 12:38, 15 May 2017 (UTC)

I changed the description accordingly. Joining style information never worked reliable anyway, so we can drop any mentioning of it and if there are cases in the database, they have to be fixed. --Stoecker (talk) 12:54, 15 May 2017 (UTC)

All tags that may be present on member ways with a "inner" role should be ignored in the multipolygon that has its own tags. Those inner ways may then have any tag they want, including conflicting ones, and these tags are set independantly of each other (so that inner holes may be representing different features.

That is how I described it, but I added a note about the drawing style of the way, which in worst case can be defined by all three objects for an inner way. --Stoecker (talk) 07:09, 16 May 2017 (UTC)

The legacy interpretation of untagged multipolygons that borrowed some tags from their member ways (in fact, borrowing all tags that were defined identically in all member ways without roles) should be dropped completely. As well the automated change of roles from inner to outer (or the reverse) should be dropped: roles should all be specified correctly (and the absence of role on member ways always interpreted as "outer", never as "inner"). — Verdy_p ^(talk) 23:29, 15 May 2017 (UTC)

That's too early. Snapshots before May still will have many of these. Maybe next year drop that note. And much too early to rely on roles. There are hundreds of thousand role errors waiting to be fixed. --Stoecker (talk) 07:09, 16 May 2017 (UTC)

Usage: Multipolygon relations are not Site relations

This is something I have been wondering for a while, should the "Usage" section of this page possibly contain a warning to not use Multipolygon relations as Site relations, analogous to the "Relations are not categories" Wiki page? I often see people "collecting" inner elements that are not true inners in the multipolygon sense, but just features lying within the bounds of some facility.

Classic examples are people creating multipolygons for "leisure=golf_course" and setting individual fairways as inners of the golf course and using the outline of the sports facility as the outer of a multipolygon. This is in my opinion senseless usage of multipolygons, and causes issues with visualization and cartographic symbolization of golf courses. Other examples I have seen: leisure=water_park with the individual leisure=swimming_pools in a multipolygon relation (which would be valid for a grass field surrounding the pools, but not the water_park outline itself).

The particular usage described actually belongs to the "Site" relation type, which allows tying together individual objects belonging to a site, which could be golf_course or water_park.--Mboeringa (talk) 13:39, 31 May 2017 (UTC)

It's definitely a type of error I have seen quite a bit. Not sure whether adding text to the wiki helps, though, as the page already uses language (such as "holes") that shouldn't lead anyone to assume that using multipolygons as a collection makes sense. So I would have assumed that the people who have this misunderstanding do already not read the wiki very closely? I might be wrong, though.

As an aside: While a site relation semantically fits the use case at hand, it also shouldn't be used in cases where all features are contained inside an area, as in your examples of a golf course and water park. --Tordanik 19:04, 31 May 2017 (UTC)

While I understand the desire to discourage using the site relations in favour of plain outlines circumfencing features, I also think it might actually be confusing, because the site page (not this one about multipolygon), now slightly suggests a dual nature of tagging for certain features, and that site relations may in fact be rendered, even if discouraged. While in reality, I personally see site relations only as a functional element to bind some stuff together, the whole basic principal of a generic "relation" in the OSM sense, and mostly as an "adminstrative" entity, allowing you to find stuff related through their relation membership, possibly by following HTML links on the OSM main website.

Considering site relations can contain literally anything, including other relations, I see very little - if any at all - use for them for rendering and cartography. It would be considerably difficult to make any sense of them in a cartographic context, or to process them in a relational database structure of a render database.--Mboeringa (talk) 19:11, 1 June 2017 (UTC)

IMHO, the case where an closed polygonal way has its own tag for the entire "leisure=golf_course" is valid (it covers everything, the grass, fairways, sand banks, water ponds, buildings, parkings, forests, gardens/parks, rocks, riverbanks...).

Then you can still have this polygon used directly as the "outer" member of a multipolygon relation with other "inner" member ways for holes so that you can build the grass areas: these inner ways will be tagged themselves as sand banks, water ponds, buildings, parkings as needed).

There's no problem for that: this is still not necessarily building a collection inside of the multipolygon for all sandbanks, it just says that these are holes not covered by grass, but the holes may be various kinds of features (grass, water ponds, riverbanks, rocks, buildings, pitches...), and not all fairways may be inner members (for example if they are surrounded by parks, gardens, pedestrian areas, parkings, buildings, swimming pools, tennis pitches, forests, beaches, hippodrom, skate parks, heliport, private residential or service areas, camping sites...).

To find all fairways inside the golf course, you'll need to perform a geometric search of fairways that fall inside the area of the entire golf course, which is still defined itself as a single closed polygon (or separate multipolygon, distinct from the multipolygon(s) used for the grass area(s) that are inside the golf course, and distinct from the closed way or multipolygon(s) which may be used for representing the surfaces of the fairways, or the surfaces of other components inside the golf course).

It is even possible that some of these sub-features may not be represetned as surfaces (for example only as nodes if these subfeatures are small and not clearly delimited: these nodes won't be part of the multipolygon of the entire golf course).

— Verdy_p ^(talk) 22:04, 12 December 2017 (UTC)

Verdy_p: I essentially 100% agree with all you write. In fact, almost each time I encounter a multipolygon having been misused to represent not the actual grass, but the golf course, I re-tag the outer to be a leisure=golf_course, and the MP itself to something like landuse=grass. This is in accordance with what you write. My reference to site relations was just because, if people really-really-really want to use a relation to "group" elements together, they should never use a multipolygon relation but a site relation instead.--Mboeringa (talk) 00:05, 13 December 2017 (UTC)

Multipolygons with an outer ring and inner rings which touch it

Multipolygon with one outer ring and two inner rings touching the outer ring

This is an example of a shape that isn't understood by osm-carto. I've read some things on this page that suggest that 'having inner rings that touch an outer ring should be avoided', although technically what this shape is could, I guess, be described in two different ways:

1. An outer ring with two inner rings that touch the outer ring, meaning the two inner rings should have the role 'inner'

2. An outer ring with two points at which two outer rings intersect with that ring, so the two rings should have the role 'outer'

osm-carto handles case (1) if there is only one inner ring. It gets confused however if there are two or more. It handles case (2) properly, but josm issues a warning about the self-intersecting polygon, and I'm under the impression that this (in form 1 or form 2) should be valid and not generate a warning.

So my question is, is (2) the correct way to map such a multipolygon or boundary? If the answer is yes, should I be lodging a bug with josm's multipolygon validator telling them that they should watch for cases where an (apparently) inner ring touches an outer one, because that makes it an outer ring, and despite being self intersecting, is valid? Skybunny (talk) 03:19, 16 June 2018 (UTC)

This is a borderline case. But note that this type of "multipolygon" can always be simplified by merging the touching inner and outer ways into the same way (the way will pass twice over the same touching node, but without crossing. In your example, a single polygon can represent it) ; This is possible even for forms like chess boards which can be represented by a single closed way passing one twice on many nodes.

But there are also other tools that do not like single polygons that have nodes reused, even if the lines do not cross at the touching node...

Which form to adopt ? In reality polygons like this do not exist, the common node is an approximation and either there's a small gap not represented (this gap is sometimes as large a a road padding between them and represented in OSM only as a line), or a small adherence along a narrow segment not represented (example with touching buildings). Use the form that best matches the reality.

— Verdy_p ^(talk) 05:12, 16 June 2018 (UTC)

"In reality polygons like this do not exist" - yes, such multipolygon is always a tagging problem that should be fixed Mateusz Konieczny (talk) 07:08, 16 June 2018 (UTC)

The "In reality...do not exist" note is irrelevant and should be ignored. It may lead to a serious professional error. Besides, such inner-outer area borders touching/overlapping cases do exist in the reality. For instance, just take the hydrographic 3 to 6m depth area presentation, where the 3 and the 6m depth lines define the outer and the inner borders in the MP presentation. Assume a vertical shore section of 10m depth. Here the 6m depth line will overlap the 3m depth line. Whether JOSM or other inspectors, detectors, renderes, editors... are handling these cases is something quite different. Robust GIS and rendering systems handle do that just perfectly.

"The order of the relation members does not matter" should be clarified.

It's not clear why order does not matter in this sentence. While whole next section "Valid Multipolygon conditions" describes why ways should be sorted to form valid closed polygons. There should be clarification, about inner and outer way order in order to keep polygons closed. What do you think?

Molind (talk) 09:58, 18 March 2020 (UTC)

Removing waterway from the list of keys which are used with this relation

DaveF63, I belive it is incorrect to have water=* in the list of main feature keys which can be used with this relation. The key water=* is never used alone, it as always used with natural=*, which is already on the list (natural=water). Previously waterway=* was mentioned because waterway=riverbank can be mapped as a multipolygon (waterway=dam and waterway=weir are also mapped as areas, but almost never as multipolygons).

So water=* should be removed. I think waterway=* should be mentioned, since it is one of the most common features which are mapped as multipolygons (Currently there are 47,750 waterway=riverbank multipolygons, it's the 7th most common feature key on that list).

Disjunct outers with the same main tags but different additional tags

Suppose I am mapping a parking lot with three disjunct sections, as an mp with three outers. amenity=parking, parking=surface, surface=asphalt, name=* are the same for the lot, so these go on the mp relation. The tags for capacity, fee and access tags differ. So these go on the outers.

Question is, will it work, and if not what is the problem at the map user side?

Looking at the information, everything is there. Routability and basic rendering is no issue I think. But can data users handle this? E.g. a map showing Parking capacity, you would like to show that per disjunct section.

The text suggest to use either the mp tags or the tags of one of the outers as one set of tags for the lot.

(I am talking about principle, not about solutions for this particular example)

--Peter Elderson (talk) 09:48, 15 July 2020 (UTC)

I doubt that most data users will be able to handle that situation. If you want to map the parking as one multipolygon, then please tag the total capacity of the whole thing. If access is different, say one part is an access=private parking lot for employees only, and another part is public (access=yes), then I believe these ought to be mapped as separate features. --Jeisenbe (talk) 05:00, 20 July 2020 (UTC)

I would not expect this to work and I would not consider it as a good idea. If entire parking lot is actually named (as entire structure) then it sadly gets tricky and I see no good way of tagging that Mateusz Konieczny (talk) 07:42, 20 July 2020 (UTC)

Page Clean-up

This page is a mess. I'm an experienced OSMer & half of it isn't clear to me. Please remember wikis are for people, primarily newbies, to learn. The KISS (Keep It Simple, Stupid) principle should be adhered to. It's definitely not a site for contributors to show off how much they (think) they know.

To start with, I suggest removing all XML code references. A newbie doesn't need(or want) to know about OSM's data structure when learning MP Relations. None of the main editors expose users to it. It's just confusing.clutter. --DaveF63 (talk) 22:05, 4 October 2020 (UTC)

Or maybe move the XML into some separate page if it can be useful in some cases. OSM Wiki can be used also by people developing OSM related software Mateusz Konieczny (talk) 08:52, 5 October 2020 (UTC)

I agree with you that the page is not well written for novices, but I'm not sure the XML code should be moved. I'm been around a few hoops and honestly this page still baffles me. I would love for there to be no-nonsense picture guides on how to map some of the simpler example (outer relation with inner relation hole) in ID and JOSM. I really don't what know what I am supposed to do with the XML code. Perhaps make it collapsible would be a start?--IanVG (talk) 01:22, 6 October 2020 (UTC)

I edited it a bit in attempt to improve it. iD and JOSM examples are sorely needed Mateusz Konieczny (talk) 07:24, 6 October 2020 (UTC)

Outline of Looping Structure with Multipolygon

I tried to describe an outline of looping bridge and split the outline to set the layers. Then I tried to use a multipolygon to integrate the outline, but it turns out that self-intersection without point is invalid. How should I describe it correctly? Otenkiya (talk) 03:03, 31 January 2021 (UTC)

@Otenkiya: Ouch. That is quite irritatting case, either you split single bridge in two (not good) or fail to record that this parts are not intersecting but on a different level (even worse). Not sure what to do - but adding note=this is a looping bridge that is passing over itself - not sure how to map it better would be highly useful for other mappers. Personally I would split it into two man_made=bridge areas and add mentioned note tags. Mateusz Konieczny (talk) 12:06, 31 January 2021 (UTC)

Hmm... To my understanding、multipolygon is a 2D mapping scheme, and some 3D scheme like "building:part" is needed to handle loop structures. OK, I'll leave a note for future improvements. Otenkiya (talk) 10:34, 1 February 2021 (UTC)

Island within a hole

The text below section "Island within a hole" presents the technique as a shortcut to have the multipolygon area type shine through the "hole in the hole". Yet, as long as its space is not excluded from the "hole" too, it actually just codifies overlapping of the area outlined by way2 (the hole) with the area outlined by way3 (the island). Imagine the hole being a pond, the surrounding being a wood, would it code for submerged trees? How to make this section concise? --Hungerburg (talk) 10:00, 8 June 2021 (UTC)

Valid multipolygon conditions

Since OGC Simple Features is named as a relevant standard the text shoud be consistent wth OGC-definitions. Where the text uses the tem "closed polygon" however I have the impression that instead "closed boundary" is meant. (Btw.:This would be a pleonasm because "boundary" implies to be closed).

I suggest to rewrite this section so that the validity conditions can be formulated:

• Members of a multipolygon relation must form valid polygons
• a polygon is defined by one or more valid boundaries
• a boundary is a set of ways or routes that conforms to the OGC-definition of a LinearRing (closed and simple)

Does anybody object? Quärtz (talk) 10:14, 12 July 2022 (UTC)

I guess, you refer to section "Valid multipolygon conditions". While it explains, what a "closed polygon" is, your change will make it reference the term "boundary", which is not explained in the text here. So you have to show, that both are indeed equivalent, before any changes to the verbal account of what a valid multipolygon in OSM is, otherwise you risk changing the definition of, what's a valid multipolygon in OSM data --Hungerburg (talk) 22:23, 12 July 2022 (UTC)

That is understood. Your comment addresses a major problem with this page (in general with the wiki-pages on multipolygon):

• it explicitely states the compliance to OGC Simple Features ("the multipolygon relation can be used to build multipolygons in compliance with the OGC Simple Feature standard")
• it does not consistently reference or cite the OGC-definition.

The OGC-definitions are consistent and complete. So inventing new definitions for existing OGC-terms does not make sense. If this text is intended to contain a definition of "polygon" it fails: it does not state that it deviates from OGC, but it does not match the definition of a OGC-Polygon (which is a 2-dimensional subset (a surface) that can have holes). Instead when reading it I associate a closed and simple LineString (a 1-dimensional subset of the Euclidean plane). So frankly I do not understand what is meant by the term "polygon" in OSM. Reading this talk-page and reading https://wiki.openstreetmap.org/wiki/Relation:multipolygon/validity I am not sure that there is a consistent understanding of this term in the OSM community.

Of course, there can be reason to deviate from OGC model, e.g. perhaps there is reason to have different concepts of "simple" or "connected". But then it is very helpful to explicitely relate to comparable OGC-terms and name the differences (as done in the case of "touching inner rings").

I am aware that rewriting the page (pages) on multipolygons addressing the problem described above is a major effort. But perhaps this section is a good start ([Wiki-help page[3]] says: “be bold”) Quärtz (talk) 09:03, 13 July 2022 (UTC)

There was extensive talk on OGC compliance, c.f. section Touching_inner_rings

In any case, I advise against using the term "boundary" in the explanatory text here, because boundary is something else in openstreetmap and this page addresses implementors of data consumers and newbie mappers alike.

Additionally, I do not see, how this new initiative is different from the ones above. Please show, if I missed something. --Hungerburg (talk) 10:43, 14 July 2022 (UTC)

On the main page, below "How to Map", the https://wiki.openstreetmap.org/wiki/Relation:multipolygon#JOSM example, that I put there as a single walk-through sometime got split into two sections, the second one featuring "touching inner rings". The method I used indeed creates a multipolygon, that is not valid according to OGC, as explained in talk above, because the boundary between the two inner rings becomes part of the most outer ring.

If I understand correctly, for OGC compliance, I would have to either create a way that traces the combined outline of the inner area, or split their outlines, thereby turning the "second" wetland from a simple polygon into a multipolygon too, so that the most outer multipolygon can reference only the ways, that separate it from its inners, leaving out the way that separates the inners from themselves. I did update the gallery, to spell that out in full in the most concise way, that I managed to come up with. --Hungerburg (talk) 10:43, 14 July 2022 (UTC)

Render issues with openstreetmap.org

Openstreetmap.org seems to fill multipolygons not correctly when selected. More precisely, the attributes of the relation are not used correctly for drawing. E.g. I have a temple as simple way, which is rendered as filled polygon: [4]. But a multipolygon relation with almost the same attributes is not rendered filled: [5] , so you can't differ which parts are the inner holes. But if I give the outline the attributes (historic=archaeological_site, site_type=temple and tourism=attraction), the holes are also filled. You can see the same issue on the parent relation.--Sinuhe20 (talk) 16:13, 16 July 2022 (UTC)

Exactly two unclosed ways, and no more should share an endpoint

The above statement is in the text and I think it's wrong because Exactly two unclosed ways can also share two endpoints.
I think it's better to write "An endpoint should connect exactly two ways and no more". --Kogacarlo (talk) 11:39, 22 June 2024 (UTC)