The only narrower proposal than highway=scramble on a section of a trail that I can conceive of is barrier=scramble on a node (or a number of nodes, so to capture scrambles spanning more than 5m length.)
So have I seen youngsters unable to scramble, but that was not the point. I though I made it clear in previous posts that using âgrandmaâ as an example was an illustration (and not a call for search of statistical outliers). Perhaps ânot a walk in the parkâ might be more acceptable idiom? Yeah, most young people would be able to scramble, and most very old ones wouldnât be. Regardless, it does not really affect the idea of highway=demanding_trail + demanding_trail=*, does it?
In my experience, people complain most when you step on their toes. I.e. it is not wideness that is the problem (e.g. see natural=water poposal etc - any complaints were about naming and minor details on merging similar features, and not wideness of proposal per se).
So, in my opinion, it would be worth trying proposing it like suggested, with wide main key highway=demanding_trail and then two or thee more specific demanding_trail=* as examples to show the need exists for such wider definition.
2 Likes
Post Feature Proposal - Voting - highway=scramble - #50 by eartrumpet by @eartrumpet gives a nice classification of what might have inspired people to support or to oppose the proposal. Would be nice if @Matija_Nalis kept to the promise, to do some analysis of the suspended vote. I am not the right person to do that, and am too exhausted too at the moment, and an abstaining third party should be better charged any ways.
PS: Iâd classify opinions like âThe funcâm ntion of those path are transportation by footâ (oblivious, if there is a path at all, but yeah, how else would you transport yourselves?) and âwould be survivable as property, but not when it is top level tagâ into the âconsumerâs problemâ category.
@Hungerburg, many thanks for the work done so far in this discussion. 
3 Likes
The highway=scramble is proposal that should be a first attempt at differentiating the various type of footways. This much like when highway=road was split up based on it attributes such number of lanes, types of markings, average speed, presence of divider and number and type of entry points.
There needs be something similar done to footways so that the average person can determine what to expect. Would you take a moped out on an expressway? Probably not, since you couldnât match high speed traffic. More than like you would limp along until a officer arrested you for hindering traffic and have your vehicle impounded. So why do treat a way that is a âwalk in the parkâ the sames as one that might put you in the hospital after slipping on a rock on a steep grade. Each foot tag should imply how uneven the surface is, average amount of grade and possibility other general attributes.
Yes, there are 5+ different scales that describe trail difficulty each from various organizations throughout the world. Do you expect the average person, let alone mapper, to read and understand exactly what they mean?
Unfortunately this confusion has leaded to real-world consequences for those who accidentally took the wrong path. Leading to unnecessary rescue and sometimes recovery of those who would have otherwise avoided the area had they known it was dangerous.
At the end of the day, we need a set highway based footway tags. So that it is clear what is someone should expected find at that way segment. It should be simple for anyone planning outing to quickly understand whether thier participants have the necessary ability, experience and possibly tools needed to traverse the landscape.
Applications can then decide whether to even render segments over a certain difficulty. In particular trail apps could render ways based on a userâs settings. Then use a range of colors to indicate the general level of difficulty along with a more specific rating from the local mountaineering organization.
2 Likes
This never happened? highway=road was introduced after the main highway= road types were.
4 Likes
I live in the United States, am a fairly active hiker, and had never heard of the term âscrambleâ until this proposal. Although I still donât understand what exactly it means even after reading through the proposal, this discussion, and asking to have it explained to me multiple times. Given how many oppose votes there are for it Iâm clearly not the one who doesnât understand exactly what itâs for. And from what I can tell most of those people are also pretty active hikers. So in no way is highway=scramble going to solve the problem of understandability.
As a side to that, @Hungerburg decided to suspend the proposal back into a draft and suspended the vote period indefinitely in the meantime even though it was clearly rejected, both when it was originally announced and after he extended it for another week. In the meantime thereâs still people voting on it like the whole thing is going on. Me and another user have indicated to Hungerburg that the proposalâs status should be set to rejected, but apparently they are unwilling to do it. I donât know how to do the cleanup for a failed proposal myself. So Iâm not going to do it. But it would cool if someone could âofficiallyâ set it to rejected and do the cleanup so people donât get the false impression the vote is still going on or that it still has any chance of passing. It clearly doesnât have any chance of being accepted by the community as is and thereâs no reason to pretend like it does by drafting it
Eating away from highway=path space will be incredibly hard, as fifteen years ago the highway=path tag was explicitly approved to be ânonspecificâ - c.f. Proposed features/Path - OpenStreetMap Wiki - anything, where you cannot or must not drive a car, even if there are no signs of actual use for anything on the ground there. In my area, there are OSM-notes saying: There is no path there, and replies, I have seen someone passing there. The pictures Proposed features/Path/Examples - OpenStreetMap Wiki do not show scrambles, they show paths suitable for all of walking, cycling, horseback riding and driving cars, The mirror in the second picture looks suspicious 
But the words speak different. By todays standards, such a proposal would not have been approved, but that is the way it is; Not a few seem to enjoy that.
1 Like
Using hands is something the ones that I am aware of all have in their repertoire of deciding matter. Curiously, the YDS goes much further in âfor balanceâ - Passages, that here are widely graded UIAA II would be covered by that. And yes, the SAC calls them scrambles. I know of some such, that are mapped sac_scale T4, while the documentation allows that only in T6 mappings. While some T6 mappings go into UIAA VII, which will be deep in the YDS class 5. Muddy waters indeed, highly unspecificâŚ
1 Like
Here is my analysis of 35 rejections and 5 abstains (note that this adds to more than 40, because while few have not given a reason, more than few had multiple concerns). Also, take it with grain of salt, as it is impossible to put myriad of opinions in just a few generic categories.
It should provide some rough outline, though:
21feel than currently existing tags are enough (e.g.highway=path+sac_scale=*and others)11feel that new supplementary tag (e.g.scramble=yes) would be OK-ish, but are against newhighway=*value11would be OK with newhighway=value, but think that it should be something more generic and not so narrowly scoped (e.g.highway=demanding_path+demanding_path=scramble)11feel that there are Verifiability issues (i.e. too subject and/or not clearly defined, corner cases, etc.)14(and more, assac_scaleas well asscramble=yesmight count here too) seem to miss the point why is was proposed as separatehighway=*value (because it is according to current experience very near impossible to get renderers/routers to correctly parse secondary tags too).
So, the majority feels that sac_scale=* and other existing tags are good enough.
If you still disagree with that @Hungerburg, I would suggest:
- take more time to prepare it. Explain clearly but in short why separate
highway=*value is wanted, and exactly why secondary tags likesac_scale=*andscramble=yesdonât cut it (x out of y renderers/routers mislead unsuspecting people on such technical trails, c.f.via_ferratahow it helped). It should fit in one paragraph of about 5 (not too long) sentences. Also provide link to a post with more detailed evaluations if needed. That should take care of point (5), as well as much of (1) and (2). - go with something more generic like
highway=demanding_path+demanding_path=scramble. Give 3-4 more popular options for otherdemanding_path=*values besidesscrambleas examples to demonstrate why it is preferred to a secondary key, but be clear youâre not trying to get approval for them in that proposal at that time. That should take care of whole point (3) as well as majority (if not all) of point (2), as well as some of the point (5) too. - also, be more clear about what is and what isnât scramble. Give more then few examples, with explanations how they differ from others, and pictures, and all tags that might be used (or explanations why they wouldnât/shouldnât be used. e.g.
sac_scale,trail_visibility,incline,surface,smoothnessâŚ). Especially give extra examples about corner cases. It does not need to be definitions of scramble that everybody would think of, but it needs to be as verifiable as possible. Take smoothness=* as inspiration. E.g.smoothness=intermediatewould mean a million different things, but when you have table with example pictures, what vehicles it is usable for, how big each crack (or how deep a rut) may be incm, how much average car may be slowed on such road etc it becomes more verifiable. Still somewhat subjective, but much less so. If you needs several types of scramble, define then. I think table like used insmoothness=*is good and readable way to go. That should take care of point (4). - use this thread (or a new linked one) to have other people help with suggest better wordings, clearer explanations, and good examples before doing the proposal (i.e. only do a proposal when it looks to be final production version). You want to have something which is short and easily readable (not confusing, vague or open to interpretation in any part) followed by table of several examples showing what would be
demanding_path=scramble(and how/why it would be tagged), and several examples showing what would not be (again with explanation why; and how it should be tagged instead).
I do agree that is a significant amount of work, but hopefully others would help (especially if asked. I would), and to make significant and good and long lasting changes, some extra effort will always be required.
Thank you Matija for the summary. When you say, the majority feels, you might be precise: the majority of opponents. Maybe say too: The opponents themselves were far from being the majority of voters. But certainly, lots of people are fond of sac_scale and what they can do with it 
From the top of my head, Iâd not expected eleven votes, that would have approved a highway=demanding_path tag. I especially invite @eartrumpet to start a draft on this. It would be quite sad, if his idea was just a reason to oppose scramble and nothing else came out of it. I will gladly serve on the scramble attribute subcommittee.
I am certainly the wrong person to develop such an abstract tag. I deliberately did not coin the proposal referencing dangerousness or other such demands. The only thing a scramble demands is use of hands.
2 Likes
Iâm sorry, but highway=demanding_path wasnât my idea. I read about it first here and the following answers on the mailing list for the RFC to highway=scramble:
https://www.mail-archive.com/tagging@openstreetmap.org/msg57001.html
And I donât really know what you want to achieve with other things you wrote above, I always try to be constructive; thereâs no need for comments like that.
1 Like
I see, so Iâd rather invite @schoschi instead, to spear hunt the demanding path proposal.
If the numbers in the vote analysis section of the proposal are correct the final count was 39 for and 34 against. Probably 35 if you count the vote after it was re-drafted. So the opponents were actually pretty close to being the majority of voters. At the end of the day though it was essentially split.
Anyway IMO after reading through the discussions here and in the proposal a couple of times either a proposal for highway=demanding_path or a re-jiggered one for highway=scramble that addresses peopleâs concerns both have about as much chance of passing a vote. Really, if I was to guess I think scramble=* as a sub-tag has the best shot of being approved. If it were me thatâs what Iâd do the next proposal for. Then if that fails try one for highway=demanding_path and if that doesnât get approved follow it up with a proposal for demanding_path=* as a sub-tag Etc. Etc. But scramble=* probably has the best chance of being accepted at this point.
1 Like
I disagree. The idea is to tag scramble sections of a path, in order to find/avoid or select/deselect scrambles. E.g. for a path tagged with a sac scale indicating it might include scrambling, a rendering could actually display where the scrambles are. A routing app could avoid or seek out routes with scrambles.
To me, itâs not a type of footway, itâs an attribute of a section of a path, or of an area if there is no clear path between beginning and ending of the section.
For hikers, a scramble presents a difficulty. For mountaineers itâs probably a moment of easy progress.
3 Likes
My count until suspension gives 41 pro, 34 against, 5 abstain comments. But yes, you are up to something: As long as sac_scale allows to map highway=path in pathless terrain, however unspecific the demands, no highway=<new-something> tag can compete with it. My guess: Because path renders and routes the beloved routes (sic) everywhere, and anything else will require consumers to adapt. So highway=demanding-path is doomed to fail a vote too, not by being subjective.
In my endeavour, to style scramble as a subset of what currently gets mapped as path, I might have been wrong. Iâd perhaps should have proposed scramble as covering what currently, for a lack of a better alternative, gets mapped as path, where quite often there is no path. The documentation on trail_visibilty is quite accurate; some meters of pathless terrain still gives visibilty=good.
4 Likes
I actually could care less the actual terminology. My aim is to allow average users and other data consumers to quickly understand concepts of general path difficulties. Why canât we have paths designations like we do with roads.
You wouldnât let a new driver go out on the highway without at least preparing them for it. Why not follow the same idea of making sure people understand the general level of difficulty on a particular part of a footway.
Isnât that exactly what the sac scale is for?
Wouldnât it be nice to also indicate precisely where a particular difficulty such as a scramble is?
1 Like
First youâre expect the average user to know what that is. Next, they need to have access to the value since not all maps include the regional scale. Users must then understand what that value means and how that relates to thier abilities. It shouldnât take that much effort for the average user to know what to expect from a particular path.
4 Likes
The mapping and tagging records the information. Then data users (applications) use the information to inform and help the end user. The end user does not have to do anything, that is up to the data user. Mappers are expected to look up how to enter the information so that data users can look up what it means for their target end users.
The information what to expect from a path is recorded as a sac scale value. A renderer can translate that nicely to coloured lines, or nifty icons, or layers, or whatever. Itâs there, and there are no proposals to change this. But it is not possible to show the exact location of a scramble, unless it is tagged as a scramble. That is the proposal: tag a section of a path or tag an area as a scramble. Data users can then show them on the map (comparable to the way bridges and steps are shown), or put an icon.
Tagging as a new highway value breaks current applications. Tagging as a secondary tag breaks nothing, and the applications can ignore it without breaking anything. If they think it could enhance their value for the end users, then they can profit from the information.
3 Likes