Sure, detail about physical properties is good; I don’t think anyone has a problem with that. But I don’t think there are many mappers who’d go through the trouble of determining the legal or physical clearance of an overpass, only to toss that measurement out in favor of hgv=no. When someone tags bicycle=no based on practicality, they lack either the data or the vocabulary to articulate precisely why, or they haven’t even given it much thought and consider it to be self-explanatory. We should totally develop that vocabulary, but a simple Boolean flag can still be a decent first approximation.
1 Like
You keep repeating this point, and insisting that there isn’t a relevant distinction to be made with legal access and physical suitability, and that they are equally self-explanatory. I’d argue that this is a classic case of a category mistake. Like saying that colours have a smell. Signage and laws are explicit. Suitability is not only subjective, but also multi-modal by nature.
Put explicitly another way: would you think it fine to tag a way with both bicycle=no and mtb:scale=⟨>1⟩? I’d say it’s a contradictory pair. A mountain bike is a kind of bicycle. If I ever came across a way tagged like that, I’d immediately remove the access tag.
Regarding the Boolean value first-approximation argument: confounding legal access and suitability under the same key, and under the same =no value (as your examples repeatedly show) seems to many of us an absurd proposition. I mean, take a look at the example pictures of ways tagged >1 on the mtb:scale key!
Earlier, you mentioned that you’d be OK with a subkey that “pertains to both permission and reachability.” @julcnx asked you for a concrete example. It’s a long thread and I may have missed that example, but could you point to your answer?
even as a first approximation this is not recommendable because it will sit in the db and look ok although it isn’t.
1 Like
I’m not defending continued mixing of legal and practical usage of bicycle=no. I’m insisting that we should have a compelling alternative that doesn’t leave mappers with a lexical gap due to inexperience or an unusual real-world situation. Just because someone thinks it’s self-explanatory doesn’t necessarily make it so to everyone, but we are all humans.
You seem to be suggesting that, if we discover a changeset that says “Tagged bicycle=no on some legal but impossible paths”, we should immediately delete bicycle=no from each of these paths without replacement, unless we go out and survey each of them for their MTB scale (and probably also for width, surface, smoothness, visibility, incline, etc.). And if it already has an MTB scale assigned, you’d trust it over the bicycle=no uncritically. I cannot explain why one would combine bicycle=no with mtb:scale=2, but that would seem unnecessarily aggressive to me.
You make some assumptions about signs. Search this forum for mutcd @minh_nguyen and you’ll be shocked to discover that both American and European signs can be nuanced in their own special ways. Most of the time, this nuance doesn’t matter enough to undermine their legitimacy. But even in this thread, we had an example of a sign that on its face says one thing but opens up a can of worms about legal authority.
To elaborate on this point:
- Undeprecate the
bicycle:practical=yes/nopattern for reachability. Hardly any*:practical=*tags remain in the database, so this would be relatively safe. - Introduce a pattern like
bicycle:designated=yes/no/private/etc. for permission. (I’m not wedded to this nomenclature.) - Acknowledge that
bicycle=*in practice could potentially refer to a combination of permission AND reachability unless clarified by one or both of these subkeys.
Existing data consumers will continue to be as (in)correct as they have been, but now they can update to avoid a way tagged with any one of bicycle:practical=no, bicycle:designated=no, or bicycle=no. An application could offer an option for places with lax traffic enforcement that ignores bicycle:designated=no, or a YOLO Mode that ignores bicycle:practical=no.
How does this solve the problem statement expressed in the original post? Going forward, when you see bicycle:designated=* or hgv:designated=*, you can be sure it’s an observation of a legality. To the extent that a feature still has only bicycle=*, you can reasonably assume it’s because the legalities match practical realities. In situations where this assumption may be faulty, such as off-road paths in rural Thailand, the local community can establish an expectation that the subkeys be tagged explicitly just in case. But we won’t have to have bizarre discussions completely detached from reality about, say, whether it’s legally permissible to drive an Amphicar in a public swimming pool just because that leisure=swimming_pool way is still tagged access=yes.
First of all, thank you very much for your clear & concise reply. It really did clear things up for me in your thinking!
Let me also say upfront that I think your solution to un-deprecate the :practical qualifier is a perfectly possible one. Having said that, I wouldn’t support a similar :designated qualifier , since the access tags would (and do) work fine without it. Concerning your third point on acknowledging ambiguity in the access tags:
Precisely! Well, perhaps I’d say an mtb:scale estimate and/or a few crucial secondary tags describing its physical characteristics would suffice. Indeed, regarding the ‘lexical gap’ you rightly speak of, the descriptive secondary tags offer plenty of vocabulary! Furthermore, paths that lack all secondary tags can already be safely supposed to be in a rough condition—and more importantly in dire need of revising and further mapping. A prohibitive/dissuading access tag for ⟨vehicle⟩ on a way that doesn’t legally prohibit/officially dissuade a ⟨vehicle⟩ is simply incorrect.
Again: Bingo! An estimate of mtb:scale gives me a pretty good idea what to expect. I drive my non-suspended commuter/road bike on short stretches of few paths nearby (correctly) tagged with mtb:scale=1, because they offer a decent shortcut. A way suitable for mountain bikes shouldn’t be tagged as off limits to all bicycles.
I have a very different sense of the completeness of our tagging schema. There are a lot of keys, to be sure, but that doesn’t mean we can dust our hands. The world is a hugely varied place, especially when we consider countries other than our own. For a sense of perspective, look at all the 
and “Speculative” littering some of our tag correspondence tables, and consider how many of the tags that are there enjoy adequate editor support. And that’s for signs, which are more standardized than practical means by which access can be restricted.
As tempting as it might be to make this discussion all about highway=path and bicycle=*, it’s inherently about so much more, because these tags don’t exist in isolation; they’re part of an existing system, and the difference in understanding is systematic.
In the abstract, yes, but would you trust an mtb:scale=2 added 15 years ago over a bicycle=no added this year to the same feature? Would you trust an mtb:scale=2 added in a large changeset over a bicycle=no added more specifically? Are you confident enough about this assessment to propose a mass edit to this effect, or to convince the router developers to ignore the bicycle=no? These are the sorts of considerations we need to weigh before tossing out contributions as meritless.
How can a data consumer be sure that we’ve completely purified the existing access keys of any practical assessments? Do we know how many there are?
I would split and set the before steps segment with highway=footway + bicycle=yes or dismount, then the steps with highway=steps + bicycle=dismount and the next segment to highway=footway + bicycle=yes or dismount
1 Like
Thank you for taking the time to explain this concept so clearly!
I agree with you on this. If we were to document and support a new [vehicle]:practical key, how can we ensure that people stop using [vehicle] access keys for practicality? And how can we identify which existing keys have been reclassified?
The only way would be to introduce a second key. Additionally, I would suggest deprecating the original access keys and encouraging users to switch to the :practical and :designated keys. Does that make sense?
& here’s another variation on the same theme!
What’s the foot equivalent of bicycle=dismount? 
Just to make it explicit, these points concern (mis)using access key for practicality/suitability. I’m sure that there are open questions about edge-cases and gray areas in using the access keys for legitimate reasons too.
I would otherwise agree, but this case seems to be a matter of mappers misusing the key. I don’t see how this differs from the misuse of any other key. I mean, how can we ensure that people don’t misuse other keys & how can we track which cases were corrected? Regarging this:
My direct answer is I would, and I’d toss away the access key without a second thought. Like I said above, the keys are mutually exclusive. The fact that the mapper didn’t remove the mtb:scale key immediately tells me that they were misusing the access key. Perhaps I’d add a curt comment to their changeset as advice.
However, I suppose @Minh_Nguyen s more general point was that it’s probably not very terribly unwise to treat features last updated a very long time ago with some suspicion and take them cum grano salis. This, however, I think applies to all tags.
Indeed, to return to the question of how we can ever be sure that the tags are correct, doesn’t it go something along the lines of…
I’m fixin’ to get from ⟨A⟩ to ⟨B⟩, and gee golly doesn’t the [beat my router suggests|map rendering|whatever] give me the heebie-jeebies! I’ll betcha that the
pathtagged⟨x⟩=⟨y⟩oughta be⟨x⟩=⟨z⟩or gosh-darn just plain⟨p⟩=⟨q⟩! I’ll be a good scout 'n check it out myselfs!
…for any keys ⟨x⟩ & ⟨p⟩ and any values ⟨y⟩,⟨z⟩ & ⟨q⟩)? Unless there’s a consensus that we should start adding notes to every tag (in which case please see this post).
Good luck with that. You’re proposing to redefine an access tag - you know and I know that that is not going to happen.
Where I map stuff (UK, mainly England), I don’t see a massive problem (apart from access=yes where it is actually permissive - for all access tags, not just bicycle**). We have lots of ways tagged bicycle=yes or =designated which are impractical for anything but the most mud-loving MTBer. I suspect that that is somewhat because in England and Wales there are lots of ways where the legal access rights for bicycles is very clear (legally designated “public bridleways”), and it might be that elsewhere there is more of an issue. The tricky bit is that fixing these requires people to “get on their bike” 
I agree that “a compelling alternative” is required, but with surface and smoothness we have some of that already. Can anyone think of examples where surface and smoothness (and perhaps other tags) are already mapped but more is needed?
** a completely different issue.
3 Likes
bicycle=dismount and bicycle=no are the oddities here. Something like horse=no or horse=dismount is very clear, but cyclists can “get away with” pushing a bicycle even when access=no (and we’re clearly not going to change that now).
The access wiki page actually does a good job of explaining these nuances.
I see the logic behind what’s being proposed here, but the proportions don’t reflect my experience.
In the UK, at least, I’d say that bicycle= is 95% used for legal access and only 5% for practicality. I can remember just three occurrences of the latter in recent years (some footpaths around Leicestershire which were erroneously tagged as bicycle=yes because someone wanted to cycle on them, some National Trust organised editing in North Wales which asserted bicycle=no on a bridleway, and a Scottish trunk road discussed on this forum). That’s just everyday I’m-new-here-and-don’t-quite-understand-how-things-work, and not something that requires rethinking some of our most fundamental tags.
So I can see two ways of addressing this. One is by introducing a new tag like bicycle:practical=no. You are welcome to do this, but it will be approximately the 39786th attempt to fix path tagging in OSM by inventing a new tag, and at that point XKCD 927 applies. It will be used by approximately thirty people, most of whom are reading this thread and all of whom know how to tag anyway. Most routers will ignore it, and those whose authors read this forum will treat it identically to smoothness=impassable.
Or, circling back to @julcnx’s original suggestion, you can introduce a new value to the existing access tags to mean “allowed but impractical”. This has the advantage that it (potentially) appears in the same iD drop-down that the newbies are using anyway, so they will see it at the same time as they would otherwise select “no”. It is slightly impure in that it pollutes a key space otherwise mostly used for access, but if you’re worried about a pure taxonomy then OSM is probably not the project for you.
4 Likes
Presumably several? As well as yes;impractical we’d want `permissive;impractical" and a bunch more?
… anywhere with highway=path already knackers “pure” access tags
(I’m not 100% convinced that this approach is a good idea, but it deserves investigation)
1 Like
sac_scale=mountain_hiking
Add: At least, when regarding the physical aspect, especially regarding barriers, as mentioned above.
1 Like
I agree. Maybe another option is to make the smoothness wiki more path-friendly? I use smoothness=impassable on legal paths where local mappers originally tagged them as not practical for horses or bikes using access tags.
I also use sac_scale=fixme, mtb:scale=fixme, etc., on ways that were tagged foot/bicycle=yes just for practical reasons (even though some of them could technically be restricted legally). The idea is to educate mappers about these additional tags and encourage them to update the values. This was based on an earlier discussion, and it probably needs to be documented in the wiki.
Additionally, a lot of these uninformed practical tagging issues seem to come from new mappers (at least around here), so maybe the iD editor just needs a few tweaks:
- Add dropdowns for
sac_scale,horse_scale, andmtb:scaleand stick them near the top. - Drop the “Structure” field to the bottom.
- Rename “Allowed Access” to “Allowed Access (Legal/Signage)” to make it clearer.
But yeah, I know how hard it is to get anything changed in the OSM ecosystem, so I’m not getting my hopes up.
3 Likes
What is this discussion even about, if not the redefinition (or further definition) of access tags?
I don’t either, really. The onus is on the proposal and its supporters to demonstrate that there’s such a problem that a solution is needed. But as it stands, the proposal is for us to reread the wiki, and then reread the wiki in a few months when this issue arises again.
My counterproposal is essentially to break out of this cycle and define some subkeys that can be used, possibly redundantly, for more clarity, as an option when anyone cares about the distinction. The next time this topic comes up again, we can point to these subkeys and observe that “approximately thirty people” have ever used it. It would be a superb ROI versus the ink spilled every time.
You’re making it sound like the only issue is an unreasonable resistance to change, but I don’t see any issue in the id-tagging-schema repository that suggests enabling the Hiking Difficulty (sac_scale=*) field by default instead of hiding it behind a dropdown menu. I can’t guarantee that some consideration won’t come up that needs more thought, but in general, changing the UI requires less deliberation than changing a very well-established tagging scheme.
1 Like
Yes, as long as it isn’t called discouraged. That’s different.
2 Likes
Ok I want to move forward with a new impractical access value proposal that I believe will address several common issues raised in this and other discussions:
- Clear distinction between legal vs. physical restrictions.
- A simple dropdown option for iD users to prevent misuse of
noaccess value. - A way to tag routes impractical for certain vehicles not covered by existing scale tags (e.g., strollers, motorcycles, …).
- Reducing misuse of
access=nofor blocked, under-construction, or impassable sections. - Clarifying tagging of narrow urban ways, e.g.,
width=1 + motor_vehicle=impractical.
Proposed Wiki Description
impractical
“This tag indicates that a way has no legal or signed restrictions, but is physically impractical due to trail conditions, obstacles, or danger.
While more descriptive tags (e.g.,smoothness,width,mb:scale,sac_scale,obstacle, …) are preferred, this tag provides useful information when those are unavailable (such as a scale tag for the vehicle).”
Addressing Concerns
- Overlap with existing tags – This is a common issue in OSM (e.g.,
tracktype=grade1alongsidesurface=dirt).- The recommendation is for mappers and data consumers to prioritize additional tags when available.
- Do we need more keywords to describe impractical ways under other access values (
permissive,designated,discouraged, …)?- No, because the goal is to keep it simple for beginners to provide a basic indication.
- If a way is
permissive, it can be considered as already suitable. If it’sprivateordiscouraged, routers will already avoid it.
Open Questions
- Any alternative word for
impractical? Options:unsuitable,impassable, or another native English term? - What’s the process? Can I start using it and document it in the wiki, or does it require a formal proposal?
2 Likes
I’m not sure if it affects your overall proposal, but this behavior isn’t guaranteed:
Data consumers’ handling of unrecognized values is also inconsistent:
But sometimes it’s especially important for routers to adhere to practicality regardless of the legalities: