Consuming highway=path, Take 3

That would essentially be troll tagging.
Cycleway and footway convey certain expectations to users. A normal person on a normal bicycle should be able to use a highway=cycleway. An additional tag=not_actually_a_cycleway destroys that and makes highway=cycleway less useful as a whole. (The same goes for footways).


About simply adding additional tags:

In a lot of cases, we simply do not have tags that can express that easily.

What we do have is a tagging scheme for legal access (access=*) and various tags describing physical characteristics of a way (surface=*, smoothness=*, width=*, incline=*, trail_visibility=*, etc…).

Legal access is, as has been mentioned before, not the issue here. That is usually pretty clearly defined and the tagging scheme is also quite straightforward and unambiguous. The problem is whether it is practical to use a path for walking/cycling.

The physical characteristics of a way can help with that decision, but the problem is that they are extremely tedious to tag and can also be fairly hard to tag accurately.
If I’m hiking along a hiking trail, it’s obvious whether a path is suitable for cycling or not, but there’s no easy way to express that. I don’t want to stop every 10 meters and get out my phone to tag the surface and smoothness of a piece of way, even less do I want to get out a tape measure to tag the width.
Adding these tags remotely is often simply impossible since you really need the on-the-ground information for these tags.

sac_scale=* and mtb:scale=* are the best contenders here, but they also highlight an additional problem: Many data consumers simply don’t know or care about additional tags and don’t evaluate them. Having different main tags for these highways that each have very different implications is a feature not a bug.

That is exactly the problem here. highway=path itself is completely inconsistent and therefore does not convey much useful information. Extending that inconsistency to other tags is not the solution.

1 Like