There is fairly significant usage of check_date:surface and check_date:smoothness, though. I can’t investigate right now, but I wonder if that is coming mainly from QA tools or perhaps StreetComplete. As they are rather similar to sac_scale, perhaps there is already an approach that could be followed.
With bare check_date there is the risk that the mapper is confirming the path exists rather than every single tag (the wiki gives some support to this interpretation). As you say, it doesn’t seem to happen much now. But it could arise, for example, in the context of some completely unrelated QA task that we can’t predict in advance.
I fear this proposal is worsening a different problem.
hw=path is an ill-defined tag mixing up wide, paved mixed-use cycleways with single trail hiking paths in nature. You need to guess about the real state from the access tags and if there are no access tags it is quite a random guess.
I think we should develop the sac_scale to make actual hiking trails better distinguishable and resolving that dilemma. E.g. if there was a requirement/encouragement to always use sac_scale with real hiking paths (rather than not tagging but implying hiking), but not with urban foot/cycleways, one could use sac_scale to describe the actual type of the way.
Unfortunately this proposal does the opposite by associating a new sac_scale value with the wide, trivial paths, deepening the ambiguity and missing the chance to resolve it.
Unless of course you add that encouragement/requirement to always use a sac_scale for actual hiking paths to the proposal, that would help to improve the database.
That might work if we were starting a new database. But millions of paths are already mapped without sac_scale. So we can’t read anything into the absence of a tag. Even if we could enforce an obligatory use of sac_scale for hiking trails, we would never know if no sac_scale means “not a hiking trail” or “mapped before sac_scale was enforced for hiking trails”. The proposal gives us the chance to make that less ambiguous, by allowing the mapper to say “I checked this and it’s a path for strolling”. I don’t see how the proposal adds ambiguity as you suggest.
I agree with @alan_gr, and also a lot of highway=paths are / have been mapped from aerial imagery or Strava by people who haven’t walked them, so they don’t know how difficult they are.
In my view, that’s an argument for something like path=trail which allows me to tag the fact that something is a hiking trail without knowing the difficulty.
Also: while the proposal does not talk about “requiring” sac_scale, I think it does encourage its use by clarifying some of the uncertainty around it:
confirm that the hiking grade does not mean “hiking and easier including strolling”, as some mappers have thought
clarify that it no longer maps directly to the “real” SAC scale
clarify that it is not just for mountains (I’m sure some mappers have thought “there’s a lot of stuff on the wiki about Switzerland and mountains, but I hike in a flat desert”).
I think we agree that more widespread and systematic use of sac_scale would be a good thing.
Nobody claims this proposal will solve all the issues with mapping paths, but I see it as a chance to make incremental progress, that we can start now. That seems better than waiting for some grand scheme to completely redesign highway=path, that will almost certainly be voted down.
I also think that requiring mappers to use sac_scale is not the greatest way to segment highway=path as not everybody feels confident to apply it. A more human readable secondary tags are more sensible solution I think.
I would be for renaming a lot of tags (unclassified, anyone :-D?) but my understanding is that that is not something that has much chance of succes for popular tags, or does it?
Another question. Since the proposal drops the “requirement” (which hasn’t been followed anyway) that the tag should only be used in the mountains, does it mean we just accept that =mountain_hiking for T2 was a poor choice of name, so using it for a cliff path like this or a path in the woods with lots of obstacles like this one posted by @hungerburg is fine, even when no mountain is in sight?
Not sure if you are propsoing to change the value – I indicated above that the names are not well chosen. I just do not see it passing :-(. But my understanding is that mountain and alpinehiking can be used outside of mountains,yes (if it passes… well, they are anyway).
If this proposal passes, I’ll seriously propose to re-define the acronym SAC with Stride Ability and Complication Scale on the wiki.
The tag would then not be Swiss neither Alpine anymore, and not affilated to any Club. We will of course keep an historical note.
I do not keep tabs on the numbers, but from a first glance, it looks a bit like those people soon can point at others that do not hike but stroll to their workplace or grocery store. Vote will end real soon
On a second glance, this lack of respect only comes to show, when sac_scale used outside of recreational context, as has been stipulated here too, as a follow-up change to the documentation, that this requirement should be dropped.
What made me start the poll back then was, that people tag sac_scale=hiking as an equivalent of hiking=yes, that is, to convey, that the path only for recreational use. While technically, it does not conform to what the definitions in key sac_scale describe as applicable for that value, at least in my reading of the documentation.
Of course, depending on “recreational” not always easy to tell. Some people may enjoy hiking busy city centre / downtown streets. What may be a hiking route for one, for the shepherd is part of daily work.
Around here, hiking paths generally easy to classify by signage/designation. Recently the DAV, a rambling club that operates a substantial amount of hiking paths here, decided to close an sac_scale=mountain_hiking path due to landslides. I walked, err scrambled, it successfully. When sac_scale independent from designation, will such then be a closed (access=no) T3 path or will it be a 1.4 km T3 path with 7 metres of T4/T5/T6?
I am planning on opening issues for JOSM, iD and Vespucci to include the new value. As for consumers, I would let openandromaps know, but I think it is better to wait a bit beforethe new value is used a bit. Any ideas who else needs to be notified?
You can see a number of data consumers at taginfo. That’s not everyone, but it’s a start. The ones most interested in a new low-end value will likely be those that explicitly deal with hiking, which is this list; only about 4 others over what you are already considering.
I am filling the bugs but I wonder if it is appropriate for iD. I tried grepping its source for tag_info and found nothing. When I played with it, it suggested me values like =1 or =yeswhich are wrong. It seems tome iD is populating the suggestions on the fly somehow and so asking it to include strolling is meaningless, no? I added a bug but I am not sure it mapes sense:
I will wait with notifying for the renderers until the new key is used a bit more in the wild, as wiki suggests. So far there is one occurence around Seattle:-).
I have worked out the differences between the grades better (especially for alpine hikes) and wrote some notes therefore in a new paragraph at the respective wiki page Key:sac_scale - OpenStreetMap Wiki.
I also think we should remove the colours in the grading table. Firstly, most T6 routes are not marked and secondly, this marking only takes place in switzerland, which is not relevant for a global application.
