As seen here:
The natural=wood appears behind the park rendering; however, just a little over to the right it appears in front:
What’s up with that?
it seems that wetland is simply not mapped as forest, see Way: 977361872 | OpenStreetMap
in this map style forest has two parts - fill area (ordering of fill areas is to paint them starting from larger ones, smaller covering any larger)
and there is tree pattern rendered on top of any fill areas
1 Like
The wetland is not part of the forest so I think it is not part of the problem here.
But your explanation of the difference in rendering the forest areas hits the nail on the head. To the east side the wooded area is much larger than the park area whereas to the west side it is vice versa.
I have to admit that I would not have been able to provide this explanation even after seriously thinking about is for the rest of 2025 … 
Err, I don’t follow what you mean. The wetland is not mapped as a forest (natural=wood) because it is a wetland… I’m not sure I follow what the relevance is.
Ahhh, okay, that makes sense! Personally, I think it would be better to be more consistent in the rendering order, though I haven’t given that much thought, so I’m not firm in my belief 
The rendering order by area is correct / consistent. The underlying issue is that landcover-type areas are intended to be non-overlapping or with smaller areas enclosed by a larger one. The combination of leisure=park and natural=wood is undefined, and different renderers will do different things.
You would get consistent behaviour by splitting the natural=wood at the park boundary. That way the overlapped areas would be consistently smaller and the “order by decreasing area” would work as intended.
I would not say that.
As someone who was/is developing map styles it is rather imperfect heuristic.
Large areas partially overlapping each other may be perfectly valid mapping.
1 Like
So how would you map a wooded area of a park? Sorry I misread the post
There’s also woods not entirely contained in a park, e.g. Relation: 7142334 | OpenStreetMap
Actually, there are two parks there - Palewell Fields and Common and Richmond Park. Apart from a tiny overspill, that woodland is within one or the other.
What would be an interesting example would be where a wood overlaps two parks but has a way_area between them in size…
Yes, but my point was the wood is not contained within either park
I don’t understand this sentence, is there a typo or is it a Britishism?
Neither - it’s perhaps a “renderism”
way_area is just the size of a feature. Have a look at this map with debug turned on - things that have a name displayed at the centre also have the way_area stored. Alternatively you can load a database as per the switch2osm guides and you’ll get a database that you can query way_area and also “X overlaps Y” with.
1 Like
Good spot - I had been too lazy to check.
I don’t think a tree-covered area really fits the definition of leisure=park (area of open space). It’s a recreational woodland.
(somewhat offtopic diversion that explains why tagging is hard)
What would suggest as an appropriate tagging for Black Park West of London? The last time that was discussed people thought that leisure=park was about the least worst option there.
True, tagging is often hard, but to keep to the topic of rendering, it’s very difficult to design a render for multiple ideas of what a park is. The Carto rendering (plain “artificial” green) is tilted towards a typical municipal tended park.
Frankly the Black Park example looks a bit of mess:
with a protected area boundary (protect_class=2 ?!) dual tagged with leisure=park, then almost the entire area covered with different landcovers, so there is only a tiny bit of leisure=park render sticking out!
The rendering is fine here, since the wooded area must be consistently smaller than the park area(s). The original example was visually confusing because the wooded area was larger than one of the parks.