Multipolygon relations 'Island within a hole' not rendering as expected

[DaveF63]

Hi

Expected behaviour

https://www.openstreetmap.org/#map=18/51.02480/-3.93326&layers=C

Actual behaviour

https://www.openstreetmap.org/#map=18/51.02480/-3.93326

https://wiki.openstreetmap.org/wiki/Relation:multipolygon#Island_within_a_hole

Why isn't OSM-Carto rendering the inner island? I could have sworn it used to.

[matthijsmelissen]

This is a data issue: the water area doesn't have a hole in the data (it's not a multipolygon).

[DaveF63]

Hi
You know how OSM-carto is frequently asking for new contributors, but rarely gets any? I'm pretty sure rude, instant, knee-jerk closure of threads is one reason.

---

How comes the island renders the graphic? How come the other renders manage it?
From the wiki link I posted:
"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 inner."

It's an outer within an inner within an outer. The water doesn't require a specific relation as it doesn't have a separate tag for the island - it should render as a wood.
Again, from the wiki:
"Such cascading is still needed 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."

Can you confirm OSM-Carto has always done this, as I'm sure I've created island which render

[SomeoneElseOSM]

@DaveF63 I'm not sure exactly how you'd like @matthijsmelissen to phrase it, but https://www.openstreetmap.org/way/616701768 is an inner to the wood but is not itself a relation. https://www.openstreetmap.org/way/615985619 is not an inner to the water relation and hence is both "wood" and "water". This change was made here a while back to accommodate places where those things happen together (think mangroves). See e.g. #1754 for some previous discussion.

[dieterdreist]

sent from a phone

On 16. Aug 2018, at 17:56, SomeoneElseOSM ***@***.***> wrote: This change was made here a while back to accommodate places where those things happen together (think mangroves).

+1, we have to look at the actual data, not whether other renderers show or don’t show the problems. And yes, this style should try to show the problems rather than hiding them in favor of a more pleasant map, because people will fix the problems much more likely if they suffer from them.

[kocio-pl]

This is a follow up to this question:

https://help.openstreetmap.org/questions/65303/could-someone-check-this-multipolygon-outerinnerouter-relation

The only problem I see is that when water was properly tagged as a multipolygon with a hole inside, the island has the tree symbols, but not the green background. Which is interesting, but I would probably just tag the forest on the island instead of complicated two part multipolygon with forest-inside-a-forest shape.

[matthijsmelissen]

@DaveF63 Happy to expand on my answer.

First: the current tagging indicates that the middle island is both trees and water, i.e. that the trees are growing in the water. Does this describe the situation correctly? If not, the tagging needs changing.

How comes the island renders the graphic? How come the other renders manage it?

The current tagging describes the middle circle as both water and forest. Some renderers (such as the cycling map) decide to render it as forest, others as water.

From the wiki link I posted:
"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 inner."

This is a quote from link, which seems wrong to me. In the new situation, we also need two multipolygon relations. The quote seems to have been written years ago by @woodpeck, maybe he can comment?

Can you confirm OSM-Carto has always done this, as I'm sure I've created island which render

No, OSM-Carto never rendered the island: http://bl.ocks.org/matthijsmelissen/raw/7d2b0538a8b64b9d31e2/#18.00/51.02482/-3.93383
Your previous tagging might have been slightly different.