OpenStreetMap
Replace the "multipolygon" (and its 'relation') attribute with "area".
Posted by ThePromenader on 19 April 2011 in English.One of the biggest challenges to the 'Area' concept is OSM's method of treating nodes and ways - polygons simply do not enter into the equation in the present state of things. It took me a while to understand that OSM defines a polygon only by adding an "is it filled?" tag, and even longer to grasp the fact that OSM data is how it is, and it is up to the end user on how to deal with it. This, if anything, calls of consistency in contributor methods of treating areas - or polygons - and that is certainly not the case today. In my work on data concerning the City of Paris, I see that every multipolygon building was 'joined' using the 'relation' - with all the object's tags added to the "outer" way, and I have learned since that this is totally the wrong way of going about it.
Enter the "multipolygon" key/attribute, and add another level of (possible) confusion: In my work mentioned above, some buildings are simple polygons (aka simple ways with the 'building' "is it filled?" tag) and others multipolygons - the method for creating each (drawing a simple square with a "building" key, vs. creating a relation, adding a "multipolygon" key, then all member polygons) is twice as complex as it needs to be, leaves room for inconsistencies (key placement), and overall is difficult for a new contributor to grasp.
I don't think the 'relation' key should be used at all in polygon creation (and reserved for data relations, but more on that in another post) - instead it should be replaced (along with its 'multipolygon' key) with a single attribute - 'Area' seems the best solution - to which all the object's data would be attached. This would make shape creation much more coherent, 'key-consistant', and user-friendly.
There is a discussion (actually, not much) about this here: http://wiki.openstreetmap.org/wiki/The_Future_of_Areas . I'll be adding a proposition of my own later today.
PS: I just added a comment here: http://wiki.openstreetmap.org/wiki/Talk:The_Future_of_Areas/Areas_on_Nodes_or_Ways - this method is very close to that I was imagining already.
Discussion
Comment from Tavernsenses on 20 April 2011 at 08:59
I agree that the polygon approach is too complex for the average user to use. The 'area' idea seems to be more elegant and user friendly indeed.
But what if one area is situated within another, or overlaps another? I would in that case simply asign a background-foreground priority to each area, in very much the same way as PowerPoint allows object to be put either in the background or foreground, or moved to front or back, or make one or two areas 'transparant'; SIMPLE!! The proof that it would work is that you can recreate in PowerPoint alomost any 'polygon' combination that is featured in OSM ...
Comment from ThePromenader on 21 April 2011 at 13:15
The answer I got from other OSM contributors was 'never overlap two polygons of the same type, and this makes a lot of sense. Every OSM-data application treats "what's on top" differently - I may want to render buildings after grass, for example - and having "area"s would make this even simpler. If you have two touching/overlapping polygons serving the same purpose/shape, why not just make one out of them? Unless, of course, you're describing situations such as juxtaposing buildings (distinct properties) that are sharing the same way.