Multipolygon rendering of outer when inside of an inner

[hungerburg]

A meadow, which is an inner of a forest, contains a woody area, which is mapped as outer of the forest.

Expected behavior

The woody area should be rendered just like the forest

Actual behavior

The woody area gets the background colour of the meadow and the icons of the forest

Links and screenshots illustrating the problem

https://www.openstreetmap.org/way/120475768 - Rendering prompted me to tag the inner, but OSMI told me, that this is wrong. From reading the specification of multipolygon, I believe OSMI is right and OSM-Carto is wrong. The woody area actually is forest, in the meaning of managed for extraction of timber, btw. Also it is densely covered, nowhere thin like the rendering might suggest.

[imagico]

I think this is a duplicate of #1796.

The issue description is a bit confusing - mixing real world semantics (meadow, forest) with data model semantics (inner, outer). Also the modeling of the forest is unnecessarily complex (MP with multiple but topologically nested outer rings - while this is technically valid it is very hard to maintain and various software could have troubles with that).

Anyway - the bottom line is you have a landuse=meadow polygon:

https://www.openstreetmap.org/way/28617016

and a landuse=forest polygon:

https://www.openstreetmap.org/relation/2613608

which overlap and are rendered here exactly as intended: With the fill color of the meadow above the fill color of the forest (size based drawing order, the forest is larger than the meadow) and the symbols overlay of the forest being drawn above the meadow explicitly and intentionally showing the overlap.

[imagico]

Addendum: Since the suggestion was to render with the forest fill above the meadow fill - that would require abandoning the size based drawing order in the landcover layer (see #4371 - which suggested that in the exact opposite direction) or revisiting #59 - which we most certainly also don't want to do.

[hungerburg]

I see, this is treated the same as if the wood had not been cut out from the multipolygon, but just laid there over the meadow. This indeed might be the more common case to find in the wild. The heuristics sure have a reason. So, the way to have it show correctly on the openstreetmap front map would be, make the (inner) meadow a multipolygon too and cut out the wooded part.

The multipolygons in this area are mostly ten years old, people then liked them a lot, perhaps to save on something. They make many edits a chore ;)

[mboeringa]

The multipolygons in this area are mostly ten years old, people then liked them a lot

MPs are still the only sane and unambiguous way to solve these issues. Sorting by size is just a stopgap...

[imagico]

@hungerburg - I think you probably have an incorrect understanding of the current mapping here but since you mix real world semantics with data model semantics in your writing i can't tell for sure. You have two rendering-relevant features here:

https://www.openstreetmap.org/way/28617016
https://www.openstreetmap.org/relation/2613608

Both of these are polygons which overlap at the closed (and untagged - therefore itself not rendered) way:

https://www.openstreetmap.org/way/120475768

[hungerburg]

@imagico I refer to this https://wiki.openstreetmap.org/wiki/Relation:multipolygon#Island_within_a_hole - There it says, "where the "island" is the same stuff [as what is outside, so I understand this] it can just be made a hole in the hole." Does the documentation need an update or made more comprehensive? BTW, mboeringa meanwhile chose to change the facts. Will see soon how that turns out.

[hungerburg]

@mboeringa When I say chore, I do not think about "pond in a forest" but of tens of km² sized forests, with many "true" outer ways shared with their neighbouring forests, screes, bare_rocks etc. and even more inners. Openstreetmap rendering of changes in them may sometimes lag for two weeks too.

Looking at your changes, the only thing that comes to mind that makes the outcome now true to the intention, the "inner" meadow now is a multipolygon too, before it was a simple area. Doing a full revert in JOSM, there it looks just the same, before and after.

Indeed, the "island in the pond in the forest" case seems rare, a bit of panning found this, https://www.openstreetmap.org/relation/6257170 - Kartler175 seems to know the stuff. If the pond was just a way and the island "outer" the forest, would there be trees on blue ground?

[hungerburg]

Extensive panning found me another way of the kind, where an outer of a multipolygon is fully contained within an inner of same mp - https://www.openstreetmap.org/way/137686277 - but is not rendered the same as the other outers - please do not correct! The case is rare, quite often so it seems, mapping has been made to look correct in osm-carto. Maybe though, the documentation cited above is wrong, or I got it wrong, so please leave the case alone, until issue is decided - or documentation is made clear.

UPDATE: This is even more different, the outer is a true outer! There are several of those, some render the same as the biggest of them, some not, so this is not the same case as the one, that was destroyed/corrected recently

PS: What have they been smoking back in 2011 - same year as case in Natters, from the top post.

UPDATE2: I guess I finally got it: A "tagless" island inside of an island gets its area type from the multipolygon it is an outer part of, but OSM-Carto still sees overlapping areas there, so it renders a mixture.

[mboeringa]

A "tagless" island inside of an island gets its area type from the multipolygon it is an outer part of

No, it doesn't. There is no "inheritance" of tags between different objects. The fill of the larger object just renders over the area of the smaller forest patch, because no donut hole was created there, so from the perspective of the larger meadow object, there aren't any inner forest patches at all, only meadow!

The effects you see are just the consequence of a couple of things:

• No use of multipolygons where it technically should or would be highly preferable.
• This particular style rendering polygon color fills and patterns (the tree icons) in two different "layers" or drawing cycles, with the icons in second layer on top of all fills.
• openstreetmap-carto using size based sorting (smaller objects rendering on top of larger ones).
• The database, depending on osm2pgsql settings during import of OSM data in the rendering database, potentially breaking up "multipolygons" in individual "polygons", where each multipolygon part becomes an independent record. osm2pgsql can do both: maintain "multipolygons" as-is, or break them apart. Breaking them apart increases the size of tables in terms of number of records, but may reduce the size of individual features to a more manageable level (although most modern hardware should be able to cope with most monster polygons with hundreds of parts in OSM).
• Other particular cartographic choices made in this particular style.

Rather than trying to fully understand why openstreetmap-carto creates a particular rendering, I would recommend you to focus not on rendering, but on what you know is technically right. We do not map for the renderer, but to create the most useful database. That in most cases means creating multipolygons for lakes with islands, or larger meadows with patches of forest in them, and thus not rely on the "size based sorting" and other stuff to "maybe" get it visually right...