Stop rendering extreme mountain paths without giving indication of difficulty

[ghost]

Some mappers use highway=path instead of via_ferrata ( #156 ) to make the paths they like visible.

As long as via_ferrata is not rendered and ferrata/path difficulty not displayed I believe it would be good not to render

• highway=path with via_ferrata=yes and no further difficulty indicator
• paths with via_ferrata_scale>=2
• paths with sac_scale>=demanding_mountain_hiking
• http://www.klettersteig.de/klettersteig/via_attrezzata_rino_pisetta/760

[matkoniecz]

There should be a consensus about via ferrata tagging before changing rendering. In addition:

via_ferrata=yes

Undocumented, extremely low usage ( http://taginfo.openstreetmap.org/keys/via_ferrata )

paths with via_ferrata_scale>=2

Undocumented, really low usage ( http://taginfo.openstreetmap.org/keys/via_ferrata_scale )

http://www.klettersteig.de/klettersteig/via_attrezzata_rino_pisetta/760

Not a tag.

[mboeringa]

@matkoniecz , I wouldn't say this is 'undocumented'. The first post in #156 that RicoZ pointed out, has a link to a pretty well documented proposal:

http://wiki.openstreetmap.org/wiki/Proposed_features/via_ferrata

It is just missing from the main highway=x key Wiki page, probably because it is still a non-voted proposal, or no one yet had the time or bothered to add it...

[ghost]

@matkoniecz: the problem I see is that people deliberately map via ferratas as highway=path only because it is rendered and for the same reason do not agree with the proposal because they fear it won't be rendered.

Mapnik should not encourage such practices but current configuration does that. As long as highway=via_ferrata is not rendered neither should be any of the "tag for the renderer workarounds" be rendered.. as far as technically feasible.

 http://www.klettersteig.de/klettersteig/via_attrezzata_rino_pisetta/760

was just one example of a pretty extreme ferrata which someone tagged as highway=path. Changed that one today.

[mboeringa]

For what it is worth: I have now implemented this in my ArcGIS Renderer. My take on this is:

• I renderer sac_scale as a tiny red cross hair overlay over paths, from sac_scale >= 3. I don't render these cross hairs below sac_scale = 3, as the average healthy "Joe" should be able to do sac_scale 1 and 2, and thus no need to signify these paths as particularly demanding or dangerous.
• I render T2-T6 sac_scale text labels in black. T1 clutters up the map to much, and again is not much relevant, as the average Joe can do it, and essentially _any_ path on the entire globe is T1, so it is kind of redundant info... ;)
• I now render highway = via_ferrata. NOT highway = path + via_ferrata = yes. It has it's own distinct symbol: red dashed line with double black cross hair
• Via_ferrata scale labels are rendered in red next to it with values 0-6.

Here are some results, first two images sac_scale. Please note my renderer is foremost targeted at high quality printed output (it outputs 100% vector PDF data), so some stuff and text labels may look small/tiny on screen but will print fine. Do click on the images though to enlarge them to original size, as otherwise they will look even more tiny. The second image is a 125% zoom in Adobe Reader.

As you can see from the first two images, not rendering sac_scale >= 3 would lead to many paths disappearing from the map (whether that is good or bad is up to the style developers).

The third and fourth image show the rendering of a small section of via ferrata near the Monte Grona in Italy. Notice the via ferrata scale label 4 in red next to it.

I made a concious decision to not render different sac_scale = x or via_ferrata_scale = x as different coloured lines, as is often seen on other maps. There is just to much variation and colours involved, making for a cluttered map. By just rendering a single symbol for the higher sac_scales to depict the special demanding nature of the path, and a uniform text label for the scale, the map stays clean and uniform, while still getting the message across that these higher sac_scale paths aren't for the average Joe on his sneakers.

[ghost]

For what it is worth: I have now implemented this in my ArcGIS Renderer. My take on this is:

• I renderer sac_scale as a tiny red cross hair overlay over paths, from sac_scale >= 3. I don't render these cross hairs below sac_scale = 3, as the average healthy "Joe" should be able to do sac_scale 1 and 2, and thus no need to signify these paths as particularly demanding or dangerous.
• I render T2-T6 sac_scale text labels in black. T1 clutters up the map to much, and again is not much relevant, as the average Joe can do it, and essentially _any_ path on the entire globe is T1, so it is kind of redundant info... ;)
• I now render highway = via_ferrata. NOT highway = path + via_ferrata = yes. It has it's own distinct symbol: red dashed line with double black cross hair
• Via_ferrata scale labels are rendered in red next to it with values 0-6.

that looks good:)

As you can see from the first two images, not rendering sac_scale >= 3 would lead to many paths disappearing from the map (whether that is good or bad is up to the style developers).

agree, and it is good to render them when the difficulty information can be
shown.
Not so sure about that if no difficulty information is shown like in mapnik,
some of those can hardly be called paths.

[matkoniecz]

Using sac_scale seems to be the best idea, this tag is documented, quite popular and tagging scheme makes sense.

[pnorman]

Are there any hiking maps using this tag for rendering?

[ghost]

@matkoniecz : sac_scale is good, but not enough in this case. Some mappers use highway=path + via_ferrata_scale=* as a hack to have their via ferratas rendered (mapping for the renderer, the proposal is to use highway=via_ferrata which is not rendered in mapnik). Specialized hiking maps support this and display the value of via_ferrata_scale but until (if ever) mapnik decides to support via_ferrata_scale=* the combination highway=path+via_ferrata_scale=* should not be rendered at all because it is a typical mapping for the renderer hack and may actually cause damage if mapnik displays the "path" with absolutely no hint that it may be a particularly demanding via ferrata.

@pnorman : yes, at least openandromaps.org supports sac_scale, highway=via_ferrata, via_ferrata_scale and combinations of those - http://www.openandromaps.org/en/legend/elevate-mountain-hike-theme

[matkoniecz]

@RicoZ-OSM It is impossible to ensure that tagging for renderer will be impossible. After blocking display of highway=path+via_ferrata_scale=* they would probably start mapping the same way twice (once as highway=path, once as highway=via_ferrata) or do something else.

The proper method to combat this problem (assuming that it is a problem) is to find such cases (for example using http://overpass-turbo.eu/s/aJf) and edit this places.

[ghost]

@matkoniecz : you are right, but if mapnik would stop rendering paths with eg sac_scale>4 it should also stop rendering paths with via_ferrata_scale>1 or similar.

Also I hope that the incentive to map for the renderer will now be overall much lower when several outdoor maps support highway=via_ferrata properly. Otoh I am very cautious to go over the results of http://overpass-turbo.eu/s/aJf and edit anything ferrata/climbing related without having local knowledge to verify the data.

[fkv1]

@RicoZ-OSM thinks that ferratas are more difficult or dangerous than free climbing routes, which is not true. via_ferrata_scale=2 (in Austria: B) is mostly done by average hikers without any equipment. It's comparable to sac_scale=alpine_hiking (sometimes need a hand...) or uiaa_scale=1. If you want to introduce limits, I'd suggest via_ferrata_scale>=3 || uiaa_scale>=2 || sac_scale = demanding_alpine_hiking || sac_scale=difficult_alpine_hiking. But they shouldn't be hidden, because some of the most crowded paths (such as the Haidsteig) belong to those categories. Better just use a slightly different line style.

[brycenesbitt]

On Sun, Aug 2, 2015 at 3:40 AM, Mateusz Konieczny notifications@github.com
wrote:

@RicoZ-OSM https://github.com/RicoZ-OSM It is impossible to ensure that
tagging for renderer will be impossible. ... The proper method to combat
this problem (assuming that it is a problem) is to find such cases (for
example using http://overpass-turbo.eu/s/aJf) and edit this places.

I think the proper way is not to create the "tag for the rendering"
incentive.
In carto (not a climbing map) render the highway=via_ferrata very
faintly. It's there, render it: tagging for the rendering problem solved.
Leave it to climbing maps to sort out the distinctions between various
routes.

[matkoniecz]

render the highway=via_ferrata

That would strongly promote rare tag that is neither popular (329 usages on ways since it was proposed in 2010) nor went through rfc/vote. This style should not be place to propose tagging schemes.

[brycenesbitt]

That would strongly promote rare tag that is neither popular (329 usages
on ways since it was proposed in 2010) nor went through rfc/vote. This
style should not be place to propose tagging schemes.

The reluctance from the osm-carto style to meet evolving tagging convention is,
unfortunately, a key pressure behind tagging for the rendering.
Potentially it also hinders tag development, as people seek workarounds.
If ferrata (in this example) were rendered, some of the miss-tagging would
resolve itself and potentially uncover far more than 329 instances.

Besides which: if it's really 329 instances it represents no clutter problem for a
global map.
And if those 329 items are of high interest or utility, how does it make
the map better to leave them off?

Motorhome toilet dumps are an even more clear case. They're irrelevant to most people, but most people don't see them. However if you're actually zoomed in on a campground they're conspicuously missing #1507. Here a feature that might not have high numbers, but does have high utility in a specific area of the map.

[kocio-pl]

The reluctance the osm-carto style to meet evolving tagging convention is, unfortunately, a key pressure behind tagging for the rendering.

Leaving aside all the other factors: lack of rendering can really be an issue for the mappers. Latest proof is area:highway=*, which had ~12k uses 4 years after specification was written and until the test rendering layers were started for just a few countries (Poland, Germany and Ukraine; before that only Russia had it implemented somehow). Now it's above 28k in less than a month!

[ghost]

@fkv1: I simply think that until mapnik will display the difficulty (if ever, it is not a specialized climbing map) there must be limits what is displayed as path.

There are excellent specialized hiking-biking maps which do display sac_scale, mtb:scale and via_ferrata_scale so there is no need for mapnik to do everything.

[ghost]

@matkoniecz :

render the highway=via_ferrata

That would strongly promote rare tag that is neither popular (329 usages on ways since it was proposed in 2010) nor went through rfc/vote. This style should not be place to propose tagging schemes.

well this bug is not about rendering highway=via_ferrata but anyway. It is a rare tag because there are not so many via_ferratas and people are discouraged by lack of rendering in mapnik.

[pnorman]

Are there any hiking maps using this tag for rendering?

Does anyone have any OSM-based examples of this?

[brycenesbitt]

Does anyone have any OSM-based examples of this?

Not even Hike Bike Map shows the VF's, which leads to its own safety hazard. The rendering shows hiking paths that go a certain distance then "disappear". In reality they change character from hiking paths to Via Ferrata.

From a pure "map what's on the ground" point of view and "maps show hazards so they can be known and avoided", something different seems better. I'd be against any sort of dashed line, but a string of small rope or climber symbols would really get a message across: "yes, it's a way, no it's not for you".

---

highway = path + via_ferrata = yes is a rendering hack that's hazardous.

[Ircama]

Considering that openstreetmap-carto.style is currently frozen, I thinks we need to wait the availability of hstore to try addressing this topic.

Most traditional touristic topographic maps decently show mountain routes giving indication of difficulty and I had in program to provide a development proposal with the idea of improving the rendering of highway=path for this style, but I found that many needed columns are not included in the current data model (via_ferrata, via_ferrata_scale, sac_scale itself, etc.).

I think that there are many cases where paths are improperly tagged in OSM due to the missing rendering of the related attributes and IMO by trying to address some better rendering of highway=path as soon as hstore is available we could help mappers to fix current tagging errors, incentivizing the documentation of mountain areas; in parallel, avoiding the rendering of extreme mountain paths like SAC scale T6 (sac_scale=difficult_alpine_hiking) could be appropriate. At least sac_scale column is needed anyway.

[pnorman]

Considering that openstreetmap-carto.style is currently frozen, I thinks we need to wait the availability of hstore to try addressing this topic.

Yes, the milestone is set to the reload to reflect this, but this doesn't stop us from deciding if we want to change the rendering or not.

[Ircama]

Yes, the milestone is set to the reload to reflect this, but this doesn't stop us from deciding if we want to change the rendering or not.

OK, fine. I'll try to find time to develop some proposal (e.g. in form of screenshots) in the next days.

[pnorman]

OK, fine. I'll try to find time to develop some proposal (e.g. in form of screenshots) in the next days.

I'd start by finding specialized OSM-based hiking maps that render these differently. If there aren't any, it seems something that the specialized maps should do first.

[systemed]

Relevant: https://www.reddit.com/r/openstreetmap/comments/8wyek8/rescue_due_to_marking_of_trails_on_openstreetmap/

[chaot4]

@hungerburg I agree with what you say. I think it's more important to render "correctly" (meaning in this case: a sac_scale >= 4 path is not a footpath in the intuitive sense but rather a scramble) than to keep mappers from mapping for the rendering. Especially, one can partially resolve the "mapping for the renderer" problem by also mapping some other tags to the same visual representation of a wider spaced path.

And yes, I also agree that in the search&rescue case mentioned above, the people probably did not use OSM-carto but some other map style. However, I think that OSM-carto has some authority just by being the default rendering of OSM, so it should be a good example.

[Adamant36]

"can partially resolve the "mapping for the renderer" problem by also mapping some other tags to the same visual representation of a wider spaced path."

Can you provide some examples of people doing that? I'm not really sure how doing so would resolve anything or really why people would do it in the first place since there's zero correlation (implied or otherwise) between the rendered width of highways and ones IRL (No one tags a residential road as highway=residential because they think how its rendered accurately represents the real world).

[chaot4]

@Adamant36 I think that I might have phrased it poorly such that you understood it the wrong way. I wanted to say that the rendering that @hungerburg suggested above (wider spaced red dots) could also be used for, e.g., via ferratas, less visible paths, etc., such that people do not misuse the sac_scale tag just to obtain the desired rendering result (the wider spaced red dots) in OSM-carto. Does that make more sense?

[kennykb]

PS: Years ago, the opener of this topic, who dropped out of here, did change the SAC-Scale Wiki documentation to his liking, in order to make the sac-scale applicable anywhere, so e.g. he could mark any old footway in a city park as "mountain-hiking", if it was obstructed by potholes or rubbish or such nonsense. That might explain his desire. The Wiki no longer recommends that.

I hope I'm not the person you're talking about! I did an extensive revision to the English-language sac_scale Wiki page a while back. Indeed, it was a near-total rewrite - because the descriptions, while quoted from the SAC web site, were clearly clumsily machine-translated and came out as near-gibberish. I remember particularly the phrase 'single plainly climbing up to second grade' which I couldn't make sense of at all until I read the French version on the SAC site. That phrase got replaced with 'isolated easy climbing pitches, up to UIAA class 2." I revised a lot of the other language, too, because who knows what an 'acclivity' is if they're neither a geologist nor a Francophone? I tried very hard to preserve the sense and not try to assign an SAC scale based on poor maintenance or rubbish or any such thing.

On at least one trail that I graded as 4, I ran into a party that I think were Swiss - they were speaking Alemannic German among themselves (I have real trouble trying to follow German in that accent.) The one with the best English remarked to me, "These mountains aren't very high, but they're demanding!" If someone from the actual Alps is calling a trail, 'demanding,' and I'm seriously wondering, "should I have brought a rope and a helmet for this?" that's demanding_mountain_hiking enough for me!

I agree with nearly everyone here that sac_scale>=5should render differently, and I'm on the fence about 4. There's a class 4 trail near me that regularly gets trumpeted as 'the most difficult and dangerous hiking trail in the East' and as a consequence attracts a legion of the clueless and accumulates a dismal safety record.

For most trails in city parks, I don't put an sac_scale at all. It it degenerates into a dirt path that's "you probably want to have good shoes for this, and don't expect to take a toddler or a disabled person,", then I'll give it hiking.

In any case, over-grading is safer than sandbagging.

[hungerburg]

@kennykb No, you are not the ghost I mentioned, You are still around :) And the translations you did too! I opened fossgis-routing-server/cbf-routing-profiles#9 with a sister repository. And, No, It do not consider wrong tagging - a.k.a. overgrading - safer, but this is not the tagging ML.

[chaot4]

Is there any chance that this is getting resolved by the maintainers? If not, is there any chance that a pull request resolving this issue is accepted?

My only plea is: please render sac_scale >= 4 or sac_scale >= 5 paths differently than the standard paths. I don't have a strong opinion on any of the specifics, but I believe something must be done.

[imagico]

No opposition has so far been expressed by any maintainer against addressing this issue in the generic form expressed in the issue title. However several people have expressed concern that the bad state of tagging in that domain is going to make it difficult to implement a solution to this under the goals we have.

I would suggest to concentrate less on the desire to adjust rendering based on the abstract real world concept of extremeness of a mountain path and based on that develop a belief that a certain tag or tag combination must be meaningful to represent that concept. Instead i'd suggest to look at mapping practice in OSM, analyzing how tags are used and which tags are consistently used to document information that is useful for resolving this issue and based on that either make a concrete proposal (for tag interpretation and design) or to work on improving mapping practice in OSM (by developing new tags, better documenting existing tags and by simply communicating good mapping practice in the field).

I would also like to point to a recent discussions on the German forum: https://forum.openstreetmap.org/viewtopic.php?id=76158 - This indicates consensus in the German community that climbing sections on hiking routes are not to be tagged highway=path but with climbing=route - indicating that this is not primarily a physically manifested and observable path but a route, that - similar to route=ferry is verifiable not through observation of the physical geography but primarily through the fact that it is used as a route of navigation (in this case by rock climbing). Same idea is articulated in https://forum.openstreetmap.org/viewtopic.php?pid=870216#p870216. Related to that also note that in the SAC definitions (https://www.sac-cas.ch/fileadmin/Ausbildung_und_Wissen/Tourenplanung/Schwierigkeitsskala/Wanderskala-SAC.pdf) sac grade T4 is described with "Wegspur nicht zwingend vorhanden" (a physically manifested path might not be present), T5 with "Oft weglos" (often pathless) and T6 with "Meist weglos" (usually pathless). I don't want to invite a tagging discussion here based on that (please don't!) but keep in mind that we render highway=path and if highway=path is used for mapping a pathless climbing/scrambling route that is incorrect use of the tag and the solution is not to interpret some secondary tag on highway=path implying a pathless path but to fix tag use.

[hungerburg]

I found https://wiki.openstreetmap.org/wiki/Proposed_features/Trail_(new_proposal) - Anybody volunteering to give this a lift? I certainly will lend a hand. The base looks promising. It is a bit longish and broad, for a start, it would be enough, if the tag "highway=trail" would be just so narrow, that a bot could rebase all "sac_scale=*alpine*" tagged paths. Well, this may sound like wishful thinking, needs to go full proposal anyway, be prepared for harsh pushback, maybe half-way is enough, like via_ferrata did.

PS: Please apologize, if this considered hijacking the issue. I do not see another option, if we want to fix the routing issue too, see my post above, which in my view is a bit more pressing, than this one here. There is an older proposal for the hw=trail tag, it got superseded by "hw=path", incidentally. Kind of history repeating. And NO, climbing is not an option, the OSM sac_scale is derived from the SAC Hiking Scale.

[Adamant36]

This indicates consensus in the German community that climbing sections on hiking routes are not to be tagged highway=path but with climbing=route - indicating that this is not primarily a physically manifested and observable path but a route

I'd be interested to know what exactly "not primarily a physically manifested and observable path" means in this context. At the end of the purpose of the SAC scale is to denote the difficulty of all paths, hiking ways and trails. Even T6 trails are "mostly unmarked", not completely non-exiting. So the comparison to a ferry route isn't really accurate.

Really you could argue that "not primarily a physically manifested and observable path" is no different then a lot of back country paths that are still being tagged as highway=path (and also at times pretty dangerous btw). There's nothing particularly special about alpine paths that make them magically worth rendering differently then how similar non-alpine paths already are. If anything it's sort of insulting to "regular hikers" and mountain climbers to act like there is. Alpine hiking is actually relatively safe in most of the world. Like I think only 1 person died while ice climbing in Canada last year. Although I admit the Austrian Alps has a particularly high death rate, but I don't think that justifies special rendering.

Arguably mountain climbing is more dangerous then alpine hiking. Yet most (or all) tags related to mountain climbing aren't rendered. If lives (not just Austrian ones either) are really that important then the mountain climbing tags should be rendered. Same goes for the various tags for accessibility mapping. It would be ridiculous to prioritized the safety of Austrian alpine hikers over the vision impaired by rendering SAC scale but not tactile paving.

And NO, climbing is not an option, the OSM sac_scale is derived from the SAC Hiking Scale.

I don't know a super amount about the different sac scales, but from what I remember T4 (alpine walking) sometimes requires people use their hands to keep going, T5 (challenging alpine walking) has simple climbing sections, and T6 (difficult alpine walking) is mostly challenging climbing. So climbing is a perfectly reasonable option for T5 and T6 paths. If not also T4, although sure to a much lesser degree. But so what? IMO that's part of the problem with this whole thing. People trying to shoehorn the sac scale system, which wasn't made for the purpose of rendering maps, into situations where other tags that were created for the specific purpose of being rendered on a map are already being used and work perfectly fine.

At the end of the day anyone hiking a T4, T5, or T6 trail should know it's going to be dangerous. I don't really see how their ignorance is OSMs problem. And really, I don't think ignorance has anything to do with it anyway. It's just that the trails are inherently dangerous so people will die hiking them either way. Sac scales being rendered in OSM isn't going to stop anyone from slipping off the edge of the cliff into a ravine though. Conversely, do we really want to encourage people to look at their phones while their hanging off the side of a cliff by rendering SAC scales? I'd argue no we don't. If anything rendering this will just increase the amount of deaths.

[hungerburg]

Hmm, I actually wanted to solicit constructive feedback. With this I have a hard time. I try my best: Yes, you are on the right track, hiking is only one of the cases, where the meaning of hw=path needs to be sharpened.

It will be a sad day, when so many of those hiking paths disappear from OSM Carto, but this is just a price for the success of openstreetmap as a data source, for not just OSM Carto, but OSRM, and many others.

[Adamant36]

"It will be a sad day, when so many of those hiking paths disappear from OSM Carto."

If the Austrian OSM community wants to kick over their own sand castle just because the style doesn't render the SAC scales that's on them. What has anyone from that community done in the mean time to help find a compromise or otherwise move this forward though besides ask every couple of months if it's been rendered yet and then dodge out as soon as they find out it isn't?

[ebickle]

Take a look at this:
https://www.openstreetmap.org/edit?node=8827029797#map=19/27.98824/86.92502

In what reality does it make sense to tag the route to the summit of Mount Everest as a "hiking trail" and render it the same as the 1km wildflower subalpine path I walked with my 80 year old grandmother on? I'm not even exaggerating!

The problem with all of this is that any sort of difficulty scale will always be subjective. Here in Vancouver we'd consider a hiking trail with 800m in elevation gain and 14% average grade to be "moderate" but someone from the Southern United States would consider it insane. The descriptions for sac_scale don't even make sense here - I've been on a large number of extremely easy alpine trails. "Alpine" is just whether or it's above the treeline, not whether or not you use your hands.

All paper maps here separate trails (hiking or otherwise) from mountaineering routes. The trails are rendered as dashed lines, the routes rendered using small dotted lines. There is extremely strong precedent for rendering them in different styles.

My recommendation is to separate things by sport, just like OSM already does for backcountry skiing (piste:type) and rock climbing (climbing:route).

Specifically:

• Introduce mountaineering:route as a tag and render it differently than a path. In the Pacific Northwest, they are traditionally rendered as a line of small faint dots. This tag (mountaineering:route) is what would determine the style of rendering.
• Allow the sac_scale tag to be specified on a mountaineering:route to indicate the difficulty using a traditional hiking-style classification.
• Allow the climbing:grade:* tags to be specified on a mountaineering:route to indicate the difficulty of routes that require scrambling or mountaineering. Many mountaineering routes in North America are described using these classifications (e.g. "A class 3 scramble with one exposed class 4 section".

There are many different types of mountaineering routes, and it's a sport in itself. It's just never had a proper home in OSM and people have just been tagging (and therefore rendering) in wonky ways because of it.

[ebickle]

Some examples from many of my North American topo maps separating out mountaineering routes from trails:

I'd be curious to hear if it is a similar situation on other continents too. 😎

[matkoniecz]

In what reality does it make sense to tag the route to the summit of Mount Everest as a "hiking trail" and render it the same as the 1km wildflower subalpine path I walked with my 80 year old grandmother on

OSM Carto cannot magically fix invalid data. See https://www.openstreetmap.org/note/1480240 (I asked people who edited this way for feedback, but it seems that it should be deleted unless path actually exists there)

[hungerburg]

@matkoniecz Tagging the route to Mount Everest difficult_alpine_hiking is just plain wrong. After all, OSM SAC scale is a hiking scale. This might still qualify for the "SAC Hochtourenskala". There is some overlap, but not in this case. Now whether there is actually a path, I cannot assess.

@ebickle Thank you very much. The legends look awfully familiar to someone from another continent, and I think, such nuances in colouring and stippling inspired this issue right from the start. It is great to learn, that the term trail is used for the more official paths. The term route surfaced in my country only recently, maybe ten years ago, to much the same meaning, from what I can guess. How would you namespace the route entry from the Canadian map (top image), that has no "mountaineering" qualifier?

[Adamant36]

"In what reality does it make sense to tag the route to the summit of Mount Everest as a "hiking trail" and render it the same as the 1km wildflower subalpine path I walked with my 80 year old grandmother on? I'm not even exaggerating!"

The reality where there's literally zero chance of you ever hiking Everest with your 80 year old grandmother. That's the the issue. The whole thing is predicated on the idea that SAC scales should be rendered so randos viewing the map don't accidently confuse an alpine path for a "normal" one, but there's literally zero chance of your grandmother ever accidently stumbling onto Everest while she's picking flowers. No one who is actually climbing Everest isn't going to already know it's a deadly alpine route and account for it ahead of time though. So it's a distinction without a justification to render it. Unlike say something like access=private where someone might not know ahead of time that a road can't be accessed by the general public.

"The problem with all of this is that any sort of difficulty scale will always be subjective."

No, the problem with rendering this is that doing so would only cater to an extremely small subset OSM users on Github, all of whom I assume are just safety justice warriors (for lack of a better word. No insult though) who just want "their" way of tagging being rendered regardless of it makes sense or has wider support by the rest of the community (see my next point).

"The descriptions for sac_scale don't even make sense here."

There seems to be a miss-conception that SAC scale is just for designating potently dangerous alpine paths. That's not really the case. T1 (Flat or slightly inclined. No danger of falling with appropriate behaviour) is a perfectly reasonable designation for your example. The problem is that SAC scales as a tagging scheme (as opposed to a real world way to designate the potential difficulty of trails) hasn't and probably never will be adopted for anything outside of potentially dangerous alpine trails in Austria. So it's advocates act like that's the only use case instead of just admitting no one cares about it because it isn't a good tagging scheme (I'm sure it's perfectly fine as a real life grading system, but it clearly wasn't created for the purpose of world wide, general purpose use outside of Austria or the Swiss Alpine Club even if it could technically be shoehorned in other places).

[imagico]

While i appreciate people contemplating how to improve how things are mapped and improving documentation of tagging (this is after all one of the things i suggested above in #1500 (comment)) - please discuss this in a different venue. This issue is for discussing concrete ideas how to improve rendering of highway=path based on tags that are used right now and based how they are used at the moment and not based on how it would be nice if they were used.

[ebickle]

@hungerburg For my Canadian and US topographic maps that use the term "Route" in their legends, I'd describe it this way:
"A route in a wilderness region intended for non-motorized travel, leads to an objective, and lacks any indication of physical features (e.g. a path / trail)"

[hungerburg]

Talk on this issue here made me propose a new tag. Late one night days ago, I felt lucky and sent this to vote. Reading through the comments, I start to appreciate the solution mentioned above:

i would probably render the start of such paths (i.e. where they connect to the non-extreme path network) in some form but ending them with a '...' like signature indicating there is a path here but it is not of interest in its further extent for the purpose of this map.

The comments on the wiki make it clear, that there is no consensus in the voting community on how to read the sac_scale, even though it is praised so much for its clarity. The proposal is not about visibility, it is about walkability. One comment lets it end with scale T3, another one lets it end with T5. I am quite confident, that something that concerned visibility would not show any more agreement. Actually, I never understood, why visibility was split to a separate key in the sac proposal, very late only at that. All I know, visibility is no less subjective than walkability.

PS: The title of the issue better said "challenging" instead of "extreme".

PPS: https://www.openstreetmap.org/relation/12822598 last year got tagged with visibilty in such a way, that it exactly mirrors the SwissTopo Rendering (dotted vs. dashed). I think that says a lot about the use of the signature by SwissTopo. At least, if the OSM tagging is true to the ground (which it certainly is not, because the route is trail_blazed and in OSM a trail_blazed route should always be visibility=excellent.)

[amadvance]

As the new tag "scramble" proposal didn't pass, I reiterate the simplest proposal made by other users to render differently anything with sac_scale>=4 (alpine_hiking).

I agree that it's not perfect, but I consider it an acceptable compromise that will avoid my concerns about people safety when mapping difficult paths, especially if they are nearby easy ones.

I really don't like that my mapping could result in putting people in unpleasant situations.

Obviously, any other solution that achieves the same goal is acceptable, but this simplest one looks like the best compromise to me.

[Woazboat]

Some people here are seemingly getting hung up on the use of the term "alpine" in the OSM tags for sac_scale, somehow thinking that this is something that is only applicable in the actual Alps mountain range. That is absolutely not the case. These terms are used because the scale was invented by the swiss alpine club, but the difficulty ratings are generic and applicable everywhere. There isn't anything special or magical about the Alps that would only allow them to be graded and no other mountain.
To underpin that point, here's the current usage distribution map for sac_scale in OSM. It's used absolutely everywhere: https://taginfo.openstreetmap.org/keys/sac_scale#map

The sac scale actually primarily uses numbers T1 - T6. The associated descriptions "hiking" - "very difficult alpine hiking" are just that: descriptions to make it clearer what these numbers mean.

[Woazboat]

It's also important to realize that the "sac scale" we refer to here is specifically the one used for mountain hiking. It's not intended to cover everything from a walk in the park to climbing mount everest. Different scales are used for different sports: https://www.sac-cas.ch/en/ausbildung-und-sicherheit/tourenplanung/grading-systems/

[hungerburg]

The Swiss Alpine Club created a scale to gauge the mountain hiking routes that it entertains. This scale got translated into a tag for use on ways in openstreetmap. The scale combines multiple facets. Consequently, consumers never know, which of the facets actually prompted the value put into the data. Tagging sac_scale is a delicate endeavour. There is much that can go wrong. It gives a lot of lee-way. Some people prefer to err on the safe side, some people do not see the problem, others have.

Moreover, different communities from all over the world have their own scales. In the US there is YDS (with Sierra Club rating at its base), there is CAI Scale in Italy, there is a Scrambling scale by the BMI, there is the Austrian system derived from the skiing pistes scheme that differs slightly from the German scheme that uses the same colours. The guiding vectors are not the same. Comparing values from one system to the other may be good enough for a funny Wikipedia table. It is not of much use in practice. It is comparing apples with oranges.

One thing all those have in common, they are aimed at giving people hints at what to be prepared for, in matter of: equipment needed, head for heigh needed, physical abilities needed (all but endurance, which is not covered except in CAI) &c. Due to this and due to their multi-aspect nature, none is concisely describing what is there, on the ground.

That said, from what I learned in related discussions, there are indeed maps especially geared at hikers, that deliberately omit paths tagged sac_scale above a certain threshold from rendering. If OSM-Carto followed that example, it might make for a nice social experiment.

[Woazboat]

If OSM-Carto followed that example, it might make for a nice social experiment.

I'm not sure why you'd consider this a "social experiment"? Lots of other OSM map styles have used sac_scale to convey difficulty via different rendering styles for quite a while now. This isn't really anything new. (Not to mention the myriad non-OSM based hiking maps that show difficulty of individual path sections via different styles pretty much since hiking maps were invented.)
I'd consider any map that didn't differentiate paths by difficulty unsuitable for hiking.

Moreover, different communities from all over the world have their own scales.

The sac scale is the de-facto OSM standard and is also used (in OSM) in areas where traditionally other schemes/scales have been used. The only other route difficulty rating scheme that I know of that is somewhat popular in OSM is the UIAA grading system for climbing routes (which doesn't apply here as it's for a different use case/sport). The (proposed) CAI scale also has some uses (confined to Italy), but notably the proposal mentions that it should only be used on route relations because the difficulty of individual ways is already covered by sac_scale.

[mboeringa]

Sigh... just to show once again it is possible to create a beautiful map including sac_scale based on OSM data, another example of my personal renderer. If the gods allow it and I find the right partner to finish this job, it might one day make it onto www.openstreetmap.org...

I doubt anyone will attempt a T6 on its sneakers using a map like this...

[5Boggis]

Yes! Finally mboeringa's map is a map that I would have expected.
It should be very clear for everybody what difficulty he should expect when using a specific path. I would strongly support this proposal.

[hungerburg]

I doubt anyone will attempt a T6 on its sneakers using a map like this...

Ortler is not a T6 mountain hike, it is a ZS Hochtour with a UIAA III climb. Openstreetmap has no means to accurately tag this and have it rendered in OSM carto at the same time. Yet, as regularly people pass there, Openstreetmap must have a path there. It is tagged T6 because there is no T7.

This is not much of a problem at all though. One just cannot get there by accident. It is kind of a problem, where T6 sections hide in lower ranges between a hut and a parking e.g. and this is not something OSM-Carto or any other renderer competing for the standard view can fix.

If OSM-Carto stopped rendering those though, I wonder, if perhaps a new base-tag for such passes got developed, so they would only show on maps that cater to such a niche audience? After all, there is not much path there…

[RealByteBuster]

(Source: sac-cas.ch) -> (http://www.sac-cas.ch/unterwegs/schwierigkeits-skalen.html)
So, there is a connection between SAC system for hiking and high-altitude mountain tours (Hochtouren). Or someone can see it like an extension ...