To improve safety, accuracy, and map quality, I propose updating the wiki guidelines for highway=track and highway=path to recommend that routing engines only route when at least one of the following is present:
An explicit legal access tag (yes, designated, destination, permissive, etc.)
A relevant scale tag indicating physical suitability (smoothness, mtb:scale, sac_scale, etc.)
A physical suitability tag (TBD: e.g., [vehicle]:suitable=yes, [vehicle]:practical=yes, or [vehicle]:physical=yes) when no specific scale exists for the activity
Any other relevant tags on the way or relation that describe the activity (e.g., class:bicycle, lcn_ref, etc.)
If none of these tags is present, the way should be considered preferably unroutable (or given a strong penalty). This approach ensures that users are not routed onto undocumented or potentially dangerous trails.
Naturally, a router will avoid restricted legal ways by default, even if they are suitable for the activity or have a relevant scale.
Motivation
Safety and Reliability: This proposal reduces the risk of routing users to non-existent or hazardous paths, which may have been mapped without on-the-ground verification or imported from imagery alone.
Accurate Use of Tags: It prevents the misuse of legal access tags to indicate physical suitability, ensuring they are used strictly for legal purposes. (see Discussion)
Incentivize Better Tagging: Mappers will be encouraged to add relevant tags, leading to more detailed and accurate mapping.
Rescue Operations Reduction: By avoiding routing on poorly documented paths, unnecessary rescue operations could be reduced.
If someone were to use bicycle=no on a path because it’s physically unsuitable for bicycles (e.g., too rough), the proposal would still require a legal access tag like bicycle=yes or a scale tag to make the path routable for bicycles. This prevents the misuse of legal access tags for indicating physical unsuitability.
Examples
Routable paths:
highway=path + bicycle=yes
highway=path + mtb:practical=yes
highway=path + mtb:scale=1
highway=path + smoothness=bad
Non-routable paths:
highway=path
highway=path + bicycle=no
highway=path + mtb=no
highway=path + bicycle=yes + mtb:scale=6 (legal but impassable way)
highway=path + bicycle=yes + mtb:practical=no (legal but impractical way)
Potential Concerns and Solutions
“But my favorite trails don’t have any additional tags!”
This proposal encourages the community to enhance mapping details, so this is an opportunity to add the missing tags.
”My activity doesn’t have a scale tag!”
This is the perfect time to create a new scale tag for your activity and invite other community members to contribute to OSM. Alternatively, a physical suitability tag could be used. (TBD)
Compatibility with Existing Routers:
The change might require routing engines to update their algorithms, but the long-term benefits outweigh the initial adjustments.
Scope and Limitations
This proposal focuses on highway=track and highway=path, as these are the most common classifications where issues arise.
The approach could be expanded to other highway classifications and water activities (waterway) in the future if needed.
Call to Action
I invite the community to provide feedback and share insights on this proposal. Constructive discussion will help refine this idea and ensure it benefits all users.
Would you support this approach? Do you see any potential challenges or improvements?
But OSM can’t control how routers choose to do things.
We can set all the rules in the world, but if they choose to route somebody’s car along an abandoned, private, 1m wide, mud track, there’s nothing we can do about it!
I’m not quite sure who this is aimed at. Conscientious router authors already do more than this, and you can no more propose that routing engines should do X than propose that the King of England gives me £1m a month.
If this is rephrased as “change the wiki documentation for highway=path and highway=track to emphasise that mappers should always add access tags” then sure. But as a router author I work with the data that’s there.
Many outdoor apps I’m familiar with (such as AllTrails, Komoot, to name a few) route users through basic highway=path ways, so that’s one area to address.
Additionally, some mappers use legal access tags to describe subjective physical suitability, which is another target group of this proposal.
I’ve clarified the wiki documentation aspect. I’m not suggesting that wiki guidelines should force consumers to take specific actions, but the documentation can still be hopefully influential.
Additional tagging is highly recommended for paths. Without access and surface tags, routing engines may penalise the use of a path. Difficult hiking paths should be tagged with a sac_scale difficulty, to prevent people unwittingly choosing a route which is too difficult for them.
Define the physical attributes of a track road with these supporting tags… adding these supporting tags is recommended if the information is available.
Or the absence of such data. Cycle.travel as far as I know penalises bare and naked highway=path. More consumers should follow. After all, such a mapping only tells consumers, that the terrain can be traversed by unspecific means in unspecified mode using unspecified skills.
If the OSMF ever starts a Quality Seal for routers/renderers, to do like that would be my first suggestion as a mark that has to be checked.
Great, apologies for not double-checking earlier. From another thread, I got the impression that we needed to explicitly add access no tags on impractical or unsafe paths, as routers aren’t expected to handle additional tags.
It seems anyway that many outdoor routers still don’t follow these wiki recommendations. I might add a more prominent section specifically for routers in the wiki to re-iterate the message, similar to what we have for highway=road under Renderers.
if it was not reported already to them - I would recommend creating issue at their issue trackers or otherwise sending feedback (unless they have public issue tracker with this issue listed there)
It’s good to keep RFC 2119 in mind when interpreting tagging guidance. The passages quoted above say that, as a best practice, mappers should (not must) clarify the physical attributes, and as an option, routing engines may (not must) penalize (not categorically avoid) paths lacking access or surface tags. The most important part of this guidance is the explanation of why these best practices are such a good idea.
