Tag trail_visibility: Proposed Improvements for this Descriptive Tag

Well, let’s say “nearly no one,” it isn’t actually “no one” but it’s “almost nobody” or “relatively few.” (Compared to Europe).

Here’s two more proposed solutions after some further thinking,

Solution 1

  1. Keep trail_visibility as is (an effective path_visibility given it’s about the overall visibility of the highway=path object) with documentation to steer it clear of its original purpose. I and many others don’t read the not being about routes bit as addressing unclear signage at intersections (which isn’t a trail issue, it’s a junction issue) but as focusing it only on the physical impact upon the ground (worn/rutted track, footprints, lack of vegetation, lining stones, etc) vs the overall route itself.
  2. Create a new tag trail_surface_visibility that fulfills the original intent of the tag and explicitly exclude markers/trailblazed from it, referencing trailblazed on the trail_surface_visibility page.

Solution 2

This might just be a more US vs EU centric view, and probably isn’t worth the effort, but hey…

  1. Create a path_visibility tag as mentioned above but have it perform the same function as trail_visibility currently does (an alias in effect) and deprecate trail_visibility at some point merging things over to path_visibility. Some logic around picking the higher of either trail_visibility and trailblazed:visibility if they exist should solve most edge cases. Having them mean the same thing (while path is more accurate with how it is used now) should reduce the headache of trying to keep trail_visibility to it’s original intention and then have people start using path_visibility. This would also play well with highway=demanding_path potentially in the future.
  2. Create a new tag trail_surface_visibility that fulfills the original intent of the tag and explicitly exclude markers/trailblazed from it, referencing trailblazed on the trail_surface_visibility page. path_visibility will be used most often, but in cases where people want to comment on both the visibility of the trail/path itself and how it is marked that will be possible.

I was speaking colloquially / tongue in cheek, as should be evident by the full sentence…

No one in the US knows what the SAC_scale is unless they’ve done climbing in Europe or edit OSM or are just rating system geeks.

I’ve never encountered anyone in the Western US using it in a variety of mountaineering communities, and had to learn it for OSM - having it be a global standard for rating trails seems odd to me. Why not have European trails be rated by SAC_scale and US ones by YDS_scale? IMO if OSM was started in the US it’d be strange to expect Europeans to apply YDS to all their trails.

??

1 Like

That’s fair.

That is exactly the opposite of the key name - and that would be the worst definition of that key possible, not an improvement.

This key reflects the visibility of the trail itself, that’s the most important meaning of this key.
But it depends on the definition what a trail is. For me: the way I can follow without any markers at all, in OSM the path.

1 Like

For me, markers are just one of the many visual clues available to see where the path is. I don’t see why we would want to have a key for path_visibility_if_there_were_no_markers for a marked trail. What is the usefulness of having this information? What’s the use case?

1 Like

As an American, I will admit I only learned about the SAC_scale because I saw the tags on hiking paths in Cyprus.

Keep in mind that OSM tagss doesn’t have the same meaning as the word use as key. This discussion can certainly not be summarised by a single word. Take ‘landuse’ for instance.

1 Like

As a humorous aside, this is like the old joke by Henny Youngman (20th century comedian):
“Take my wife…PLEASE!”

There’s a whole tome on OSM’s landuse=* waiting to be written, as indeed, it is a fairly complex topic. (Meanwhile, our wiki is pretty darn good).

To wit (and fully agreeing with @yvecai), keys in OSM are not what they appear to be as their literal meaning in English: OSM keys can be quite a bit more complex than that. (landuse=* certainly is).

So is trail_visibility!

2 Likes

All of these keys have unintuitive names. I didn’t know trailblazing had a literal meaning related to hiking until I read the OSM wiki.

As a European I only learned about the SAC scale (that is, the Swiss scale) when I started learning about OSM. The scales differ between countries, and sometimes even within a country. For example I think most people who have hiked in Austria will know blue, red and black paths because that’s what’s on the signs. These are the same colours as for ski pistes, and this is probably not a coincidence. Even people who don’t ski usually know what a black piste is! So the colours are pretty intuitive and probably more widely known.

This is so interesting! So the word trail has different meanings even in different parts of the US.

Maybe unintuitive names are good. If sac_scale was hiking_difficulty=none/easy/intermediate/hard etc. then people would use it without reading the Wiki at all, instead the cryptic name encourages people to look up the intended meaning.

For what it’s worth I agree with the proposed changes but they only make sense if there is consensus on them.

There’s been multiple use cases lined above - for abandoned trails where path visibility and cairning are both poor to intermediate, or for ones where cairns/markers can be seasonally covered etc.

If current trail_visibility as a whole (mix of trail surface and makers) is all we need, then why do we have a separate trailblazed:visibility? Why is the visibility of markers in and of themselves important, but an actual physical path/trail unimportant??

Your argumentation would support the removal of trailblazed and trailblazed:visibility unless you can make a case for why they are more important than there being a physical visible trail surface as they are currently included in trail_visibility. Currently trailblazed:visibility is essentially trailblazed:visibility_if_there_is_no_trail

On my phone so no code wraps, but the point should still stand. At the very least it seems like if we’re keeping trailblazed having a trail_surface_visibility seems reasonable.

Apps rely

The issue is that the evolved usage and meaning don’t reflect the intention of the name (as per the creator as documented above) . It was meant to be the visibility of the trail itself, but including markers in it has morphed into a mix of both - so the current usage is the opposite of how it was created and IMO that deserves some clarification if it’s going to kept as is.

It is in no way different in Austria, neighbour to Switzerland. Nobody cares about SAC Scale. Apart from some OSM nerds. I bet, the Germans care no less. Both OEAV und DAV have a three grades system: blue=easy, red=intermediate, black=hard.

Only recently, some suggested to go with the Swiss in avalanche warnings. People in charge all declined - Much too complicated!

It’s a word that is used casually. I don’t think that I’m going for a hike on a highway=path in the forest, I think of a trail. In areas where terrain will hold a physical visible trail people will think of the trail as that mark on the terrain - in areas where the terrain doesn’t support that and a trail is only a set of markers, people will visualize what a trail means differently.

When I’m hiking on an abandoned or informal trail and it fades into invisibility I think of it as the trail not existing anymore. Sometimes (like where the John Muir Trail in Center Basin was before the early 1930s) a single track trail still is highly visible and easily followable, except in sections where there is more water and vegetation. I tend to dislike backcountry cairns (not those used on formally maintained paths) but built a large one where the trail disappeared for a few hundred feet / hundred meters near a stream crossing. In that case in OSM speak the path would still be visible, even if to me the trail is non-existent, and me creating a cairn to bridge that gap would make the trail visibility there excellent or good as the rest of it is easily followable.

It’s non-intuitive, but it’s also not entirely clear from a documentation standpoint that trail_visibility actually means trail_plus_marker_visibilty or path_visibility unless you read that markers can effect excellent or good. According the spec as markers do not contribute to intermediate, bad, horrible, or no.

A trail/path with no visible trail surface and trailblazed:visibility=intermediate should get trail_visibility=no as it is currently defined.

That’s why I suggested making trail_surface_visibility earlier to match the existing trailblazed:visibility (and the original intent of trail_visibility) and being more explicit with how trail_visibility is a mix of both markers and surface (which would mean adding marker information to intermediate, bad, horrible, & no) whether or not an alias of path_visibility is made or not.

Both keys, sac_scale and trail_visibility were derived from the Hiking Scale by the SAC. trail_visibility got split out of sac_scale very late in the proposal process. From the originalist point of view, trail_visibility tags the visibility of the path, what is there on the ground - regardless of marks and blazes. Thats how it is used in the SAC document.

Remember: When we here (Switzerland, Austria, Germany) say Route, we do not think of the OSM data type ordered-relation, but we mean the itinerary. So, when we say route markers, this need not be about knowing which path to follow at a crossing: That is what guideposts are for, the marks most often are just the same :slight_smile: Route markers are to tell the route, no more no less. In remote areas, where not many people pass, so no path emerges, where terrain is pathless, they are essential.

Yeah, trail_visibility is bit of a mess, it makes sense it happened late and fast. The documentation even refers to markers in an inconsistent way see more in the second half of my reply above where an intermediate or lower trailblazed:visibility doesn’t affect it, only good and excellent.

I don’t see https://wiki.openstreetmap.org/wiki/Tag:information%3Dguidepost being used anywhere in the US, but seem like they could be useful. A few days ago I had to pull up topo to help an elderly couple on a dayhike that ended up at a junction of an informal and formal trails and were confused by the lack of signage. :slight_smile:

For a pathless, marker less route, how are route markers handled in Europe, as a node network? I’ve come across some mapped paths in the southwest (example) where the majority of it is a handful for nodes strung together that create an arbitrary path line with no real impact on terrain. While I haven’t hiked that one, my partner and I explored around one south of there (just route finding with our eyes and topo) then tried following it on the way back and ended up at a 15-20 meter rappel down a dry waterfall. We saw one or two cairns the entire time, and maybe four footsteps, so it’s someone’s informal route they are trying to share. I’ve actually got a topic on this running on the #trails channel in the OSM slack channel at the moment.

The Swiss have organized their hiking network in a node like fashion on administrative governmental level. The SwissTopo map shows only routes where there are paths on the ground. They do not show routes where there are just markers. Most of the hiking routes have paths up to the demanding_mountain_hiking sac_scale value.

Not so in Austria or Germany. Hiking paths are managed by local organisations on their own thinking. There is a bit of governance, when tourism agencies want a special seal of quality. These are all paths on the ground. Many of them show in the ÖK50, the official map of the country.

Outside of this managed network, there are lots of paths in OSM that are mountaineering routes, they do not show in any official maps. In OSM they are often tagged sac_scale T6. There are notes in the area, where people that walked by did not see the path. Of course not! This is just a route out of a guide book with hundreds of routes, some blazed, some not, that somebody happened to drop a GPX of his ramblings there. But what can you do? It follows policy up to the letter, trail_visibility=no.

PS: I once argued on the principle of reproducibility. Little interest in that. I must say, I belong to the kind of people, that see paths everywhere. Very useful in remote areas. Not helpful in discussing OSM issues.

It would be kind of disheartening to learn, that these routes can be claimed “trail_visibility=excellent|good” in case the next cairn can be seen from the current one|has to be searched out for" (possibly loosing 100m height?)

This point keeps getting brought up on this thread, but is there anyone who actually uses the tag this way, or thinks that it would be a good thing if people used it this way? Don’t people just mentally fill in the blanks?

For comparison, here is how iD shows them (differences to Wiki highlighted):

Excellent: unambiguous path or markers everywhere
Good: markers visible, sometimes require searching
Intermediate: few markers, path mostly visible
Bad: no markers, path sometimes invisible/pathless
Horrible: often pathless, some orientation skills required
No: pathless, excellent orientation skills required

Effectively the iD tagging scheme has already implemented the suggestion of

This is probably a good idea if it prevents people from tagging every marked trail as good or excellent. The way they’ve done it is not ideal if you ask me, because if you take it very literally, it implies that any path with markers needs to be at least intermediate. I’m just copying it here to show that people probably don’t take the Wiki so literally, nor should they.

A few cairns spaced far apart are only useful on a sunny day and even then the path between the cairns may not be visible and that should be taken into account. That’s why I suggested that

In the real world, ignoring for a moment what the Wiki says, isn’t it more like this?

For comparison, the Wiki page on trailblazed is very explicit that the tag should not be used on route relations. I interpreted “describes trail visibility (not route visibility)” on the trail_visibility page the same way. But it’s perfectly possible that I’m the only one who was interpreting it like this!