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) Any number (including zero) segments have no tags at all, but all others have the same tags

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

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

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

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.

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)