A large portion of an area that you can usually walk through has been closed off. They have put up a fence around the whole area, which is expected to remain for quite a while.
I added the fence, and let it share a node with every single path the fence crossed. I thought this would indicate the paths are unusable. But 1) Organic Map still happily route through the fence, assuming you can cross, and 2) StreetComplete is asking questions about what kind of opening in the fence it is at these nodes, also assuming you can cross. There is no opening. You cannot cross.
I could of course simply detach the two sides of each path from each other where the fence goes. This would solve both problems, but then editors would complain there are paths not connected to any other roads, and paths close to each other but not connected. So that does not seem like the right way to do it either.
I could add barrier=gate with access=no, even if there are no gate. This would solve both problems without causing any warnings. But there is no gate.
Ideally, the routers and editors would be improved to handle this validly-mapped case of highway ways intersecting fence ways but realistically, I’d say it’s fine to just add the barrier=fence + access=no tags to each of the nodes connecting the fence and the paths and to add the access=no tag to the segments of the paths inside the fence.
It is complaining that barrier=fence is not valid for nodes, only lines. I tried barrier=yes, access=no instead, but then StreetComplete still asks what kind of barrier it is.
Where can I see that this is a valid case and implies you cannot cross?
Because a forum search only brought up this post on the topic, and it seems to imply the opposite, that if a path crosses a fence, that implies you can cross the fence there.
There’s 10228 cases of type:node barrier=fence according to Taginfo.
Yes, barrier=fence tag on the node where the highway=* way intersects the barrier=fence way can be seen as duplication, but not harmful imo - the same case happens where barrier=kerb is mapped as a way along a curb edge but it is still expected that a barrier=kerb node is present at the intersection of the barrier=kerb way and an intersecting footway=* way.
Okay, I tagged it as barrier=fence + access=no. Now iD warns about “Fence should be a line, not a node”, but I think the situation is better. At least now we won’t get notes on the map from StreetComplete users that cannot answer quests, and routers should no longer route through these paths because access=no.
I suspect that there are lots of these in the OSM database, and in most cases it’s happened because someone has forgotten to add a gate or a stile. It seems reasonable to me for StreetComplete etc. to ask what is there.
Things that would definitely work would be a break in the path before and after the fence (perhaps with disused:highway=footway in it). In your case you might argue that it’s “mistagging for the renderer / router” or similar, but in the example I linked to it matches what’s there pretty well.
It’s both perfectly valid and necessary to tag the intersection node with the barrier=* (+ access=*) tag.
Data consumers cannot safely infer if a way is barred or not by looking at the ways it shares nodes with. Aside from simply being massively more complicated to implement, there are plenty of cases where you can actually pass through the barrier at those locations.
You could argue that those cases are missing data and should have some tags that indicate that you can pass through, but as a counterpoint, that’s what highway=* already implies unless explicitly specified otherwise. If you can’t traverse it in any way, it shouldn’t really be a highway=* in the first place.
Any router that completely ignores anybarrier=* on a way without good reason should be rightfully considered to be broken.
Recognizing that there’s a barrier tagged in the usual tagging scheme, that’s of a kind that implies that it’s impassable and then deliberately ignoring it and leading users into a dead end because it’s ‘defined as linear only somewhere’ borders on wilful malicious behavior.
There is no such thing as a tag being strictly ‘defined’ to be used only as a linear way in reality. OSM tags are abstractions and need to be interpreted as such in the context where they appear. A tag can have multiple meanings which can often overlap and apply simultaneously.
A barrier tag on a way node has a dual function in that it implies:
the way is blocked in some way
there is a physical feature here (gate, stile, fence, …)
If a barrier is mapped as a separate linear way, it fulfills the function of (2), but function (1) is missing. The (additional) barrier node on the way is required to fulfill that purpose.
None of this is unique to barrier=fence either. Any other barrier where it could make sense to map them as linear ways (e.g. gates, …) can be mapped that way and also need a barrier node on the intersection with the highway.
If it doesn’t fulfill the main purpose of a highway=*, being able to traverse it in some way, it probably shouldn’t be tagged that way. disused:highway=* seems like a good fit.
Updated applies to nodes=is not applicable to applies to nodes=is applicable on Item:barrier=fence (diff)
Updated the Values table on Key:barrier by moving the barrier=fence row from the “Linear barriers” section to the “Linear barriers or access control on highways” section and adding {{IconNode}} into the Element column. (diff 1, diff 2, diff 3)