Open ravenfeld opened 3 months ago
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/)
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?
bicycle!~"no|private"
to exclude ways that are forbidden for cyclists.mtb:scale:uphill
be added somehow as a option?mtb:scale
does not apply? And if so, how should this be handled?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.
- I would add
bicycle!~"no|private"
to exclude ways that are forbidden for cyclists.- Should
mtb:scale:uphill
be added somehow as a option?- 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
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.
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?
Similar to sac_scale
I'm not sure whether a (filter) quest is the right choice.
Did you read https://github.com/streetcomplete/StreetComplete/issues/1850 or https://github.com/streetcomplete/StreetComplete/pull/5308? If you were to implement it as overlay, it would be acceptable for SC and thus reach far more users.
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?
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?
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.
@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.
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.
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 themtb: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.
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.
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.
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
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)
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? https://github.com/Helium314/SCEE/pull/559#issuecomment-2209475937
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.
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.
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.
@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 :)
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.
@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:
@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.
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?
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.