This remake is to heal complaints that were voiced. Trying to be as concise as goes, upfront a description of subject matter from a mountaineers perspective:
On to the poll: How to map what is on the ground there, as told above:
This not mappable, because nothing on the ground, such will always make problems with opinions not in alignment.
This a highway=path, regardless of what on the ground and users are recommended to exclude based on secondary tags/a.k.a. attributes from routing/rendering for respective profiles as deemed fit.
This a highway=pathless, because nothing there on the ground and users are recommended to include based on primary tag in routing/rendering for respective profiles as deemed fit.
This continuous cycle of polling and rewording does not feel productive.
This whole ‘there is nothing on the ground, we can’t map it’ thing is not helpful. As pointed out many times by a number of mappers: there are a lot of places where we do map ways, despite there not being a clear linear route on the ground. Beaches, squares, stony areas in the mountains (even on trails suitable for novices), meadows between two gates; these are all places where trails and ways pass; this is common and desirable.
If you feel that advanced mountaineering trails (the alpine SAC-scales) are not suitable for highway=path, then come up with a proposal for something to replace it — like highway=mountain_trail or something like that — where allowances are made for shifting routes, advanced difficulties, and required orienteering expertise. highway=via_ferrata exists, so this would not be too far-fetched. Better yet, create that proposal with input and buy-in from mountaineering mappers.
Thank you to @Hungerburg for keeping the discussion alive. Like I’ve said, these threads have been very interesting precisely because the issues are hard and complex.
I’ve changed my mind, and think now that in this particular case (and others comparable to it), a new tag along the lines of =pathless does make sense. For the extreme cases. Otherwise, I think that further fragmenting the =path tag is a fundamentally troublesome endeavour and we should be able to do with further use of the already existing descriptive tags (you’ll find my more detailed arguments in the previous posts if you care).
Absolutely that - for those cases where a poorly-prepared walker following a poorly-prepared map or app that “just showed all the highway=path”.
Personally, I would pick scramble rather than pathless for the value, but the most important thing is that the value is not some other highway value such as path than might deceive.
I voted for the highway=pathless option because I agree with the reasoning. I’m not sure that is the right key value pair though. I definitely feel that a new primary feature tag is needed for pathless cross-country/orienteering, walking, hiking, mountaineering, and canyoneering routes. However, this should only be used for named, well known, or commonly used routes with either some minimal evidence on the ground or some sort of official status from a land manager or similar. The criteria can be a bit fuzzy, but this new tag should not be used for just any random way a couple of people happened to walk one time.
I worry a bit that a tag for a “pathless highway” (oxymoronic as that is) could be interpreted by some mappers as an invitation to essentially make up all sorts of routes that really only exist in their own heads. Alternatives to highway=pathless might include the terms cross_country, orienteering or pathless_route. On the other hand, perhaps the choice of key and value doesn’t matter too much, and some people will use it inappropriately no matter what. Either way, thorough documentation of the new tag will be important.
highway=path can continue to be used for this purpose, as long as no better tagging is approved or generally accepted.
Better tagging: either a specific highway value (not “pathless” because that is just silly), or a specific path=* value to refine the highway=path tag.
I think a path= tag would have a better chance of being accepted, and better backward compatibility.
If so, then I’d say, you can just click the “This a path” box
Scramble is defined by way of movement. Not certain, the route in Italy requires scrambling at all, just a good portion of wayfinding. Having reread the beautiful description given by CAI Salò, the scramble is in another section.
I think, “only exists in their own heads” a perfect fit for the route in Italy. I know more of those. I like pathless, because it is duck-tagging Placing into highway key will tell users that it is routable. The term itself should ring bells, that path will keep silent.
I am not choosing sides about “what it is”. I say I’m ok with mapping it as highway=path, and I prefer to see a subtag setting it apart from other special cases of highway=path.
Your stance on the issue is exactly what the “path” choice says: Use path to map it and let consumers decide from secondary tags/attributes it they are interested in it, in other words, the let consumers opt-out choice.
PS: I did vote for pathless, but I have some sympathies for “this not mappable” too.
There are two related, but distinct use cases, which we are in danger of subsuming under one skunked tag. Let’s call them by their originally proposed names:
highway=scramble: a route that requires use of hands and/or specialized equipment. Therefore, it is likely hazardous even for hikers, and totally unsuitable for any other mode of transport. Also, the definition may overlap with the existing highway=via_ferrata.
highway=pathless: a route which is not visible on the ground and is only drawn as a suggested connection between endpoints (see also waterway=link). It may be indeed an unmarked alpine route over scree and rocks, but it may also be a nice stroll over a sandbeach or a meadow where pedestrians can roam wherever they please.
While I think that both of those types should be excluded from definition of path, I’m unsure how best to approach classification, since trail visibility and difficulty are generally orthogonal.
what is wrong this time.