Hi,
I was not able to find a clear answer that would no be years old so I would like to know what the best practise.
Is it okay to use “barrier” tag on area features like sport pitch, dog park, playground etc.? These are almost always enclosed by fences.
I was previously using a line feature sharing the nodes of the area feature but then I discovered that it is probably a waste of time or even redundant.
Thanks!
Isn’t the fence the barrier?
It is possible to add barrier=fence to the area itself. But it is preferred to use a separate object for the barrier. A separate has the advantage, that you can map gaps or changes in the barrier type.
If you do not want to draw a fence separately and it is sufficient for you not to record any other properties of the fence (material, height, colour, etc.) then it is also possible to attribute an area as fenced, see here:
As usual in OSM, opinions differ widely as to whether this is a good way of mapping. However, you are always free to decide for yourself!
You can find discussions about this e.g.
here, here, here and some more here
Thank you for the replies. I will probably use barrier=fence/wall for area features that are usually fenced and the area most likely would not change over time. You can still add tags like fence_type to the area feature and I am focusing more on adding fence at all than adding every posible detail of it, like color. Sometimes there are ruins or leftovers of wall that can be crossed because it is very low or fence that has hole and in that case a line feature is definitely better, because I can just make a gap.
In my opinion, that is wrong.
barrier=fence is not intended for areas
Fenced areas are to be tagged with fenced=yes
Between May 2016 and June 2023 fenced=* was deprecated on this page under the false assumption that fenced=yes and barrier=fence had the same meaning.
Subsequent addition:
However, fenced=yes only means that an area object is fenced. This is very very simplified. However, no attributes of the fence (e.g. type and material) can be added.
The better and more common variant is therefore to draw another way around the area and tag it as barrier=fence (additionally fence_type, material, height etc.).
It’s not? Okay, I was thinking about it and you’re probably right. I have reverted all my changes. I will stick to the line feature for any kind of fence and wall.
A wiki page does not a sensible tag make.
fenced=yes has 2,783 uses.
barrier=fence has around 7,900,000.
If you want to draw a fence around an area, then draw a fence around an area, using some or all of the same nodes, and tag the fence barrier=fence.
Thank you, I wanted to go into this in a similar way, but had forgotten in my haste. I’ve added something to my post above.
This is a slight misunderstanding of closed ways vs. areas. Barrier tagging on a way is never interpreted as an area. The icons just show that barriers can never be areas, and so renderers always interpret barrier tagging on an way as a linear feature whether it is open, a line, or closed, an area.
So adding barrier=fence to leisure=pitch is unambiguous (the pitch will be interpreted as an area, the barrier as a linear way). Dual tagging would be problem if the leisure and barrier tagging conflicted.
Expanding to all barriers, that’s an assumption, but if you have a look into OSM data you can see that’s it’s not a completely correct one. There always have been hedges mapped as areas** - see this old diary entry for some examples. Also walls. I can’t think of any “area fences” though.
I’d agree that that conclusion makes sense for that combination, but closed leisure=pitch ways without an area tag are actually ambiguous. If you have a look at some examples you’ll see some that are “obviously linear” (running tracks, trotting tracks, etc.) and some that are “obviously areas” (running tracks again, and also things like bike parks).
I’d argue that this is more evidence behind the “please map the fence as a separate feature to the area that it is around” argument - that way, unless someone has explicitly mapped e.g. barrier=wall; area=yes we can safely assume that the barrier is linear.
** OSM Carto used to render area hedges as such, but that got disabled, I suspect because the maintainers found it too difficult to to detect “hedge around another area object”.
does this mean there should be 2 superimposed lines at the border, one for area=xyz, and another barrier = wall?
That’s entirely the choice of the map style, but I would imagine that most map styles would just show the wall in preference to the area outline
leisure=track is a bit of an exception as it has distinct renderings for whether is an area (area=yes) or a linear feature.
BUT that said, I’m now agreeing that leisure=pitch combined with barrier=X is incorrect tagging. It may, strictly speaking, be unambiguous, but combining a linear feature with an area feature is going to cause problems, at least for raster maps using an osm2pgsql import; as I read the import script for Carto, such a feature will be imported into the polygon table (rather than the linear way table) and so will be rendered as leisure=pitch and the barrier=X will be ignored.
TL;DR Use a separate way for barrier and areas.
Yes, in Carto at least, the area will be drawn first, and the barrier=wall will be drawn on top.