Currently, we have acceptable (but not ideal) tagging scheme for access restrictions. I’m talking about access=* key and its values. Here, I want to tell something about an application of this scheme in terms of topology, data interpretation, and data architecture.

OSM documentation says that it may be used on nodes, ways, closed ways (use on relations is unspecified, but it’s not prohibited). And many people take that literally. Let’s review some cases.

access=* is often assigned to a node, representing a barrier. Many mappers have an idea that it is way easier to add this tag to a gate, liftgate or another kind of barrier to indicate that access restriction starts here. In such cases, adding access=* to a highway=* is often omitted. A common argument for omitting it is that usually, navigation software starts the route planning from a point, which is publicly accessible. Then, analyzing the road network, it should avoid crossing those points with access=* restriction, if possible, just like it does with user-defined avoidance marks.

But there is a problem with this method. Having a road, divided into two parts by a node with access=* tag, it is impossible to tell, to which half this restriction is applied. This problem has only heuristical solutions, involving extensive analysis of road network. For example, it will be a nice educated guess to say that restricted portion is often a dead-end comprised of lower rank roads, while unrestricted portion likely has a connection with higher rank roads. But this kind of analysis is a problem with no definite depth, and it still doesn’t give you 100% accurate result, which is unacceptable.

That argument about a route always starting from a publicly accessible point, is obviously false. There are enough cases when you have to calculate a route from a private property or limited access property. And the only universal way to deal with that is to disregard restrictions completely if no unrestricted route is possible. This solution is widely used, but it means devaluation of information about restrictions in the OSM database. Another known approach is to always avoid passing through the restricted portions of a road network by counting restriction points, but again, in a case of node-based restriction, it fails (requires a fallback to ignoring all restrictions) if both start and finish points are behind the restriction.

Applying access=* to a road itself eliminates any topological ambiguity since there is no question, to which part of a road restriction is applied. It is also clear if a route starts from or/and ends at a restricted portion. Therefore, no fallback is required.

Another option is to apply restrictions to a boundary, such as a fence or a land parcel, where a restriction is in effect. It helps to avoid tagging every road. However, it requires certain pre-processing to make data actually usable. Information about restrictions should be normalized by applying it to roads within a boundary using a spatial query (just like in the case of simplified address tagging, when addr:city is omitted on buildings, but can be easily propagated from a city boundary). To make it right, two additional operations should be performed: splitting roads at an intersection with a boundary, obtaining all members of a boundary contour. The latter one could be tricky if processing is performed offline.

So, it could be a drawback, but it doesn’t create any problems with an indefinite depth.

The purpose of this diary entry is to explain how access restrictions work in case of being applied to every type of geometry and to demonstrate that existing node-based restrictions can not be reliably used.