I strongly oppose using yes/no access tags for documenting physical restrictions instead of legal ones on ways. Why? Because it’s too subjective and often leads to inconsistent mapping. It also obscures whether a no is due to a legal restriction or simply because someone thinks the route is “dangerous” or physically impassable for a particular vehicle.
Additionally, many mappers are either unaware of additional tags (like width, smoothness, sac_scale, …) or are reluctant to use them. In some cases, relevant physical scale tags don’t even exist (e.g., for wheelchair or stroller accessibility).
Examples
highway=residential + motorcar=no: If there’s no sign, does it mean the street is actually pedestrian-only? Or is it just too narrow, and it should be tagged as highway=residential/path/footway + width=1?
highway=path + foot=yes + bicycle=no on an unsigned trail: Is it because the trail is extremely difficult (mtb:scale=6) or simply not passable (smoothness=impassable)? Without more context, it’s open to interpretation.
Trying Out Alternatives
I’ve tried using tags like mtb:scale=fixme or sac_scale=fixme to nudge mappers toward better tagging practices. But the reality is, many still stick to the basic bicycle/mtb/horse/foot=yes/no tags. To clarify: In Thailand, legal restrictions are uncommon, and all vehicles are generally permitted on trails.
A Better Way to Tag
I believe a balanced approach would be to document the use of:
yes if it’s legally allowed AND there are no physical restrictions.
no ONLY when there’s a legal restriction (like a sign or law).
discouraged or a new tag like unsuitable when it’s about safety concerns or the route just isn’t suitable for a vehicle, but not strictly illegal.
Note: the discouraged tag is already out there, but it’s a bit controversial for similar reasons:
However, it is likely already supported by routers, whereas a new tag value will not be. The bottom line is, if mappers are unwilling to use additional tags, I would much rather they use discouraged instead of no on legally unrestricted ways.
If you think something is unsuitable for use by a theoretically allowed mode of transport, explain why in verifiable tags like width, surface, incline and (controversially) smoothness. Introducing a tag that no router could handle properly (“Your route leads over 200m of path which was labelled as unsuitable for bicycles. Still want to go?” vs “The chosen route is extremely steep and narrow for 200m. Still want to go?”) is not really helpful.
For barriers, it’s a different thing, but the meaning there is different anyway.
That’s what I do, and theoretically, it’s what everyone should be doing. But that’s often not the case. I can understand that new mappers and lazy ones might not want to deal with a bunch of extra tags. However, I don’t think excluding their contributions is the right solution for OpenStreetMap, especially since attracting new users is already challenging.
That’s a different topic, but I don’t entirely agree. There are also additional tags that can describe physical restrictions on gates (locked, width, …)
I believe routers can handle “discouraged” , and most end-users would likely appreciate avoiding paths that might not be suitable. Having some data is always better than having none.
I wanted to chime in because the topic is really interesting and surprisingly complex. I’d be really interested in what others have to say!
The way I read the access wiki page (that you kindly linked to), that is precisely how that tag is meant to be used. That is, they should be used only to describe legal restrictions (whether based on explicit traffic signs, advisory signs, or local legislation). And that’s plenty complex! The page muses on the difference of legal restrictions and de facto usage, but that is a separate issue from misusing access tags to describe physical fitness for particular uses.
However, I do recognize the problem you eloquently describe with missing additional tags! Unfortunately I don’t see an easy or quick solution to it either. Having said that, I think that adding a mtb:scale=fixme (and similar) tags is one really good idea! Perhaps a fixme=smoothness to paths that you suspect might be nigh-impassable would make sense. Though in some sense, that is already a sensible interpretation without the fixme tags. That is to say, it’s safe to assume that a highway=path with no (or few) other secondary descriptive tags is a narrow, unpaved, and horribly rough or bumpy pathway, since path is reserved for the absolute pariah-class of highways.
I do agree with the other users above in that we should not add options based on non-legal or extralegal criteria to the access tags.
While I understand you want router support in access= , promoting wrong use of =discouraged or access= for physical instead of legal restrictions only creates more problem. There are some *:physical= following maxheight:physical= that’s worth considering.
This sign communicates that the road is legally open to motor vehicles, but the highway authority is discouraging you from doing so. It’s in keeping with the rest of access tagging, in that it is observable (from a sign) and records the decision of the legal authority in charge of that road.
Using =discouraged for other purposes will mess this up. So please don’t!
And yet, statements to this effect won’t stem the tide of access keys being used more holistically until there is a similarly straightforward key (singular) to record reachability. That isn’t laziness, that’s reality.
That said, discouraged never really fit the whole “legal restriction” paradigm anyways. The blue signs in the UK are classified as informatory, while analogous signs in the U.S. would be warning (hazard) signs.
There is a hiking trail on Bureau of Land Management property that crosses a barbed-wire fence. There’s no gate or anything, you’re just expected to hold the wires apart and slip through. It’s legal to ride a horse on this trail. Is this horse=yes or horse=no?
There is a a trail in a state park that is maintained for ski and snowmobile use. In the summer, it is legal to hike or bicycle this trail. Since the snow gets rather deep, they don’t bother clearing fallen logs, and traveling it in summer can be a bit of a scramble in places. Is this bicycle=yes, bicycle=no, or bicycle=carry?
The trail to the top of Steamboat Rock is legally open to horses. A particularly sure-footed mule might be able to make it up (but would probably refuse to go back down). Is this horse=yes or horse=no?
Hi, I understand and share the need for a simple way to document practical usability, but I think the way forward is to look for a additional key instead of a additional value within the access-scheme
The access-scheme is already quite crowded since it tries to answer multiple questions in a single tag:
is access allowed ?
(=yes / persmissive vs =no/private etc)
what is the legal basis of access ?
(right of way -=yes vs allowed by owner (=permissive)
are transport modes explicitly designated ? (=designated )
is access discouraged ? (=discouraged)
are only certain user groups within a transport mode allowed
(=customers, destination…)
is a permit needed ? (=permit)
A problem with this is that -since single values are common in tags- a value answering one question obscures information about the answer on other questions
(for instance : if a way is tagged =designated) you don’t know if access is based on right of way (=yes) or just because the landowner allows it at this moment (=permissive).
Adding yet another layer (with a value for practical suitability) to the access-scheme would add to these already interfering complexities
I think inspiration could be found in additional keys with suffixes such as xx:practial= or xx:suitable=
To clarify: In Thailand, legal restrictions are uncommon, and all vehicles are generally permitted on trails.
PS
It’s good that you mention this. I could see that the solution you propose would work quite well in such circumstances, but less so in other countries with much more distinctions in public / private access rules and signs, where an =unsuitable-value would obscure that information.
The wiki does not (yet) reflect the current (and controversial) use of access=yes/no keys for physical restrictions on ways, which appears to be common at least in the areas where I map.
The good news is that there seems to be a suitable alternative to this tagging style:
I agree that would be the way to go, but it seems that :practical is discouraged:
Let’s say it’s less uncommon to be more accurate. Or conservatively, less rare. The advantage is prior discussion based, and having one source of support.
Both *:practical= and *suitable were mostly mass added. Practicality or suitability isn’t all the same as physical accessibility either. What does "Usable by" mean?
Maybe (as @multimodaal s and @Minh_Nguyen point out) a new key might be needed to make this work. But it’s a really complex matter. Very good points so far, let’s keep them coming and the discussion alive!
The point on =steps, is a good one for example. Here, step_count= matters as well. I might cycle through (or carry my bicycle on) two or even three steps if it provides a substantial shortcut, but dismounting and carrying a heavy bicycle over many steps would have to save multiple kilometers to be even remotely worth the while.
This is a good point too. And the access tags aren’t really meant to describe physical accessibility (more on this just below), right? I’d imagine it very difficult to come up with good or even somewhat objective criteria particularly for suitability/practicality. Again: enough descriptive tags might be more helpful and less controversial than a new key…
Indeed! One way I’ve seen access=no being (mis?)used is to tag ways that are under construction (or undergoing slight renovation, but long-term, and fenced-off). It seems that recently some routers began dismissing the ⟨transport⟩=no tags on ways that still had a ⟨transport⟩=designated tag (i.e. route through them even though they had an access=no tag). I suppose that is the way to go. I can, however, also understand the argument that if the way (e.g. a cycleway) is still substantially unscathed by the construction and the traffic signs are still present—but the ways are fenced off for construction—they are in some sense still designated even though not accessible to anyone.
The point @Carnildo made about skiing is one I’ve encountered also. A sizeable portion of paths near Helsinki (and other Finnish cities) get turned into ski tracks in winters that have enough snowfall. Even though walking or cycling on the prepared ski tracks isn’t really illegal, it is frowned upon in the extreme. As in risking-your-front-teeth-getting-knocked-out extremely frowned upon. Since the ski tracks are prepared only in winters with sufficient snowfall, these paths are not usually a part of piste-relations indicating that they might be unusable during (some) winters. This would be a suitability category too (in that it is not captured with descriptive tags nor a legal restriction)?
Actually, in my area, mappers use bicycle/motorcycle=yes/no to indicate practicality (comfortably passable), not just physical passability. This is evident from the fact that many legal paths tagged as bicycle/motorcycle=no are actually difficult but passable by some.
Wait, that wiki says that mtb=yes/no isn’t about legal restrictions, but the access wiki says the opposite! Wouldn’t it be simpler if we used [vehicle]=yes/no for legal access and [vehicle]:practical|physical=yes/no for practical or physical passability?
Another alternative to bicycle:physical=* might be using mtb=, which is not very clearly defined either, but common consensus on its wiki seem to be that it “points more towards practical suitability than legal access-restrictions” . Using mtb= would mostly solve the issue with “which bicycle type are we talking about?”
mtb=* – for rare cases where there are different legal access restrictions indicated for mountain bikes then for other types of bicycles (such as “access only allowed on mountain bikes” or “cycling allowed, but not on mountain bikes”). For legal access restrictions that to apply to all types of bicycles use bicycle=. To indicate practical (un)suitability for certain types of cycles / riders do not use mtb= (a form of access=), but tags as smoothness= , mtb:scale=* or surface=*
The “permission or reachability” definition dates back to the original access tagging proposal and has been with us ever since. It was only later that mappers insisted on purifying the keys to only pertain to legal access restrictions, but in practice, everyone draws the line somewhere.
The reason this issue keeps coming up is that, in many cases, to indicate permission is to answer a question that nobody asked, yet a purist interpretation of access keys leaves the question that matters – reachability – either unspoken or relegated to an obscure key that routers and renderers don’t recognize.
Most of the time we tag access restrictions, we’re doing it to influence data consumers to inform users about where they’re supposed to go. Few if any routers are intended to send users on the most extreme, barely legal route. Rather, the job of a router is to answer the question, “What’s the best way to go?”, for some definition of “best”. It’s our job to make sure that “best” route is neither illegal nor a legal fiction.
It would be (and has been) quite difficult to define a bright line rule that no edge case would confound. For every case where an access key has been “misused” to make a subjective judgment, there are countless cases where no means impassable based on common sense. Mappers didn’t need to come up with a whole new scheme or scale just to record that fact.
I’d favor establishing subkeys to clarify access restrictions where necessary. However, there should be subkeys pertaining to both permission and reachability, with the main access keys being a summary of these aspects when no distinction is necessary or relevant.
The “permission or reachability” definition dates back to the original access tagging proposal and has been with us ever since. It was only later that mappers insisted on purifying the keys to only pertain to legal access restrictions
“unsuitable” leads to many discussions and is not objectively determinable, e.g. it never was clear whether this was about the average person or if it meant unsuitable for the majority.
IMHO we should not subtag that an access tag is about suitability and not about legality, these should get their own “first level” keys (if suitability gets to be tagged at all).
In the first place, it was unclear whether “unsuitable” referred to reachability or merely preference or comfort, but I suspect it was the former. It isn’t difficult to come up with realistic scenarios where permission is beside the point but reachability is important. The existence of a gray area doesn’t invalidate the cases at the extremes. We don’t need to relitigate the pedestrian oneway=* discussion here, but there are clear parallels.
To reiterate, until there’s a mechanism for indicating reachability that’s as straightforward as the mechanism for indicating permission, the existing access keys will remain skunked (and maybe it isn’t even the big problem we make it out to be). An excessive focus on legalities inherently leads to awkwardness in situations where the only law that applies is the law of physics.
Agreed, but that doesn’t mean unsuitable belongs into the access tag category, because it’s an additional tag. Something can be access=private + unsuited, access=designated + unsuited, and it’s something completely different. Maybe, we just need a proper suffix like vehicle:usability=*, but certainly not yet another value for access …
Wouldn’t it be simpler if we used