Introduce sac_scale and trail_visibility on highway=path

[yvecai]

This is a first step to fix #1500 , attempted to be the least disturbing as possible from the current style. From this, future change can be made and (heavily) discussed, either more elaborate (fine-grain tuning for hikers), or less (don't render at all).

Changes proposed in this pull request:
Introduce tags sac_scale and trail_visibility, and draws an arbitrary limit on what an average walker would expect.

                CASE WHEN (tags->'sac_scale' IN ('demanding_mountain_hiking', 'alpine_hiking', 'demanding_alpine_hiking', 'difficult_alpine_hiking')
                  OR
                  tags->'trail_visibility' IN ('intermediate','bad','horrible','no')) THEN 'demanding'
                  ELSE 'normal'
                END AS int_difficulty,

The style change is 'naive' and aim at reducing visibility of most 'demanding' path by introducing wide dash and reduced background visibility:

          [int_difficulty = 'demanding'] {background/line-opacity: 0.1;}
          ...
            [int_difficulty = 'demanding'] {line/line-dasharray: 1,12;}

This style is extended to bridleways and cycleways in order to keep in line with the current stylesheet.

Test rendering with comparison with surface tags (null, paved, unpaved), bridleway, cycleway, and access=no:

[imagico]

Thanks for working on improving rendering of paths.

First of all a technical remark - please always post sample images in native resolution reflecting what the map user will see if the change is merged and released.

The change introduces a new, fourth line signature for paths in addition to the existing surface=paved/unpaved/unknown stylings. This is based on having any of eight tags present on the way:

• sac_scale=demanding_mountain_hiking
• sac_scale=alpine_hiking
• sac_scale=demanding_alpine_hiking
• sac_scale=difficult_alpine_hiking
• trail_visibility=intermediate
• trail_visibility=bad
• trail_visibility=horrible
• trail_visibility=no

It does so in a way that overrides the surface classification, so a path with surface=concrete, sac_scale=demanding_mountain_hiking (yes, such exist in the database) will be rendered according to the sac_scale and not (like right now) according to the surface.

The rendering of this starts at z14 (surface distinction starts at z15).

I will comment separately on the idea this change implements and how it implements that.

The implementation

The newly introduced line signature is almost always unreadable at z14 and usually very poorly readable at higher zoom levels. It aggrevates the existing problems we have with #1748, #1793, #1765.

Having any of eight poorly defined and not very consistently used tags override existing distinction of paved and unpaved paths (that is taggged by mappers with a very high level of consistency) does not seem a good idea.

The idea of the change

What the change here essentially tries to do is to interpret eight tags which are all rather poorly defined and documented and mostly not used very consistently as code for this path is to be considered as special in some form. That this special nature of the path is meant to represent some form of difficulty for the user is not intuitively visible. The chosen design is more communicating some sort of path light or something between there being a path and there not being a path. This is indeed a frequent use case of the tags in question, on the extreme end for example a pathless walking route on rocks or on a beach, but there is clearly no consensus among mappers that this is a valid use case for highway=path.

I already commented on the consistency and definition of the sac_scale and trail_visibility tags in #1500 and elsewhere. The idea that collectively these eight tags can be aggregated as being meant to indicate some sort of difficulty or as being discouraged to be used by the mapper is sound (though of course subjective and non-verifiable) but there is clearly also no consensus among mappers that this is the main meaning of these tags.

I am kind of torn between supporting or rejecting this change. On the one hand it is clearly not in support of the goal of this style to support mappers in consistent use of tags. And it is also not very useful for the target map user because while, as explained, the interpreted tags indeed typically indicate some sort of difficulty or being problematic to use in some form these tags are in practical use not even remotely the generally accepted form to indicate any sort of difficulty of a path.

On the other hand it seems that all arguments and reasoning about the flaws of these tagging ideas have not substantially diminished the desire of mappers for sac_scale/trail_visibility to have meaning (independent of how much wishful thinking that is). So maybe the most constructive way forward is to actually support degrading the eight tags this change wants to interpret to being synonyms for render_in_the_map_as_path_light=yes to help creating space for mappers to develop tagging concepts to document specific, well defined and locally verifiable risks/difficulties/etc. of paths. This is a long game of course, it could easily take a decade for this to happen. But we kind of have precedents for that - see #4322.

As said - i am unsure about this, in particular because the second alternative is based on an extremely long term scenario and it would mean us encouraging mappers to invest enormeous amounts of time into work we expect to be pointless in the long term. In other words: I have serious moral scruple about supporting such a course of action.

In any case - since there is an active discussion going on in the community about new tagging ideas in that context (see https://wiki.openstreetmap.org/wiki/Proposed_features/highway%3Dscramble and links on that page) i would be strongly against prejudicing consensus building in that discussion with a change like this at this time.

[yvecai]

"tags which are all rather poorly defined and documented", really ?
https://wiki.openstreetmap.org/w/index.php?title=Key:sac_scale&oldid=124302 (2008->2022)

"prejudicing consensus building in that discussion with a change like this at this time" I also agree this is a major blocker. Anyway I just wanted to show that things could also evolve here. Also because the status quo of issue #1500 (2015 !!) is probably not completely sinless in the recent tagging proposals around more demanding hiking trails.

[yvecai]

... until next time ;-) Le 19 septembre 2022 18:43:39 GMT+02:00, Christoph Hormann ***@***.***> a écrit : ***@***.*** commented on this pull request.

…

> line/line-join: round; line/line-cap: round; line/line-width: @footway-width-z14; [zoom >= 15][int_surface = 'paved'] { line/line-dasharray: 2,3.5; + [int_difficulty = 'demanding'] {line/line-dasharray: 1,12;} You obviously would have to make the other dasharrays conditional to the attributes they are used for. But i agree your version makes the logic of int_difficulty overriding int_surface most explicit. -- Reply to this email directly or view it on GitHub: #4692 (comment) You are receiving this because you authored the thread. Message ID: ***@***.***>

[Woazboat]

I think the comments on the proposal for highway=scramble have shown that the use of highway=path won't be replaced for these kinds of difficult hiking routes anytime soon and is here to stay (for better or for worse).