[Poll / Follow-up] How to tag MTB rideability when difficulty is unknown?

General talk Tagging general discussion
,
1

This is a follow-up poll from these discussion, this other one, and this poll.

I want to tag whether a path is known to be rideable by mountain bike, even when its difficulty (e.g. mtb:scale) hasn’t been tagged yet.

This info helps:

  • Differentiate potentially unrideable paths from those confirmed rideable
  • Prioritize future surveys and improve mapping in under-mapped regions
  • Let non-OSM-savvy riders indirectly contribute useful knowledge

What counts as “rideable”?

“Rideable” refers to trails that are actually used by mountain bikers — not just ones that could be used in theory. It’s based on real-world use, not assumptions or visual guesswork.

:white_check_mark: Confirmed rideability means:

  • The trail has been ridden by someone on a mountain bike
  • There’s local knowledge, GPS traces, or firsthand experience backing it
  • Even if the trail is technically difficult, rocky, steep, or has unknown conditions, someone has managed to ride it

:no_entry_sign: It does not mean:

  • The trail looks suitable based on imagery or assumptions
  • You think it might be rideable but haven’t seen or heard of anyone actually doing it
  • It’s perfectly smooth or easy — rideable trails can still be challenging

What about legal access ?

:small_orange_diamond: “Rideability” is unrelated to legal access — the trail may be legally accessible, or the status may simply be unknown.*

The key distinction is: actual use over theoretical suitability.
This helps keep OSM grounded in verifiable, real-world data — especially in under-mapped areas where reliable local input is crucial.

How is “rideability” currently mapped?

In practice, mappers sometimes use tags like bicycle=yes or mtb=yes to indicate rideability, even when legal access is unclear or restricted — leading to ambiguity and tag misuse.

Tags like mtb:scale=yes, unknown, or fixme, and similarly sac_scale=yes or dirtbike:scale=? are commonly used, highlighting the need for a clearer tagging method to distinguish confirmed real-world use (e.g. rideability or hikeability) from uncertain or missing legal and technical details.

Requirements:

  • Must use a meaningful key/value that routers/renderers can interpret based on vehicle profile so no fixme, note, description or similar
  • Should work regardless of access (yes, permissive, unknown, …)
  • Should be preferably vehicle specific (e.g. mtb) — not general bicycle:*
  • Should be broad enough to apply to other activities and existing/future scales (e.g. horse, atv, dirtbike, via_ferrata, climbing), so avoid :rideable:
  • Typically applied to highway=path or similar where vehicle usage is not always implied.

Note on mtb:scale:
Though officially defined as 0–6, real-world tagging already includes many alphanumeric values) like 0+ and 2-, which are typically processed as strings by data consumers (e.g. OsmAnd). Therefore, using new text values would not be a blocker.

:ballot_box: Poll 1: How should we tag MTB rideability when difficulty is unknown?

Select your preferred overall approach, or suggest your own in the comments.

  • Use mtb=yes for physical reasons while bicycle=yes/no is kept for legal reasons.
  • Guesstimate mtb:scale value (e.g. mtb:scale=2, based on vague description and/or GPX speed data)
  • Document a new mtb:scale value (e.g. mtb:scale=unknown, =yes, =?, etc.)
  • Document a new tag with an mtb: prefix (e.g. mtb:usable=yes, ``)
  • Document a new tag with a :mtb suffix (e.g. usable:mtb=yes)
0 voters

:ballot_box: Poll 2: If we document a new mtb:scale value, what’s the best keyword?

Vote here if you selected “Document new mtb:scale value” in Poll 1, or suggest your own in the comments.

  • mtb:scale=passable
  • mtb:scale=navigable
  • mtb:scale=traversable
  • mtb:scale=yes
  • mtb:scale=unknown
  • mtb:scale=fixme
  • mtb:scale=unrated
  • mtb:scale=survey
  • mtb:scale=?
0 voters

:ballot_box: Poll 3: If using a new tag with a prefix or suffix, what’s the best keyword?

Vote here if you selected new mtb: prefix or :mtb suffix in Poll 1, or suggest your own in the comments.

  • practical
  • physical
  • usable
  • passable
  • navigable
  • traversable
  • feasible
0 voters
2

:negative_squared_cross_mark: We don’t!
This is a highly subjective estimation.
The rider has to decide if a section is rideable for him or not.
A tagging “rideable=yes/no” is impossible.

8 Likes
3

Aren’t these requirements mutually exclusive?

My suggestion to the overall problem would be adding a few key physical descriptions, at least width= or est_width=, surface=, and smoothness=

3 Likes
4

Maybe there’s a misunderstanding here. If a reliable source provides GPS data and says a trail is rideable, that’s not a subjective guess. Mapping without a ground survey is common—people map roads and buildings from imagery all the time.

That said, I fully agree that assuming a trail is MTB-suitable without local knowledge is subjective, error-prone, and shouldn’t go into OSM.

Just to clarify: this poll is about reliable local knowledge of trail rideability. Many areas are poorly mapped, with few active mappers but many users—some of whom are happy to share useful info even if they don’t map themselves.

1 Like
5

That might work for short, memorable trails, but if someone rides 50 km in a poorly mapped area, it’s hard to describe the many variations in trail conditions. Assigning a smoothness value without a ground survey is like guessing mtb:scale, and in any case, smoothness is rarely used on highway=path and not very popular among mappers.

6

What you mean by “MTB rideability”?

That it is legal to cycle there? (refuted by “Should work regardless of access (yes, permissive, unknown, …)”)

That it is interesting and worth riding (not a flat path)

That it is not 30m vertical drop with ladder etc?

7

See updated What counts as “rideable” ? section above.

8

=passable

?

neither unknown nor fixme nor unrated nor ? express that it is passable with MTB

it just express that value is missing, which does not require tag to be set

3 Likes
9

That makes a lot more sense now that you’ve pointed out the issues with the other one. I’ve added it to the poll.

10

I’d like to point out that bicycle=yes/no is very often de-facto is used for passability, (even though the official guidelines seem to be about legality).

In Israel Hiking map, a popular OSM based app in Israel, purple indicates “passable but difficulty unknown”. a highway=path is brown, but becomes purple by virtue of having bicycle=yes, adding mtb:scale augments the color and changes it according to difficulty.

You have to switch to the MTB basemap to see this behavior.

So, according to that logic, a rideable path with unknown difficulty is simply highway=path, bicycle=yes.

1 Like
11

This thread is explicitly a follow-up from a recent big thread about this where a whole bunch of shortcomings of this de-facto approach were discussed, so presumably this thread is an attempt to arrive at a better solution

2 Likes
12

I used mtb:scale=6 when GraphHopper started routing bikes up a new path I had mapped. There were rocks and so on, only room for one person in several places, so I didn’t want anyone to inadvertedly try to go up there

13

That makes sense as an immediate workaround — but ideally, a better long-term solution would be to ask routers like GraphHopper to avoid routing MTB or bicycle profiles on paths without at least one of the following:

  • bicycle=yes/permissive/designated
  • mtb=yes/permissive/designated
  • a mtb:scale value

This aligns with the recommended approach for data consumers.

If you’re a highly skilled rider and genuinely feel that section qualifies for mtb:scale=6 (which, as noted in the wiki talk page, is increasingly used for very advanced trails), then that’s valid. But if it’s assigned purely to block routers — without actually reflecting ground truth — it crosses into tagging for the router, which we generally try to avoid.

3 Likes
14

Assuming these paths are legally accessible, it’s reasonable to tag them as “legal and passable but difficulty unknown” — as long as we don’t misuse bicycle=yes without evidence that someone actually rode the trail. That’s subjective and misleading.

Similarly, tagging bicycle=no just because a path hasn’t been ridden yet is also subjective and should be avoided. It risks conflicting with truly restricted paths.

If the concern is misrouting, the solution is to fix the router behavior — not tag for the router.

15

I assume that the subject of MTB rideability was chosen as an example, and that the results of this thread should be applied to any mode of transport to which it can be applied? I think it should be generalised to include other transport-mode specific quality tags such as sac_scale, dirtbike:scale, etc. as well as to more general ones like smoothness and maybe trail_visibility

There is a strong demand for being able to tag somehow that a way has an issue for a certain mode of transport, i.e it may not be practical, passable or even dangerous for a large group of map users. The access space (and to a lesser extent, smoothness=impassable) is often abused to express this, and this should be avoided (it’s “tagging for the renderer”).

However, I think it is not for us mappers to decide whether a way is practical for use by a certain transport mode or not: it should be up to the map user to decide whether a way is practical for him or not. Some map user might want to cycle to work in a fast and comfortable way, while another user might be looking for a challenging trail to cycle to train his skills. Our job is to provide the map user with information so he can take a decision whether a way is practical for him or not.

So a tag that is used to mark an issue with a way for a certain mode of transport should never be judgemental: it should not express the opinion of the mapper whether a way is practical. That’s why I voted mtb:scale=unknown in the second question and not passable or traversable That it is unknown expresses an objective fact, the others are not objective.

mtb:scale=unknown also nicely expresses what the problem is and how we want to solve it: if mtb:scale was known, there would not be a problem, and replacing mtb:scale=unknown with a surveyed value is what we want to happen to solve the problem and enable to map user to decide for himself.

Just adding a new value to the mtb:scale=* space is not enough to solve the problem: we also need

  1. to give advice to data consumers on how to interpret this new value, and
  2. a mechanism to make sure that these tags are noticed and replaced with surveyed values.

For the first, I think we should add to the wiki documentation of the new value that this value expresses that the way has an issue, and recommend to data consumers to either not display or route the way (for the particular transport mode, or in general?) or to only display and route it with a warning that there is an (unknown) issue.

For the second, the new value should be interpreted by mappers as fixme=this way needs to be surveyed for mtb:scale=* with priority but it should be more noticeable than the fixme tag is. It often also takes more expertise (MTB riding experience, for instance) than most mappers have. Maybe we could cooperate on this with apps that use our data? Could we cooperate with Strava, for instance, and ask them to ask their users who use Strava in MTB mode and are using a way tagged with mtb:scale=unknown to “review” these ways and give it an mtb:scale=* value? That review could be in the form of a StreetComplete-like quest, with some well-described answer options for each mtb:scale=* value

I consider myself an experienced hiker, and use Locus Maps with OpenAndroMaps maps. Locus Maps already has the possibility to display OSM notes and to respond to them: wouldn’t it be great if it would also display ways tagged with sac_scale=unknown and ask its users to review them (giving 7 possible descriptions to choose from), and pass on the results to us? We could then decide that if a 2/3 majority of hiking app users, with a minimum sample size of 10, selects sac_scale=mountain_hiking for that way, that is reliable enough to then tag the way like that (could even be automated).

3 Likes
16

That’s definitely the intention!

In my experience, starting with very broad or generic polls can sometimes lead to confusion or a lack of clear direction, which makes it harder to gain traction. That’s why I thought it might be better to begin with MTB, which I thought had a strong mapping and user base. There’s also a precedent with tags like dirtbike:scale=?, which helps illustrate the idea.

Regarding sac_scale, it may be a bit less directly applicable in this context, but a similar approach could still be useful—especially to distinguish known walkable trails (even when access is uncertain) from highway=path segments that may have been mapped from imagery alone or could represent abandoned or disused paths.

Do you think it would make sense to run a separate poll for hikers and sac_scale users, or would it be better to invite them to participate in this one?

17

What’s the difference between “mtb:scale=unknown” and no mtb:scale tag? Isn’t it the same? Should we use ‘unknown’ for smoothness, surface, sac_scale… ?

1 Like
18

I guess routers may have improved, because now even the pedestrian routing avoids the path (it’s tagged with sac_scale=mountain_hiking), so I think I will remove mtb_scale

1 Like
19

A more appropriate value would be mtb:scale=passable, which indicates that the way is passable on a MTB, though the exact difficulty is unknown. This is different from leaving the tag empty because it still offers a hint to data consumers (apps, routers, etc.) that the trail isn’t completely unknown or unmapped — just not fully assessed. It’s similar to using surface=unpaved—vague, but still informative. The same idea could apply to sac_scale, but not to smoothness, since that tag isn’t vehicle-specific.

1 Like
20

OK, let’s see if we can agree on this concerning MTBs, and then see how we can apply it to other quality tags.

I hope they are already watching this thread. When we reach consensus on this for MTB, we should discuss it again for other quality tags.

You changed the focus in this thread compared to previous ones from tagging potentially impassable ways, to tagging passable ways. I think the first has priority, as it can lead to dangerous situations when a way that is impassable for most map users doesn’t appear like that. But we can discuss tags for both cases.

Then mtb:scale=unknown could be used for ways that a mapper considers impassable for the majority of map users, with the intended meaning of that tag being fixme=this way urgently needs to be surveyed for mtb:scale=* because I think it is impassable and possibly dangerous for many (answering @bradrh 's question above). In the cooperation with app makers I proposed above, these would be shown for review with priority.
Likewise, mtb:scale=passable (or usable, in line with the term “usability” used on the smoothness wiki) could be used to tag ways that have some evidence of being passable (strong Strava heat, being mentioned in travel blogs, wikiloc, etc.) but haven’t been surveyed for mtb:scale=*. The intended meaning would be fixme=please survey for mtb:scale=*. In apps we cooperate with, these would be shown for review only if no mtb:scale=unknown-tagged ways are present in the map view.
We could advice data consumers not to route MTBs over ways tagged with the first, but to include them if tagged with the second.