The examples given (vehicle, animal, person) are deliberately chosen to underline the broad applicability of this approach. Which features router applications offer, is up to them and of course mainly depends on what their users prefer.
The approach is broadly applicable, with the caveat that it doesn’t answer the question of what to do when a mapper hasn’t or can’t detail the dimensions specifically.
Barriers aside, in Asia, one of the biggest frustrations of mappers and data consumers alike is that there’s no established method for keeping full-width cars out of the special kind of narrow alleyway found abundantly in urban areas in these countries. These alleyways are designed for narrower motor vehicles, unlike wider alleys. Legally, there’s nothing stopping a car from attempting to go down one of these alleyways, as long as the driver is OK with destroying the car’s side mirrors. But good luck gathering data on the widths of alleys that you can’t even see in aerial imagery.
Waze and proprietary datasets have a special road classification for these alleyways. (Waze calls them “narrow streets” or “passageways” depending on the country.) Like the manner in which OSM mappers apply highway=cycleway versus footway in some countries, it’s more about intended design than legal access. Maybe this isn’t pure from a theoretical perspective, but people have found this approach to work better than a pure approach in reality.
I see a parallel to this barrier discussion, where practical realities matter somewhat more than legal theory to the audience that would make use of this data.
2 Likes
I used service=alley on some such in a medieval street around here, I guess that is not enough? No legal driving constraints. Should have added width/maxwidth/estimaded_width?
4 Likes
If you can estimate a width, sure, that would be helpful additional information. The situation in Asia, as I understand it, is that there are a lot of urban alleyways and most would only be physically passable in miniature cars. (Japan classifies them as kei cars and kei trucks.)
To some extent, users can skirt this whole issue by asking the router to disfavor alleys, but that potentially throws out a significant number of perfectly passable alleyways, especially in less built-up areas. In other words, going back to the original topic, the decision of whether motor vehicle access is implied to be present or absent depends on geography, which calls into question the notion of implied access.
I’m also doing this, and adding “width”. It is not perfect (e.g. sharp corners) but it gives at least some indication
Speaking of narrow alleyways in Asia:
Personally, I like to map gates. Today I happened over this gate:
As can be seen, it is locked – by snow. But this is just a coincidence. I chose to tag locked=no.
Is it wrong to tag foot=yes there? From reading this topic, I’d say, yes, this is wrong.
First of all, the snow probably definitely falls under the guidance against mapping temporary events. 
Aside from that, the fence is clearly designed for foot traffic, but if the lock prevents access anyways, it should be indicated somehow. locked=yes would be an elegant tag for that, although unfortunately, Organic Maps is the only router I know of that supports it so far.
Note that locked=yes only applies when a lock impedes pedestrians, whereas foot=private or foot=no could also apply in some other situations, such as an inoperable gate in an otherwise impenetrable fence, or an unlocked gate that’s only large enough for a dog to squeeze through.
1 Like
@Minh_Nguyen @SomeoneElse In the same CS I also did add a locked=yes, screenshot with lock
and a plethora of access tags. BTW: There is no track there, at least as I observe.
PS: In case of being fond of mapping gates certainly will share delight in this File:Gate and Stile with Dog Gate.jpg - OpenStreetMap Wiki
@Minh_Nguyen, would love to hear your routing expertise on that topic. 
e.g Is there a fundamental difference for routers between the two tagging options?
Off the top of my head, Valhalla has an option to bias the route against following a highway=service service=alley, which wouldn’t recognize highway=residential lanes=1. On the other hand, I don’t know if any router specifically penalizes a one-lane road of any classification in the manner that some mappers would expect.
But the aspect I find more interesting is that many narrow alleyways would discriminate against a subset of a legal vehicle classification, so legal restrictions are somewhat irrelevant:
1 Like
This is actually a very minor use-case only found in old major urban centers. Some one-way and residents only signs are finally popping up after likely some incidents happen with larger vehicles or drivers unfamiliar with the narrow roads 
Thats actually a more concerning and pressing issue as most residential roads in Thailand are not wide enough for 2 cars to fully pass. What other tags would penalize these narrow roads? access=private?
It might be more minor in Thailand. I know it’s a big deal in Japan (comes up in discussions with delivery companies) and Vietnam (where plenty of roads are designed for motorcycles rather than cars anyways).
No, as I pointed out above, access=private would make no sense if access tagging were solely about physical accessibility. Let’s continue the discussion about narrow roads in the other thread; I’ve already finished making my point that physical accessibility matters.
2 Likes
I would not consider the snow, from what it looks, this is not designed to be locked any time or prevent access for people, so I think foot=yes would be suitable (but you know the situation better than me, I have to guess from the picture).
Tagging such would NOT map legal rights of way, but the physical ability.
From this topic I infer, foot=yes would not say anything about passibility. So I went with locked=no.
PS: The path the gate is on has sac_scale tagged, so foot=yes is implicit, on the path, and I suppose on all the hurdles.
What is the legal situation, may you cross this gate on foot or not?
I am not sure if there is consensus (yet) to start documenting on the Wiki.
Let’s look again at the example that led to this thread: bollards that block cars from driving on a cycleway but are far enough apart so mopeds fit through. The Dutch agree that even when mopeds are allowed on the cycleway, barrier=bollard by itself is sufficient, there’s no need to add moped=yes, the node should not prevent the moped from being routed along the cycleway. Elsewhere (e.g. Germany, UK) where mopeds are not allowed on cycleways, mappers also agree that a simple barrier=bollard node is fine: even though mopeds aren’t allowed, we don’t tag it moped=no (nor do we tag it as moped=yes just because mopeds fit past). So there is no real disagreement about the tagging, it’s just a question of how we document how we map on the Wiki.
Then there are cases where there are actually different tagging approaches. They are probably not that common but still common enough to think about. A landowner has illegally put up a locked gate across a public footpath, is that foot=no or is it foot=yes but locked=yes? A fence has appeared and I have absolutely no idea if it’s still my legal right to access the land behind it - I am not a lawyer - but what I do know is it prevents me from accessing it without climbing over it, is it OK to still tag foot=no? You have to carry your mountain bike over a stile but you can legally continue on the other side, should I tag the stile as bicycle=no?
How do we document this situation on the Wiki and explain it to new mappers and data consumers? Do we say
- on barriers, as on highways, access tags should be used for legal access only. They are sometimes used to mean that a mode of transport cannot pass the barrier physically but this usage is wrong, it’s a misunderstanding of access tags, and there is community consensus that this should be avoided. Use other tags instead to indicate physical accessibility (
maxwidth:physical,locked, …) - there is a difference between barriers and highways: on barriers, access tags are mostly used to mean physical access, i.e. what the barrier practically blocks from accessing the other side
- access tags represent a combination of permission and physical access, in other words,
yesmeans allowed and possible, andnomeans either illegal or impossible - there is no consensus in the community about how exactly access tags should be used on barriers. Some mappers reserve them for legal access while ohers also use them for physical access
If we don’t make a decision we end up with (5): the Wiki says completely contradictory things in different places 
1 Like
I agree these are worth discussing. For clarity I think the examples should also include cases where signage might be illegal, either because somebody puts in place a sign where they have no legal right to do so, or because they destroy legal signage.
I can think of an example in Ireland where a dispute between a landowner and local authority about access to footpaths went all the way to the Supreme Court, a 58 day (!) trial, and several million euro of legal costs. During a period of around 5 years, it would have been impossible for a mapper to determine the legal access rights.
For these reasons I don’t see the distinction between legal and physical access as clearly as some people seem to. As a practical matter, don’t we generally have to assume that physical barriers reflect the legal situation, unless there is specific reason to think otherwise?
Note I am talking here about intentional physical restrictions, not (for example) a path where bicycle access is legal but the condition of the path makes it unsuitable.
I think so, but it seems like there’s some contention over whether mappers are also responsible for evaluating the effect of a barrier’s design. A closed gate is relatively straightforward – literally an open-and-shut case – compared to a bollard or other permeable barrier. As much as I hope that more routers adopt locked=* over time, I can easily imagine a long tail of other micromapping that routers would now need to understand if we handle physical passability with the same precise fervor as legal permission.
Incidentally, where was the concern about ambiguity when we decided that wheelchair=* would simultaneously describe physical passability (by virtue of values like limited) and legal permission (by virtue of its inclusion in the access key list)? Does this sign indicate a lack of permission or of physical access?
