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

[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 https://github.com/gravitystorm/openstreetmap-carto/issues/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/

[simonpoole]

There is actually a current discussion on the German forum on the topic https://forum.openstreetmap.org/viewtopic.php?pid=709993#p709993

A classic example of the mess we've got in to is https://www.openstreetmap.org/way/360591032 I've previously argued that we shouldn't render via ferratas , I now think handling all of these cases with a broad brush (probably in preprocessing) would be a better approach. Rendering could simply be same color as current path/footway rendering but with wide spaced dots or similar.

The broad brush would cover at least: anything with sac_scale > T2 (likely best to test explicitly for the string values for T1 and T2), anything with via_ferrata_scale, anything with climbing:grade* and highway=via_ferrata .

[imagico]

The problem about sac_scale is that it is not really verifiable and the criteria documented are specific for mountain areas and alpine hazards. I have looked at sac_scale use in the past with the idea of using it for rendering differentiation and came to the conclusion that it is not really consistently used outside mountain areas. If you look at use of sac_scale in flatland areas you can see that and rendering sac_scale > T2 in a distinct way would probably further increase use of sac_scale=demanding_mountain_hiking as a general indicator for this path is rough in some way - which can be due to exposition and mountain hazards but can equally be due to overgrowth, mud etc.

Using different tags as criteria for a common rendering is a possibility but each of the tags should be verifiable and consistently used and the criteria should be kind of complete - if they are meant to indicate a path being hazardous in some way the criteria should cover all the most common types of hazards so mappers have no incentive to abuse tags meant for some type of hazard for others.

[simonpoole]

@imagico but treating sac_scale > T2 as an indication of "there is something difficult about this and you should only use it if you know what you are doing" even if it is actually "just" an overgrown path in a jungle where using sac_scale is nonsense, would still achieve the goal of differentiating such ways from other stuff.

Doing so does rewards wrong tagging, which is however what we are doing with the current rendering in an even worse way. That effect can be, as you say, reduced by including correct tagging for the category too, providing positive feedback. In this case likely trail_visibility, some of the surface tags and perhaps even some hazard values.

[mboeringa]

I have looked at sac_scale use in the past with the idea of using it for rendering differentiation and came to the conclusion that it is not really consistently used outside mountain areas.

sac_scale shouldn't be used outside mountain areas. If it is, it is a tagging error, and should be removed. That the sac_scale is not to be used outside mountainous areas is explicitly stated on the Wiki page:

https://wiki.openstreetmap.org/wiki/Key:sac_scale

As this is a more or less direct translation from the Swiss Alpine Clubs hiking difficulty assessment, this is generally suited for mountainous areas. For non-mountainous regions, other difficulties and requirements are present and therefore other scales should be used. E.g A way in a forest that is difficult to walk because of muddy ground and trees or bushes making walking difficult does not classify for T2.

I have removed erroneous stuff like this in the Netherlands, where I noticed an area being tagged with sac_scale=hiking(T1). T1 is essentially any path ("Requirements: None"), and senseless tagging outside mountainous areas.

[kocio-pl]

Thinking about visual representation, maybe we could use some kind of shields or the pattern with small "x" for example.

[jragusa]

On French topographic map, there is no difference with other hiking paths and dotted lines are used when the path is not correctly constrained (over glacier, for example the Mer de Glace). On Swiss map, only well defined path are indicated so you can have interrupted path in some elevated areas (example).

Hence, it seems that official topographic maps do not consider the difficulty or hazards as a criteria to display or not a path and only the trail_visibility criteria is considered. By the way the sac_scale tag is really subjective. Beginners would consider a given path more difficult than experts and vice versa. It's not officially constrained such as maxspeed for highways.

[matkoniecz]

if they are meant to indicate a path being hazardous in some way the criteria should cover all the most common types of hazards so mappers have no incentive to abuse tags meant for some type of hazard for others

I agree, sac_scale should not be supported alone. There must be a way to tag common hard/complicater/dangerous situations outside mountains (to avoid promotimng sac_scale usage outside mountains).

It may require inventing new tagging schemes or documenting existing ones.

[SomeoneElseOSM]

I agree with most or all of what's been said above (including where sac_scale makes sense and where it doesn't). If it helps, this was what I did in a similar style to suppress some paths based on both sac_scale and trail_visibility.

However, there will still be a problem with paths added to OSM other than from survey - this one on Everest is an example. Without any extra tagging, that's going to appear as a "normal" path. I'd suggest that's really not the fault of this map style, and that we need to try and educate mappers about "what it is sensible to add to OSM" and "what other tags to consider" (both offtopic for this repository, obviously).

Given that this style tries to be a "general" map style I'd be surprised if there was much that could be done e.g. with dot spacing to show "difficult" mountain paths etc. - perhaps better to try and redirect potential users at a more specific style for them?

[jidanni]

I also felt that it was always important to render some international borders, https://github.com/openstreetmap/openstreetmap-website/issues/2002 .

[matkoniecz]

I am not sure how international borders are supposed to be on topic of potential rendering of mountain path difficulty.

[jidanni]

It has to do with policy regarding (not) removing hazards from the map.

[matkoniecz]

Each problem should have its own issue, it is generally a poor idea to start discussion about a sort of related topics.

But anyway this map style renders all mapped administrative borders.

[jeisenbe]

Dan,

I believe you are concerned about two different map styles, the Cycling map and Transport map on Openstreetmap.org, but this forum is for the “Standard” style, called Openstreetmap Carto, only. And this style already renders international borders

Sorry, Joseph

On Mon, Sep 24, 2018 at 8:44 AM 積丹尼 Dan Jacobson notifications@github.com wrote:

It has to do with policy regarding not removing hazards from the map https://wiki.openstreetmap.org/wiki/Talk:Featured_tile_layers/Guidelines_for_new_tile_layers .

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/gravitystorm/openstreetmap-carto/issues/1500#issuecomment-423856830, or mute the thread https://github.com/notifications/unsubscribe-auth/AoxshNeb1pmI24ler5EjuPPsPZMtpuxiks5ueBzbgaJpZM4EI_fr .

[alantrick]

Hence, it seems that official topographic maps do not consider the difficulty or hazards as a criteria to display or not a path and only the trail_visibility criteria is considered.

For what it's worth, that's probably good enough 95% of the time. By and large, routes that "extreme" or whatever you want to call it also have really bad/no "trail visibility". Those that do have good visiblity (like via ferratas) are obvious and not the sort of thing that would sucker a newbie.

In short, I strongly support the idea of rendering different values of trail visibility differently (much like track_type or whatever it is for highway=track).

Edit: also trails with poor visibility are generally not good for inexperienced folk to follow even when they're not on the mountains. Getting lost on an old jungle trail would not be fun.

[brycenesbitt]

This is such an issue tied between tagging and rendering. Would people support the idea of creating rendering discussion group -- or notification group -- with the goal of having ongoing communication in a focused manner with the people actively designing rendering.

Tagging has a group, rendering does not.

[Adamant36]

@brycenesbitt, this is it isn't it? I mean, there's a bunch of discussions here about rendering that anyone is free to join. I don't think separating conversations about rendering from the place where issues are created and resolved would really work. Since no rendering decision is done in isolation and this is where everything related to rendering is tested, referenced, archived etc. Anyone is free to create an issue if they don't agree how something is rendered to. Sometimes, things will be rejected though. That's just how it goes. There's a lot that either can't be done or isn't realistic to implement, even if it could be.

[systemed]

this is where everything related to rendering is tested, referenced, archived

No, this is where everything related to openstreetmap-carto is discussed. Other renderings are available. The recent (and relevant) case at https://www.cbc.ca/news/canada/british-columbia/michael-buckingham-vancouver-hiker-rescued-north-shore-crown-mountain-1.4857646 looks like it may have been a maps.me rendering issue, for example.

A forum for cross-project rendering discussion might be interesting, though given that the cross-project routing list is very underused, maybe not.

[matkoniecz]

Would people support the idea of creating rendering discussion group -- or notification group -- with the goal of having ongoing communication in a focused manner with the people actively designing rendering.

Note that this completely offtopic in issue about potential rendering change of paths in openstreetmap-carto map style.

[Adamant36]

@systemed, good point. I assumed the person meant a rendering discussion about this style only, or it would have been brought up in the general OpenStreetMap forums or somewhere else. Since it is kind of off topic here.

[SomeoneElseOSM]

(apologies for somewhat offtopic continuation)

I suspect there will be examples (both in this style, and others) where something does legitimately get displayed on a map but isn't safe to use. As an example, in another style I do make an attempt to not show paths that people have tagged as "particularly difficult", but the whole purpose behind that map style is to show England and Wales public rights of way, and there are examples of those that can be dangerous at times. I put a specific caveat in an "about" page about that. Maybe something similar would work for OSM Carto, but there isn't really "per style" stuff at osm.org other than the map key where it could go.

[matkoniecz]

The recent (and relevant) case at https://www.cbc.ca/news/canada/british-columbia/michael-buckingham-vancouver-hiker-rescued-north-shore-crown-mountain-1.4857646 looks like it may have been a maps.me rendering issue, for example.

no, it was a different problem

His companion would eventually turn back, but Buckingham, an avid hiker, pushed on — planning a circular route using the Maps.me app on his phone.

He planned to descend by dark, but the hike took longer than he expected, because he says the app didn't take into account the steepness of the terrain.

It was not a rendering problem, it was ETA problem (that I reported in 2017 at https://github.com/mapsme/omim/issues/6980 ). What turned into near disaster when combined with hiker who was underequipped (missing proper maps) and unexperienced.

---

Arghhh, and now I should ban myself for blatant offtopic.

[polarbearing]

Blindly trusting an electronic gadget in a high-risk situation without having tested the behaviour before in a safe environment is a lack of skills. Calculating the walking time from the height profile is elementary in Mountain Skills, and every instructor tells you the factor for time per altitude.

[5Boggis]

Dear all, maybe the topic is not very new any more. But it is still an open topic. People will continue tagging via ferratas as path, as long as via ferratas are not shown on the map. At least in Europe via ferratas (Klettersteige) are very popular. There is plenty of literature about them. In the open nature there are signs to show the way to them. Maybe it helps to have a look on an old-style, analog paper hiking map. All of them show the via ferratas. But they are shown in a different style than a normal hiking path. Some editors of paper hiking maps use continued lines or dotted lines for hiking paths, ++++-lines for via ferratas. That is basically what I would expect from an OpenStreetMap.org map also. The difficulty of a via ferrata is very subjective, but this should not be a criteria to suppress rendering of the via ferrata. It is definitely not the mappers, but the hikers responsibility to get proper information about the degree of difficulty that he dares to do. Not showing hiking paths leads to workarounds that may be misleading. In my eyes this is much more risky than showing the hiking path, and showing it in a way that makes clear that it is a via ferrata.

[jeisenbe]

TL/DR:

• The best way to tag a via ferrata is not established.
• trail_visibility and sac_scale are more popular tags which we could use, but they also have problems with verifiability

There are several unresolved problems:

• Is highway=via_ferrata or highway=path + another tag the preferred way of mapping?
• Are via ferrata actually more dangerous or difficult than the average path in a mountainous area?
• We have limited options for varying the rendering. Should we show trail visibiliy, sac scale, or via ferrata scale?
• How should difficult or hard to see paths be mapped in non-mountainous areas?

1) How should via ferratas and similar paths be mapped?

Re: highway=via_ferrata (wiki) - this tag is now used 1,132 times, which is not very much compared to other highway=* values.

Compare with via_ferrata_scale=* is now used 1900 times. So highway=path or highway=footway + via_ferrata_scale= or via_ferrata= is an equally common way to map a via ferrata, see: https://overpass-turbo.eu/s/Ihr

Almost half the values of via_ferrata_scale=* are >= 3 and a clear majority are >=2 (https://taginfo.openstreetmap.org/keys/via_ferrata_scale) - which might merit a special rendering.

via_ferrata=* is used 248 times, some of which are "end", "start" and "cable" (i.e. subtags).

I hesitate to work on this after looking at this map of usage. It appears 99% of Via Ferratas are mapped in Continental Europe, suggesting that this tag has not been adopted in Japan, North America, New Zealand and other countries that have developed hiking and climbing infrastructure:

There is also an approved proposal for safety features to be added to highway=path, including ladder=*, rope=*, rung=* and assisted_trail=* - combined these have been used 2,778 times as of April 2019.

Overall, I'm not convinced that highway=via_ferrata is clearly preferred to highway=path + other tags. I believe this should be discussed again.

2) Sac_scale vs trail_visibility

Both of these tags are orders of magnitude more popular than any of the via ferrata tags:

However, sac_scale is only intended for use in mountainous areas. How should challenging paths and trails be tagged in flat areas?

Many of the paths in the lowland rainforest of Indonesia are just as challenging as the high mountain paths. You trade the risks of cold weather, steep slopes, rushing rivers and rickety wooden ladders for crocodiles, swamps, lightning storms, broken bridges and malaria.

The tag trail_visibility can be used anywhere, but is somewhat subjective. The values are not very clear.

It would be difficult to render differences between both of these scales in this style, where we already show highway=track, highway=footway, highway=cycleway and highway=bridleway as dashed lines in various colors. It might be possible to change the path/footway rendering style, but there would still be limited options for showing additional information.

[pnorman]

Thanks for the detailed writeup.

I hesitate to work on this after looking at this map of usage

Agreed.

It would be difficult to render differences between both of these scales in this style

Yes. It will end up looking like an unpaved footway.

[mboeringa]

Are via ferrata actually more dangerous or difficult than the average path in a mountainous area?

A "Via ferrata" is a very specific type of mountain path, secured by permanent ropes and cables and requiring additional safety equipment. This is not an ordinary hiking path you can do with a good pair of hiking boots and walking poles, see the Wiki:

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

"A via ferrata is a route equipped with fixed cables, stemples, ladders, and bridges in order to increase ease and security for climbers. These via ferrata require equipment : climbing harness, shock absorber and two short lengths of rope, but do not require a long rope as for climbing."

Thus, do not confuse it with an ordinary mountain hiking path, or try to redefine it as something else.

From my ArcGIS Renderer for OpenStreetMap, how I render it (admittedly no trail visibility or surface rendered here, I find sac_scale and via_ferrate_scale way more useful, as scales specifically designed for hiking and climbing):

I hesitate to work on this after looking at this map of usage. It appears 99% of Via Ferratas are mapped in Continental Europe

I think that is mainly because Europe probably still has the most developed hiking and climbing infrastructure and the most dense due to the highest population density. Also, sac_scale and via_ferrata_scale originate as European scales. That said, it should be no hindrance to adoption anywhere else. A key name like "sac_scale" is just a name to describe a class of something. After all, nobody outside the English countries, knows about "amenities" either, yet we can all understand what it means and use it since it is described on the Wiki.