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.

Thanks for your replies. @Sanderd17, could you elaborate? This sounds very interesting.

Thanks for the input, Vincent, I see your point - but you hit the nail on the head and get to the gist of my argument in your phrase "real-world object". If you think the object you are creating is worthy of having tags added to to it, an additional 'object' key provides that place ~no matter what form that object has~. In the present system, I have to add keys ~somewhere in the shape~ of the actual physical object I am trying to add - but the ~form~ of what I am adding should be secondary. To simplify, first ask "what role does what I'm adding to this map play in this map", then tell "what form does it have?". Sheesh, I just summarized my entire long-winded post in ~20 words.

I agree that free-form tagging would be a force - and I see every reason why - but could OSM at least control ~where~ we put the tags (keys)? Even if my software is well-formed, it still has to look ~in all possible locations~ for keys. BTW, I have written a quite successful php script that extracts targeted data quite successfully, but it requires about ten times more memory and time (because of the needed recursive searches) than would be required if the keys were in one place and relations (shape and 'belonging' roles) were treated more precisely. Cheers.

(comically pulling hair) Is there no standard way to do anything here? Actually, in both cases, whether the node is part of a way or not, the node would get an "addr:*" key attributed to it... that would weigh about the same, data-wise. The city I'm working on, has TONS of multipolygon buildings (take for example, its biggest: osm.org/browse/relation/539480 - the Louvre museum. I can also think of cases where I came across a multipolygon that had multiple addresses on all ~four~ sides. And think of the Pentagon ; )

Thank you for your quite clear explanation. I'll try to recreate that error later today. Take care!

Thanks for the example, ToeBee.

Gotcha for a single way to be mapped between two relations - makes sense, especially from a data (load) point of view.

After reading up on the "landuse" tag, perhaps I shouldn't have used that term. "Land covering" would be closer to what I was trying to say, but I think my ideas on that are clearer now.

In your last example, I see that the buildings are nicely overlaying your "block" polygon (blowing apart my "no overlapping polygons" misconception), but what purpose does the "outer" polygon in the overall multipolygon have?

Thanks for your reply. If that is the case, I don't understand the "relation" concept currently at use in OSM - some contributors add buildings as an 'inner' member of a landuse multipolygon; others draw buildings as independent elements. Already I have run into problems with this in just experimenting with OSM data. If the usage of this concept is so varied, how can the end-user determine 'what belongs to what' and 'what goes where'? It is (seemingly) OSM itself that determines this. Is there really no coherent system?

I knew I missed something: Okay, if we can have overlapping polygons, a) why do I get a warning everytime I place a polygon over another, and b) even if I did that in spite of the warning, how can I ensure that a polygon remain on 'top'? Are 'building' keys, for example, already programmed to appear on top of everything else? I find little documentation about this sort of subject anywhere.