RfC: Highway=Scramble

@ezekielf I did update the proposal text to state “Steps with a railing, however steep, and ladders may need hands, but do not make a scramble.” In the sense of, insufficient by themselves, but not a conflict neither.

1 Like

This is a good clarification.

Do you also think an assisted trail with fixed cables, ropes, and bars should not qualify for highway=scramble and be mapped as highway=path instead? (assisted_trail=yes could be added in either case). Personally I’m not sure. On a trail like this you are pulling yourself up with your hands using these bars and cables. These movements are very similar to scrambling where there are only rocks, trees, and other natural features to grab with your hands. But the cables and bars are installed to make the route easier and more safe, so is that contrary to the idea of a scramble being more rough and rugged than a path?

A small intermezzo: Anybody willing to grade this - https://www.sac-cas.ch/processed/sa2020assetsprod/a/e/csm_1524487713_406330776master_e13890b353.jpg - it is a scramble, that has sac_scale set by the lord herself, so to say, Cheaters will be caught :slight_smile:

If there were some rungs or sticks out of the rock, or even a fixed rope, I’d still call it a scramble. Where ever I came over such assistance, I always had to take hold on rock too, unlike with a ladder. If the rungs were spaced like a ladder, I’d call them a ladder instead.

PS: trail_visibility according to OSM Wiki on the photo is “excellent”.

1 Like

I have to say I agree with your assessment here!

1 Like

Commenting as someone quite fond of mapping remote trails, often steep and/or barely visible.

I think highway=path is more than sufficient for covering the purposes highway=scramble is suggested for.

Linguistically it is broad enough:

  • It covers what we commonly think of as a visible trail.
  • It also covers a more general notion; that of an object’s path, in the sense of a trajectory. In light of this, I understand the tag to not require a visible trail on the ground, but just that “this is a common trajectory for people moving on the ground”. This latter interpretation shouldn’t be the default, though, but rather implied by trail_visibility.

As for safety considerations, I understand the concern, but I also think this is covered well enough by the current use of sac_scale. An alternative, if there is a desire for a more binary division, is to introduce a path=scramble tag, to indicate, for instance, that the use of hands is required. This is similar to path=climbing_access, which I’ve used before for paths that end in a full blown climbing route, requiring gear.

1 Like

By now, I believe we have a few years’ worth of evidence that end user applications often won’t get the distinction right if you leave it to sub-tags. Some developer will rush to build an app in time for the deadline, see that all the walking paths in their urban surroundings look great if they apply this or that render style to highway=path, and have no idea that this causes scrambles to be displayed in a way that misleads their app’s users into dangerous behavior.

It’s generally safer to design in such a way that imperfect humans will tend to do the right thing by default. That’s more effective than warning labels telling them not to take the seemingly obvious approach.


…and have no idea that this causes scrambles to be displayed in a way that misleads their app’s users into dangerous behavior.

I do not think this is the case, though. Humans have the ability to judge the reality on the ground for them selves, and turn around, should that be the appropriate thing to do. There’s no misleading going on if you expect your users to understand that “paths” is a relatively broad category in terms of what you can experience. And I don’t think this is an unreasonable expectation.

It’s generally safer to design in such a way that imperfect humans will tend to do the right thing by default. That’s more effective than warning labels telling them not to take the seemingly obvious approach.

In my mind it is more correct for a slightly risky trail to be rendered as a trail than not to be rendered at all. In that sense, these rushed developers you are referring to are already “doing the right thing” by rendering these trails the same way as a footway in a park. They’re just not doing the complete set of right things, which would be to differentiate the rendering somewhat for more demanding paths. Hence, I feel like the tagging scheme we already have abides by this principle, which I do agree with.

I think my biggest concern is the lack of backwards compatibility in this proposal. Steep trails in the mountains is a pretty niche concept, and introducing a dedicated tag for such trails risks them never being rendered at all in most rendering engines, precisely because city-based developers wouldn’t care about them. The reason I map such trails in OSM is because I want to be able to make use of these trails in rendering/routing engines (in my case Strava). By effectively taking away the rendering of these trails, you’re also taking away my motivation to contribute them.

I’d be less annoyed with it if you were able to get buy-in from major rendering and routing engines before introducing the tag, to show that it is actually viable to make this transition. But even then, I still think highway=path combined with sac_scale is a fundamentally more correct description of the phenomenon in question.


None of the SAC-scale values says: this is a scramble section for most people. It says: this path may contain difficulties, possibly requiring scrambling. If you want to map a pareticular scramble section as an on-the-ground feature, you should somehow mark it as a scramble section.
Introducing a new highway type to replace highway=path for this feature does carry the risk of not being recognized or processed any time soon by datausers and renderers. Changes like that should be checked in, and ideally committed to, with major data users and renderers. I think this is not worth it in this case.

A clear additional tag specifying the type of path would be the way to go. I have seen these two options passing by:
highway=path + path=scramble tagged on the scramble section
highway=… + scramble=yes on the scramble section

These options are totally backwards compatible and will break nothing, they just offer the free and extra opportunity to detail styles and renderings or filter/select/search for scrambles.
scramble=yes has the advantage that it can be used on any type of highway, and on areas and relations for that matter.

Issues such as…

  • if a long path ends with one scramble section, do I tag the whole path or just the scramble section as a scramble?
  • if a path has scramble sections with a rising path and/or some hardware assistance in between, do I tag the whole path or separate sections?
  • children scramble, I scramble, but my uncle Billy “the Mountain” just steps over the rocks and my wife can run it by floating from one rock to the other, do I tag that as a scramble part?
  • there is no visible path, only trailblazes mark the way. Can I draw a path and tag it as a scramble feature for my route relation?
  • is this really necessary or worth it?

…are, as usual in OSM, up to the mapper and his/her mapper community, and “use your best judgment and try to verify it with locals and peers”. Yes, that may lead to differences between countries and regions. What’s new?

Native speaker of Hiberno-English (en_IE) here. My first thought for “scrambling” was motorcross ( wikipedia agrees that there is a link). Ireland does not have mountains that would require scrambling-as-you-describe-here. “to scramble [over something]” in en_IE is the same “using your hands to sort of climb over”. So to me, this term is OK.

1 Like

I addressed this same concern earlier in the thread:

This I can get behind! I didn’t, at first realise that my proposal highway=path + path=scramble has the issue of path=scramble only being usable with highway=path. In hindsight this is an obvious problem. I like your proposal better. Appreciate the input, Peter.

I noticed, but did not give you the credit you deserve. I just felt like adding a voice to this concern, which is real, at least for me.

Because I recognise that highway=path is being asked to cover a lot at the moment, and that this is a problem, I want to see us deal with that issue. I do, however, think that we should be careful in how we approach that issue, so that we avoid throwing the baby out with the bathwater, so to speak.

Could it be worth taking a step back, and take a holistic view on highway=path and related tags, like track, sidewalk, cycleway, footway, pedestrian? Some of these are arguably an attempt to limit the scope of highway=path, so that it becomes more consistent. I think a process of dividing/replacing the highway=path tag should come with a proper review of the different possible objective criteria that could be used to do so, along with the pros and cons of each approach, and their impact on neighbouring tags as mentioned above. I can’t imagine introducing highway=scramble is the only competing solution to address this issue. Also, such a process should almost certainly involve input from data consumers, such as rendering and routing engines tailored towards outdoor activities, in order to make sure we have their concerns in mind. Do we have representatives of any of them present in the forums?

I haven’t checked the history here, so this idea might not be novel at all, but I am tempted to suggest highway=trail as an alternative to solving this problem. This would cover about two thirds of the scope that highway=path occupies today, on the more extreme end of the spectrum, intentionally ruling out thoroughly prepared and maintained park footways, and paved paths. I’d then suggest moving these more “civilised” paths to other highway tags.

The benefit of making such a division, over the one proposed here, is that highway=trail would still be a big enough category for data consumers to care about, but not so big that demanding hikes and scrambles end up being rendered as “walks in the park”.

I think the term trail is in practice nearly as vague and encompassing as path. You would end up redefining the term for a particular selection in OSM, which mappers and users would hardly understand. Such a solution would create more issues than it solves, I think.

Peter Elderson

1 Like

Perhaps. I’m not seriously proposing it at the moment, just airing the idea. My only hunch is that is is a better idea than highway=scramble would be, not that it is a good idea.

Did some research and came across this:


These issues seem to result from new tags being added without any holistic view in mind for how routable features should be tagged. Although the intentions are good, I fear that the addition of more highway tags will just add more mess, unless there is a clear, achievable path (pun intended) to resolve most of the issues mentioned in the article above.

Not sure there is any project in the works that is taking this kind of approach, but perhaps, again, if we got some experienced developers from our various data consumers to sit down together and talk, that might be a good approach to mapping out a path forward.

1 Like

Meanwhile I am about to flesh out a description of “highway=scramble” that does not put openstreetmap to shame, I want to thank the contributors in here, that provided valuable input. You know, who you are :slight_smile:

If scrambleway existed way back then, when “highway=path” was conceived, it certainly would have been superseded by a “scramble=*” on a path. So I see “highway=scramble” as a retroactive creation to complement “bridleway, footway, cycleway, &c.”.

I rather not coin the term “scrambleway” now. It seems to me too much contrived. Unfortunately, some mappers seem to confuse the shortness of the name with the shortness of the feature. How to go about this?

PS: Nobody willing to sac_grade the picture I linked above?



Certainly a very different use of the word “scramble” :grin:

The SAC scale is not used in North America, so I am quite unfamiliar with it. In the Yosemite Decimal System I’d say this picture would be at least Class 3 and could be Class 4 if the consequence of a fall could be fatal. As the camera is pointed upwards, I cannot tell.

Did some more research and found another another argument that goes against both highway=scramble and my semi-proposed alternative highway=trail. Quoting from Key:highway - OpenStreetMap Wiki

Note that highway=* distinguishes roads by function and importance rather by their physical characteristic and legal classification. Usually these things are highly correlated, but OSM is not obligated to copy official road classifications.

I’d argue that both scramble and trail are most definetly describing “physical characteristic”. The appropriate thing to do, then, is to vote on reverting this previous decision as part of a vote on highway=scramble. This also means that the proposal should detail an alternative way of breaking up the highway tag. Hope you take this into account in your proposal @Hungerburg.

1 Like

I do not see any evidence that classification by importance is used for anything but roads from residential to primary. (at least in Germany trunk is determined by physical characteristics and motorway by legal status, this might be different in other countries). The vote had only roads in mind. It was very early in OSM’s history where there was a focus on roads. If this would apply to all of highway= some cycleways in the Netherlands might be highway=primary because of their importance but this is not current practice. Also note “These are the principal tags for the road network. They range from the most to least important.” refers only to the first section of the table in Key:highway - OpenStreetMap Wiki

1 Like

the importance ranking is for actual roads and does not extend to footways, paths and tracks etc, and there are some exceptions on the upper and lower end (motorway is defined legally, requiring signs, trunk has different definitions but in some places is about construction standard (like motorways), tracks are distinguished from paths by width, bridleway and cycleway and footway are classified by designation, …)

… also highway=steps is clearly based on physical characteristics.

I think highway=construction is also relevant here. We could convey the same information with e.g. highway=motorway, construction=yes - but we don’t. I would guess this is at least partly to allow data consumers to make an important distinction without considering second-level tags.


The word ‘scramble’ sounds very much like a function to me: this path is here mainly for mountaineers to have fun.

And maybe this would be a much better way to approach this whole issue. Instead of trying to describe what it looks like, start with what it was made for: recreational value for hikers and climbers.

To contrast that: a “normal” highway=path has the main function to provide access to places. It is mainly for modes of transport that require a single track (as opposed to highway=track which allows double-track modes of transport). Usage requires no special experience or gear other than what is required to use the chosen mood of transport (i.e. knowing how to ride a bike or horse is not considered ‘special experience’).

From a router’s point of view this is truly valuable information. Usually a router knows if its purpose is to find a route from A to B or find an interesting route for an outing.