There also needs to be an alternative for Not Applicable

How should that be tagged?

Good question... I was thinking that paths that should not have an mtb:scale tag should be filtered out. But it would obviously be difficult with a particular OSM tag.

The reason for not tagging a path with mtb:scale, that I can think of, would be if the surface is paved or smoothness is excellent. If those are not tagged, maybe the user could be given a choice to tag surface instead?

Something like "Not applicable, surface is paved" or simply "Not applicable, please comment why".

The reason for not tagging a path with mtb:scale, that I can think of, would be if the surface is paved or smoothness is excellent. If those are not tagged, maybe the user could be given a choice to tag surface instead?

Ok I'd turn this around then: Only ask for places where the smoothness is bad or worse.

One comment regarding the tag in general:
I prefer if there was a tag that doesn't force users to classify something but just to report what they see. Because, classification is always subjective, while for example recording the incline, or recording the surface, or recording the nature of obstacles is more objective and verifiable.

Ok I'd turn this around then: Only ask for places where the smoothness is bad or worse.

I wouldn't recommend that. There are 560 493 ways tagged with mtb:scale. 51.7 % of them are tagged with highway=path, 42.2 % are on highway=track.

14.9 % of the ways tagged with mtb:scale are also tagged with smoothness and only 1.74 % of all paths are tagged with smoothness (0.85 % of all paths are tagged with highway=bad or worse).

Conclusion: Filtering by smoothness will return almost no paths to tag. And I originally wrote to filter by path only, but probably track should be in the filter too.

As for verifiability, I hear you and I agree that it should be possible for others to verify to as much extent as possible. Still, to get any useful data to categorize paths on anything else than surface - which is quite important for trail running, mountain biking and to some extent hiking - mtb:scale and smoothness are the two most important keys available...

I think the descriptions for the 0-6 values are quite good. Combined with two photos for each value it will not be too difficult for the user to decide. And by the way, of all mtb:scale tags in OSM, 75 % have a value of 0 or 1.

Conclusion: Filtering by smoothness will return almost no paths to tag. And I originally wrote to filter by path only, but probably track should be in the filter too.

Well the user will tag smoothness first, and then conditionally be asked about mtb scale.

Again regarding the tag - wasn't there a scale or some tag for "hiking difficulty" or something like that, too?

Again regarding the tag - wasn't there a scale or some tag for "hiking difficulty" or something like that, too?

https://wiki.openstreetmap.org/wiki/Key:sac_scale

Ah, there is also trail_visibility.

Well the user will tag smoothness first, and then conditionally be asked about mtb scale.

Ok. So users will have to tag smoothness first and then only add mtb:scale to "bad" paths? In a way it makes sense, since mtb:scale=0 basically means anything that has smoothness=intermediate or better and as such doesn't really add any information. Still, mtb:scale may give a lot of information regardless of whether there is a smoothness tag.

But since smoothness is used more than mtb:scale I can buy the reasoning. :)

Again regarding the tag - wasn't there a scale or some tag for "hiking difficulty" or something like that, too?

https://wiki.openstreetmap.org/wiki/Key:sac_scale

Ah, there is also trail_visibility.

What would you think about adding those two as separate quests as well? Judging from the number of times the tags are used, there could be a hierarchy of the order that the characteristics of a path have to be added:

1. surface
2. smoothness
3. mtb:scale
4. sac_scale
5. trail_visibility

Or should any of the lower ones be possible to add without having to add the ones above it first? mtb:scale and sac_scale should probably be possible to use independently, as well as possibly trail_visibility.

This is why i suggested that smoothness should be tagged first to ensure the question is only asked for eligible elements.

Right. I'm not completely convinced that only paths with smoothness should be eligible for tagging mtb:scale. There could possibly be other ways of filtering out paths that should not be displayed. But if a way only has highway=path and nothing else, then surface should always be tagged first.

But it may sometimes be easier to set mtb:scale for a highway=path with surface=ground, than to set smoothness. Many MTB-specific paths may be easy to tag with mtb:scale, but those tagging may not care much for smoothness.

Still, is there a better way to filter out irrelevant paths? Maybe not, unless we filter only by surface. Smoothness could be set for any surface, while mtb:scale really is only relevant for all unpaved surfaces, that are not specifically set to exclude bicycles. Would that return too many paths? And what about highway=track, that may get tracktype rather than smoothness?

Thinking out loud... But possibly filter by:

1. highway= path OR track
2. exclude any ways with sidewalk=both|left|right, bicycle=no
3. exclude any ways with smoothness=excellent|good
4. exclude any ways with paved surfaces

Maybe if smoothness is bad or worse OR surface is ground

Fair enough! Although not just ground. I would include all of unpaved|ground|gravel|dirt|grass|compacted|sand|cobblestone|fine_gravel|earth|wood|mud|clay.

Basically, I would tag mtb:scale for any unpaved path, although many of them will be mtb:scale=0.

How about tagging just mtb:scale=no and sac_scale=no when the user don't this that path fit into the sac or mtb scale?

This way router can use this tag too, to route for example city bikes through a wood, while on a path with mtb:scale=0 it might skip that because the tires are not made for gravel, even when it's solid - while it's no challenge for an MTB with the wide tires.

Additionally, there's also mtb:scale=0+ according to the wiki. I think this might be helpful to distinguish between 0 and 1 which is a pretty large step (just from the pictures)

It's also important, that mtb:scale is mapped for each direction of the way, not in general. So we need to ask for the incline direction and then add mtb:scale:uphill.

Could this be restricted further to things that are explicitly bicycle=yes maybe?

Thinking about my local area; the legal access is very limited for mountain biking; and it wouldn't make much sense to map unpaved walking paths through a flat park; which are tagged in a similar fashion to an unpaved mtb trail in an explicit area.

Could this be restricted further to things that are explicitly bicycle=yes maybe?

That wouldn't work in Sweden, where we basically can use a bike anywhere. Virtually no forest paths are tagged with bicycle=yes. Also, I find that many interpret bicycle=yes as fine for a "normal" bicycle to use, whereas mtb=yes may be used to specifically mean mountain bikes. There doesn't really seem to be any consensus on this however, so it's probably very much depending on location and the mapper.

Also, mtb:scale can be used on any path, not just MTB trails and it can also be a way to tell how technical the path is for hiking.

How about tagging just mtb:scale=no and sac_scale=no when the user don't this that path fit into the sac or mtb scale?

There's a vivid discussion on the tagging mailing list about how to tag different kinds of pathways. I think adding a "no" option to mtb:scale and sac_scale would be great, as it explicitly tells that this path is easy enough for a "normal" bicycle (with smoothness being used for more detail) and people of ordinary ability to walk on.

Additionally, there's also mtb:scale=0+ according to the wiki. I think this might be helpful to distinguish between 0 and 1 which is a pretty large step (just from the pictures)

Question is if any ordnary mapper is able to make such detailed distinctions? I agree in principle, although not sure how easy it would be for mappers to know the difference.

adding a "no" option to mtb:scale and sac_scale would be great

Introducing new tag values into established tags should be done elsewhere, not on the GitHub issue tracker of a specific editor.

Tagging mailing list/OSM Wiki proposal would be a better place for such discussion.

I tested some ideas on area near me.

Asking for any unpaved (or excluding paved) is generating far too many false positives: http://overpass-turbo.eu/s/10em
Smoothness only filter seems more reasonable: http://overpass-turbo.eu/s/10eo

As an outdoor freak, I would definitely love such kind of quest. Indeed mostly because of my trail running background, I would rather prefer seeing a separate quest for tagging mtb_scale and sac_scale. I use the latter a lot in mountain environments (see for instance the area around St-Gervais-les-Bains, France) and make a deep use of it with Oruxmaps and OpenAndroMaps for mountain hiking and running. Separating both and not making them hierarchised (mtb_scale before sac_scale) seems to make better sense to me because MTB and hiking/running users are different populations : I wouldn't feel comfortable enough to tag mtb_scale while I am for sac_scale.

WRT which ways to tag as such, using smoothness only is quite restrictive at least if the target is tagging sac_scale, as most of the ways where this information is useful are not for use by any kind of vehicle (MTB included) and thus smotthness would always be "impassable"....I don't feel like tagging all mountain trails as very_horrible or impassable.

So, that's indeed a bit tricky but I'd love seeing something like this in ST

Maybe that would be fitting as an overlay? I sometimes add mtb scale (in hope that routing will avoid path not actually usable by cyclist)

Even Vespucci has problems as full description is not displayed there.

Menu could be similar to smoothness quest and show images with a description, allowing sane editing of that data.

Overlays would allow to avoid problem "where this info should be asked" query blocker

I think it would be great to get a solution to this issue. For lots of MTB riders, mtb:scale is by far the most important tag across all of OSM, as it enables MTB maps such as https://mtbmap.no/.

Using an overlay for this type of tag is an interesting idea. While it would probably work well for just mtb:scale, there are so many more tags that would benefit from the same mechanism, and that would lead to an explosion in the number of overlays:

• mtb:scale
• smoothness
• trail_visibility
• tracktype
• sac_scale
• incline
• mtb:scale:uphill
• class:bicycle:mtb
• class:bicycle
• a bunch of additional class:bicycle subclasses

Actually, I would love to have all of these as overlays, if overlays could be disabled the way quests can. Most of these should probably be disabled by default.

But I think adding them as quests probably makes more sense. I like the idea of requiring surface to be set before mtb:scale will be asked. I do not like having to set smoothness as well, because that seems intended mostly for motorised vehicles, and as such are irrelevant on all forest and mountain paths. But then there is the issue of filtering away false positives. I think we'll just have to filter the surface tag more. The MTB tag is of most use on bare terrain, and less interesting on gravel, cobblestones, etc. So I suggest the following filtering, adapted from what's suggested earlier in the discussion:

highway=path|track
exclude any ways with sidewalk=both|left|right, bicycle=no, or mtb:scale already set

surface=ground|dirt|grass|sand|earth|wood|mud|clay|rock|woodchips|snow|ice|salt
OR
smoothness is bad or worse

This is going to be more restrictive than @westis wants, but it seems necessary in order to proceed with this issue.

Agreed @torhovland. It would be great to get more info in this teretorium of paths. Currently there's nearly nothing to do while hiking in StreetComplete and there's a lot of details which are not mapped.

It's especially boring to use those "walking" trails, which are made around here a lot. Which are either paving stones or compressed stabilized earth block soil plus some kind of stones and the width of a car.

It's like highway driving, if you want to drive off road, while absolutly impossible to even spot the difference on the map right now, as both are considered tracks for logging.

This is going to be more restrictive than @westis wants, but it seems necessary in order to proceed with this issue.

Restrictions can be lifted in the future, if there's enough demand for a change. Let's get first something under way and see how it works - aka minimum viable product.

To confuse the matter, in Swinley Forest (popular with mountain bikers), many of the mountain bike trails are tagged as highway=cycleway. It would be good to capture details about these to stop my journey planner from sending my road bike along them.

e.g. https://www.openstreetmap.org/way/220312904

That may be the case for Germany as well, as basically everything with a blue sign (=bicycles allowed and nothing else) is usually thought of as cycle way.

So while the infrastructure may not be different it could be tagged as cycleway, path, footway, track or unclassified.

I think it kinda make sense to think of a way to correct these mistakes in SC as well.

Would it be possible and helpful if ways are included or excluded based on whether they are inside/outside landuse areas. For instance exclude paths inside landuse=residential or only include ways at least partially inside landuse=wood or landuse=forest?
I also think that such a quest should be off by default, as I think you need to have been riding the way on an MTB to really be able to classify it well (i.e. I disagree that this is "Easily answerable by everyone from the outside but a survey is necessary": some MTB experience is necessary). Maybe add a "Do you really have enough MTB experience" question before allowing it to be switched on.

That's an interesting idea. True, if a way is inside a residential area, it's basically always made for normal bicycles to ride on. I guess the same could be said for commercial, industrial and retail.

But I don't think it makes sense to use a positive list like landuse=forest for this, as there are plenty MTB trails elsewhere - like on rocky mountain sides.

I agree those quests should be disabled by default, to avoid that people try to solve them but are not fully understand them.

I like @torhovland idea to move this forward, but I disagree with:

I do not like having to set smoothness as well, because that seems intended mostly for motorised vehicles, and as such are irrelevant on all forest and mountain paths

I've never owned a motorized land vehicle, and care greatly about bicycle-related quests (my primary use of OSM). I'd hotly disagree that smoothness is "mostly for motorized vehicles" -- it is absolutely one of most useful tags for my bicycles (trekking, touring). I also don't get the claim that it is "irrelevant on all forest and mountain paths" -- majority of smoothness values (everything below bad) basically only ever exists on "forest and mountain paths", so it is quite relevant there.

Note that if one is not able to answer smoothness quest, they certainly won't be able to answer mtb:scale quest either, as at least 2 out of 5 factors needed to define mtb:scale ("Surface" and "Obstacles") are the basis of smoothness as well.

So, in short, I would change OR to AND in that comment.

Would it be possible and helpful if ways are included or excluded based on whether they are inside/outside landuse areas. For instance exclude paths inside landuse=residential or only include ways at least partially inside landuse=wood or landuse=forest?

I only have some slight idea how those are actually programmed and principle of their work (so take this with huge grain of salt), but I think it won't work, as you would need to have download whole landuse polygon first (which for forests, residential ares etc is often huge and quite unlikely to be downloaded in full, unless you meticulously pre-downloaded whole forest part-by-part. Also, I understand that such matching inflicts additional performance penalties even in cases where it is possible). (But, I could be wrong there, so someone more knowledgeable should correct me!)

I think you need to have been riding the way on an MTB to really be able to classify it well (i.e. I disagree that this is "Easily answerable by everyone from the outside but a survey is necessary": some MTB experience is necessary).

You are right, if included, it should definitely be disabled by default. There is also the question of presenting the mtb:scale values to mapper who is not familiar with OSM tags and their wiki (e.g. just the work for making values of smoothness readable to layman using StreetComplete was quite an effort and took a lot of time; and mtb:scale is arguably of same or even higher complexity).

Alternatively, if the suggested Quest ends up not passing thresholds for StreetComplete, SCEE fork is less concerned with quests having to be user-friendly. Also, for the impatient, it's Custom overlay feature kind-of already allows adding a mtb:scale (or any other tag), just not in fast & user-friendly way (i.e. you have to know tag names and values by heart) 😺

I have added a PR that implements this. It is currently based on what I suggested, but I am happy to do whatever changes are necessary to get this merged.

Sorry, I haven't been following this thread in the last days.

I tentatively agree with @mnalis here regarding that smoothness should be tagged first. Otherwise, questions about MTB scale on e.g. city parks, cemeteries etc. would pop up, too (many ground paths, but rather well-kept).

On the other hand, I really do agree strongly with @matkoniecz about it would be a better fit as an overlay. Actually, I long thought that smoothness should be an overlay, too. Reasons why MTB difficulty should be an overlay:

1. We can do away with worrying about and crafting appropriate filters to not ask for the MTB difficulty for too many paths. Because this filter will always be too strict for some people and too unconstrained for other people. So as a quest, it will always be a source for discontent, either in the one direction or the other, or both. Which will also generate a lot of strife, refining the filters, for us maintainers. We can mostly avoid that with an overlay.

2. People who map MTB scale (i.e. those who would activate the quest) have an interest in mapping it comprehensively for their area and also keep it up to date when they see that something is outdated. Overlays are perfect for that. The re-survey functionality of quests is somewhat limited, especially for ways and for large values like 8 years or something, as when no check_date:mtb:scale is set, SC looks at the last edit date of the whole element, which will very likely change for other reasons too, e.g. someone correcting the geometry or someone adding/changing surface, smoothness, incline, access restrictions etc. .... - in other words, it is likely that the MTB scale will de-facto not be asked again, ever, when implemented as quest

3. MTB scale data, just like smoothness, is quite subjective and contextual. We must acknowledge that MTB scale has been and will be tagged by many different people who will have (slightly) different opinions on what scale a particular path should be. It very much helps, then, to see how nearby paths have been tagged in order to make the tagging of MTB scale in that area consistent.

Regarding your comment that the overlays menu would absolutely overflow with different overlays if overlays for such (fringe?) tags as MTB scale are added: Yes, you are right. But this will happen in either case. So, sooner or later, we will have to think about either changing the UI to accommodate more overlays, or like you suggest, only show the most popular ones up-front and hide the other ones in the settings. (I like that idea.) But that shall not be your concern.