the T4, is not what I think we map as path in OpenStreetMap.
They are there, in the thousands. They are mapped as path of course, how else?
I was specifically referring to the first of the videos, second route starting at the linked position.
If this breaks rendering and routing, I could not care less.
if it breaks rendering and routing for applications that do not specifically cater for these “highways”, it is intentional.
From the looks of it, its quite similar to what - again from the looks of it (photo linked from the proposal page) - the SAC T4 hike up Guggihütte has on offer. (The route relation in openstreetmap grades it T5, but the ways are all T4.)
Unfortunately “trail” in American English means “path”, as noted above at https://community.openstreetmap.org/t/feature-proposal-voting-highway-scramble/5228/32, so it’s not a great option.
I wish you good luck in arguing, that a demanding_trail actually is not a trail at all; because, as said above, in my research I looked at highway=trail and I learned, that in colloquial language this only applies where trail_visibility=excellent and sac_scale=hiking, perhaps mountain_hiking where trail_visibiliry=excellent. Fortunately, the English language is quite rich in its terms, and from a post of a South African mountain rescue member to some openstreetmap mailing list I learned the term scramble, that I could readily translate. Unfortunately, scramble does not cover all of your use cases. You did not oppose, did you?
Oh, I was not aiming at avoiding the similar meaning in English (although that would be even better, if someone with better control of English would suggest one) , I was trying to avoid it being similar in OSM tag name.
Other possible alternatives to demanding_trail:
demanding_byway (I’d like to avoid frequently used OSM term “way”, also it is more road-like)demanding_bypath (more correct, but I’d like to avoid having “path” anywhere in the name, so it can’t be by accident matched by humans, regex or substring)demanding_route (“route” is OSM term for different element type, so best avoided)demanding_course (meaning similar to “route”, so people might be inclined to incorrectly tag it on OSM route instead of a way)demanding_spoor (might be a good match, but maybe somewhat obscure term for non-English speakers, and kind-of implies there is visible track or trail of an animal or person, which while often is a case, might not be really visible at some parts, which is a problem many other terms share too)demanding_progress, demanding_movement, etc. not nouns, but as values of highway= key might fit.Other suggestions?
Well, same colloquial usage caveats apply to “path” as used in highway=path, don’t they? And still, it gets used with all different trail_visibility and sac_scale values. Also note that trails usually get trailblazed exactly because their trail_visibility is way below excellent. So much for precision of colloquial speech.
I would also like to note, that we have (although not quite at Humpty Dumpty level) some artistic freedom in use of words in OSM tags.
So we have shop=massage or shop=hairdresser which are not really shops, highway=bus_stop which is not a highway, waterway=fuel which is not a waterway at all etc. We have cuisine=heuriger which is not even an English word, or cuisine=brunch which indicates time of day for meal, and not cuisine.
Tags mean what we define them to mean in the wiki. It is nice bonus if it makes sense in colloquial (and/or British) English when you read key and value aloud, but it is not requirement at all. What the specific key=value means is what you define it means in a wiki.
Unless its name is hugely different (e.g. intentionally opposite) of what it means, such minor deviations from British English Dictionary de jour are not really a problem, as long as exact meaning is clearly explained at tag wiki page (and in proposal before that!)
So yeah, if we can agree on highway=demanding_spoor for example, we can define there that the actually visibility of that spoor is defined by extra tag trail_visibility=*.
We should also define there, what it means if trail_visibility=* is not specified: for example, that the trail_visibility=intermediate is to be assumed (or, trail_visibility=no is to be assumed, or whatever we agree on as most likely scenario. Or, we can even clearly define on that wiki page that no assumption about trail visibility may be assumed if it is not explicitly specified – what is important is that we be crystal clear about it upfront, before tag becomes official and starts being used).
I was just researching the geograph picture location from the proposal page and found Way: 825811006 | OpenStreetMap - From the looks on the picture, the terrain on its own likely does not warrant a sac_scale T4, can be T3 just as well, but maybe there are other things that make it merit that. What do I know? All I know is, SAC T4 breaks routing in graphhopper.
The picture is actually https://www.geograph.org.uk/photo/2053532. if you switch there to an interactive map, and based on the camera direction, it’s actually the western end of https://www.openstreetmap.org/way/517237335#map=19/54.45650/-3.12141 that this is a photo of, which is tagged as “demanding_mountain_hiking” - so whoever mapped it agrees with you!
I have the feeling that in British English highway=trail would be a good tag for ‘not really a path anymore’ (bad visibility, only trailblazed, bare rock…), but not for with the same goal as the currently proposed highway=scramble which is narrower.
Am I right?
I fear that would only add to the confusion. I don’t think trail is that clearly defined.
Yes, you’re right, highway=trail would only work along with sac_scale, trail_visibility, scramble=yes, etc… tags.
Alone this would be as fuzzy as actual highway=path, but limited by definition (documentation) to the more challenging path, or where it becomes doubtful this is still a path.
This is an option that let room for existing and future additional tags.
The other global option would be to try to map with single tags such as highway=via_ferrata, highway=scramble, highway=mountaineering, and other values yet to be invented for other particulars.
Unfortunately, experience** suggests that that won’t work, because some of the app developers we are dealing with here are complete muppets***.
** in my case, dealing with DWG complaints - I’m aware I probably see more of this sort of thing than many people, hence me being insistent about this part of the issue.
*** in the https://www.urbandictionary.com/define.php?term=Muppet sense. As noted above, there are excellent ones too.
Sure, if its a duck…
But what kind of highway=* value could possibly satisfy highway=path, trail_visibility =no, trailblazed=yes ??
There isn’t one but that is not the point of the scramble value. It’s all about preventing a “muppet” user or application from treating challenging trail or path like a walk in the park. A mistake that could lead to injury to inexperienced hikers. In extreme cases, wasting time and resources of first responders.
But these cases don’t start and end with scrambles.
As mostly a data consumer with OpenAndroMaps nowadays, that’s really an objective for me to mark cleary where a path could get too dangerous for one’s own ability. And this is of course subjective, so I try to differentiate and show many characteristics so our users can make an informed decisions (so we might be more interested in scrambles as micromapping, for which scramble=yes is fine).
But if we leave specialized maps like OAM, you have to take the ability of the average person into account. I see really a big problem with the huge spectrum that highway=path is covering currently, and how more basic maps are ignorant of that. In my opinion physical and psychological hazards that lead to rescue operations in the mountains don’t start at scrambles; exposed segments, head for heights/sure-footedness as requirements are on the one end, actual climbing routes (not scrambles) that are (wrongly) mapped as highway=path on the other end of the spectrum. And @Matija_Nalis also wrote about other use cases outside the mountain hiking spectrum.
That’s why I see that highway=scramble is in principle a good idea; but it should be part of a bolder move to separate more hazardous parts out of highway=path. Others already elaborated why a wider tag can’t be as intuitive as highway=scramble, and why it might not be necessary anyway. I want to add another thought: if a data consumer really thinks that highway=demanding_trail should be rendered the same as highway=path, what stops him to do the same with highway=scramble?
Unfortunately, in American English, “trail” is often used for a generic multi-use path. (Sometimes in British English too, as in the Taff Trail and the Tissington Trail.)
Although OSM uses British English, we do try to steer clear of ambiguity where it’s very likely to lead to mistagging. That’s why we use the American English “sidewalk” rather than the British English “pavement”.
I fear that highway=trail would be intuitively used by many mappers to mean a non-hazardous path and then we’d be back where we started.
The issue here is about people who don’t “really think”.
A lot of data consumers don’t “really think”. They just behave as if a path is a path is a path. I don’t think we should cast too much blame in this scenario: you shouldn’t need a PhD in OSMing to be able to make a map from OSM data.
And to be fair, a lot of mappers also don’t really think. They will, and do, happily trace a faint line across Snowdon as a “path”. Coping with this is a real live problem for mountain rescue teams.
The advantage of highway=scramble is that it causes both data consumers and mappers to think. As a data consumer, you have to make an active decision how to treat highway=scramble; and if you don’t know about the tag, you won’t render it. As a mapper, you now have a choice to make when you map a path; and even if you make the wrong call, as ever, another mapper can come along later and improve your mapping.
Sure, it won’t be right 100% of the time. OSM is iterative. But highway=scramble fails safe, and the current situation doesn’t.
I agree on the current situation, but wouldn’t highway=demanding_trail (or anything else, any better solution is welcome) be also disruptive and make it easier? Wouldn’t it make it easier for a whole lot of more problems for mountain rescue teams?
I was lead here by @ezekielf because of a discussion in the voting section about finding a compromise which current no-voters might agree too. If this proposal fails to get the threshold of approval one can still use highway=scramble. But in my opinion a solution/future oriented compromise which builds upon this proposal and includes it (e.g. highway=demand_trail, demanding_trail=scramble), is the better way to go in the long term. There are so many good ideas in the proposal AND the discussions that it would be a shame to let it end at this point.
That’s why it supposed to be highway=demanding_trail instead. Much less chance of confusion “oh I didn’t know it was about demanding trail”
As I’ve stated before, I’m open to considering a proposal for a broader tag for steep/challenging/dangerous paths/trails, of which a scramble would be a subset. I don’t know if I would support it or not, as it hasn’t been written yet. My initial feeling is that demanding_trail or demanding_path are quite unspecific tag names and far too open to interpretation, but I’m willing to consider a well thought out proposal if someone writes one.