So, what’s your point? Are you saying we shouldn’t create new tags/values or use secondary ones (smoothness, width, …) just because they might not be supported consistently or at all?
Sure, using access=no for anything deemed “impractical” makes routing easier, but it creates a poor experience for mappers—without mappers, there’s no map.
I don’t see how the threat of legal action over proprietary Google Maps data applies to open-source data in OSM. If anything, it would push consumers toward better and standardized support.
That’s not how I read that bit. As an example, the steps on this public bridleway are “legally cyclable”, but I wouldn’t recommend that route to an unsuspecting cyclist. Obviously you could add more tags there, but a very long highway=steps should be a bit of a red flag to an average cycling router.
I was simply backing up the point you made in your original post and underscoring the constraints that led you to propose misusing discouraged instead:
In practice, most people only use no in extreme circumstances, whether due to practicality or legality. There’s even a view that, legally speaking, no is equivalent to private but more emphatic, for when something is inaccessible for both reasons. So should we just get rid of no altogether?
@julcnx - I sympathise with the pain! I have been in your position. (I may be the source of the case @Richard was referring to regarding a trunk road in Scotland, ).
This forum is great - experienced mappers are really supportive of questions and the learning curve we all pass through. Neither of us were the first to ask about access key in this way and I doubt we will be the last…
Anyway, upshot of my question is that I now use other tags to indicate appropriateness: sac_scale; width; smoothness; etc. and hazard tags (e.g. for fallen trees).
Absurdum indeed. Along these lines, I’ve previously gotten into some back and forth with a mapping team over the access keys for service roads on and around airport tarmacs. It’s very tempting to tag access=no, to ensure that no router sends a hapless traveler to a back gate, but it isn’t quite true that no one may use the service road. Maybe this is what the wiki’s discussion of access=no is getting at.
access=private allows iterative refinement in order to distinguish private=ground_support (e.g., the little vehicles that ferry your luggage around) from private=maintenance, while yes=* and no=* would truly be magnets for absurdity.
I hate to say it again, but that’s not true in the areas where I map.
I thought the current wiki was clear—it states that “no” applies to legal restrictions on public roads, while “private” and “permissive” refer to non-public roads. In my view, based on the general consensus, impractical or non-legal usage needs its own value or should be documented as controversial like it’s done for “discouraged”.
Then I’m glad we’re in agreement that they’re doing it wrong. Have you tried a non-tagging-proposal intervention? Where can we read up on any public dispute among local mappers about the meanings of the existing tags?
If these mappers are reaching for access=no at the slightest inconvenience, how would the existence of a hypothetical access=theoretically_legal_but_highly_impractical value change their behavior? On the other hand, access=definitely_legal_but_kind_of_inconvenient would create its own perverse incentives, dissuading even more reasonable mappers from applying access=private, mtb:scale=*, etc. when appropriate.
By the way, this table also has a couple long footnotes that go into detail about what counts as a “public” or “nonpublic” road. It goes into legal fine points that would probably go over the head of anyone who’s using access=no as you seem to be describing.
I’m not sure this distinction is as firm as the wiki seems to suggest. Here’s a road leading to the tarmac of San Francisco International Airport, with a sign indicating that the road is restricted. Unauthorized entry is not only trespassing but also against national safety and security regulations. Yet we’ve tagged it access=privateprivate=ground_support for the reason stated earlier.
And here’s the “private highway” that enters the same airport from the other side, leading to the terminals. This sign uses more or less the same language as access=permissive signs in several countries that have inherited English common law. It just so happens that the “private” owner in this case is the City and County of San Francisco, the same entity that owns most of the city’s streets. Technically, we should tag this highway as access=permissive, despite ownership=public.
Anyways, I’m not sure the distinction this table makes is particularly useful to your point. Is it not possible for a park operator to prohibit anyone from traipsing over an abandoned trail, even their own staff, regardless of whether they’re a public authority or private entity?
To clarify, there is no current dispute. Access tags for physical feasibility were introduced many years ago by mappers who are no longer active locally. Best practices are documented in our Thailand wiki, but new mappers sometimes replicate older contributions or overlook alternative tags.
Mappers in the region are generally not very communicative, but past discussions suggest these edits were made for convenience. They preferred a simpler approach, using only highway and access tags to ensure compatibility with most renderers and routers rather than managing complex tagging schemes.
Yes, you’re right—it may not fully resolve the issue.
Some end-users want to contribute, which is great, but they prefer simpler tagging. How do we make that work without affecting more detailed tags?
People worldwide seem to use mtb=yes/no for convenience, so there’s clearly demand for something similar.
I like your idea! There are many cases where a mapper thinks a way that is already mapped or he is about to map may not be practical for use by some map users, but doesn’t have/doesn’t know how/can’t be bothered to add information on what it is that may make a way impractical for use. I’ve been playing with the idea to introduce a number of new values in the highway=* space to temporarily tag newly mapped highways for which information is lacking to be able to give it a definite existing set of highway and descriptive tags, and proposed one for dangerous paths. But since most mappers seem to abuse the access=* space for this, it may not be a bad idea to introduce one or more tag values in that space to accommodate this. However, I think it should be clear that such tags are meant to be temporary, and should eventually be replaced by tags that describe what it is that makes a way impractical for some use (smoothness, sac_scale, width, etc.).
I think this is the utopia we should strive for: it is the map user that ultimately wants to decide for himself if he wants to use a way or not. We should not take that decision for him, but provide him with the information needed to take that decision himself. An ideal router would then have a number of default profiles that a user can choose to help him take the decision (GraphHopper already has several), and allow the user to create custom profiles according to his own wishes and abilities. For this to work, a large majority of ways would need to be tagged with many different quality and other descriptive secondary tags, but we are nowhere near that. Introducing temporary tags that provide at least some information (if only boolean) and at the same highlight ways for priority surveying will make this task a little less daunting.
Update: Following the general consensus of the majority of participants, I’ve added a note to the wiki highlighting that using access=no for physical restrictions on highway is controversial, and recommending alternative tags.
Definitely ‘temporary’ until more tags are added. I believe this tag can still serve as a useful option for new mappers working on basic highways, hopefully helping to educate them about additional tags and encouraging other mappers to add them.
Before drafting a formal proposal, I’d like to get community feedback on this follow-up idea:
Would you support adding access=impractical as an official and temporary value?
Yes
Maybe / needs more discussion
No
0voters
This tag would apply specifically to ways that are legally accessible for a given mode of transport (e.g., motorcycle, bicycle) — but physically very difficult or unrealistic to use due to terrain, obstacles, or other non-legal factors.
None of the existing access=* values clearly capture this case:
permissive, customer, destination, and even public describe legal or social usage rights, not physical usability.
no or private imply legal restriction, which would be misleading here.
discouraged refers to signs or formal dissuasion, not terrain or difficulty.
access=impractical would fill this gap — as a temporary placeholder when more specific tags (e.g., dirtbike:scale, mtb:scale, surface) aren’t yet available. Mappers would be encouraged to refine it later.
This could also help new mappers flag questionable paths early on, while nudging the community toward better, more structured tagging.
On the topic of more urban stuff, I suggest introducting access=illegal and access=impassable while access=no stays as an imprecise value for either of these.
So for example a dedicated busway would have access=illegal + bus=designated but a bollard would have motor_vehicle=impassable.
The big difference this makes is that emergency vehicles can omit laws but still won’t cross uncrossable barriers (except removable ones but an average ambulance won’t be removing those if not neccessary).
In case of overlap access=private and impassablewould have priority over illegal.
I haven’t yet voted on @julcnx’s poll above, but I guess I’ll add a ‘no’ vote soon as well (or a ‘maybe’ vote, I don’t know). One reason for the ‘no’ vote would be precisely the idea expressed above.
I’ve been pessimistically waiting for a suggestion like this to crop up. In some ways I think it (and of course further dozens like it) is a perfectly reasonable continuation if we indeed were to go down the path of accepting the =impractical key and diluting the access key space.
In my opinion, there is little to no imprecision in access=no as the wiki now suggests using it. Of course ambulances, fire trucks and police vehicles, tanks, and whatever can ignore legal restrictions if they are on their way to save lives, put out fires, apprehend criminals or fire shells… We already have other tags to express uncrossable barriers.
I agree — @pavvv’s idea would be a real improvement. But let’s be honest, introducing two new values like illegal and impassable would likely trigger even more resistance.
Also telling is how quickly the naysayers jumped in to vote on my poll within seconds — most without ever engaging in this thread. That alone says a lot about how change in OSM is often shut down, regardless of nuance or context.
Whether or not a new tag or access value is the right solution, it’s trying to fill a clear gap — where access tags are often misused or conflated without providing a distinction between legal and physical restrictions on ways (AND nodes). If you’ve got a better idea, great — let’s hear it!
Maybe that’s because it’s kind of phrased wrong. I wouldn’t call a key “temporary” since we don’t map temporary features in OSM.
Also it may be because all other access tags describe legal access only so perhaps other tags should be used for describing physical access(?)
I guess you got me here… But are you sure that covers all the cases? Though it’s not like I can think of any counter-examples.
I don’t have to post hundreds of comments on a thread that dismisses the consensus that access-tagging is for legal restrictions, when others have already done so and were ignored. You’re free to discuss your thoughts and suggestions, but the voting just seems to show that the discussion has taken place in a “bubble”, and that the majority on the forums disagrees with you. Nothing more.
None of the arguments, why we should use legal access tagging for practical usability has convinced me, and thus I vote nay.
I can understand that you’re frustrated, but please don’t make the mistake of assuming that the voters haven’t read the thread or are fundamentally opposed to change just because you couldn’t convince them.
And therein lies the fundamental problem: that is also true of access=impractical/impassable. We already have other tags that describe more precisely the way in which a route is ‘impractical’ or ‘impassable’. The descriptive tags. This is a complicated issue for sure (and the discussion has been very interesting)!
Concerning =impractical or =illegal, in my neck of the woods, ambulances and fire trucks e.g. do drive on tram tracks when they are in a hurry. Police cars also take shortcuts over grassy areas between roads. At least that, would represent an uncrossable barrier in OSM, since there is noway to be used! But I’d think even the railway=tram for ambulances, police and fire trucks is a tough one to tag.
I genuinely thought the idea of the voting mechanism was to quickly gauge opinion based on the 90+ posts already in the thread, without the need for everyone to repeat each other’s points, for or against. It seems unfair to ask people to vote and then say they are closing down change when they participate.
I didn’t vote because I don’t fully understand the idea. E.g. if a way is tagged as “destination” or “customers”, how would it be tagged as impractical without losing the information about who is allowed to use it? It would be good to have more detailed examples, e.g. a track that allows permissive access to all modes but is only practical on (say) foot, MTB, and 4WD.
Or how about a way that is both private and impractical? Should mappers prioritise one tag over the other?
Yeah, I guess they can also pass through some traffic islands if the kerb is low enough but we don’t really map ways through those.
Well that’s impossible when it’s just tracks. But rails embedded into concrete should indeed be mapped as highway=service + access=no and perhaps even as service=emergency_access in case no buses drive on that road.
).
Yes
Maybe / needs more discussion
No