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.
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.
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…
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:
21 feel than currently existing tags are enough (e.g. highway=path+sac_scale=* and others)
11 feel that new supplementary tag (e.g. scramble=yes) would be OK-ish, but are against new highway=* value
11 would be OK with new highway=value, but think that it should be something more generic and not so narrowly scoped (e.g. highway=demanding_path + demanding_path=scramble)
11 feel that there are Verifiability issues (i.e. too subject and/or not clearly defined, corner cases, etc.)
14 (and more, as sac_scale as well as scramble=yes might count here too) seem to miss the point why is was proposed as separate highway=* 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 like sac_scale=* and scramble=yes don’t cut it (x out of y renderers/routers mislead unsuspecting people on such technical trails, c.f. via_ferrata how 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 other demanding_path=* values besides scramble as 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=intermediate would 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 in cm, 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 in smoothness=* 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 bedemanding_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.
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.
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.
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.
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.
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.
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.
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.
I appreciate the amount of information added by trail mappers. My issue is with families with multiple ability levels and reduced mental bandwidth to read it all. Along with less experienced hikers who don’t fully understand some of the finer point of all the information available.
Could you provide a list of applications that show this information.I would love to see if a map geared to that audience presents it in a easy to understand way. Maybe we can solve part of the problem by working with applications to present path data in a clearer way.
sac scale information is in the database as a secondary tag, and I’m sure there are applications showing it.
Exact information on scrambles is not yet in the database in a uniform way. If it were present in a uniform and unambiguous form, e.g. scramble=yes as a secondary tag, it would enable data users to use it for maps and routers. Comparable to bridge=yes, which is generally shown on maps.
Renderers and other data users are not in the habit of using not (yet) established tags. They tend to wait until the tag is established by either approval or increasing actual usage.
To tell its members what to expect from the routes they manage in a single term, the Swiss Alpine Club developed its mountain hiking scale. It combines multiple aspects that are of concern when hiking in mountainous terrain. A committee graded all their routes a long time ago. There is some value in it. Same as in the UIAA rock climbing scale and many other difficulty scales, CAI, YDS come to mind. Where I live, a system aligned with downhill skiing piste difficulties gets used officially.
Sometime in the past, mappers decided to apply this to so-called paths mapped in openstreetmap. They called the key sac_scale. The SAC has several scales, but the OSM one got taken directly from the mountain hiking scale.
To me, the gist of what you write is: sac_scale is not in any way the Swiss Army Knife to grade demands, that hikers observe in places other than the Swiss Alps. I doubt, a sak_scale key will ever be possible.
Second, both grading after sac_scale and learning something from the term when reading it from a map needs intimate knowledge of the graded matter. This is a very delicate task.
At last, I consider all those “sac_scale does it all” comments wholly preposterous. I recently learned, that the developers of the foot-profile for the router on the www.openstreetmap.org website have no clue about sac_scale and seemingly even cannot be bothered to read the wiki documentation. How then are we to expect the myriad of other consumers to be up to that?
Whatever the specifics are, OpenStreetMap is always at a disadvantage when it’s trying to shoe horn an outside standard that wasn’t created by cartographers/mappers into a tagging scheme. The same goes for isced:level with schools. It’s never worked well or been widely adopted because it wasn’t made for maps and doesn’t work well as a tag. Sure renders could technically just adopt them anyway, but why force them to when tags based on standards we haven’t created ourselves clearly isn’t the best way to do things?
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.