Openstreetmap-carto: Stop rendering extreme mountain paths without giving indication of difficulty

0

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

ghost picture ghost  ·  26 Apr 2015

Most helpful comment

6

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

via-ferrata-vs-scale

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:

via-ferrata-map

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.

via-ferrata-vs-safety-features

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:

sac-scale-vs-visibility-vs-via-ferrata-scale

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.

jeisenbe picture jeisenbe  ·  26 Apr 2019

All comments

0

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.

matkoniecz picture matkoniecz  ·  26 Apr 2015
0

@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...

mboeringa picture mboeringa  ·  26 Apr 2015
0

@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.

ghost picture ghost  ·  26 Apr 2015
1

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.

sac_scale_100perc
sac_scale_125perc
via_ferrata_100perc
via_ferrata_125perc

mboeringa picture mboeringa  ·  27 Apr 2015
0

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.

ghost picture ghost  ·  28 Apr 2015
0

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

matkoniecz picture matkoniecz  ·  2 Aug 2015
0

Are there any hiking maps using this tag for rendering?

pnorman picture pnorman  ·  2 Aug 2015
0

@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

ghost picture ghost  ·  2 Aug 2015
0

@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.

matkoniecz picture matkoniecz  ·  2 Aug 2015
0

@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.

ghost picture ghost  ·  2 Aug 2015
2

@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.

fkv1 picture fkv1  ·  2 Sep 2015
1

On Sun, Aug 2, 2015 at 3:40 AM, Mateusz Konieczny [email protected]
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.

brycenesbitt picture brycenesbitt  ·  2 Sep 2015
0

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.

matkoniecz picture matkoniecz  ·  2 Sep 2015
0

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.

brycenesbitt picture brycenesbitt  ·  2 Sep 2015
0

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!

kocio-pl picture kocio-pl  ·  3 Sep 2015
0

@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 picture ghost  ·  3 Sep 2015
0

@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.

ghost picture ghost  ·  3 Sep 2015
0

Are there any hiking maps using this tag for rendering?

Does anyone have any OSM-based examples of this?

pnorman picture pnorman  ·  15 Dec 2016
0

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.

brycenesbitt picture brycenesbitt  ·  15 Dec 2016
0

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.

Ircama picture Ircama  ·  15 Dec 2016
0

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.

pnorman picture pnorman  ·  15 Dec 2016
0

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.

Ircama picture Ircama  ·  15 Dec 2016
0

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.

pnorman picture pnorman  ·  15 Dec 2016
0

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 .

simonpoole picture simonpoole  ·  4 Aug 2018
0

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.

imagico picture imagico  ·  4 Aug 2018
0

@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.

simonpoole picture simonpoole  ·  4 Aug 2018
0

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.

mboeringa picture mboeringa  ·  4 Aug 2018
1

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

kocio-pl picture kocio-pl  ·  4 Aug 2018
0

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.

jragusa picture jragusa  ·  5 Aug 2018
0

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.

matkoniecz picture matkoniecz  ·  5 Aug 2018
0

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?

SomeoneElseOSM picture SomeoneElseOSM  ·  6 Aug 2018
0

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

jidanni picture jidanni  ·  23 Sep 2018
1

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

matkoniecz picture matkoniecz  ·  23 Sep 2018
1
jidanni picture jidanni  ·  24 Sep 2018
0

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.

matkoniecz picture matkoniecz  ·  24 Sep 2018
3

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
.

jeisenbe picture jeisenbe  ·  24 Sep 2018
0

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.

alantrick picture alantrick  ·  18 Oct 2018
0

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.

brycenesbitt picture brycenesbitt  ·  18 Oct 2018
0

@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.

Adamant36 picture Adamant36  ·  18 Oct 2018
0

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.

systemed picture systemed  ·  18 Oct 2018
1

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.

matkoniecz picture matkoniecz  ·  18 Oct 2018
0

@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.

Adamant36 picture Adamant36  ·  18 Oct 2018
0

(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.

SomeoneElseOSM picture SomeoneElseOSM  ·  18 Oct 2018
0

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.

matkoniecz picture matkoniecz  ·  18 Oct 2018
1

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.

polarbearing picture polarbearing  ·  18 Oct 2018
0

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.

5Boggis picture 5Boggis  ·  25 Apr 2019
6

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

via-ferrata-vs-scale

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:

via-ferrata-map

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.

via-ferrata-vs-safety-features

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:

sac-scale-vs-visibility-vs-via-ferrata-scale

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.

jeisenbe picture jeisenbe  ·  26 Apr 2019
0

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.

pnorman picture pnorman  ·  26 Apr 2019
2

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):

afbeelding

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.

mboeringa picture mboeringa  ·  26 Apr 2019
0

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?

5Boggis picture 5Boggis  ·  28 Apr 2019
0

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.

Adamant36 picture Adamant36  ·  29 Apr 2019
0

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.

SomeoneElseOSM picture SomeoneElseOSM  ·  29 Apr 2019
0

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.

5Boggis picture 5Boggis  ·  30 Apr 2019
1

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.

Adamant36 picture Adamant36  ·  1 May 2019
3

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

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

jeisenbe picture jeisenbe  ·  1 May 2019
2

@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")

SomeoneElseOSM picture SomeoneElseOSM  ·  1 May 2019
0

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

All the best and good hikes,
Klaus

5Boggis picture 5Boggis  ·  2 May 2019
0

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.

Flossersteig, easy ferrata

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.

Hard ferrata

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.

Sjord picture Sjord  ·  20 Jul 2019
0

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

taghistory(1)

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

kocio-pl picture kocio-pl  ·  20 Jul 2019
0

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.

polarbearing picture polarbearing  ·  21 Jul 2019
2

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

via-ferrata-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

via-ferrata-blue

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.

via-ferrata-dashes

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.

Sjord picture Sjord  ·  21 Jul 2019
0

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.

polarbearing picture polarbearing  ·  21 Jul 2019
0

Blue dashes

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

matkoniecz picture matkoniecz  ·  21 Jul 2019
0

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 picture ebickle  ·  2 Sep 2019
0

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.

SkiTour

Climbing

Mountaineering

ViaFerrata

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.

ebickle picture ebickle  ·  2 Sep 2019
0

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.

fkv1 picture fkv1  ·  2 Sep 2019
0

@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 picture jeisenbe  ·  2 Sep 2019
1

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.

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.

jeisenbe picture jeisenbe  ·  2 Sep 2019
0

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. 😁

ebickle picture ebickle  ·  2 Sep 2019
0

@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.

jeisenbe picture jeisenbe  ·  3 Sep 2019
0

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 picture Tyg-g  ·  8 Jun 2020
0

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.
Tyg-g picture Tyg-g  ·  8 Jun 2020
0

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.

Adamant36 picture Adamant36  ·  8 Jun 2020
0

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.

Tyg-g picture Tyg-g  ·  8 Jun 2020
1

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.

brycenesbitt picture brycenesbitt  ·  8 Jun 2020
1

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".
IMG_0764

Wood ladder.
86453949_3549924691744382_1158157288784003072_o

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

Dangerous log crossing, no protection:
57368734_2675171125886414_549749422976663552_o

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:

Half_dome_cables_big_(cropped)

The via ferrata tags are almost exclusively used in Europe, around the Alps and Pyrennes:
https://taginfo.openstreetmap.org/tags/highway=via_ferrata#map
Screen Shot 2020-06-10 at 12 31 24

https://taginfo.openstreetmap.org/keys/via_ferrata_scale#map
Screen Shot 2020-06-10 at 12 31 33

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.

jeisenbe picture jeisenbe  ·  10 Jun 2020
1

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)

matkoniecz picture matkoniecz  ·  10 Jun 2020
0

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.

Adamant36 picture Adamant36  ·  11 Jun 2020
0

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.

Sjord picture Sjord  ·  11 Jun 2020
0

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.

Adamant36 picture Adamant36  ·  11 Jun 2020
3

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.

imagico picture imagico  ·  11 Jun 2020
0

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.

Adamant36 picture Adamant36  ·  11 Jun 2020
2

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.

imagico picture imagico  ·  11 Jun 2020
3

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

jragusa picture jragusa  ·  16 Jun 2020
0

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.

Adamant36 picture Adamant36  ·  16 Jun 2020
0

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...

matkoniecz picture matkoniecz  ·  16 Jun 2020
Tags:
roads
Source: Link