Actually, if the leisure=playground is fully enclosed within the natural=grassland, then I would make the playground an inner of a grassland multipolygon here. It depends if you consider the path part of the playground or not. If you do, then @ivanbranco’s approach makes sense. If the path is “part of the grassland” then a multipolygon makes sense here.
The imagery suggest that the hedge has gaps in it, so I’d remove the hedge tag from the playground and add new linear hedge ways where there is a hedge, leaving gaps where there is no hedge. You could reuse the playground’s corners as hedge nodes.
Edit: Here’s what that looks like. on the dev server: To see the underlying imagery and the other objects you’ll need to edit it, and that needs a dev server account, but hopefully the idea is clear.
There’s no searchable help within iD to explain how to make the playground an inner of a grassland multipolygon, but a web search finds this old help question which in turn links to this learnosm page. “c” (combine) still works even if the inner already has tags and creates this multipolygon.
Fantastic, @SomeoneElse! Thank you so much for putting in the effort and preparing this example. Although I don’t use iD, I exported it to .osm and reviewed it in JOSM. Your example has made it much clearer for me to understand how to deal with multipolygons, particularly in this case.
Regarding this example, I randomly selected it using Overpass, and I had no intention to modify it. However, while conducting surveys or browsing OSM, I come across playgrounds on grasslands that are fully enclosed with hedges or other barriers and have one or more gates. But these playgrounds are mapped without multipolygons like in the example given by me earlier.
Returning to this specific example, I would like to know how disruptive it is (for any tools or applications based on OSM) to encounter a closed way representing the grassland and a closed way representing the playground within it. I’m curious if multipolygons add significant value in this scenario.
On the other hand, the wiki suggests that it’s perfectly normal to use only one way and add features like barrier=fence or barrier=wall for the perimeter, and barrier=gate for a node on the perimeter. They don’t mention barrier=hedge, but I assume that would also be valid.
then the wiki could be improved, it is tolerated to have multiple features represented by the same geometry in OpenStreetMap as a shortcut, but it is not recommended, because it creates ambiguity or may lead to ambiguity in the future. The preferred way of mapping is one feature one element.