Similarly cycle.travel uses it as a (very mild) influence on routing weightings.
3 Likes
The map at https://map.atownsend.org.uk takes sac_scale into consideration too. See this diary entry that I wrote last week.
3 Likes
There are various data consumers that use sac_scale, but most are specialized for hiking, e.g. see this comparison:
https://wiki.openstreetmap.org/wiki/Hiking_maps
And also BRouter web client is using it for routing (depending on the profiles).
So sac_scale has its uses, but less in maps for general usage. That’s why changing the highway value would be the way to go if something should change there, but as we’ve seen that’s no walk in the park.
scramble=yes is a no-brainer for me and would at least solve this case; I would probably add it to OpenAndroMaps as I already have done with ladder=yes/rungs=yes/safety_rope=yes which are kind of similar - in adding additional information to a hiking trail that is more micro-mapping and specific than sac_scale and complements it.
4 Likes
Do we have analytics available, how often routing is called from the osm homepage? The routing interface on the osm web page directs me here - GitHub - fossgis-routing-server/cbf-routing-profiles: Experimental routing profiles for OSRM. instead. The profile there does account for sac_scale in code. There the key has only five values, not six. From the looks of it, it should not route anything with sac_scale except “hiking”, but from black-box-testing the interface on osm, no sac_scale value on a path has any effect on the routes produced. Only distance counts. Maybe this has not made it into production yet?
Maybe it also targets software developers, that build services based on OSRMF? Though it is quite hidden for that. I wager to say, lots of router developers pay little attention to such a niche thing; so this is kind of exemplary, isn’t it? And it is right in front of the public.
True, I went there to explain a bit, hopefully in friendly tone.
Curiously, some of those hide the higher grades:
AllTrails seems to grade “hard” in their own scale starting from T2. It is a bit the same with all those scales. Some later introduce “very hard”, then “extremely hard”, what next, “insanely hard”?
I’d like to test but the hiking area here is infested with bicycle=no tags, so not much chance.
If I may add: sac_scale=hiking in my view does not prohibit cycling. The path my be a rumble-strip, but there should not be steep sections, where elevation from terrain model is way off, or roots and rocks where hikers have to lift their legs above the knee. If mapped not in a route relation like way, mountain_hiking though should mean lots of pushing, even haul and carry. demanding_mountain_hiking even more so and alpine hiking will inspire artistic behaviour with a bike 
Out of curiosity: Why is this Way: 149419322 | OpenStreetMap shown as a pushing section?
Thanks for adding that information, it is useful!
I would like however to add that such behaviour is exactly opposite of the one I would want:
-
in current case (parsing of secondary tag like
sac_scale=*(or suggestedscramble=yes), by default routers and renderers will lead people into danger, and they need special effort and programming in order to be safe (as vast majority of them will not have support for quite well establishedsac_scale=*, not to mention ATYLscramble=yesand similar solutions), as shown by your example. -
however in
highway=demanding_trailcase (orhighway=scramblecase, or anything changing primary tag value) the situation is exactly opposite – by default, renderers and routers will have no idea what new value is, so won’t render it or route over it – i.e. they would be safe by default (and it would take extra effort and programming by authors of apps designed for hiking mountaineering to add support for it - where those few authors so inclined, as you note, will add proper support: i.e. different rendering/routing depending on difficulty and/or user preferences etc.)
So to me, only sensible solution is something that is safe by default – that consideration simply cannot be something optional that only a few app authors might have resources, knowledge, will and time to implement.
And that means using separate highway=* value instead of adding a secondary (more-or-less trolltag) to highway=path (e.g. if I need special equipment / skills to pass this “path”, than it is not really a “path” – it is borderline in scramble case, but even worse in other cases like mountaineering and others which would be covered by more generic highway=demanding_trail or similar primary tag value).
Of course, secondary tag like demanding_trail=scramble or demanding_trail=mountaineering or demanding_trail=jungle or whatever might be used to add extra details to that ignored by default primary tag value highway=demanding_trail.
4 Likes
Why do you think so? sac_scale=* OSM tag (as opposed to other meanings of words “SAC scale” you may have encoutered) is defined exactly as pertaining to exact locations / sections, and not on whole route (“relation” is OSM parlor, where it is forbidden to be used).
So if there is hikeable part of the route, that OSM way element will be marked with sac_scale=hiking, and if after that there is 50m way element that requires use of hands, only that way section will be marked as say sac_scale=demanding_mountain_hiking (or sac_scale=alpine_hiking) indicating use of hands is potentially needed (or required in latter case).
It’s not either sac_scale or scramble; the tags give different information and complement each other.
I’ve heard that several times, but always vaguely, and never explained exactly - even if that would be primary thing to consider when proposing new tag - how you envision it being used. Without such information, there is much less chance of accepting a tag (if not even proponents have an idea how it will be used by data consumers!)
So, assuming that something scramble=yes gets approved, how would you (propose to) modify your favorite router (and renderer) to use it?
In this thread there was example for cbf-routing-profiles/foot.lua at master · fossgis-routing-server/cbf-routing-profiles · GitHub; how exactly would you want it to change its behaviour for your “I want scrambling” profile, and how for your “I want to avoid scrambling” profile? (line 177 is example for sac_scale; for reference of how to use similar feature).
Feel free to use some other router and renderer which you use or would consider using instead, for showing what configuration changes exactly would you like, if you dislike one linked above.
Contrast that new handling of scramble=yes with its current handling of sac_scale (hopefully it handles that; because if it does not, there is likely even less chance it would support some new tag - if that popular one is unsupported!)
For example, here is how I would handle it in my I'm old and fragile and want to survive (AKA “no scrambling wanted, just give me a leisurely walk in the park”) profile:
speed_path = {
+ scramble = { yes = 0 },
sac_scale = { hiking = 0.5,
mountain_hiking = 0,
demanding_mountain_hiking = 0,
alpine_hiking = 0,
demanding_alpine_hiking = 0
},
So @Peter_Elderson how would you modify it for your “I’m a scrambler and I wanna scramble” profile instead? Question is also for @Hungerburg and other proponents of “scramble is totally different from sac_scale” philosophy – how exactly (i.e. show me the config code change like above!) would you want this (or some other) data consumer (e.g. router/renderer) to use your data?
2 Likes
This is exactly what I would expect from these profiles. Namely, to be a minimal working example that demonstrates all the relevant functions. This assumption holds true for the foot profile I linked, but not for the bicycle profile in the same repository.
To be honest, if I wanted to develop an APP built on top of OSRM, the foot.lua linked above would have been the first thing I would have copied and pasted.
My guess (after a quick glance at the code) would be that routing and time estimation is done in two steps and the code you linked only refers to the latter. If you wanted to exclude certain ways from routing you would have to add it to
avoid = Set {
'impassable'
},
which is ultimately handled here: cbf-routing-profiles/lib/way_handlers.lua at 16453fa5ded78671560dba15e124ea5bac6d52d3 · fossgis-routing-server/cbf-routing-profiles · GitHub, or implement a a new sac_scale_whitelist (which would probably be the most reasonable approach).
The problem is, that this is not true. Here two BRouter examples:
- Default Hiking Profile happily sending you across an invisible
highway=fia_ferrata - BRouter Trekking Profile happy sending you across an invisible
highway=scramble
And the guy behind BRouter Web is a cautious person. He once said in an interview that he intentionally does not have an MTB profile on his website because he does not want to be held responsible when people do stupid things because his router tells them to.
But we should also keep in mind that even specialized routers that strive for the “perfect” hiking or biking profile will always have to perform the balancing act of maintaining a high fault tolerance for bad data without losing the ability to capture all the fine details that OSM has to offer.
A trustworthy router doing everything right would just as easily throw you off a cliff if the underlying data was only bad enough.
My naive assumption would be that adding scramble=yes combined with a concerted effort to make the available default profiles of the major routers (valhalla, osrm, graphhopper, brouter) more robust could satisfy almost everyone.
1 Like
The section marked “sac_scale=alpine_hiking” does not give the information that it is a scramble section. I think sac scale is not meant to be applied to short sections of a path. It is meant to apply to trails/paths to indicate what you can expect along the way, without pinpointing exactly what you encounter on which exact location.
Scramble-yes pinpoints exactly what there is and says what it is. Not what it might be.
If a router encounters a scramble section, regardless of any sac assessment, even when there is no sac scale tag, it might discard the route if that fits the profile. At that location, the rendering might show a nice scramble icon. I would prefer that, just as I prefer to actually see a ferry, bridge, steps or a stile over some scale value that says “this section contains a bridge, steps, a ferry or a stile”.
The information in sac_scale is simply different from the information of a tag indicating a specific feature. Even if the handling in some router profile for different cases and features seems the same, that does not mean it is the same thing. If that were true, OSM would be much, much simpler.
This is probably wishful thinking: some OSM mappers tend to go down to the most precise micromapping you may imagine, while others happily generalises whatever tags on route relations.
I tend to prefer the 1st approach to some extent.
2 Likes
I prefer detailed mapping of the features themselves over any scale assessment. Map what is, not what scale or grade value it belongs to. The feature can imply a grade or scale value, that’s fine, but a grade or scale does not say what exact feature is present on that location.
It’s simply different information.
2 Likes
That’s good, because cycle.travel doesn’t think it does either 
Because it’s a bare highway=path without access or surface tags. Using highway=path without access and surface information is bad tagging. Bringing it back to the original topic, it’s just as often applied to rough hiking paths as it is to cyclable city paths. cycle.travel doesn’t want you to get killed by riding somewhere unsuitable so it won’t tell you to ride that way.
4 Likes
That happens, but in my experience in rendering sac_scale in hiking maps the majority uses are from fork to fork (or some attraction along the way), at least here in the alps.
Probably also because difficulty is marked on guideposts here and mappers are used to that. Always the most difficult part is the deciding factor for the whole route on the guidepost, or at least till the next fork. Nothing else would make sense in real world hiking scale usage.
1 Like
the scale is still related to human scale, and is determined by the way we store the information (cm-precision), if we were ants, we would have a different system, microbes even more.
That is my experience too. Many times I have thought: if I had known, I wouldn’t have taken this trail, or: had I known where the difficulty was, I could have planned a simple detour to avoid that specific location or section. Or, the indication was easy route, just that one section had been left out of the equasion, after all one balancing above the abyss section of just 10 meters doesn’t warrant a higher dificulty grade for the whole route… I never trust these indications again. I want to know where specific difficulties are.
I definitely split paths and assign different sac_scale values for sections as short as 5-10m if they are significantly different from the rest. It can be very useful to know that the actual difficult part is only very short even if the guidepost has to show the whole length up to the next fork as difficult.
3 Likes
Yes, it is not always true. But it is safe by default in majority of cases. There are always possibility of bugs in app and wrong assumptions. You should report such a bug when you find it, so it can be fixed.
And the guy behind BRouter Web is a cautious person.
Is he? Then you definitely should report a bug there. Bicycle trekking profile should not be possible over highway=via_ferrata or highway=scramble or highway=lemmings_suicide_trail or mtb:scale>1 or bicycle=no (the last case seems to be handled, but previous ones not really, if I read that Profile correctly)
I heavily disagree. Especially for mountains (which are often with no mobile service), anything that depends on online routing engine is basically useless. For example, I do not use any of the above (while I did have the idea of trying offline BRouter app in combination with OsmAnd, never found a time for it). Do others even offer offline usage, and if so, in how many apps it is supported by default? For example, I do use OsmAnd, Organic Maps and Trekarta offline at the mobile. Users who are not opposed to proprietary apps use a dozens or hundreds of different ones. Then there are non-android users like iPhone users with their set of apps. Each has a different routing / rendering.
Have you checked all of them? Neither did I, neither can anyone realistically. Thus, it is important to be “safe by default” as opposed to “unsafe by default, but we might lobby a handful of ones I think are more popular to be safe in some of the cases”.
In my country we regularly each year have people needing rescuing via helicopters and alpinists on the mountains because they though it was fine to follow some path from the sea upwards in the flip-flops and shorts. While our rescue heroes often succeed in saving their lives, that is not always the case. While it might be tempting for some to blame it solely on the alleged stupidity of the victims, I’d much rather that they were not misled on such hazardous journeys in the first place. Yeah, people trust their mobile apps more way than is healthy, and it would be great to improve on that too. And while e.g. 98% safe-by-default is not bullet-proof, it is much better (and easier to improve on) than 10% safe-by-default.
2 Likes
No? Wiki says that it means “Use of hands needed in order to advance in certain places”. How is that not scrambling, could you elaborate on that? From the previous proposal, I got impression that having to use hands in order to advance is exactly what was intended by “scrambling”?
I think sac scale is not meant to be applied to short sections of a path
It think this is where confusion stems from. OSM key sac_scale=* is intended to be applied to as small or as large section as you want. It might differ from other real-world usage of words “SAC scale”, as I’ve said before. Please reads it wiki carefully to see what exactly is meant by it. Just like OSM key highway=* means something somewhat different that what real-word usage of word “highway” means.
The information in sac_scale is simply different from the information of a tag indicating a specific feature.
That is true. Note however that there are scrambles and then there are scrambles. Meaning, they are not all the same, or even same section recognized as scramble by two different people (what requires use of hands for me, might not for you). Those are subjectivity issues that were raised in proposal, and which (additionally to format of tagging which I’m concentrating here) should definitely be addressed separately.
Even if the handling in some router profile for different cases and features seems the same, that does not mean it is the same thing.
It is not, but it should be handled somehow. Because if it isn’t handled anywhere anyhow, than it is simply bloat and not useful information. To paraphrase “if a tree falls in a forest and there is noone around to hear it, does it make a sound?” – “if there is a tag which does not change behaviour of routers, renderers and other data consumers at all, does (or should) that tag really exist?”
That’s why I asked how exactly would you change a router behaviour for “I want to scramble” profile (which I’m still hoping you’ll answer), as opposed how it handles for example somewhat similar sac_scale.
If a router encounters a scramble section, regardless of any sac assessment, even when there is no sac scale tag, it might discard the route if that fits the profile.
That is exactly what I did in code example at the bottom of that post for “I do NOT want to scramble” profile, so if I understand you correctly you agree that in that case scramble=yes should be handled exactly the same as sac_scale=mountain_hiking or higher, yes?
At that location, the rendering might show a nice scramble icon.
OK, that is one reason (not very strong one IMHO, but at least some concrete example of wanted change!)
So, If I understand you correctly, e.g. if the section is marked with both sac_scale=alpine_hiking and scramble=yes you would prefer to see “some new scramble icon/rendering” instead of icon/rendering indicating “alpine hiking section where one has to use hands”?
How would those new icon/rendering differ from the current one, and what benefits do you see from it - do you simply dislike how existing “has to use hands” section is rendered, or do you see significant differences (and how would you explain those differences to computer?)
I.e. if one section was marked sac_scale=alpine_hiking and second with scramble=yes and third with both, what do you want your router set to “I like scrambling” profile to do - which to avoid, which to seek, what weight to set to each of them? And how would like your renderer to do for each of them? That is the part that remains unclear, and yet is imperative to be clearly defined before new proposal.
I would prefer that, just as I prefer to actually see a ferry, bridge, steps or a stile over some scale value that says “this section contains a bridge, steps, a ferry or a stile”.
Do note that it becomes problematic as number of feature rises. Sure, I’d also like to have as much information from the map as possible, but at some points it becomes counterproductive – would you like dozens of different icons for each way?
Or only the one most important shown, and all other hidden?
Because, there is sac_scale, there is surface, there is tracktype, there is smoothness, there is lit, there is width, there is trail_visibility, there is informal, there is via_ferrata, there is climbing:grade:uiaa, there is incline, there is mtb:scale, there is hiking, there is trailblazed, there is safety_rope and osmc:symbol and marked_trail and assisted_trail there would be scramble, mountaineering etc.)
I found out the other day that’s there’s also a bunch of “difficulty” tags, including mtb:difficulty. Apparently there’s a water_slide:difficulty tag to. Although it only has 73 uses, but who would have thought that would even be a thing? 
Whatever the case, there’s clearly a ton of tags that essentially serve the same purposes and none of them seem to stand out enough to say “now this one, this is the tag!” It’s not like scramble=* is unique that regard. But at least it’s simpler then sac_scale, at least in theory. And some people have already said they would support a proposal for it. That’s something 
You could argue sac_scale=alpine_hiking, but scramble=* has takes way less cognitive load and steps to use then sac_scale. With sac_scale=alpine_hiking people have to know what a sac_scale is in the first place. Plus they have to decide if wherever they are hiking is alpine or not, Etc. Etc. Compare that to “did I just climb this with my hands?”