Ask for MTB difficulty for paths #1850
Comments
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". |
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 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. |
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? |
|
|
Ah, there is also |
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. :) |
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:
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. |
|
Keep in mind the quest guidelines, specifically, that any answer the user might give must result in something being tagged and that there should be no false positives.
Asking the mtb scale for sidewalks for example may not happen, so we have to think of a tag filter that ensures that.
This is why i suggested that smoothness should be tagged first to ensure the question is only asked for eligible elements.
The same applies for the other tags. It's not about enforcing a specific order by importance but ensuring that the quest is not shown for places where it doesn't apply.
So, very roughly I'd say
First Surface
Trail visibility if surface is anything ground (earth, sand, rock, ground)
Smoothness if surface is tagged
Mtb scale if smoothness is bad or worse
Sac scale maybe not at all because the examples shown in the wiki are hardly something that would still be tagged as paths at all?
…On May 22, 2020 10:05:06 AM GMT+02:00, westis ***@***.***> wrote:
> > 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.
|
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:
|
|
That's too broad. Many sidewalks are missing the footway=sidewalk tag and many city footways/sidewalks are tagged as highway=path.
Maybe if smoothness is bad or worse OR surface is ground
…On May 22, 2020 11:11:01 AM GMT+02:00, westis ***@***.***> wrote:
> 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
|
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. |
westnordost
added
the
new quest
|
How about tagging just 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 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. |
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. |
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.
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. |
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 |
|
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, 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:
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 surface=ground|dirt|grass|sand|earth|wood|mud|clay|rock|woodchips|snow|ice|salt 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.
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. |
|
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 |
|
That's an interesting idea. True, if a way is inside a But I don't think it makes sense to use a positive list like 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've never owned a motorized land vehicle, and care greatly about bicycle-related quests (my primary use of OSM). I'd hotly disagree that Note that if one is not able to answer So, in short, I would change
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!)
You are right, if included, it should definitely be disabled by default. There is also the question of presenting the 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 |
|
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 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
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. |
General
Affected tag(s) to be modified/added: mtb:scale
Question asked: What is the difficulty level for mountain biking on this path?
Checklist
Checklist for quest suggestions (see guidelines):
Ideas for implementation
Element selection:
Select only highway=path that don't have surface=paved|asphalt or similar, and that does not have the tag mtb:scale.
Proposed GUI:
Image examples for each value, preferably with a split image for each value to display two different kinds of paths to be tagged with that value (like half the image from a mountain area with stones and another half from a forest area where obstacles are more like roots etc.
Values to display together with the image can be same as for iD:
0: Solid gravel/packed earth, no obstacles, wide curves
1: Some loose surface, small obstacles, wide curves
2: Much loose surface, large obstacles, easy hairpins
3: Slippery surface, large obstacles, tight hairpins
4: Loose surface or boulders, dangerous hairpins
5: Maximum difficulty, boulder fields, landslides
6: Not rideable except by the very best mountain bikers
There also needs to be an alternative for Not Applicable
mtb:scale is very valuable to determine the difficulty of a path, not only for MTB, but also for trail running and hiking and thus very useful for data consumers using this information for route planning.
The text was updated successfully, but these errors were encountered: