Feature Proposal - Voting - highway=scramble

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.


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.

1 Like

That’s good, because cycle.travel doesn’t think it does either :wink:

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.


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.


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.


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? :sweat_smile:

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 :man_shrugging: 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?”

One more reader that did not notice, that sac_scale has more values to the key than in the list :wink:

And quite likely you would have been done with that and never looked at it again. Thankfully, fix speed_for_path in foot profile · fossgis-routing-server/cbf-routing-profiles@2daa6d8 · GitHub the problem has been looked at, now the only thing missing there is handling difficult_alpine_hiking, which would be a killer :wink:

Some comments here get to read a bit like infighting. Please keep your temper. Others seem to pick up elements that were in the proposal right from the start. Even if the commenters present them as own contribution, I should be honoured :slight_smile:

Well, I am for a tag like this which would defines scrambling sections…

However, I disagree with this part. That is UI suggestion for the app being used, not a tagging problem.
It could be simple dropdown with hard-to-remember values like “T1” - “T6”, or it could be nice StreetComplete-like UI with pictures and descriptions, or it could be checkboxes like:

  • [x] do you want physically demanding route?
  • [x] are you willing to often use your hands to proceed?
  • [ ] do you have helmet, rope and carabiners and are prepared to use them?
  • [ ] do you have iceaxe and good mountaineering experience?

and determine acceptable levels of sac_scale=*, incline=*, demanding_trail=scramble, highway=via_ferrata or scramble:=* etc. to show to the user and navigate them (that is just illustrative example, not a suggestion what question exactly to ask, I’m not an mountaineer/alpinist)

In fact, I’d rate any user-navigation-or-rendering-oriented app which requires that user knows what OSM tags are (and much less which are there and what are their values are!) as unusable for general population.
(Such domain-specific knowledge might be suggested for apps dedicating to OSM-mapping only, but even there only in advanced mode and not as basic requirement).

And some people have already said they would support a proposal for it. That’s something :man_shrugging:

Some did, but there were also those against it… It’s not the worst idea, but it misses a lot IMHO. I’ve done some analyses and made a suggestion what I think would be a best way to proceed to get next attempt approved, but people are of course free to choose whatever path (pun intended) they like to take. It would be prudent to first make their own analyses of first proposal and its talk page to address raised concerns, though (in order not to waste their time and time of others needlessly).

1 Like

Going for highway=scramble brought along much work, because it touches deep into the fabric. scramble=yes does not need a proposal. No more than informal=yes did need that. Personally, I’d like a highway=desire tag much better. That would provide a means to wipe those desire lines that most only clutter maps.

You jest, but common programming practice it to do only one thing in one commit. I.e. in my example you should look only at green (added) lines; the rest of them (gray lines) are there only for context and represent current code, as it is only one relevant for the question posed. If I were trying to fix sac_scale handling (which I’ve seen you comment on before twice), that would be separate thread/commit/whatever (but my posts are getting too long even without such distractions, so I choose to skip that).

But I still miss your input @Hungerburg on that post – how exactly would you like that this router handle scramble=yes tag (as opposed to sac_scale=*) in your “I want to scramble” profile?
That is, unless that fix speed_for_path in foot profile · fossgis-routing-server/cbf-routing-profiles@2daa6d8 · GitHub has fixed all your issues and you no longer think separate scrambling support is needed as sac_scale=* is good enough for you?

Some comments here get to read a bit like infighting. Please keep your temper.

Maybe it’s just me, but might it be cultural differences? If anything, lately this thread seems (to me at least) to be much calmer and more constructive, than it was at some times before. At least that is how I chose to interpret your comment at the top, as a friendly poking. :santa:

Others seem to pick up elements that were in the proposal right from the start. Even if the commenters present them as own contribution, I should be honoured :slight_smile:

If some good accepted tagging comes from this discussions, everybody who invested effort should be congratulated, of course (including original ideas, as well as those who phrased it in more readable ways or whatever)! OSM is a team play, it is as much about a person who passed the ball as the one who scored a hit.
But may I suggest not starting handing ourselves medals before that task is accomplished, though? :smile:

1 Like

If, with this router you mean the one on the osm homepage, the answer will be easy: Do not route there. Note, that this can be much more easily achieved with the proposed tag for this one and whole a lot routers that do not specifically target mountain hikers in one go.

If I may add: Of course people will want to route scrambles and other often pathless terrain. BRouter comes to mind, they support that. They give reasonable durations. For them, I’d like a “Include scrambles” checkbox in the profile configuration pane, much like they have now a “Include steps” checkbox in their cycling profiles.

If I my further add: For renderers, I’d like to see a characteristic icon, in overview zooms and likely also in close zooms.

Key is here “in certain places” - so not every sac_scale=alpine_hiking is a scrambling, but it can be. Not every sac_scale=alpine hiking is a snow-free glacier crossing, but can be. So that’s where scramble=yes can be more precise and makes more sense for micro-mapping than sac_scale. Also maybe more than demanding_trail=scramble, but this would be a different discussion.

You’re right, it says nothing in the wiki. But does it really make so much sense to use a definition which by design (of the SAC) was meant for longer sections for micro mapping? When only tiny sections of a hiking route that are covered by e.g. sac_scale=alpine_hiking are tagged like this, and all others are marked as sac_scale=mountain_hiking, it would sometimes need huge zoom levels (if you use just a map and no router) to realize that the hiking route isn’t as easy as one has thought with all real life consequences. I get @eginhard that it can be useful to know if it’s just a short section, but I think that it can be a case of too much differentiation.

1 Like

Valhalla supports sac_scale, the default setting disallows routing if sac_scale > hiking (T1).

What exactly was unique about highway=scramble that it needed one and why wouldn’t whatever it is not apply to scramble=yes? I guess maybe because it doesn’t replace an exiting highway tag makes it “safer”, but I don’t think that means it has any more chance of being adopted or implemented in any software then highway=scramble would have had. What we need is a tag that the community at large generally agrees on and uses, not something that was added in large numbers by a few hiking enthusiasts as part of a pet project. I don’t see how that happens without an approved proposal.

(BTW, no insult to pet projects. But they have a low or no chance of being implemented anywhere and far as I’m concerned that’s the whole point in this)

Sure. I don’t think there’s one thing that is going to satisfy everyone though. And realistically scramble=* is the simplest, most paired down tagging suggestion we have so far. So IMO more people are likely to support it as it’s own proposal then they were to just mention it in passing as an alternative to something else.

In the meantime I’m not really sure I agree with your proposed suggestions about how to move forward. Just to give two examples, if the current tags where enough we wouldn’t be having this discussion. You also say we could potentially go with something more generic like highway=demanding_path + demanding_path=scramble, but that wouldn’t address the main issue people seemed to have with highway=scramble, that it replaces highway=path when people don’t want it. I haven’t seen much support for it in the 5 days since you made the comment either. But there have been people saying they would support scramble=*.

Why would people support something that takes two tags to do instead of one anyway? Especially since IMO once you introduce “scramble” to the equation it sort of negates or implies the other part? Like image highway=demanding_path + demanding_path=difficult_alpine_hiking. At that point everything before "difficult_alpine_hiking is redundant and doesn’t convey anything useful. It’s just extra bits on a screen for their own sake when we could just tag a path as difficult_alpine_hiking=yes

As a side to that look up tautological statements if your interested. As far as I’m aware tag=key pairs shouldn’t repeat the idea or statement of each other. Like demanding_path=demanding_path obviously wouldn’t work, but then there’s lots of gradients when it comes to “types” of paths that wouldn’t work either. Including demanding_path=difficult_alpine_hiking and demanding_path=scramble. Mainly because “demanding path” is an evaluative statement about the difficultly. Not a type of trail. Whereas, you could argue scrambles are.

I agree that a new highway value would probably be the most reasonable and also most effective approach to reducing the risk of dangerous routing, but I think these examples still show that a new highway value may not be as bulletproof as one might think at first, when even developers who are neither stupid nor ignorant of safety can fail in this way.

But to be honest I see zero chance of a new highway value being approved unless the rendering (and routing) issues that come with it are solved at the same time. And at the point where there is consent that the rendering (and routing) of such ways should change we might as well continue to use highway=path + scramble=yes.

However, one does not exclude the other.

Which is why I think a whitelist would be the more sensible choice in such a case.