Talk:Multipolygon Examples

name=Coniferous

I do agree with User:MasiMaster about this change : [1] This page should not suggest to tag a thing like name=*=coniferous/decidious. "coniferous" isn't the name of the wood, even if inside another forest. Coniferous isn't a name but a type of trees. sletuffe 16:19, 7 June 2012 (BST)

Examples are just examples and not suggestions. All the more the names used in examples. In these examples the names are used to ease understanding and describing the figures. This is the same as on other wiki pages, e.g. Relation:multipolygon where the ways are numbered 1, 2, 3, ... way #1, way #2, ... Willi2006 03:28, 8 June 2012 (BST)

I think some people are lazy, they might just read the schema, not even read what it is about and just duplicate wood=* in name=* because there is no name they can think of. Therefore, I suggest this little change to avoid some misunderstandings sletuffe 14:30, 8 June 2012 (BST)

I think, there will always be some people who will misunderstand something willingly or unwillingly. But I also think it's no good idea to worsen the ease of describing and understanding the examples for the majority in the hope to eliminate any misunderstandings. That's about content. There's also the form. For me improving something means the change fits well especially if it's minor in regard to the whole content. Just putting a red stamp saying this is wrong and it should be "..." is just acting like a schoolmaster (German: "den Oberlehrer geben"). This might cause more confusion than help. And again this was done without discussion here. Reading the contributions in the German forum leads me to the impression this destructive change is impertinent and an intentional insult. This is sad and it's even more sad that it's spread to the whole community.

I repeat changing the names worsens the ease of describing and understanding. And changing the names only in the text is even worse and definitely no way to go. And also without discussion. Seems to be the new way to go in OSM.

Willi2006 03:41, 9 June 2012 (BST)

The parts may, or may not have names, but they're not name=coniferous. Just remove the names from the examples, or make it better by naming one of the smaller parts something like "Chaplain's Oaks". Even if examples are "just examples", and most IT professionals should understand that, we have lot's of users reading these, users who will look at any examples for guidance on tagging totally unaware of the (in)significance of each example to other features. Examples should always be correct in all aspects, not just the one aspect they're meant to describe on that particular page. Alv 12:55, 9 June 2012 (BST)

Just to make myself clearer, I said "I agree with User:MasiMaster's change" but truly I only agree with the idea of it, not the way it was done (red text like teacher advice that you might have found insulting) That's why I made a new change more inline with what allready was, without red text or "insults", just changing the examples, but still, you reverted it. I hope you don't find it insulting ? (this wasn't my intention at all) sletuffe 23:38, 9 June 2012 (BST)

Willi2006, please don't think it's a personal insult if someone tries to improve this page, it is not owned by you. The tag name=Coniferous is clearly wrong and because this a common error in OSM Data, we should avoid it in "text book" examples. Why is this tag needed at all? I think wood=coniferious is enough to tell the ways apart. --Bk 13:47, 9 June 2012 (BST)

Although having created the page I don't think that I own it. But I'm interested in the topic and care about it. In regard to the ongoing discussions on the German forum changing the page in the way it was done by User:MasiMaster is clearly an insult and I think a deliberately one. But I don't take such things personally. For me it's an insult against the OSM community and the way it is working and succeeding. Changes except typo and minor wording can and should be announced and discussed on the talk page. Especially when the subject is already discussed controversial or the changed items were unchanged for years there's definitely no need to hurry. There should always be time to get other opinions and to think about the best solution. When this isn't done I don't hesitate to revert changes of topics I care for.

I still think names like "name=Coniferous" are just examples and names as others. They aren't wrong at all. But I see they might be misleading. And yes, these names aren't really needed and there are no names in the other examples too. Thus I think it's the best to remove them. But I'll give some time for any proposals or objections.

Willi2006 03:31, 10 June 2012 (BST)

I can understand that you (Willi2006) are a bit angry about my change in your written MP-examples. Please don't take it as a personal attack. A last few week ago, I edit this, I'm not able to upload/change a picture, so i wrote a text. I paint it red, so it is an eyecatcher for people who know the page and others who only take a short overview. It is striking wrong (my opinion) so I changed it without contact the talk-page. I saw too much pitch, which tagged as: name=Soccer, which is truly the same missuse of the name-tag. -- MasiMaster 13:41, 10 June 2012 (BST)

touching inner-outer

In example Multipolygon_Examples#Farmland_adjacent_to_forest_and_farmyard_adjacent_to_lake_.28Adjacent_multipolygons_and_adjacent_inner_areas.29 are way 19 (and 20) touching inner-outer in more than one node. This is not correct by convention. This could be a good example how to avoid touching inner-outer. Furhermore I don't understand the following sentene: "Duplicate ways, i.e. ways on top of each other, are acceptable, duplicate nodes, i.e. nodes on each other, not." If you draw a way on top on an other, you have to use the same nodes, so you create duplicate nodes. Or please show me, where I'm wrong. -- MasiMaster 13:58, 10 June 2012 (BST)

Duplicate nodes are two nodes (that is, with different id's) at the same position - if you moved one of the nodes, the others would not move. When several ways use a single node, it's not a duplicate node - that is, moving the single node would change the geometry of all of the ways. Alv 16:08, 10 June 2012 (BST)

"Avoid building multipolygons where an inner ring touches an outer ring though." does not mean it's forbidden. Touching inner and outer is rather common in the real word. And as far as I know the main OSM applications support this. To avoid touching inner and outer the closed lines around areas G and F could be split, the duplicate lines eliminated and two additional multipolygons for G and F introduced. I think that would be overkill for such a simple situation or just that what leads to complains in discussions.

When you use the same nodes you don't create duplicate nodes. You only create duplicate ways which are acceptable. Acceptable means not forbidden but should be avoided where possible and reasonable. Duplicating nodes means: for each existing node a second node is created at the exact same position. Thus duplicating the number of nodes. Sometimes some or all "duplicate nodes" are created close to the existing nodes, deliberately or not. Check tools, like JOSM validator, don't complain anymore. E.g. roundabout Eschelbacher Straße and landuse=commercial.

Willi2006 16:33, 10 June 2012 (BST)

I confirm MasiMaster's concern about Multipolygon_Examples#Farmland_adjacent_to_forest_and_farmyard_adjacent_to_lake_.28Adjacent_multipolygons_and_adjacent_inner_areas.29, this tagging is wrong according to MP's definition: way 19 (surface G) inner of surface E is touching way 7 (outer of surface E) in more than one node, this isn't allowed, so this example is partillay broken and should better be fixed. In fact surface G shouldn't be an inner of surface E since it is not inside but outside. sletuffe 18:51, 10 June 2012 (BST)

Is this stated somewhere in the wiki? I couldn't find it on the page Relation:multipolygon. Instead when reading in chapter Touching inner rings the sentence "Avoid building multipolygons where an inner ring touches an outer ring though." I understand that touching inner and outer should be avoided but not that they are forbidden. As touching is not relevant to the examples I will change them no matter if the page Relation:multipolygon gets changed as well. Willi2006 12:05, 11 June 2012 (BST)

It is written on Relation:multipolygon as "hidden" in this sentence : 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).

The OGC "simple feature standard" is rather hard to read, but it says touching rings (outer or inner) on two or more consecutive nodes are considerered invalid. I also wrote en email to dev list (+ on talk page of MP): [2] asking to make the OGC (in)validity clearer on the wiki, and asked about OSM's MP touching rings by an isolated node but ultimately haven't had an answer.

By the way, here : [3] chapter 4.3.5. You can find simple example showing (in)validity of POLYGON and MULTIPOLYGON of the OGC standard. sletuffe 12:32, 11 June 2012 (BST)

A plea for simplification

A relatively new mapper writes: Could someone with a black-belt in multipolygon relations please attempt some clarification/simplification of the instructions here, with respect to the tags 'inner' and 'outer'? There seems to be no wiki article on 'outer', and no indication whether these are keys, or values, or what - in short, the tagging examples seem to be incompletely described.

Maybe I'm missing something obvious but I'm just not getting it - if others are in the same boat, some elucidation may be in order. Yours (wanly frustrated), Eteb3 (talk) 23:54, 3 September 2019 (UTC)

You might want to take a look at pictures in the Dutch version. https://wiki.openstreetmap.org/wiki/NL:Multipolygon_Examples . The Dutch have taken out all examples with complex outers and inners, because these connect landuse areas to linear elements which is a risk to the map and should not be done. Ever.