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.
).
