Rethinking yes/no legal access tags on ways to document physical restrictions

[Minh_Nguyen (Minh Nguyễn)]

@Tolstoi21

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!

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.

@julcnx

@Minh_Nguyen

I’d favor establishing subkeys to clarify access restrictions where necessary. However, there should be subkeys pertaining to both permission and reachability, with the main access keys being a summary of these aspects when no distinction is necessary or relevant.

Could you give a concrete example of how this would look in practice and how it would solve the issues we’re discussing?

To elaborate on this point:

• Undeprecate the bicycle:practical=yes/no pattern 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.