Feature Proposal - Voting - highway=scramble

From a native (so never as much authoritative as Wikipedia): The only essential defining properties of a Steig are: It it is narrow and it is not paved. It need not be steep, eg. when it runs on the contour line. Steepness is at best a property of the terrain, Steige are in. Where I live, we have lots of steep terrain, almost all of the terrain here is steep.

The maintainers of hiking trails in Austria are to take care, that what has the map signature of a Steig is at least 10 or 12 inch wide, so walking is always comfortable.

I see one problem: If you’d ask me, how to translate Steig into Englisch, I’d answer with certainty, In English, its called a path.

It also doesn’t say anywhere that any kind of hiking trail is excluded. And if you’re new to OSM and have a closer look, there’s only highway=track, footway and path that are useful combinations with sac_scale, including all values which involve hands. So the use of hands is not contradictory to the current definition and usage of path; for me this proposal would have changed that, which is one of the main points.

That was covered early in RfC: It allows double tagging. The result will be a more complicated version of a scramble=yes attribute on highway=path.

If it was only for the people, that want to keep the highway key clean, the proposal would have been accepted. The proposal failed, because too big a number of people obviously are happy with what they can do with path and did defend their use of it.

The suggestion from one of the opponents, to bring hiking map producers on board, so transition can be without downtime might be a game changer, but unfortunately is beyond my capabilities to organise such a roll-out.

If the feature was wider, perhaps 1m or so, I would call it a “Weg” in German, or a “way” in English. Most of what is mapped as a path in openstreetmap, we here call “Weg”, like Gehweg/footway, Radweg/cycleway, Reitweg/bridleway. Perhaps. our use of terms is not much different from English, with the notable exception of path, of course. The picture on the OSM Wiki for path does not show a Steig.

Nor does it show a “Pfad”. If you ask me, it shows a way. I rarely use Pfad/path, but when I do, only where the terrain is not steep. Maybe that is the reason, why I use it rarely.

Indeed it does not. All that is clear is that some hiking trails are included.

I am not :slightly_smiling_face:

The difference I see is that the approval of highway=path + scramble=yes would be a clear statement that scrambles should be included within highway=path. Although an approval of route=scramble would allow for dual tagging with highway=path it could be made clear that this is considered an incorrect combination (at least eventually). However, a proposal tolerating such dual tagging during a transition period might gain more more support, as it would give data consumers time to adapt.

I can follow this thought. Going through though, I can only see a mechanical edit to heal the double tagging, perhaps disguised as an editor validator suggestion, to make it less obvious.

The main use of route=* is to refine relations type=route. Something else would IMO attract valid concerns.

There’s always the possibility to draw ways without tags and make them member of a hiking relation, but some may find it cumbersome.

Also creating double tagging with the view to solve it with a mechanical edit later is close to evil :japanese_ogre: :grinning:

1 Like

I suspect it would be easy to get a proposal to pass that is more generic than highway=scramble, I didn’t vote on it because that was my major issue with it too (what would be the next one, highway=ledge ?).

What we really need is a generic tag value* that will not be rendered “accidentally” (the main issue with adding more attributes to highway=path), and feels reasonably natural to add sac_scale or other difficulty scales to (this is assuming that untagged ways in a route will not fly). highway=climb would be my favorite, but highway=trail would work too. Both of these have the potential to be misunderstood one way or the other, but that is likely unavoidable.

* I would argue that the actual value is of no concern at all, and could just as well be “123456”, but we still have to give the thing a name that will be used for display and preset purposes.

** micromapping say a scramble as highway=climb climb=scramble would look fairly good to me.

*** and yes this is essentially highway=mountaineering without the implied “mountain” :slight_smile:


I’d be fine with “trail”. It sounds reasonably generic to go into the highway key, after all, trails will get people from A to B. Narrow and unpaved is too little to make it specific, more has to be specified. It was one of the first terms I looked at, before starting to develop scramble which took quite some turns :wink: If I understand correctly, it was once a contender for what is path now, Tag:highway=trail - OpenStreetMap Wiki - I guess then I stopped to pursue this. The work from then is not bad Proposed features/Trail (new proposal) - OpenStreetMap Wiki

Uh wait, wouldn’t this exactly be the problem? highway=trail sounds so generic that people may just use that tag for non-scrambling/non-climbing paths too. Just look at a random image search for “trail”:


I said, I stopped to consider that, it is just too generic. Width and surface could rule out much of what the pictures show. Event then, this would affect practically the whole hiking network. But “demanding_path” is just crying abuse. And climb is worse than scramble, because climb has no upper limit on UIAA or YDS.

While that is true, data consumers would still need to make a conscious effort to process it, and hopefully they would only use it in an appropriate way, Mappers misusing the tag simply wouldn’t get the way rendered/routed in non-specialist contexts contrary to the situation with path today, so that should be erring on the harmless side.

That said I’m not a big fan of using trail either.

Does that matter?

There is still considerable heat in the voting. Ballot casting time will be extended to give three weeks of voting.


The proposal remains unchanged, as required by process rules.

1 Like

With a DWG hat on I see quite a few complaints about “map X is showing path Y when it should not”.

Most of the time “map X” is some sort of phone app, marketed to users on the basis that it shows what Americans would call “trails” (i.e. non-city paths). Quite often there is information in OSM about access rights, surface, sac_scale, etc. which just isn’t shown in the phone app. The phone app user assumes that because a way from A to B is shown, it is suitable for them.

This is of course the fault of the developers of those problem apps; while some do a really good job of “should I show this and if so, what as”, some do not.

I find some of the “no” votes a bit frustrating where people have said “app developers ought to be able to do X”. Obviously they’re correct in one sense, but experience shows that some app developers can’t or won’t. Following on from that I think that “highway=trail” isn’t a good answer because lazy app developers who want to show “trails” will include things that are scrambles rather than paths with the new tag.

Furthermore I would suggest to people voting “no” based on thinking that “highway=something else” is needed instead of “scramble” or “path”; that voting no will mean that we stick with the status quo. If you think that “highway=scramble” is better than what we have right now, please vote yes.

Best Regards,


(written in an entirely personal capacity)


In an entirely personal capacity, with my hiking hat on, I would like to add that some way of getting the information into the database would much improve the usability of OSM for hiking. The requirement is that it enables data users to use the information without interrupting current usage.

The usage of sac_scale and other qualifying attributes does not say “this here is a scramble section”. It conveys that somewhere on the path you might have to scramble. On a path marked with sac_scale values which might include scramble sections, I would still like to know which parts actually are scrambles.

I think highway=scramble for scramble sections qualifies, though it probably would interrupt some paths which are not really paths. It could be argued that that is beneficial, because it detects false use of highway=path.

I think adding scramble=yes or, say, path=scramble to other highway=* (or route=*, for that matter) also adds the information, without interrupting anything at all.
scramble=yes just in the scramble section is very simple and effective tagging, IMO it carries exactly the same information as highway=scramble, and requires very little in terms of data usage. A data user who can process highway=scramble, should have no problem processing scramble=yes.

path=scramble would be very logical in a highway=path, path=* sequence. But I see a lot of protests coming, I fear for a can of worms if not a Pandora’s box… Forget this idea, please.


Even in a widely optimistic scenario we can only assume that this will make the situation better for data consumers that care but fell in to the trap of using path without looking at details and for whatever reason can’t back out of that (for example the devs of OSM-Carto). The lazy lot will just throw in scramble/trail/climb/etc to whatever they are using now so they can render complete routes, so I’m not expecting the situation with that group to change a jota and don’t think we should even try to cater for them.

I would note that a more promising approach to get data consumers to handle “critical” tagging better is the label or badge approach suggested at this years SOTM. Though that was mostly in the context of protection areas it applies equally to the topic at hand.


I disagree. The majority of OSM data users doesn’t care the tiniest bit about paths in mountain side. They will do the most lazy thing of them all: nothing. If a data user wants to show these routes, then they probably produce a hiking map. If they are lazy and show highway=scamble in the same way as highway=path, I don’t care. They cater to a clientele that should at least be aware of the possibility that mountain paths may be difficult.

There is a world of difference between a data user that actively adds support for a tag and is then to lazy to find a different rendering and a data user who accidentally renders things in the same way because they are not aware of some obscure extra tags they should be looking at.