I picked foot at random, but my point would still stand for horse (for bridleways) and golf_cart (for golf cart paths).
Maybe access= should be split into 2 separate tags:
legal_access=* to show that this is a public carpark, private driveway, for customers only etc, &
physical_access= to show what may actually use it e.g.
this is a legal_access=yes public footway, but it’s a 45° slope up a rocky hill, so physical_access:foot=yes; p_a:car, p_a:bike, p_a:horse, p_a:wheelchair, p_a:stroller=no
No research on what you did update: Access===legal! No talk about that. Physical===accesibilty.
This sentence doesn’t make any sense to me. Is there a word missing perhaps?
For a barrier, crossing and ford=yes, it indicates there is physical access, in the case there is a sign that should be used instead.
1 Like
physical_access=yes/no are always more or less accurate assumptions of the individual data collector and maybe hard to verify by others. physical_properties=* didn’t have this issue - they are clear measurable and verifiable by others and physical access can be derived. Currently there is a Feature Proposal - Elevator dimensions under way, which I think, points in this direction.
They are indeed measurable and verifiable, but in practice I doubt many people will have the time/equipment/inclination to record them.
Eyeballing a barrier and entering yes/no is much, much easier than busting out a tape measure and recording the details.
1 Like
Thanks for reviewing.
If we add the word “traffic” before sign, does that help. The possible problem with that is a sign “pedestrian only” that is not an official traffic sign.
Probably lost in translation but on “No research on what you did update”, I guess that research has to be done by others?
Agreed there is a difference between access and accessibility and there is a third category, “designated”. Those terms are handy for discussion but I think they are not needed on a Wiki page.
I meant “editor preset” like: A dialogue with checkboxes, and people just click all the options that apply - from their interpretation, what the tag is about.
Indeed: access is legal, accessibility is physical, and designation is ideal.
No, I assumed that much, but there’s something ungrammatical about this sentence. Did you mean something like this?
For a
barrier,crossing, orford, it indicates there is physical access. However, if there is a sign, that should be used instead.
I guess that’s pretty close to how I’d expect most mappers and data consumers to interpret these keys in practice. There are definitely some situations where a sign indicates an impossibility. This is why I formulated it differently earlier: an “access key” indicates whether the facility is physically accessible and one is allowed to use it, or whether neither are true.
If one is true and the other is false, the tagging is undefined, but it isn’t a big deal for practical purposes. I could see mappers needing this information for recordkeeping purposes, to determine why an access key is set to a particular value. A subkey or note=* may make sense in that case, but I certainly wouldn’t want mappers to have to worry about hypothetical distinctions every time they map a path or barrier, all for the sake of a relative handful of edge cases.
We can even use subkeys to express skepticism about whether and to what extent a signposted restriction applies:
1 Like
For a {{TagKey|barrier}}, crossing and {{tag|ford|yes}}, it indicates there is physical access. However, if there is a sign, that should be used instead.
was added to Tag:bicycle=yes: Difference between revisions - OpenStreetMap Wiki
But I think that it is not exactly accurate - it takes legal access unless feature is impassable.
If you have 10 cm wide passage signed as legally passable by bicycles (right of the way?) then it is still bicycle=no.
* gate that is normally open and wide enough for a cyclist: {{tag|barrier|gateway}} + {{tag|bicycle|yes}}
since when we use barrier=gateway for gates?
( applies also at least to Tag:foot=yes: Difference between revisions - OpenStreetMap Wiki )
1 Like
if there is a 10cm wide way “signed as legally passable by bicycles (right of the way?)”, this would be bicycle=yes, width=0.1 - unlikely to exist, but who knows. The typical situation for 10cm wide ways is that there is 10cm on the ground but more space above, otherwise it would not be passable by anyone and not be a path, footway, cycleway or whatever highway.
1 Like
This is what I was thinking too, though I’d prefer namespacing:
access:physical=*
access:legal=*
(for specific modes, bicycle:physical=*).
In fact, we’d really only need one new tag access:physical=* as access:legal=* is analogous to the documented usage of the current access=* tag.
So, if physical =/= legal, then we’d tag as:
bicycle=yes
bicycle:physical=no
That’s a meaningless distinction. If I physically can’t drive my bike through a 10-cm wide way, or over a 30% steep incline, I don’t care if I’m legally permitted to do so. I’d rather have the routers avoid it in all situations.
As Mateusz somewhere mentioned, much more interesting are rare cases when you are technically legally not permitted to use a certain mode of transport, but nobody obeys this and it is not enforced. I can think of at least 2-3 cases of a “No vehicles” or “One way” sign placed for bureaucratic reasons, ignored by pretty much every local. But since Hard cases make bad law™, I would agree that those should be tagged by motor_vehicle=no and leave the technical law-breaking to the locals.
2 Likes
Disagree entirely.
In England and Wales, for example, we have Public Rights of Way. These are enshrined in law with various access permissions. These deserved to be mapped, as do their access rights.
However, just because legally they can be used, it doesn’t mean they can physically. We often find some are blocked, overgrown, or simply not suitable for all legally permitted transport types.
One particularly unusual example is a public byway that runs across Morecambe Bay. It is legally enshrined that all traffic can pass through here (foot, bike, horse and even motor vehicle). However, you’d be absolutely mad to attempt this. Currently we have to add various other odd tags, and use disused:highway=* to try to prevent people being routed here. But it is, legally, a highway.
1 Like
Disagree entirely.
That’s as useful as the information that I won’t be fined If I drive a space shuttle through a byway_open_to_all_traffic. It’s neither physically possible nor I likely have a space shuttle, but just in case…
1 Like
Your straw man example really doesn’t help with anything.
The OSM UK community map public rights of way and use the as-currently-defined access tags to document the explicit legal access rights conferred to those ways due to their status. It would, however, also be beneficial to include what the physical access conditions are in some neatly defined way. Mixing access/physical restrictions leads to confusion.
Confusion by whom?
Data consumers. I see a public bridleway mapped (correctly) as a bridleway in OSM but then find I can’t use the way as intended because it’s not physically accessible for me and my horse.