[openstreetmap/openstreetmap-website] Selected multipolygons are not rendered correctly filled (Issue #3600)

[Sinuhe20]

### URL

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

### How to reproduce the issue?

### Expected behavior
Selected multipolygons should be filled correctly (without the inner holes). Selected multipolygons should be rendered as true multipolygons.

### Actual behavior
Selected multipolygons are not filled correctly or are not really rendered as multipolygons. It looks like each member (inner or outer line) is rendered individually.

### Links and screenshots illustrating the problem
Two temple sites with almost the same attributes, the one as way (Luxor) is filled, the other as multipolygon (Karnak) not:

- https://www.openstreetmap.org/way/1079039494 (filled)
- https://www.openstreetmap.org/relation/14358790 (not filled)

Overpass turbo renders multipolygons correctly filled:

https://overpass-turbo.eu/s/1kaj

And it seems not be related to the complexity of the outline:

https://www.openstreetmap.org/relation/2017780 (also not filled)


Another example, which works wrong in the other direction:

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

A multipolygon, where all areas, even the inner holes are filled. I think this can be related to the landuse property set or area=yes. Looks like all members are rendered individually and only their tags are considered, but not that of the multipolygon.
In my opinion selected multipolygons should all be rendered in the same way with the inner holes empty and the rest filled, no matter which tags are set.

### Screenshot(s) or anything else?

_No response_

-- 
Reply to this email directly or view it on GitHub:
https://github.com/openstreetmap/openstreetmap-website/issues/3600
You are receiving this because you are subscribed to this thread.

Message ID: <openstreetmap/openstreetmap-website/issues/3600 at github.com>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstreetmap.org/pipermail/rails-dev/attachments/20220716/1fa0b857/attachment.htm>