I do not have the desire to use another tag then the “access tags” to indicate something is physically passable but I would urge people that think otherwise to make a RFC for something like accessible:bicycle=no so at least there is an accepted alternative.
We do not have to change the definition of access tagging as it is now we just have to limit it to paths and roads (Key:highway) and that is I think what most people care about. There is one notable exception that I already documented in one of my earlier posts.
For everything other then Key:highway, the “access tags” are very widespread used, not for legal access but more as “designated”, for a list see my earlier post.
Does anybody feel the desire to “cut down” the usage for the non-highway use of the “access-tags”. If so what alternatives are present?
Mind you, it is people mapping using what is available in the tagging nomenclatura. Making sense of that algorithmically, certainly @Richard know their stuff. I am a human, I can tally the intricacies.
Not sure I understand what you are trying to say with this.
Are you saying that cycling=yes is never used in combination with information=guidepost because it is never documented that way? If so that make sense, the page indicates to use to use “bicycle=yes”
Note that is why is was urging people to make a RFC for something like accessible:bicycle=no if they think the “access tags” should not be use for barrier=bollard.
See, its people, people can make sense out of anything Accessibility can mean: by law, by power. I’d say, these are not the same. So separate terms perhaps warranted: Aiding in reproducibility of what is in term. As of now, consumers are tasked to decide case by case.
Thanks for finding that. It’s interesting it says access rights in the heading and then talks about what a barrier blocks, as if that was the same thing.
Another variant is the Wiki page for Key:access which claims far up that “no” means “You cannot physically go through it” while “private” that means “You are not allowed to go through it”. This is promptly contradicted further down on the same the page where “no” is defined as “general public access is prohibited. stronger interdiction than private”…
Looking into this further, the table at the top that claims that no means “you cannot physically go through it” was only added in mid 2023, the other definition or some variation of it has been in there since 2008 or so…
Do we agree that this is wrong and should be reverted?
I think the page should be updated on multiple places such that there is a clear distinction is made between access-tags in combination with roads/paths (Key:highway) for which applies:
Access values describe legal permissions/restrictions and should follow ground truth; e.g., signage or legal ruling and not introduce guesswork. It does not describe common or typical use, even if signage is generally ignored.
and things like barriers, ford=yes, railway=crossing, entrance=yes for which the primary criterium is physical access (typical use), although in the exception there is a sign, something like motor_vehichle=permit also can be used
The third category of usage is in keys like information and amenity where these “access tags” are used to indicate the usage is designated for the given “transport mode”
Do I want my router to take me through that barrier? If it’s legal and physically possible, yes. If it’s illegal or impossible, no.
Distinguishing the mixed cases (“it’s illegal, but you could drive around that barrier” or “the road is blocked, but the person putting up the barrier had no right to do so”) only matters in comparatively less common use cases.
From my point of view, it’s a router decision whether a physical barrier is passable or not and not a mapper decision. Only routers have the necessary information such as width, height,… of the vehicle, animal or person and the physical dimensions of the barriers available to find a fitting route.
I think, the data collectors task is to gather this physical information (e.g. free_width=*, free_height=*) and not to interpret it (e.g. bicycle_passable=yes/no).
I have always read ‘private’ access as privately owned. So if you are the owner or can get permission, access=private effectively no longer applies to you. A ‘no’ access would mean there is an official reason why you are denied access. Is usually for emergency access or so safety reason.
for example it could be a bollard where you may not drive through (sign), but you could push your motorcycle and walk through it if the space is sufficient (if you can drive on both sides of the bollard)
Routers usually don’t have this information. How many of us would want to use a navigation application that demands to know our girth before it can suggest the optimal route, which we could follow if only we put some elbow grease into it? (Answer honestly, lest you get stuck in a compromising position.) Even a truck routing profile may allow the driver to omit some information that’s relevant to legal restrictions, like the type of cargo. Yet the world goes on, as mappers make bold generalizations and routers err on the side of caution.
Indeed, whether a bicycle can pass a barrier=motorcycle_barrier technically depends on the length of the handlebars, but in the absence of that information, it’s still useful to know that it’s a barrier designed to allow bicycles through in general. For barrier types that don’t have inherent design criteria, like bollard and block, users benefit from mappers noting what seems to be the basic purpose of the barrier, even if they don’t happen to have a measuring tape handy. Meanwhile, for vehicle types that don’t have inherent dimensions, like bicycle and hgv, a router’s default behavior unavoidably assumes a “typical” vehicle, caveat emptor.
In cases where we really need to split hairs, more for an audience of fellow mappers than an audience of end users, nothing is stopping us from prefixing or suffixing these keys or adding a note.
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.
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?
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.
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.
Accessibility can mean: by law, by power. I’d say, these are not the same. So separate terms perhaps warranted: Aiding in reproducibility of what is in term. As of now, consumers are tasked to decide case by case.
