New Quest: mtb:scale

[ravenfeld]

Same principle as sac_scale but to indicate the mtb:scale.

I'd use the same filter and validate it as for sac_scale.

I still don't know how the PR works for translations, so I've only used the default.

I'm wondering about the relevance of the photos, in the group I'm in we're not fans of these photos and it's more by habit and practice that we know what value to put.

I did a quick icon but no problem for you to push another.

[mcliquid]

I still don't know how the PR works for translations, so I've only used the default.

Translations will be available in Weblate as soon as the PR is merged. (https://translate.codeberg.org/projects/scee/)

[ravenfeld]

Translations will be available in Weblate as soon as the PR is merged.

Do I only need to supply the default or can I also put my language in?

[mcliquid]

1. I would add bicycle!~"no|private" to exclude ways that are forbidden for cyclists.
2. Should mtb:scale:uphill be added somehow as a option?
3. Can there be routes where mtb:scale does not apply? And if so, how should this be handled?

[mcliquid]

Do I only need to supply the default or can I also put my language in?

Default is english, your language will be overwritten from Weblate as far as I know.

[ravenfeld]

1. I would add bicycle!~"no|private" to exclude ways that are forbidden for cyclists.
2. Should mtb:scale:uphill be added somehow as a option?
3. Can there be routes where mtb:scale does not apply? And if so, how should this be handled?

1 - Great
2 - I've thought about it, it's a little less used. I thought I'd do a quest called mtb scale uphill?
3 - Yes clearly all that is highway that is in asphalt it is useless or compacted

[mcliquid]

I've thought about it, it's a little less used. I thought I'd do a quest called mtb scale uphill?

I'm not very familiar with mtb:scale, so if it doesn't have a big impact, I would leave it out.

[ravenfeld]

It helps, but to my knowledge it's less used than the scale, which is for descending.
You were talking about options, at the moment I don't know how to do that, if you have a quest that does the same thing I can look at doing the same thing.
Otherwise, if someone asks for it or I need it in the future, I'm going to make a new quest, aren't I?

[Helium314]

Similar to sac_scale I'm not sure whether a (filter) quest is the right choice.
Did you read streetcomplete#1850 or streetcomplete#5308? If you were to implement it as overlay, it would be acceptable for SC and thus reach far more users.

[ravenfeld]

I think I've misunderstood the overlay, for me it's just an overlay, it doesn't let me know if any tags are missing.
I rarely use overlays in my case.
I just want the notifications to tell me when information is missing and for me that's the quests, isn't it?

[ravenfeld]

This morning I played with the overlays and I know why I don't use them.
I can't combine several.

My use case:
I'm going hiking and I want to fill in the tags:

trail_visibility
sac_scale
mtb:scale
surface
smoothness
tracktype

And then the width and incline as a bonus

Unless I'm mistaken, if it's not quests I have to change overlay all the time?

[mcliquid]

Unless I'm mistaken, if it's not quests I have to change overlay all the time?

That is correct. Overlays were developed to provide a very specific type of information in a standardized and concentrated way. Personally, I also prefer to use quests instead of overlays, as I can add more diverse information this way. But in this case of the mtb:scale, I agree that it will be very difficult to cover this via an intelligent quest filter so that the quest is not displayed in city centers, for example, where an mtb:scale would never be assigned.

What is possible, however, is to combine several quests with one overlay. At least trail_visibility, smoothness, surface and tracktype are available as quests, then you could use the overlay for mtb:scale / sac_scale. Not ideal, but perhaps a compromise.

[Helium314]

@ravenfeld I think it's not only worth considering what you want to fill in, but what others might do.
If you manage to get an overlay for mtb:scale merged into SC, this reaches far more users which should be beneficial for overall mtb:scale data.

If you only care about your region and what you personally want to add when hiking, then of course there is little incentive for adding an SC overlay and a quest might be better for your use case.

[ravenfeld]

I'm looking into it, but it's a bit more complicated, especially the form.
But I think that even with an overlay I'd keep the quest too ;)

I'm going to propose an overlay for the sac_scale and another for the mtb:scale, aren't I?
For me it's the same logic.

[Helium314]

I'm looking into it, but it's a bit more complicated, especially the form. But I think that even with an overlay I'd keep the quest too ;)

Can't you just take the basic form e.g. from surface overlay?

I'm going to propose an overlay for the sac_scale and another for the mtb:scale, aren't I? For me it's the same logic.

You can also propose an overlay for sac_scale, but I'm not sure I'm willing to have new quests and overlays for the same things.

[ravenfeld]

Yes, I understand, but then I can cancel the PR for the sac_scale and keep the quest for myself.

In my opinion, you have to try to be consistent.
If you accept a quest for sac_scale then so will mtb:scale.
For me it's like trail_visibility which is currently a quest.

But I'll check with SC as the overlay is expected for mtb:scale.

Then I'll propose what I'm doing on my fork, after that if it suits you no problem to close.

[mcliquid]

If you accept a quest for sac_scale then so will mtb:scale.

I agree, as both tags are similar.

For me it's like trail_visibility which is currently a quest.

I would say trail_visibility applies to many more trails than the SAC or MTB scale, because it is basically about the visibility of a trail. A SAC classification on the other hand can only be done correctly for hiking trails.

From another point of view, one could also argue for the two quests in favor that both are always deactivated for all SCEE users in the beginning and must be actively activated, including a corresponding warning message when activating them. Anyone who is traveling in the middle of a big city and has the quest active and answers where it should not be should not call themselves an "expert". As the app says when you install it: with great functionality comes great responsibility.

[ravenfeld]

After setting up the relation=hiking for the sac_scale, I propose to do the same for the mtb:scale so that it corresponds to my use but also so as not to pollute people who don't want to indicate it everywhere.
I therefore propose to add a parameter as for the sac_scale or by default we add the constraint that it must be in a relation with route=mtb

[Helium314]

Anyone who is traveling in the middle of a big city and has the quest active and answers where it should not be should not call themselves an "expert". As the app says when you install it: with great functionality comes great responsibility.

Every now and then I check notes created with SCEE, and in my opinion there are too many people who seem to have too little OSM knowledge. For this reason I want quests to have no spam-danger by default.

If you accept a quest for sac_scale then so will mtb:scale.

If for some reason you demand that it must be the same way of implementation, i.e. that I must accept the mtb:scale quest if I accept sac_scale, then I choose overlays. Simply because then the mtb:scale overlay can go to SC, where it would be very useful and is wanted.
(if you can lift the restriction, I'm ok with the sac_scale quest as it currently is, and would only add the mtb:scale quest if the overlay is declined in SC)

[ravenfeld]

I'm not forcing anything, sorry if I worded that wrong. I'm bad at English and often use a translator to help me.

I'm just trying to be consistent.
Did you read my last proposal? #559 (comment)

It doesn't change the fact that I'm trying to get an Overlay to work right now so that I can offer it on SC, it's more the form that's still holding me back.

[Helium314]

I'm not forcing anything, sorry if I worded that wrong. I'm bad at English and often use a translator to help me.

Oh, sorry for misinterpreting yout post.

Did you read my last proposal?

Yes, this would be fine (in case the overlay is not happening).

it's more the form that's still holding me back.

Is there anything specific you need help with?
You could also open a draft PR on SC and mention your issues with the form.

[ravenfeld]

For the moment it's fine, the problem is that the images aren't of good quality, so I might open the PR and ask for help. I'm doing some tests today and it's possible that I'll suggest it to them later today.

[mcliquid]

@ravenfeld Where did you get the new images? I can help you with make them smaller with better quality if you guide me to the original versions :)

[ravenfeld]

It's the one on the osm wiki and for mtb_scale 6 on the via ferrata.
But wait until I open a PR on SC, or I'll ask.

[RubenKelevra]

@ravenfeld Where did you get the new images? I can help you with make them smaller with better quality if you guide me to the original versions :)

They are straight from the wiki page.

@ravenfeld maybe we can just go forward and make a PR here for the overlay.

I don't see the SC folks accepting this. The conversation is just running circles there.

I'm also not sure the changes requested to the text were actually good.

I feel like we should better stick to a longer text, explaining it like exactly like the original authors of the scale intended. As objectively there's no reason to not mention skill for example, or grade with percentage.

Meaning those texts should be used:

• Grade 0: "A single trail without any particular difficulties. They are mostly forest or meadow paths on a natural surface with good grip, or compact gravel. Steps, rocks or roots are not to be expected. The gradient will be slight to moderate, curves are not tight. Even without any particular MTB technique trails with S0 can be managed."
• Grade 1: "You have to deal with smaller obstacles such as flat roots and small stones. Very often you'll find that the odd gulley or erosion damage is the reason for the raised difficulty rating. The surface may not always be firm. The gradient would have a maximum of 40%. Hairpin turns are not to be expected. On an S1 trail basic MTB technique and constant attention will be required. The trickier passages call for dosed breaking and body displacement. They should generally be ridden in standing. Obstacles can be rolled over."
• Grade 2: "The trails will most likely contain larger roots and stones. The surface is frequently loose. Steps can be expected. Often there are narrow curves and the gradient can be up to 70% in places. The obstacles require body displacement to be successfully ridden. Readiness to break at all times and the ability to shift your centre of gravity are necessary techniques as well as the ability to regulate the attack of your breaking and permanent body tension."
• Grade 3: "Blocked single trails with many larger boulders and / or root passages belong to category S3. There are often higher steps, hairpin turns and tricky traverses. The chance for some relaxed rolling is seldom. Often the surface is very slippery and with loose scree. A gradient of over 70% is not unusual. Passages with an S3 grade don't yet require special downhill technique, but do need very good command of biking and unbroken concentration. Exacting breaking and a very good sense of balance is required."
• Grade 4: "Very steep and blocked single trails with large boulders and / or demanding root passages, as well as frequently loose scree. Extremely steep slopes, narrow hairpin turns and steps on which the cogs unavoidably touch are a frequent feature of a category S4 trail. In order to ride a category S4 trail, trail techniques such as being able to shift the front and back wheels (e.g. in hairpins) are absolutely essential as well as perfect breaking technique and balance. Only extreme riders and exceptional bikers manage an S4 trail in the saddle. Even carrying a bike up such passages is often not without its dangers."
• Grade 5: "Tracks are characterized by a blocked terrain with counter climbs, scree slopes and erosion, extremely tight curves, multiple obstacles (e.g. fallen trees) occur without a break – frequently in extreme steepness (cliffs). Very little if any breaking time. Obstacles may at times need to be dealt with in combination. Only a handful of freaks tackle S5 passages. Some obstacles have to be jumped over. Hairpins are so tight that shifting the wheels is hardly possible, even carrying the bike would be almost impossible as you need your hands to hold on or even climb."

Source: https://www.singletrail-skala.de/downloads?lang=en

[ravenfeld]

@RubenKelevra I agree with you that it's all going round in circles. I suggested the code and now it's the descriptions and photos that are the problem.
I don't think it's right for the SCEE maintainer to have a PR here too.
Then if you want the overlay I can do it on my repo, I've already had the quest for several weeks on the application for my use.

[RubenKelevra]

I don't think it's right for the SCEE maintainer to have a PR here too.

Why not? Just close the PR at SC, as it obviously not going forward there and we work here on the images and the text to fit the application.

The original text is available in German, Englisch and Italian. The rest would need to be translated.

And due to the text size it may make sense to have just the Scale 1-6 written next to the text and expand the text if the user clicks on it - if that's possible?

[ravenfeld]

I'm bringing up the topic again on SC because I understand that some people would like to have it. I've had it on my version for several months now and so I forgot about you.

[Helium314]

I'm bringing up the topic again on SC because I understand that some people would like to have it. I've had it on my version for several months now and so I forgot about you.

I didn't have a "proper" look at your PR streetcomplete#5726, but from the discussion it looks like the issue is just images and text?

How about we implement the current state of the overlay into SCEE?

[ravenfeld]

I'm bringing up the topic again on SC because I understand that some people would like to have it. I've had it on my version for several months now and so I forgot about you.

I didn't have a "proper" look at your PR streetcomplete#5726, but from the discussion it looks like the issue is just images and text?

How about we implement the current state of the overlay into SCEE?

Do you prefer overlay over quest?

[TommiContursi]

I'm bringing up the topic again on SC because I understand that some people would like to have it. I've had it on my version for several months now and so I forgot about you.

I didn't have a "proper" look at your PR streetcomplete#5726, but from the discussion it looks like the issue is just images and text?
How about we implement the current state of the overlay into SCEE?

Do you prefer overlay over quest?

Personally, I would like to see overlay as it would help modify existing paths and not only focus on paths that are missing the mtb:scale. Just my two cents here.

[mcliquid]

I think each of the two variants has advantages and disadvantages.
A quest is displayed on every path (that matches the filter) and is therefore more likely to be answered. In my view, this generally increases the usage of the tag for a quest more than for an overlay. However, the danger or disadvantage of a quest is that paths that do not apply are also marked so that the quest is answered (false-positives).
An overlay, on the other hand, allows for targeted processing of an area. However, since an overlay always has to be activated or you have to switch between different overlays, the use of the tag will decrease, but the quality or rather the consistency will presumably increase.

The mtb:scale tag is probably more about consistency and targeted tagging in a specific area (forest area, bike park, etc.) and not about adding ‘masses’ to every single trail. That's why my gut feeling says that an overlay would probably be the better option.

[ravenfeld]

In my case I have both on my application, but doing both on SCEE may be confusing.

[RubenKelevra]

Just to throw in my opinion here: I think we should add both. I prefer to just answer questions while on the go, and switching to all the different overlays to see which data may be missing is kinda annoying.

But I do see the advantage of having the ability to view and change the data already present in an overlay.

I don't see a reason why a quest will lead to lower quality data. The decision by the user is based in both cases on the offered selection, and if unsure a user should never answer a quest anyway.

[mnalis]

I agree with @mcliquid that overlay is good idea and should be added (regardless of whether the quest is also added).

I don't see a reason why a quest will lead to lower quality data

Not everybody is MTB downhill expert, even among SCEE users familiar with the wiki who are also avid cyclists (myself included). 🤷‍♂️

That being said, I'm quite fine with quest too, provided it is made less spammy by default - i.e. make it depend on smoothness=bad or worse first (see streetcomplete#1850 (comment)). Otherwise it will likely be asked on all kinds of inappropriate places (streetcomplete#5308 (comment)), and history shows us that it might lead to confusion, notes and incorrect and unneeded answers (#559 (comment)). Interested parties can always edit the element selection filters to make it more spammy (i.e. removing smoothness check) or less spammy (e.g. adding incline check) if they want...

Overlays sidestep that issue (funnily) by their biggest shotcoming -- there can only be one overlay active. Thus, unless the user is active MTB downhiller, it is unlikely they'll be in mtb:scale overlay in 100% of the time (or, more likely, ever).

[TommiContursi]

I agree with @mcliquid that overlay is good idea and should be added (regardless of whether the quest is also added).

I don't see a reason why a quest will lead to lower quality data

Not everybody is MTB downhill expert, even among SCEE users familiar with the wiki who are also avid cyclists (myself included). 🤷‍♂️

That being said, I'm quite fine with quest too, provided it is made less spammy by default - i.e. make it depend on smoothness=bad or worse first (see streetcomplete#1850 (comment)). Otherwise it will likely be asked on all kinds of inappropriate places (streetcomplete#5308 (comment)), and history shows us that it might lead to confusion, notes and incorrect and unneeded answers (#559 (comment)). Interested parties can always edit the element selection filters to make it more spammy (i.e. removing smoothness check) or less spammy (e.g. adding incline check) if they want...

Overlays sidestep that issue (funnily) by their biggest shotcoming -- there can only be one overlay active. Thus, unless the user is active MTB downhiller, it is unlikely they'll be in mtb:scale overlay in 100% of the time (or, more likely, ever).

Great comments here. However, I'm a bit unsure whether smoothness=bad is the most reliable tag. I'm reflecting on how the mtb:scale is used in Finland, and to my understanding, that smoothness tag is not very commonly used with it. @TapioKn, you may have more insight on this topic.

[RubenKelevra]

I agree with @mcliquid that overlay is good idea and should be added (regardless of whether the quest is also added).

I don't see a reason why a quest will lead to lower quality data

Not everybody is MTB downhill expert, even among SCEE users familiar with the wiki who are also avid cyclists (myself included). 🤷‍♂️

By default all quests in SCEE are deactivated. So the users have actively chosen to active it, before they see it. Why would you activate a quest where you lack the knowledge to reliably answer it?

That being said, I'm quite fine with quest too, provided it is made less spammy by default - i.e. make it depend on smoothness=bad or worse first (see streetcomplete#1850 (comment)). Otherwise it will likely be asked on all kinds of inappropriate places (streetcomplete#5308 (comment)), and history shows us that it might lead to confusion, notes and incorrect and unneeded answers (#559 (comment)). Interested parties can always edit the element selection filters to make it more spammy (i.e. removing smoothness check) or less spammy (e.g. adding incline check) if they want...

Overlays sidestep that issue (funnily) by their biggest shotcoming -- there can only be one overlay active. Thus, unless the user is active MTB downhiller, it is unlikely they'll be in mtb:scale overlay in 100% of the time (or, more likely, ever).

I don't think smoothness is a reliably indicator if a mtb tag should be added or not.

I know a lot of muddy, slippery, steep ways which are perfectly smooth, but 90% of the year very dangerous to ride on with everything than an mtb and advance skills.

Spammy is also no issue for SCEE quests as far as I understand, at least not to the degree SC quests are.

Even if we add a lot of mtb:scale=0 in the process, I think that's good thing. This way we add the information, that no mountain bike is required to drive along there. So if you got just a trekking bike, you can expect to be able to drive there.

No other tag will convey this information at the moment, as everything else, like track grade or smoothness only allows for guesswork here by the routers.

Btw: Maybe we should think about adding an option for mtb:scale=0- as well? It's documented in the wiki as "easier passable than mtb:scale=0", which would translate as far as I can tell to "you can pass here with a city-style bike".

[Helium314]

Do you prefer overlay over quest?

I'd prefer the overlay. Mostly because I have the impression the overlay will get added to SC at some point, but it may take a while. So the overlay in SCEE would mostly mean some sort of "early access", and maybe also helps gathering opinions about images and descriptions from real use.
When the overlay is finally added to SC, the SCEE overlay can be removed.

[mnalis]

bit unsure whether smoothness=bad is the most reliable tag. I'm reflecting on how the mtb:scale is used in Finland, and to my understanding, that smoothness tag is not very commonly used with it.

Yes, that is likely partly because mtb:scale encodes part of the information of smoothness, so people usually don't bother; but more importantly if you're MTB user (and people tagging MTB routes usually are), you are primarily interested in mtb:scale and other factors are less important to you.
Even so, globally smoothness is already present on 19% of the mtb:scale ways (which is significant - for example, mtb:scale:uphill is present on 17% of the mtb:scale ways)

For SCEE however, IMHO it makes extra sense, as SCEE will automatically ask one quest after the other, thus encoding both tags¹

Why would you activate a quest where you lack the knowledge to reliably answer it?

That would likely be a question for someone with masters in sociology and psychology to make an educated guess 😺 But we know it does happen²

I know a lot of muddy, slippery, steep ways which are perfectly smooth, but 90% of the year very dangerous to ride on with everything than an mtb and advance skills.

As far as I know, mtb:scale does not encode such seasonal differences. For example, I'd guess if surfaces get iced, all mtb:scale would need to increase by at least 2-3 on the scale. One can attempt to use conditional restrictions on it, but that is likely futile³ (and would likely mean using raw tag editor anyway)

Spammy is also no issue for SCEE quests as far as I understand, at least not to the degree SC quests are.

Not to the degree SC quests are. But did you read #559 (comment) I mentioned in previous comment? SCEE project owner stated "[...] For this reason I want quests to have no spam-danger by default" there.

Thus, my suggestion how to make it less-spammy by default, so the quest might get accepted. As I also noted, it should not a be a big issue for the actual SCEE user, as SCEE quests (usually) allow for editing element selection, so individuals who are bothered by such limitations (and feel confident enough in their OSM usage) can remove those restrictions in Settings by themselves. (but then, if their actions inadvertently lead to problems in tagging on the OSM and get community gets nervous about it -- it is then appropriately they who will get flak, instead of SCEE - because SCEE did the safe thing by default).

Even if we add a lot of mtb:scale=0 in the process, I think that's good thing

I personally am not opposed to that. I'm however worried about several things, but primarily:

• using mtb:scale kind of implies that riding MTB is OK there. If it is tagged in every park and outdoor kindergarten and playground and public garden, I suspect other OSM mappers will get upset. Adding "it is not intended for MTB" answer as a first one might help, but it is unclear what it should tag (bicycle=no might be wrong, so it would need extra sub-question for clarification at least)
• people are already negative even about regular StreetComplete "spamming" certain tags which are implied in much cases, and while it is necessary in some cases to be able to enter useful data (and avoid asking same quests ad-infinitum), I'd prefer to avoid SCEE getting flak if it is not really necessary.

You @RubenKelevra could open (and link it here) a thread at community forum and ask people if they would be fine with mass-tagging mtb:scale on all such paths. As I said, I personally am not opposed with it provided that SCEE as a project won't be getting flak for it...

Maybe we should think about adding an option for mtb:scale=0- as well? It's documented in the wiki as "easier passable than mtb:scale=0", which would translate as far as I can tell to "you can pass here with a city-style bike".

Maybe, but they should be better defined on the wiki first IMHO. Currently it is very fuzzy to me.

Footnotes

1. or skip the other, of course - e.g. if you answer that some surface is smoothness=excellent on some path, the mtb:scale quest would be skipped as it is unlikely to be useful (and would be asked all over places where it is unwanted as they are not intended for MTB downhill rides at all). ↩

2. open NotesReview and search for StreetComplete_ee, and it happens quite a bit (and those are only the times where users openly admitted they're not sure about the answer; checking if the tags are actually answered correctly is immensely bigger task). ↩

3. although combined with the somewhat subjective differences of the mtb:scale even in most nominal conditions that it usually encodes, and with huge effect adverse weather has on it, it would likely be both futile as well as redundant (I'd wager that vast majority of MTB downhillers will already be aware that mud or ice will affect the track usability greatly) ↩

[ravenfeld]

Ok, I'm closing this PR and I'll open one for the overlay when my other PRs are finished so as not to have x PRs in progress.