Stop rendering extreme mountain paths without giving indication of difficulty

[ghost]

Some mappers use highway=path instead of via_ferrata ( https://github.com/gravitystorm/openstreetmap-carto/issues/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

[5Boggis]

mboeringa, your explanation of the destinctive character of a via_ferrata is very expressive and I agree fully. We as a family like to do Klettersteige (Via ferratas) a lot and especially from a grade C and higher this is definitively no hiking path anymore. On the other hand, they are not hidden in the nature and are shown on each hiking map with special symbols, like in your rendering. I like it very much. As far as I am concerned, I like to have also the via ferratas on my GPS-device, since some years ago I lost one crossing and got in some trouble due to very long detours that I had to go. My family was pretty upset, shame on me! This is the main reason, why I really think, via ferratas MUST be shown on the maps, and MUST be visibly different from ordinary hiking paths. Does sac_scale mean Suisse alpine club scale? If yes, then it may be more suitable for difficulty classification of real climbing routes. via_ferrata_scale= then maybe more appropriate to classify a via ferrata. But please apologize if I am not so familiar with the OSM-standards in this point. As far as I understand mboeringa's and jeisenbe's comment, the preferred way for tagging a via ferrata is highway = path and adding via_ferrata_scale = ? This would make sense to me also. jeisenbe, can the standard OSM-renderer (sorry, I am not so deep in the IT-stuff: The renderer that creates the maps that are shown, when I open openstreetmap.org) be programmed to produce something similar to mboeringa's ArcGIS-renderer? Or mboeringa, is it possible to choose, which renderer should be used at openstreetmap.org, meaning, one can select your renderer easily?

[Adamant36]

As it is, it might be hard to render them differently in a way that wouldn't be to abstract and makes sense to the average user. mboeringa's rendering is really great for a map specific to via ferrata's, but on a general map like this I could see where people just be confused by the X's and they are either a barrier or where the route is none accessible for some reason. In other words, there's nothing specifically "via ferrata" about it.

[SomeoneElseOSM]

This is the main reason, why I really think, via ferratas MUST be shown on the maps, and MUST be visibly different from ordinary hiking paths.

Fine - but that's not an argument why one particular map style (this one) should show them. There's absolutely no reason why you couldn't create your own "via ferrata map" that perhaps also rendered sac_scale etc. as well.

[5Boggis]

OK someoneelseosm, I give up. Maybe it is simply because I like the idea of OSM and wanted to contribute to the data accuracy and usability. But as I am not a programmer, but just a simple stupid OSM-user, I cannot program my own map-renderer. And because I am now significantly older than 50 years and have made many, many hikes in the mountains during my lifetime, I simply like to see on a map, where a path is. That's what I understood to be the purpose of a map. As things look, I will continue like my grandpa to buy simple paper hiking maps. They are at least complete.

[Adamant36]

Have you checked out something like OsmAnd or http://www.waymarkedtrails.org/? I think Way Marked Trails might have indications of difficulty. Although I could be wrong.

[jeisenbe]

@5Boggis - According to the wiki page for highway=via_ferrata, these renderers currently show these features:

• OpenTopoMap

• HikeBikeMap

If you would like to print these, you can download a good pdf or png file suitable for printing, for free, from MyOSMatic, and take it to any large-format printer.

I'm not sure what sort of GPS device you are using, but it may be possible to get a version of one of these styles for your device as well. There is a Garmin-specific version of OpenTopoMap, for example: http://garmin.opentopomap.org

[SomeoneElseOSM]

@5Boggis - just to add to what @jeisenbe has already said - while I'm sure that you'll be able to find one or more Garmin styles that show what you want, if you want to create your own and customise it it's really not that difficult - see https://www.openstreetmap.org/user/SomeoneElse/diary/38613 for step by step instructions.

Cheers, Andy (also "significantly older than 50 years")

[5Boggis]

Thanks a lot for the help. I'll try it.

All the best and good hikes, Klaus

[Sjord]

Via ferratas differ quite a lot in difficulty and needed equipment, and I think it is useful to split easy and hard ferratas, both for the sake of this discussion and for proper mapping.

Easy ferratas are difficult hiking paths that have wires or chains to help the hiker hold on. These are unsuited for elderly or unfit people, but you don't necessarily need a ferrata kit (harness, carabiners, helmet). There is a path in the sense that you can see on the ground where to walk.

Hard ferratas are rock climbing routes with metal wires to secure to, often on a vertical rock face. You absolutely need a ferrata kit (harness, carabiners, helmet). There is no path visible on the ground. There is a route, but you climb instead of walk, and it isn't on the ground but on a vertical wall.

When hiking, an easy ferrata may be acceptable, but a hard ferrata is typically inaccessible. For hard ferratas, preparation and equipment are needed. A hard ferrata is typically a wilfull day event, whereas a easy ferrata may be part of a hiking route to get somewhere.

Easy ferratas may be mapped as path, possibly with an indication that they are difficult. They can be part of a hiking route. There is a path on the ground, so mapping as path makes sense. highway=path with via_ferrata_scale would be a logical way to map paths that are difficult, have chains or ropes, but don't necessarily need a ferrata kit.

Hard ferratas should not be mapped as paths. When planning a hiking route you really don't want to accidentily include a hard ferrata, so these should not look like ordinary paths on the map. Also, there is no path on the ground, there are iron bars in a rock face. highway=via_ferrata makes sense for these hard ferratas.

[kocio-pl]

Still the usage of tags is relatively low, even if raising faster lately, but at least via_ferrata_scale has 2065 uses:

https://wiki.openstreetmap.org/wiki/Tag:highway%3Dvia_ferrata https://wiki.openstreetmap.org/wiki/Key%3Avia_ferrata_scale

Do you have an idea how to distinguish between "easy ferrata" and "hard ferrata"?

[polarbearing]

You absolutely need a ferrata kit (harness, carabiners, helmet)

While offtopic for rendering, your ferrata kit description is deadly. It is missing the shock absorber. Without the shock absorber you will die, because either your equipment or your spine breaks.

[Sjord]

but at least via_ferrata_scale has 2065 uses

Klettersteig.de has information on 2313 via ferratas in Europe. So although the usage of via_ferrata_scale may increase, it won't increase by much, because not much more via ferratas exist.

I came up with three methods of rendering:

Little crosses

As proposed in Proposed_features/via_ferrata, uses little crosses on via ferratas. It is immediately clear that this isn't a normal path. Although I think people who do ferratas may like this, it puts much emphasis on via ferratas. It may not be the best for a general purpose map such as OSM. Also, this would only work for via ferratas and not other kinds of difficult or hardly accessible roads.

Blue dashes

This is the color code used in Switzerland, and it would be obvious to Swiss people that this is a difficult or otherwise special path. I don't think it is obvious to anyone not familiar with the Swiss system.

Wider dashes

Using wider dashes makes it clear that the road is harder or worse than other roads. It is not immediately obvious in what way its worse. This could be used for all kinds of difficult paths: via ferratas, but also high SAC scales, or other tags that indicate very hard accessibility. I prefer this one.

When to use

I would render both highway=via_ferrata and paths with high via_ferrata_scale as difficult path. I agree with @fkv1's limits:

via_ferrata_scale>=3 || uiaa_scale>=2 || sac_scale = demanding_alpine_hiking || sac_scale=difficult_alpine_hiking

This would add rendering for highway=via_ferrata, and render some paths differently.

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

This problem is then solved. Both are visible.

[polarbearing]

wider dashes look most plausible to me as well.

Needs to be tested against a variety of background, in particular things like bare rock, forest and sparse vegetation cover.

[matkoniecz]

Blue dashes

Note that basically this rendering is used for cycleways in this style.

[ebickle]

Lots of great discussion here, and I'm generally hesitant to post on such a long topic. However, I noticed most of the comments so far are from European viewpoints.

In mountainous British Columbia, Canada (Pacific/Western North America), Via Ferrata is not very common. Instead, most of our mountainous routes can be classified as one of the following:

• Established, maintained hiking trails. (e.g. park trails)
• Unofficial "user maintained" hiking trails.
• Overgrown "lost" trails that have succumbed to the coastal rainforest jungle, and now are completely indistinguishable from the regular terrain.
• Scrambling routes. These are "pathless" routes with that require the use of hands and/or climbing skills, but do not require technical gear. These are usually referred to as "Class 2" or "Class 3" routes according to the Yosemite Decimal System (YDS).
• Technical rock climbing routes. These are "pathless" routes that are class 4 and above on the Yosemite Decimal System (YDA). (no "Via Ferrata" here).
• Mountaineering routes. These are challenging routes up a mountain (or mountain range) that typically involve a mixture of hiking trails, bushwacking, scrambling, and technical climbing.

On all paper maps that I own, defined trails on the ground are shown as dashed lines. All "pathless routes" such as scrambles and mountaineering routes are shown as "faint dotted lines". This is true for every North American topographic map I've ever seen, all the way from government maps to user-drawn ones.

I can summarize the existing problem like this: Mountaineering, climbing, and scrambling routes without a visible path should not be tagged as highway=path

"Highway" and "Path" both imply a physical structure of some sort on the ground - not the case for these routes. They are completely indistinguishable from any other terrain in the area.

My recommendations:

1. highway=path should not be tagged with trail_visibility=no as they are mutually exclusive. This could be shown as a tagging warning.
2. Render climbing=route on maps and ensure they cannot be confused with paths (trails). This will help with people deliberately tagging things incorrectly so that they show up. Add "climbing=route" and it's variations as "features" that can be selected when drawing a line. Typing "climbing" into the feature search box yields zero results.
3. Add a new "mountaineering=route" tag and associated feature type (rendered as a dotted line - never dashed) to cover all mountaineering routes that A) are not solely a technical rock climb, and B) do not have a path on the ground.
4. Consider rendering highway=path with trail_visibility=bad/horrible with "less emphasis".

3 is the most important recommendation in the list, it's a large "tagging gap" in the system in that we can have backcountry ski mountaineering routes (piste:skitour) but no summer mountaineering routes!

There have been two Search and Rescue callouts in my area due to OSM mountaineering features being incorrectly tagged as physical trails that do not exist. The worst of it is that there's no actual way to "fix" these features since OSM doesn't support them. Time to fix this 😀

[ebickle]

Also one other point worth noting - around here, our OSM users have no issues at all tagging things as "piste:skitour" and not having them show in the default OSM render. They love those backcountry ski routes here, they are everywhere!

IMHO, the bigger issue is that there's no "discoverability" for mountaineering/via_ferrata/scrambling/climbing in the "feature search box" when adding a line. Add that, wait for a bit, and determine if that helps solve the problem.

The UI shows big red scary messages if you leave things as just a "line", so people hunt around for "whatever" to choose and path is near the top. Rendering may be less of an issue.

[fkv1]

This is not the right place to discuss how paths and routes should be tagged and in which cases an editor should issue a warning. This is a discussion on rendering. For this, you MUST accept current tag usage and the documentation in the Wiki as prerequisites. It is dangerous when someone asks for editor changes here. For example, it may easily happen that an editor developer reads ebickle's request for a warning when highway=path is tagged with trail_visibility=none, finds it reasonable, and implements it. Then the users will run into this warning where hiking routes cross meadows (where trail visibility is typically significantly worse than in the forest). As other highway=* tags would obviously be even wronger, the users will first try to delete those path sections. But then they'll get another warning because of gaps in the route relations. So they'll end up setting trail_visibility=good even though it does not match the situation on the ground.

When you want dotted lines for climbing routes etc., there's no need to invent new tags. Just evaluate existing tags such as uiaa_scale=, via_ferrata_scale=, sac_scale=, sport=, etc. It's all there.

[jeisenbe]

@ebickle, thank you for your suggestions. It sound like you have some interesting ideas for improving how climbing routes and mountain pathways are tagged.

This github repository is for Openstreetmap-carto, the style sheet used to render the "standard" layer on openstreetmap.org. To discuss new tags, I would recommend subscribing to the Tagging mailing list and discussing your ideas there, and then consider making a proposal.

The editor which you mentioned (re: "no "discoverability" for mountaineering/via_ferrata/scrambling/climbing in the "feature search box") is probably the iD editor, which is found on the openstreetmap.org website. That application has their own public github page, where you can see issues and open new ones: https://github.com/openstreetmap/iD/issues

But I would recommend talking about the issue further on the Tagging list, the OSM forum, or with your local mapper community.

Here we try to render the tags and features that mappers commonly use, generally after a certain way of mapping has been widely accepted by the community.

[jeisenbe]

Regarding your specific ideas:

1) trail_visibility=no: This should be discussed in the forums about tagging

2) Rendering climbing=route: it would be helpful if this tag had it's own wiki page. Perhaps it's only been proposed but not formally discussed? It's only been used 298 times so far, so it's probably not common enough to be rendered in this style, but might be added to some more hiking-specific specific styles first? Try asking OpenTopoMap or HikeBikeMap first.

• https://taginfo.openstreetmap.org/tags/climbing=route - 298 uses
• https://taginfo.openstreetmap.org/tags/climbing=route_top - 109
• https://taginfo.openstreetmap.org/tags/climbing=route_bottom - 1081
• https://wiki.openstreetmap.org/wiki/Climbing

3) New mountaineering=route - discuss this on the tagging mailing list and make a proposal: https://wiki.openstreetmap.org/wiki/Proposal_process

4) Consider trail_visibility=* to adjust highway=path rendering"

• This is the change that we could make. trail_visibility= has been used over 400,000 times, and the values bad, horrible have been used 75k times. However, read the earlier discussion above to see some difficulties with the tags and with rendering options.

This tag is somewhat controversial due to difficulty of mappers to decide on it's meaning. That's also true of the similar tag tracktype which we use to adjust the rendering of highway=track, so it's possible we could do this for highway=path, but it would limit our rendering options.

[ebickle]

Thanks everyone! Apologies for getting a bit ahead of myself and tossing a few requests in the wrong place. I'll engage with the tagging and iD editor communities on those fronts.

As for the more on-topic cartography side of things, after re-reading through the posts here I think there are a few distinct issues trying to be solved:

1. The rendering of all paths (highway=path) the same, without an indication of difficulty (the original "topic" of this issue)
2. The lack of a distinct cartographic style for European via ferrata routes, which may or may not have a physical path. (predominant in Europe)
3. The lack of a distinct cartographic style for technical climbing routes without fixed lines. (predominant in North America)
4. The lack of a distinct cartographic style for pathless mountaineering and scrambling routes that are not solely for climbing (in Canada, the mountaineering is considered a different activity and community compared to rock climbing).

For issue 1) I agree with @fkv1 that the existing tags should be sufficient to cover this case. While some of the individual tags may be ambiguous, the ranges of them are less so.

sac_scale >= 4 is "often trackless", contains scrambling/simple climbing, exposed terrain, and mountaineering boots and knowledge in using climbing gear is recommended if not mandatory. sac_scale 5 is "mostly trailless". We would call both of these "scrambles" here.

sac_scale = 3 is a bit more troublesome since it describes "trail does not necessarily exist" (implies mostly there) and only "some use of hands". There are a lot of non-technical hiking routes here that fit that classification and are very popular with the general public - with minimal-to-no training or experience.

trail_visibility is a mess in terms of overlapping definitions, but trail_visibility=no seems very clear to me - those are your sections where a path is overgrown, leads through meadows, or over rocky surfaces where it becomes indistinct.

I would recommend deciding on a new "pathless trail" rendering style and then using it lines tagged as "(highway=path and (sac_scale >= 4 or trail_visibility=no or trail_visibility=horrible). As I mentioned earlier, in North America I will often see this rendered as small round dots instead of dashes on hiking topographic maps. (Note that official government maps (US Geological Survey and Natural Resources Canada) do not render them since they are not physical features.)

That should cover the vast majority of issues with highway=path.

For issues 2) and 3) - the via_ferrata and climbing routes - the solution could be rendering them without having to be tagged as highway=path. The clearest choice, in terms of clear definition but not necessarily usage, would be to render "climbing=route".

It's an unambiguous tag and covers all technical rock climbs that aren't related to hiking, paths, or trails. The ambiguous issues with "via_ferrata" (e.g. an easy little handhold along a hiking trail vs an extremely difficult technical climb up a sheer rock face) wouldn't be a concern if climbing=route is used instead. Tagging of climbing routes may be low today, but I would argue that it's just because the default style and user interfaces do not support them. That will change rapidly once the style is put in place. Climbers tend to be a very eager group of people. 😁

[jeisenbe]

@ebickle there are 3 basic issues to consider first:

1) surface= is not currently shown (e.g. unpaved vs paved). There is a PR (#3399) in the works to address this. This property tag is probably the most important to render in general.

2) highway=path is rendered with a red dashed line, like highway=footway. This leads to rendering problems in urban areas and parks with a high density of footways or paths.

3) footway=sidewalk and similar urban subtypes of footways and paths are not currently rendered differently than rural or wilderness paths.

Also consider that highway=footway/path is rendered in a similar style to cycleways and bridleways, with just different colors distinguishing the 3 features currently. And highway=track is also rendered similarly, with a narrow dashed line, for agricultural and forestry track roads.

It will be difficult to find an optimal rendering that can distinguish between paved and unpaved footways and sidewalks, wilderness paths, and also consider keys like trail_visibility=, sac_scale=, and via_ferrata_scale=.

For the same reasons, it's difficult to find a good rendering for climbing routes and via ferratas which will be clearly distinguished from other paths.

[Tyg-g]

I ran into this issue while I was trying to tag and clarify via ferratas in Slovakia. I'll make my contribution to this topic.

A Via Ferrata is a path that is equipped with a parmanent safety equipment: an iron rope with regularly placed blockages (not a simple rope), and is intended for attaching personal climbing gear: harness with an energy absorber for via ferratas. It is usually easy climbing (sometimes no climbing) but there is danger of lethal fall from height, hence the safety equipment. In this way it is a path with an extra feature. In my opinion the sac_scale is not sufficient to indicate a via ferrata because it doens't indicate the permanent safety equipment. Otherwise, it is a path, because it can be walked or done with very simple climbing. Via ferratas are usually indicated in touristic maps as paths distinguished by some means, e.g. a ladder pictogram.

A Climbing route is equipped with devices for attaching a climbing rope. Climbing needs special training, of course. In this way, this is not a path, because it is not walking.

[Tyg-g]

Safety sac_scale>=demanding_mountaineerin_trails (T3) needs special consideration and physical fitness. Via ferratas also need that, except of grade A, via_ferrata_scale>=2 (my opinion). These can be considered not safe walking.

The not safe paths should be rendered distinguishably, as it represents a safety issue, and needs special consideration and prepataion before the trip. On the other side it should not be hidden, as there IS something. Hiding would propose troll tagging.

highway=via_ferrata without via_ferrata_scale>=2 could default to not safe.

Rendering

• Not safe paths could be rendered red (possibly with exclamation marks), normal path with brown, for example.
• Via ferratas with dots and ladder pictograms.
• Climbing routes with dots and climber pictogram, or only a pictogram as these are usually vertical anyway.
• trail_visibility= is not a safety issue, so I don't discuss it. I doesn't need to be shown.

[Adamant36]

trail_visibility= is not a safety issue

Not to be pedantic or suggest that trail visibility should be rendered, but wouldn't it affect your ability to see if the via ferrata is safe ahead? I ask because there are 71 instances of highway=via_ferrata + trail_visibility and I don't see why else there would be unless trail visibility has some kind of effect on safety or something.

[Tyg-g]

Well, via ferrata means there are iron ladders, steps and/or cables along the way. These objects are visible.

As I understand, trail_visibility is for how easy it is to find your way, if you can see the path with your eyes. Check the pictures in Key:trail_visibility. There are less or no trails left on surfaces like bare bedrock, scree, shingle, streambed with big rocks, so you have to use some orientation skills. These situations call for trail_visibility.

[brycenesbitt]

I think the bigger picture problem is that there's good process and discussion on tagging, but considerably less of the same debate on rendering. The two are connected.

Trying to bring all the major map rendering folks and off line app folks together on these issues is probably the only way to make progress. Tagging does follow rendering: for better or worse.

Carto is often the leader on rendering innovation, but it's far from the only place that rendering decisions are made.

[jeisenbe]

iron ladders, steps and/or cables

It would be nice if there was a consistent way to tag each of these specific features. In non-European contexts it is quite common to find bamboo or wood ladders and ropes on difficult paths, but the term "via ferrata" is unknown:

Small wood log bridge. This one at least has a "handrail".

Wood ladder.

Kid on right as at the top of a vertical. wood ladder. Very steep muddy steps

Dangerous log crossing, no protection:

This very famous and popular climb up Half Dome in Yosemite National Park has steel cables: https://www.openstreetmap.org/way/435976809 - but is not tagged as a via ferrata in any way, probably because most Americans have never heard the term:

The via ferrata tags are almost exclusively used in Europe, around the Alps and Pyrennes: https://taginfo.openstreetmap.org/tags/highway=via_ferrata#map

https://taginfo.openstreetmap.org/keys/via_ferrata_scale#map

Until these tags become adopted in other continents, it is unreasonable to consider that there is community consensus around this tagging method.

I'd suggest using the Proposal process or discussing on the Tagging list, and then asking editors like iD and JOSM to support a consistent set of tags that define barriers and assistive devices.

We do render stiles and steps, so we might consider rendering ladders, cables, ropes, etc, if there was a clearly established tagging method.

[matkoniecz]

I generally agree but I want to nitpick a bit:

This very famous and popular climb up Half Dome in Yosemite National Park has steel cables: https://www.openstreetmap.org/way/435976809 - but is not tagged as a via ferrata in any way, probably because most Americans have never heard the term:

per https://en.wikipedia.org/wiki/Half_Dome#Hiking_the_Cable_Route

The final 400 ft (120 m) ascent is steeply up the rock between two steel cables used as handholds.

It is not a via ferrata.

via ferrata requires support for affixing climber to a supporting equipment

A via ferrata is a climbing route that employs steel cables, rungs or ladders, fixed to the rock to which the climbers affix a harness with two leashes, which allows the climbers to secure themselves to the metal fixture and limit any fall.

The via ferrata tags are almost exclusively used in Europe, around the Alps and Pyrennes

If https://en.wikipedia.org/wiki/Via_ferrata is correct and via ferrata are existing primarily in Europe then it should not be a big a problem (we would render railways even if only one continent would have them)

---

I'd suggest using the Proposal process or discussing on the Tagging list, and then asking editors like iD and JOSM to support a consistent set of tags that define barriers and assistive devices.

+1 (skipping proposal process, just using the tags and asking for support in editors also may work, but it will likely take longer time and it is higher risk that organically grown tags will turn out problematic in some way)

[Adamant36]

It would be nice if there was a consistent way to tag each of these specific features.

There's the approved key ladder and there is also the approved key assisted_trail. I guess they never got widely adopted though. Probably because of the favoring of via ferrata by European mappers.

Personally, I've never seen either of them mentioned anywhere. I don't think they are supported in iD Editor either. i'm especially surprised by the low numbers of assisted_trail. Since it's really the clearest and most universal way to tag these types of trails. At last compared to via ferrata. I think the way to go forward is to get support for them in iD Editor and then depreciate via ferrata in favor of assisted_trail.

[Sjord]

depreciate via ferrata in favor of assisted_trail.

I think assisted trails and via ferrata's are sufficiently different to tag them differently. They correspond to my easy and hard via ferrata's from my earlier comment. If you are fit and planning a hike, you may be OK with an assisted trail, but you can't do a via ferrata without proper equipment.

However, the point of this issue is to render difficult paths differently, and in that view in makes sense to render both via ferratas and assisted trails as difficult.

[Adamant36]

think assisted trails and via ferrata's are sufficiently different to tag them differently. They correspond to my easy and hard via ferrata's from my earlier comment. If you are fit and planning a hike, you may be OK with an assisted trail, but you can't do a via ferrata without proper equipment.

I disagree with that. In your example of the route with the rope along the stream, there's really no way to tell just from looking at picture that people need special equipment to get across it. In fact, it looks like someone could navigate either without bringing special equipment by either holding the rope or hugging the wall. The same goes for a lot of other examples of via ferrata's I've seen.

There's plenty of instances of paths with ropes, rungs, ladders, or the like that usage of them is optional. Especially these days with free climbing becoming more popular. While we could all agree they are all "assisted trails", we can't agree that they are all via ferratas. I'm sure some would be, but not all of them and just saying they are because there's a rope in the picture, or because a certain percent of people might need to bring special equipment, isn't a good metric to decide these things or to tag trails based off of.

I can 100% guarantee that if rendering of the via ferrata tag is supported that it will just become a catch all tag for any trail with a rope or whatever. Both due to ignorance by anyone outside of specific areas of Europe as to what they are and because of how presets work. Even if they were just rendered as a supplement to rendering assisted_trail.

It would also just be redundant to render both. Especially when via ferrata is essentially just an extremely regional term that means the same thing as "assisted trail."

That said, there's no reason people can't tag them together or use something like assisted_trail=via_ferrata. I just don't think there's a valid reason to render both and that it will cause problems if we do.

[imagico]

I would suggest everyone to stop discussing tagging here. As interesting and important as that might be it does not bring us any forward here. If and when there is a verifiable tagging that is being used consistently by mappers to differentiate paths regarding difficulty in some form suggestions on how to show that in rendering would be welcome. Same for rendering the local presence of technical aids in some form.

[Adamant36]

If and when there is a verifiable tagging that is being used consistently by mappers to differentiate paths regarding difficulty in some form suggestions on how to show that in rendering would be welcome.

So a verifiable approved tag, assisted_trail, shouldn't be rendered because of discussion and people in an extremely specific area using a different tag. Alright. I guess that's why it's better just to go with the approved, clearer tag from the start.

[imagico]

If by 'approved' you mean something has successfully run through a proposal process then no - this has never been a significant criterion for rendering something here. A proposal process is a means to help designing tagging ideas that have the potential to gain broad support and adoption but it does not guarantee that. We need to look if a tag is actually being adopted by mappers.

[jragusa]

Could we consider, at least, the rendering of highway=path + ladder=yes (1784 times) in a similar fashion than highway=steps ?

[Adamant36]

If by 'approved' you mean something has successfully run through a proposal process then no - this has never been a significant criterion for rendering something here.

Where did I say anything about it being a "significant" criterion? I said it's a criterion and it is. I didn't say it was the only or most important thing though. But echoing what @jragusa just posted it would be worth at least rendering the ladder key IMO and I'm not going to say it being approved doesn't have anything to do with my opinion. It factored in for me plenty of times when I was deciding what to do PRs for also. Again, it wasn't a significant factor, but I never claimed it was.

Although, if it was a choice between rendering an approved key with similar numbers to a none approved one for the same thing, I'd go with the approved one. That could just be me though. I'm not the one that always goes off about discussing things on the mailing list before they are rendered and you have to do that for a tag to be approved. Just from that alone you can't say an approved tag doesn't carry more weight then a non-approved one when it comes to rendering.

[matkoniecz]

Could we consider, at least, the rendering of highway=path + ladder=yes (1784 times) in a similar fashion than highway=steps ?

Sounds like a good idea in general (assuming that it is the preferred tagging, rather than highway=steps + additional tags).

But ladder=yes usage is quite low. But at least it crossed 1000 barrier...

[SomeoneElseOSM]

What's the current state of the core "Stop rendering extreme mountain paths without giving indication of difficulty" request here?

I ask because a question has cropped up recently on talk-gb: https://lists.openstreetmap.org/pipermail/talk-gb/2022-February/028536.html . Is the current thinking to:

• Stop rendering extreme mountain paths
• Continue rendering extreme mountain paths but with some new visual cue (pull requests welcome)
• Continue rendering extreme mountain paths with no visual cue to distinguish from any other highway=path or highway=footway?

[matkoniecz]

Right now noone has a really good idea how to improve status quo and it will likely continue unchanged in the near future.

Though maybe at least tagging situation improved since it was being discussed?

[imagico]

This still hinges on the lack of any widely accepted and verifiable tagging. The continued strong use of tags like trail_visibility and sac_scale is testimony to there being need for tagging difficulty of paths, but the lack of a proper tagging scheme that properly separates and rates the verifiable risks leads to mappers trying somehow to condense all the different dimensions of difficulty into one subjective rating and then map that to an sac_scale class. Which can mean there are classic alpine dangers (which has multiple dimensions already), or that the path is flooded, or that it is overgrown and you need to cut through weeds to get through, or just that it is a long route in a dry area without water so you need to make sure to be sufficiently equipped for that. Or various other things.

If any tagging crystalizes out and becomes widely used that avoids these issues - either by being part of a scheme that allows specific tagging of all kinds of verifiable risks or by being consistently used by mappers only for specific aspects - i would be in support of trying to indicate such tagging in our style. I would probably not consider it wise to just hide paths based on such a tag - because that would likely invite it being used as a render_in_the_map=no tag and would negatively affect mapper feedback (mappers might think: There is a path missing there just to realize that it is already mapped with a classification that hides it). And even a path that you don't want to use can be useful for orientation when walking on other paths. But we could try rendering such paths in a way that clearly indicates: This is not in any way comparable to a normal path.

Keep in mind that we have already a number of other issues with our current rendering of paths and footways that should be considered with any kind of styling changes in this field - see #1748, #1750, #1793, #1765 and also #4097. #4465 mentions some ideas how to indicate additional classifications on paths as well.

[hungerburg]

Subjectivity is not in the mind of the user, but it is in the abilities of the user. The SAC scale is based on a set of abilities of a class of hikers commonly found in the Swiss Alps. It is not for the disabled or whatever you may come up with. It has nothing to do with cutting through weeds. SAC scale is not your Swiss Army Knife to map all the difficulties you may have to conquer on a path anywhere in the world. Lots of the paths mapped with SAC scale are fully worthwhile being shown in OSM-Carto. After all, OSM-Carto is not displaying a sandpit, of only the paths you can traverse in you ball-room-apparel without any risk of wrenching your ankles. That said, a way to tell the alpine+ sac tagged paths apart from such sandpit paths may be welcome. That said, sac_scale is not a tag to deter a router, but it is an instruction for the user of the data on some prerequisites/abilities required. And BTW, in my mind, informal paths cannot ever have an sac_scale, as such would require an administration to watch the path.

[imagico]

@SomeoneElseOSM - it would help if you'd more specifically articulate your :-1: in words.

@hungerburg - i think you do not realize that use of sac_scale is decidedly not limited to alpine areas and is used in flatland environment or in other climates to indicate a very broad spectrum of risks and dangers which are partly verifiable and partly not and therefore no one interpreting the data knows how to interpret that other than mapper who has tagged this considers this path to be dangerous in a way comparable to the alpine dangers of a typical path with sac_scale=x in an alpine environment (despite these very different kinds of danger not being comparable at all). And that use is not an exotic misuse of the tag by a few mappers, it is fairly widespread. trail_visibility is somewhat better because it applies more universally independent of the setting but also suffers from the problem that it aggregates multiple dimensions in a closed classification system: The local definition/visibility of the path mapped and the clarity/ambiguity of the route - the latter further divisible into clarity of trail marking and the visibility of the route independent of markers.

The ultimate cause of these problems we have IMO is that back in the days when all these tags were introduced (just as things like tracktype) people had in mind the idea to directly render a map based on them based on the belief that they would consistently apply this tag based on their personal competent judgement in the function of both mapper and map designer and that other mappers would do the same - resulting in a simple high level abstract modeling with an aggregate, one-dimensional and closed classification. Over the years of mapping in OSM with an expanding and increasingly diverse world wide mapper community we have learned that this does not work - for the reasons explained. That is natural, collectively we have learned while OSM grew what works and what does not. But the tags and their use of course persist. That however does not mean things cannot change - the best example is again tracktype - see:

https://taghistory.raifer.tech/#***/tracktype/&***/surface/

Until 2009 tracktype and surface tags were mapped with similar dynamics but afterwards surface became much popular. A year ago when i opened #4322 tracktype was tagged still 1.48 times as frequently as surface on highway=track - today it is just 1.39 times. It is quite likely that even if we continue to support tracktype on tracks in favor of surface in a few years surface will become the more widespread secondary characterization of tracks. In other words: A semantically clearer and better defined tagging can displace an established closed aggregate classification system in wide use and supported by data users.

We should keep these mechanisms in mind when thinking about interpreting tags like sac_scale.

[SomeoneElseOSM]

it would help if you'd more specifically articulate your 👎 in words.

@imagico I was trying to keep the number of words down, actually... The main reason that I added that 👎 was that your comment didn't really answer my question. You seem to say that people are suggesting the use of sac_scale as a "general difficulty" tag to cope with might be flooded, overgrown etc., which I don't believe I've seen people do, and linking to a laundry list of "other things people have suggested about footpaths" doesn't really help either.

To summarise what it sounds to me like your views are - you don't think it's a good idea to "Stop rendering extreme mountain paths", but would be happy to "Continue rendering extreme mountain paths but with some new visual cue", but don't believe that OSM has tagging that supports that right now?

[imagico]

Thanks for the clarification - the thing is that my general views on rendering of rendering of extreme mountain paths in a map independent of mapping practice in OSM are not really of interest on this issue tracker. If you want to know, and ignoring the subjectivity of 'extreme' for the moment and just projecting my personal understanding of that term: 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. But as said: This is for my personal preferences for a hypothetical map for my personal use created from ground up based on my own specifications.

This project has a different aim and different goals and we need to take into account different considerations than my map design preferences for my personal use. I understand my response is non-satisfying in light of the concern raised (here and on talk-gb: That the non-differentiated display of paths is problematically misleading in some cases). But even with that in mind i remain steadfast in my position that it is not our place to lead mappers into mapping things in a certain way based on what we consider being desirable mapping practice. We should be on active lookout if a tagging crystalizes out that shows clear indications that it avoids the issues of the existing tagging practice in this field.

[hungerburg]

@imagico Indeed, I am on a crusade against abuse of SAC scale to denote all kinds of difficulties, I had a fight with the "ghost" who started this issue, because he modified the wiki to suggest this abuse, thereby turning sac_scale into a troll tag (you cant walk here, but you can do some alpine hike here.)

@all Still, my plea remains, to make certain paths appear different on the standard view on the OSM data. Perhaps one could use one and the same rendering for _sacscale=alpine, informal=yes and _trailvisibility=bad|horrible|no tagged paths?

Several people here suggested dotted line, as this is well known from printed maps. The OSM-Carto signature of a path is already close to that, so maybe, just add more spacing? Below a mockup with every other dash/dot removed in the central section:

Does that seem workable? This is a new, unique signature not to be mistaken for anything else. I would not mind the path being close to invisible on _barerock, that just mirrors OTG truth :)

[imagico]

No, interpreting a very specific tag combination as code to achieve a certain rendering result without that combination being consistently used to express any distinct real world meaning would go against our goals to be understandable for mappers. In principle the idea to aggregate several tags into an overall score to use in rendering is a possibility. However due to the additional complexity of such an approach and because it is therefore less intuitive for mappers there would need to be higher standards regarding how well established and consistently used the tags are than there would be if a tag is just used as is to decide on rendering. And we have already established in #4365 that informal=yes is - as documented - inherently non-verifiable.

I have already commented on the styling idea in https://github.com/gravitystorm/openstreetmap-carto/issues/4365#issuecomment-816174104

[SomeoneElseOSM]

@hungerburg What you suggest seems pretty sensible and is pretty close to what I'm already doing in a different map style.

@imagico What do you mean by "without that combination being consistently used to express any distinct real world meaning"? Each of sac_scale, informal and trail_visibility have a clear, well-documented real world meaning - are you saying that mappers currently misuse them, or would misuse them if they had a rendering effect, or something else?

[imagico]

What i am saying is that none of these three tagging schemes is used globally with a meaningful level of consistency that would on a global level allow determining meaningful real world knowledge from data with those tags.

A few hints on each of the tags:

• sac_scale: is documented to provide an aggregate of specific dangers of hiking in alpine environments but is evidently used also in non-alpine environments with obviously different semantics - which are unclear and, from looking at the data in a few places, evidently vary.
• trail_visibility: aggregates - as pointed out above - multiple dimensions into an overall score. The classes meant to be used are defined only through example images and vague English language descriptions (mostly, often, sometimes, good, basic, advanced, excellent) which are themselves not defined in any way. The use of the tags is - from where i can assess that based on local knowledge - accordingly not very consistent and usually seems to reflect a subjective assessment on how well articulated a path is in its environment, often off by ~2 classes relative to the sample image on the wiki and often not matching at all the verbal descriptions. There are >10k combinations of trail_visibility=bad and sac_scale=hiking which seems extremely odd as a combination.
• informal: don't get me started on that one. Yes, in an urban setting or an accurately maintained nature reserve in central Europe that might often be a distinction that seems clear. But the vast majority of the world is not like that. I have not really looked at how this tag is systematically applied but i simply doubt that it is a meaningful practical distinction in 90 percent of the world.

And yes, if we'd render those tags despite these shortcomings mappers would - also due to the lack of other meaningful guidance - adjust their mapping to achieve the rendering result they would consider appropriate.

[hungerburg]

Bordering the off-topic, a bit of history: _sacscale and _trailvisibility sprang from the same proposal. That shines some light on the contrived values of the _trailvisibility enumeration: Both are taken from the same source, the SAC hiking scale, trail visibility there is just another trait apart from hazards and equipment required in their mixed bag of discernibles. An important one, for sure! Loosing track is the number one reason for emergency calls in hiking. For some overblown pedantry (my opinion) it got separated in a late RFC state of the proposal, so one could e.g. mark sections of a T1 hiking trail with a _trailvisibilty of NOT excellent, where it crosses a pasture and people stray from the center line for example and not much can be observed on the ground. Sooner or later it took on a life of its own. While around my home base, _sacscale proves quite reliable, _trailvisibilty results are disheartening.

I do not think though, that this explains the number @imagico mentioned above. My guess, where most of the oddities stem from: users mapping informal paths and tagging sac_scale=hiking, and trail_visibilty too, as both are twins. Maybe, because they use them for walking their dogs or other recreational rambling, maybe even to make routers put a penalty on them, an alias for wheelchair=no so to say (something that works with at least graphhopper or OSRM, I cannot remember now which or both.)

Seen this way, this speaks for treating informal, _sacscale and _trailvisibilty the same. Of course, it does not bring the whole of it in any way closer to hard facts. Speaking of backcountry paths though, there are not many hard facts: E.g. I removed several width=? from paths, even though this attribute should describe an exactly quantifiable property - it is so often just plain wrong, not even when taken as an average - actually, it made me suspect width a hidden code for mountainbikability.

Not much counter-lift on the break pedal, that is :( All the while, people use combinations like "access=no+foot=yes" to get the desired rendering. That might make another issue.

[chaot4]

I came across this issue because I wanted to map the access path to the alpine climb on "Kleine Fermeda" with the tag sac_scale=demanding_alpine_hiking. This path consists of a well-visible but exposed path over a steep meadow where slipping might lead to a fatal fall and some easy scrambling where, again, slipping is fatal with quite a high probability. So, I certainly don't want it to be rendered like a normal path as it might endanger people. Especially, this path leads to a ridge that is very well-known for how scenic it is and people might try to access it via this path if they see it rendered on a map.

In Komoot and also OpenTopoMap paths with sac_scale greater than some value (I guess 4?) are already rendered differently. I think the suggestion of @hungerburg makes a lot of sense and is also similar to how OpenTopoMap and Komoot solve this issue. The path would then still be shown but it is clear that it is not a normal path.

Is there any specific reason why this is not done yet? It seems like a good compromise to still show the path but in a different style. I just have a very bad feeling adding a dangerous path to OSM when it is rendered as normal path in the default style.