One more question - is the name really “Parco pubblico”? That looks more like a description rather than a name. If it doesn’t have its own individual name there;s no need to give it one.

This park does not have a specific name, but if you look at the park just above it, which I also called the public park, it has this Municipality sign at the entrance:,9.9971766,3a,15y,179.55h,85.72t/data=!3m6!1e1!3m4!1shTEeCPhWudZkx339pMMC-g!2e0!7i16384!8i8192

So, I reported that name to all 4 parks that are in that area of my municipality.
Of course this is not a specific name, but generic…
I do not know if this is allowed, on the map I have however seen other park named with generic “Municipal Parks”.

Thanks :wink:

I would say this park simply doesn’t have a name and doesn’t need a name tag. People sometimes tag with names like “Municipal Park” because they feel that every notable object has to have a name, or want some kind of name to show up on a map.

If you want to indicate that the park is maintained by the municipality, you could use the operator tag. For example most parks near where I live are tagged “operator = Ayuntamiento de Málaga”, referring to the city government. But that is quite separate from the name.

Thanks Alan for the contribution. The operator=* tag I had already added to all the parks I mapped. Okay, I won’t use any generic name in parks that don’t have a specific name. :slight_smile:

The playground is the part of the park, so there’s no need for multipolygon relation here.

How should a playground located within a grassland area, such as, for example, Way: 87399521 | OpenStreetMap, be classified?

Should the playground be considered as part of the natural=grassland area, or should both the grassland and playground be represented as an outer and inner polygons with a relation?

In this case personally I would exclude the playground from the landuse. But I wouldn’t use a multipoligon relation, I would take advantage of the footway this way:


I see. It’s interesting in general. However, what about the legitimacy of the current approach, where a closed way is inside of a closed way, and the playground is with a hedge barrier?

What about it? if you don’t want to spare the way, as @ivanbranco suggested, then I’d use an MP, because otherwise, the playground would be part of the grassland.

On a related note: That barrier=hedge should not be on the playground, because it works on ways and area, meaning: this can be interpreted as the whole playground being covered by a hedge. Draw a separate way for the hedge and spare out where the entrance is :wink:

1 Like

I see what you mean. But on the other hand, what’s wrong with having the whole playground covered by a hedge (meaning tag barrier=hedge) and the gate nodes on it? It seems like a valid approach, doesn’t it?

If there are gate-nodes, then there is probably also a fence, right? There is nothing wrong with mapping it this way, I’d just put the hedge on a separate way, because it’s a separate feature and you probably want to add width=* and height=* as well, and then add area=no if it’s a closed way, because it could be interpreted as an area otherwise.

Right, I saw somewhere in the community discussions that it’s better to put a barrier on a separate way.

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.

By the way, is it necessary to connect barrier=gate to footways or not so important?

Back to my question

That’s an interesting topic on its own, and I like @ivanbranco’s and your proposals, but we’ve gotten away from the point of my question about some areas belonging to others.

In @CerretumWild’s example, it was a playground in a park. And @maro21 wrote that “The playground is the part of the park, so there’s no need for a multipolygon relationship here”. So my question was about a playground and a grassland. I asked if it was the same situation or not. And if it’s the same, if it’s okay to draw a closed way inside of a closed way like in Way: 87399521 | OpenStreetMap . Probably adding barrier=gate nodes, too.

That’s curious as JOSM does not complain about a closed way hedge with area=yes in fact it gets rendered as line, same in ID. No QA whines either about an unnecessary area=yes tag. Maybe they’re all trailing behind.

Just to expand on this, hedges historically have been both areas and lines in OSM. In 2019 one renderer (OSM Carto) removed support for area hedges, and numerous people complained about that change. There are plenty of examples of area hedges still in OSM; these are now rendered incorrectly by the OSM Carto style. I wrote a diary entry explaining how to do it properly, but a key point is that linear hedges should be drawn as lines - they shouldn’t be tagged on to area objects.

1 Like

aha, penny drops, tagged onto another area as outline feature and for hedges specifically :dizzy_face:. (Need the eyes rolling emoji)

@SomeoneElse, I’ve read your diary entry. It’s very informative! Thank you.

In summary, assuming we’re talking about a playground on a grassland, surrounded by a hedge with only one entrance through a gate:

  1. leisure=playground is a closed way inside the natural=grassland closed way.
  2. There’s no need for multipolygons in this case. (Is it true?)
  3. The barrier around the playground is barrier=hedge, which is an open way on top of the leisure=playground way, except for the gate location.
  4. The gate is represented by a node with the tag barrier=gate placed on the leisure=playground way.
  5. The gate node does not necessarily have to be connected to a highway (is it true?).
  1. dont know, 5 .any line works for a gate node so a playground edge is fine too.
1 Like

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.