I fully don’t understand the beef about attributes. I am a mapper, and I want to map what is there, in the most uncontrived way. A recent vote complained, that this proposal repeats the mistake of highway=steps, which correctly should be highway=path+steps=yes. Who else is sure about that?
If there were steps for primary, secondary, tertiary, unclassified, residential, service, track, …, I’d certainly vote for the latter.
Actually, you do have to look for that extra tags for bicycles, if you are any kind of bicycle-related data consumer.
True, it might be mapped as highway=cycleway (due to obsolete historical reasons), but it also might be mapped with much more popular newer tagging scheme:
highway=path + bicycle=yes|designated, orhighway=residential|secondary|... + cycleway:right|left|both=lane|track|... (or cycleway=*)And bicycling paths are (arguably) more common and more wildly used than scramble paths!
If it were suggested to be created today (and this comes from the avid cyclist!), I’d argue against creating highway=cycleway (as it brings nothing new to the table, and all data consumers still have to parse other bicycle-related tags, so it is just more work and TIMTOWTDI).
Note that even with highway=cycleway it may also be that that pedestrians or horses or motor vehicles are also allowed on that “cycleway” (as it simply means highway=path+bicycle=designated; due to the fact that it comes from time before *=designated were a thing, but that is historical artifact, and not an invitation to create a separate new highway value for each and every possible combination, e.g. highway=cycleway / footway / footway_and_cycleway / footway_and_bridleway / footway_and_bridleway_and_cycleway / footway_and_cycleway_and_bridleway_and_scooterway etc.).
Hey, there are even some thousand highway=cycleway on which you can’t actually ride bicycle (i.e. bicycle=dismount); how about that?!
Exactly as does highway=demanding_path + demanding_path=scramble, does it not?
The point is that highway=cycleway makes it clear the way is for bikes. If I need to know more I’ll look at other tags, but maybe I don’t. There are many different use cases.
1.2 million uses and climbing is neither obsolete nor a historical artifact, but lets keep this topic focused on scrambles.
This combination may communicate the same thing (I don’t know because the proposal hasn’t been written), but the key word in my statement was “alone”, as in only one tag needed. So no, not exactly.
But it does not. If you look only at highway=cycleway, you’ll miss most of the cycleways (i.e. get only 1.5 million cycleways out of more than 8 millions of them). So you absolutely need to look at other tags used to mark cycleways, or you’ll end up with completely useless map for bicycles.
highway=cycleway 1528k
bicycle 6735k-1449k no
cycleway 944k-267k no
cycleway:left 203k-78k no
cycleway:right 584k-223k no
cycleway:both 795k-732k no
1.2 million uses and climbing is neither obsolete nor a historical artifact
But it is. It only seems its usage is growing because of the way iD editor choose to handle the situation (i.e. mark cycleways both with highway=cycleway and bicycle=designated). If you replace those redundant highway=cycleway with cycleway=path, you’d get a much lower number, which continues to fall.
but lets keep this topic focused on scrambles.
Well sure; you’re the one who brought highway=cycleway into discussion! (It’s not my fault that cycleway numbers happen to speak against highway=scramble - /I’m guessing/ somewhat contrary to your expectations 
)
So, the gist of your support (as I understand it) of highway=scramble specifically (compared to highway=demanding_path + demanding_path=scramble) is that you would prefer to type-in manually one tag instead of two?
Should I assume then that you don’t use iD, JOSM, or Vespucci? As those editors (amongst others) support presets which automatically set any number of tags when you select them (so exact number of tags some preset have is irrelevant to the user doing the editing)?
That is quite a reductive mis-charactarisation of my position. I’ve done my best to explain my thinking on the matter, but you don’t seem interested in actually understanding. I’ve already stated in the other thread on this topic:
Please, do not imply malice on my part. Because I do try to understand your position, but as I didn’t (in this thread which I follow) found other arguments you might have against highway=demanding_path + demanding_path=scramble in this thread, and you didn’t mention it when asked about, I assumed there were none. Please do let me know if you have some arguments against such solution (other then already mentioned “two tags are more to type than one”)?
I’ve already stated in the other thread on this topic:
Perhaps that might be the reason for me not finding your other statements on the matter: I’m not omnipresent
I see I have another 77-long-messages thread to contemplate, hopefully some gold nuggets might be found there which are missing here. It will take some time for me to process it, though, so please do let me know if I reply in a way that seems like I’m intentionally ignoring your arguments (I assure you, any such failure of mine is due to omission, not malice).
Oh, have I known it sooner, it would’ve saved some replying here! So, I gather from this short quote that you are not in principle against such idea? (I’ll read up details from other thread when I get some time).
To quickly comment on it as to not leave you hanging: Yes, highway=demanding_path + demanding_path=scramble is wider proposal than the original one by @Hungerburg, but that is very good IMO – main purpose of Proposal process is indeed to bring together potential tag users from different backgrounds so the more generic tag solution can be found (as it is much better if 1 proposals of 2 tags can solve 5 different needs, than if there need to be 5 different proposals, each aiming for 1-tag solution just for their narrow field of interest).
When voting turns into “a comments section” many times that is more indicative of the responses to the RFC input not being actually addressed:
“The Rationale is not negotiable.” x2 - the submitter of this proposal straight up said that they were not flexible to user feedback during the RFC process.
1- Suggesting that highway=path + an add on tag was sufficient
2- A RFC specifying that the tagging is non-intuitive where the commenter lists three different definitions for what constitutes a ‘scramble’ that don’t seem to align
“The proposal cannot and shall not deprecate that.” - thus admitting that highway=path is prefer but insists a replacement is still necessary
“only map scrambles where on location signs of actual use by humans” - I’ve done a lot of mountain hiking, even blowing my knee after a summit, and while mountain hiking/climbing books refer to scrambles I’ve never seen one with a sign as it’s simply one of those “I know a ___ when I see a ___” things
“I myself cannot imagine scrambles in other domains as hiking, but others may.” - A single query for “scramble” in TagInfo will pull back 100+ tags that already exist for crossing:scramble (i.e. the “pedestrian scramble” - where all cars get red lights and pedestrians can walk all directions including diagonally. Far more applicable to OSM and only one ranking behind hike scrambling in Google search rankings making them on par with one another and the call for distinguishment between them to be reasonable.
Under “Subjective” the proposer responded, “Additional pictures have been added to exemplify, what use of hands is about.” The issue is that the pictures he pulled happen to be the same from sac_scale=demanding_mountain_hiking AND sac_scale=alpine_hiking BOTH meaning the way they addressed the subjectivity issue of ‘scramble’ is by pulling pictures that span what is already less subjectively defined by the existing sac_scale, which I might point out already has 697,571 tags in OSM use already and is far better suited to the task at hand.
The proposer stated as a resolution, “I hope, that resorting to values in the UIAA scale, as has been in the text from the beginning, will do.” - Then UIAA exists as a tag and UIAA=1 would be the equivalent to a “scramble” although I still think sac_scale does a much better job at deliniation but I see no reason both existing tags with thousands or tens of thousands of uses each can’t be used and don’t already fulfill the need.
“The proposal text puts now even more emphasis on the similarity with highway=steps” that a response to " Existing tags like sac_scale=demanding_mountain_hiking can be used" because highway=steps are clearly definable and have clearly defined starts and stop and clearer still impact on their use by bicycles and the disabled. While ‘scramble’ has none of these distinguishing factors simply pointing to something else doesn’t address the original comment which is that sac_scale not only can be used but already is being used to describe this exact “thing” and in more clearly delineated detail and with a scale and not a binary yes/no flag
“When this goes to vote, I would not be surprised, if the ‘too late’ argument or the ‘we can do that with attributes on paths’ argument may prevent approval, so maybe voters should be asked to write that in the vote, to ease counting of reasons.” - I realize the argument being made prior is that OSM-Carto makes some poor decisions based on highway=path but that isn’t a problem with highway=path that is a problem with OSM-Carto. This goes to “don’t map to the render” as OSM best/good-practice. This doesn’t mean that it’s too late but it also doesn’t disqualify “we can do that with attributes on paths” as an argument as a scramble is more or less a path especially ones that are well trailblazed. In fact, the insistence on sticking with highway=path is largely in line with the one feature, one tag ideology, as well as these, are paths first, hiking/climbing paths second, and at best a scramble third if the first two don’t do the job, which I feel they do.
Bottomline, is if a proposer listens to RFC feedback and actually changes their proposal to address the concerns of those taking the time to comment then those same comments should not need to be repeated in the voting process. I should never hope to see, “The Rationale is not negotiable.” spoken ever as an RFC response and highlight the problem, not as one with the voting or the RFC process but lays those issues at the feet of the proposer who by their own admission in the RFC process expected and discounted the responses they know would likely come in advance.
The value of a simple tag mainkey=X for an observable feature X which is generally called X by most people is, that it makes life easy for mappers and data users. One attribute tag X=yes comes in as second on the easyness scale, and mainkey=garbagecanvalue garbagecanvalue=X is third.
Combining attributes which may or may not imply X is at the low end of the easyness scale.
I would prefer to tag a scramble section of a trail, path or route as such as a feature exactly where it actually is, as directly and as simple as possible, and in a way that data consumers can use as directly and as simple as possible.
If a trail contains scramble section, it is probably tagged with a sac_scale value that says there probably wil be scrambling sections. As a hiker, I would like to know for sure where exactly these sections are on my planned route, in order to plan a workaround. I know other hikers who would seek those sections out for their trips. As it stands, they can’t, not with OSM-data.
The problem is that scrambles aren’t observable features. Otherwise, how would someone go about observing one? By sitting at random places along a trail that they think looks “scrambly” or whatever until they see X amount of hikers falling and using their hands to crawl up the rest of it?
Like where’s the threshold? Say 10 people used their hands and 7 didn’t is that a scramble? what about if 7 people used their hands, 4 didn’t, but 4 of the people who used their hands are obviously out of shape. Is that a scramble?
What about if a mapper just sees a hill on satellite photos or in person, thinks it looks like something they can’t hike up without using their hands, and tags it as highway=scramble. Would that be OK? Or is that not a highway=scramble because they didn’t actually observe an “able bodied person” hiking it?
What if someone wants to verify a highway=scramble after it’s been mapped. Do they go through the whole observation process again or what?
If “use of hands” cannot be observed, all references to “use of hands” have to be removed from the sac_scale key documentation. This will leave some glaring holes.
BTW: In Australia scrambles, in the sense of having to use hands, are mapped as “demanding_mountain_hiking” (T3). So much on the praised precision of sac_scale.
Yes they are. Yes, people will disagree on some sections, just as they disgree on whether a terrain is scrubland with some trees or low density forest. Most mappers would then say: OK, I would have mapped this as a forest, but I can see why it’s mapped as scrubland, and leave it at that. Same with scrambles: most people would have to scramble, and people who wouldn’t would still understand that most people would have to scramble. At the same time some would say it was heavy climbing, while still acknowledging it as a scramble for most people. This is the kind of fuzzy clearness found everywhere in mapping. It is not solved by stricter definitions, but by tolerance and understanding. Bandwidth thinking and respect for choices.
There is no single objective measure for scramblyness. Still people will agree on most occasions. If not, there wouldn’t even be a word for it.
Sure, I don’t disagree with that and nowhere have I said there has to be one objective measure for scramblyness. What I did do give you multiple scenarios to use to tell me what a scramble is or isn’t and you can’t even do that. No one expects tagging to be an exact science, but if someone gives you 15 possible options and asks which ones fit the definition of the highway=secondary tag you should be able to provide a half coherent answer that isn’t just handwaving about forests.
The issue with that analogy is that the whole purpose of this tag is to stop people from hiking terrain that isn’t safe for then to hike on. I could really care less if there’s some level of disagreement, but that level at least has to be low enough for the tag to fit it’s purpose of supposedly mitigating dangerous hiking. Which it doesn’t do if every other mountain pass is tag subjectively because “people will disagree on some sections” or whatever. Whereas, the bar just isn’t that high for something like if whether a terrain is scrubland with some trees or low density forest. Since it doesn’t 100% come down to the ability of the tags to save lives like highway=scramble was supposedly specifically created for. Just like there has to be a clear definition of what a defibrillator is from the onset and stay that way or emergency=defibrillator would essentially be worthless as tag.
Nowhere the proposal says that. The rationale states, that this tag is about giving consumers a means to assess if a way is appropriate for their clientel, in such a way, that they just cannot turn a blind eye to it. This is the non-negotiable part.
Rationale Many data consumers that have no interest in non-walkable paths evidently have been failing to filter those out for years now."
Why exactly would data consumers have no interest in non-walkable paths and why would need to be filtered out if it wasn’t for safety reasons? Just for the chuckles?
Personal note of the author of this proposal, who is not afraid of scrambles
So it has with safety, but your not afraid of scrambles. Sure dude. What are you not afraid of then?
Later during the voting phase you replied to something I said with “The language you ridicule is taken literally from the worlds most renowned difficulty rating schemes for mountain hiking.” The difficulty of a hiking path literally has to do how safe it is.
I’m sure I could find more if I wanted to, but the purpose of the tag is clearly to stop people from hiking terrain that isn’t safe for them to hike on.
Are you saying you couldn’t identify a scramble section when you see one in front of you?
The single purpose of a defibrillator is to save lives. Mapping them has the purpose of showing where they are. A scramble does not have the purpose to save lives. Mapping scrambles has the purpose of showing where they are, because people would like to know where they are, for various reasons, including just because you see them, and because it might prevent people from getting themselves into trouble, and because it is interesting to know, just as it is interesting for hikers to know surface, ferry sections, landmarks and picnic sites. It doesn’t have to be a single important purpose.
Yes, scrambles exist, and yes, people want to know/see on the map where they are. Sac_scale values tell you that you probably will have difficulties such as scrambling sections, but they will not tell you where the difficulties are. An explicit scramble tag does just that. Personally, I have confidence that OSM-mappers will be reliable enough to map most sections I would call a scramble, as a scramble.
I have hiked in Germany and Switzerland along trails marked as “Klettersteig”, meaning that there are scrambling sections. In fact most of those paths were easy paths, smooth incline 0-10%, with often just a single scramble-section, easily avoidable by a planned detour around the section. And the opposite, trails marked as easy paths, still with scramble sections I could hardly manage (which doesn’t say very much, except that it is really scrambling and certainly not climbing), and I have seen people returning looking for a bus to get them to the next stay location. Wouldn’t it be nice if there was a map showing both the scramble section and the detour?
I asked you to identify a scramble. I’m not going to answer my question just because you apparently can’t answer it. Your the one who is saying they exist so the impetuous is on you to prove it. I’m not doing your job for you.
Sure, but my comment specifically had to do with why @Hungerburg created the proposal. Not why some random user might map a scramble. Along those lines, the last time I checked the title of this discussion is “feature proposal - Voting - highway=scramble”, not “lets discuss why rando users might map trails certain ways.” I assume you get the difference. Personally, I’m here to discuss the proposal and if the proposal makes sense or not as it’s currently worded or whatever. That doesn’t have anything to do with what Joe Blow hiking some random back trail is doing. Obliviously.
At the end of the day I don’t really care if they exist or not. What I care about is if there is an objective way to map them or not. Your the one that said there is. So I asked you how we do that. Again, your the one making the claim that they can be objectively mapped. Just saying they exist or that people disagree about things sometimes doesn’t answer my question. This isn’t that difficult dude. You say they can be objectively mapped. Cool, how do you objectively map them then?
Scramble are no more no less objective than the judgment call every mapper does when tagging tracktype=x.
Cool for tracktype. I didn’t know there was a proposal for it that was currently being voted on or discussed 
Hey, I just want to know how to objectively map scrambles. I really don’t get why it’s so hard for someone to tell me how to 
Being able to say how to use a tag is pretty basic and fundamental. If people who support it can’t even muster meeting that low of a bar without this much deflection then I don’t really know what else to say about it. Except that the tag is clearly unverifiable nonsense 
“signs of actual use” as in traces/manifestations that humans use the path, it’s not referring to a physical sign or board.
Tagging highway=scramble also doesn’t exclude further specification with sac_scale= and/or UIAA=.
Not sure why there is this big insistence on secondary attributes that can already explain everything. We also don’t tag every road as highway=road with a lot of attributes, but have different values for functionally quite different roads like motorway, living_street, pedestrian. Why can’t we have more diversity in the footway/path space as well?
scramble is significantly more objective than tracktype: