Several years ago, I added a barrier=gate with access=private and locked=yes on the node between this highway=steps and highway=footway. However, both osm.org and Osmand happily route through it.
Is this a bug in both routers? Or is there a sure-fire way I can indicate that you can’t get through this gate that actually prevents routing in well-written routers?
Just to check the situation, are the paths (or steps where relevant) both north and south of the gate open to the public, and the only thing the public can’t do is pass the gate from one public section to the other?
They are accessible, and I don’t remember seeing any signs forbidding passing. It was some time ago, and I don’t remember all details.
As far as I remember, I have only seen it from the southern side. The northern side may be inaccessible, I don’t know. (I was trying to catch a train, and because the path, that I thought was public, was blocked and I had to take a large detour, I had to hurry and couldn’t check the northern side).
I am also interested in the theoretical question: what if a gate or door (not this particular one) is publicly accessible from both sides, but permanently closed? How to properly and robustly map such a situation in general?
Two thoughts:
For what it’s worth, CoMaps refuses to route past the gate in either direction.
So that might be an indication that it is not the barrier acces but the penalty for going up the stairs?
Yes, or maybe the combination of the two, if the barrier impact is implemented as a penalty rather than an absolute prohibition.
We plan to fix this issue for GraphHopper. See Not blocking private locked=yes barrier for foot - Open Source Routing Engine - GraphHopper Forum
Per the discussion in the other thread, it sounds like routing foot traffic through access=private was intentional, with the reasoning being that often barriers are mis-tagged with access=private when only motor vehicles are blocked and foot traffic is allowed through. So does that mean tagging foot=no on this gate would also solve the problem?
Edit: It appears not: OpenStreetMap (see Changeset: 189223059 | OpenStreetMap). Though I guess I don’t know how long it takes routers to update their data.
A few days IIRC.
Yesterday my graphhopper code change was me merged. This will block the gate under discussion once new OSM data is used.
You wrote that you intended to add tagging foot=no, but actually added foot=private, which is a difference. You are lucky that even after the code change this modification will not revert the result back to the original observed case.
Interpretation of the OSM tagging sometimes is not that easy. See this discussion for the reasoning behind opening locked=yes in certain cases.
By the way, on the Graphhopper online instance it is possible to see the date of the OSM data, which was used to build the routing graph. It is a little bit hidden, but it is there if you click on “Details” and open the route instructions:
Looks like the data is updated, GraphHopper is still routing through foot=private. Presumably the upcoming fix will resolve that…
locked=yes alone should suffice for most routers, but an additional access=no will prevent most[1] of them from routing through.
Here is one such example, the southern road has always been open to public, the northern road used to be inside a military area up until 2012, but is now accessible as well. The gate is still locked to this day.
In my example below, OSRM with the car profile still tries to route through the gate: OpenStreetMap ↩︎
I guess the question then is why doesn’t access=private do the same thing? access=no seems a bit strong for a feature like a gate which is literally designed to be able to be opened to allow access.
Now the code change arrived at the Graphhopper online instance.
