Tag trail_visibility: Proposed Improvements for this Descriptive Tag

I would personally/intuitively say that a path consists of a physical trail (either caused by repeated usage over the same place, or formally created by an organization) which may or may not have markers on it. If you just have markers spaced out then people have some freedom to create their own route between them and aren’t following a strict path. As you say, a path can form from repeated usage on a route, and in heavily used routes that have terrain amenable to it (aka not a granite slab) you generally have a path created where terrain is more constrained, which fades as things become more open/easy, then can re-appears again when things are constrained. It’s interesting seeing this happens even with game trails, as well as human used informal trails and abandoned/unmaintained trails that people still use.

On the high sandstone in Canyonlands there was a cairn below where we were, then one at the same altitude we were at past it. We chose not to drop there, as we were confident we could safely traverse terrain to the next one while being more efficient, many people probably do choose to go down and then back up again. We were still technically on-route (we went from Cairn A to Cairn B, they go from Cairn A to Cairn B) though we would have chosen a different specific (invisible) path to take than others.

My words, again :slight_smile: Perhaps, that is the main reason why I wanted the trailblazing tag to succeed in finding approval. Though, trust me, I did my share in marking (what you’d perhaps call PROW) ways. Blazes are in no way comparable to a trodden path.

I agree that the two aren’t equivalent, and I made some points in a previous post of mine as to why it’s good to have separate trail-blazed and trail visibility tags. I edited my response earlier to make it a bit clearer what I meant before you responded it.

At this point I think it’s worth explicitly pointing out the unintuitive nature of trail_visibility in documentation (how it is referring to the visibility of the path as a whole and can exist if there is no trail per se) if the consensus is that it’s too hard to change ingrained habits and existing data. I’d personally prefer if it was divorced from markers entirely.

I do think there are legitimate regional differences in how tags are used around the world (let alone the words path, trail, and route) - I know of others in the US that are currently using trail_visibility and trailblazed:visibility like I was for abandoned trails where the trail might be bad and cairns intermediate. 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.

In terms of pure fidelity such trails that consist solely of markers would be node networks where each marker was a node placed with GPS waypoints, but that’s sort of insane from a human workflow perspective.

I just repeat that here, because I consider the preponderance on this pur hyperbole.

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!


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 Tag:information=guidepost - OpenStreetMap Wiki 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.