Tag trail_visibility: Proposed Improvements for this Descriptive Tag

I altered the title of this thread a little for clarity. It is not a substantive change.

It does seem a little weird that trail_visibility as an abstracted combination of markers and any worn path/trail doesn’t have any related tags for the actual visibility of the path/trail itself, but does have detailed information for the visibility of markers. It’d seem to me that if you have one, you should have the other. :slight_smile:

This key describes attributes regarding trail visibility (not route visibility) and orientation.

Is up at the top of the trail visibility page. It should probably be rewritten if the consensus is the tag refers to the overall ease in understanding where the route is (which can consist of a trail/path and/or markers) and not the physical trail itself. It seems like at this point it’s turned into a misnamed path_visibility but that it’s too late/messy to fix the integration of markers into it. IMO since highway=path is the high level abstraction of what the map object as a whole is, logically trail and markers would be attributes of the path.

Maybe something like:

This key describes attributes regarding path visibility (which includes any physical trail or marker visibility) and the ease of orientation and pathfinding, and doesn't reflect the visibility of the trail itself.

If there was a visible trail, you wouldn’t need markers to understand where the path was without staring at your phone. :smirk:

Now I am completely at a loss: I always thought, the abstract entity was the route, a mostly verbal account, of how to get from A to B; From what you write, the path is the abstract entity? While I always understood path as something to be seen on the ground. And no, markers do not make a path, if so, then only from making people not stray too much so that, given enough use, a path can come into existence.

Path is somewhat abstracted in my mind, sorry if that was confusing. :slight_smile: This is how I see it as I trying to think in OSM semantics. The path consists of a mix of a physical trail one can see and markers that one can see (or not) - that is the abstraction I was thinking about. Caveat: I’m not an expert OSM user, though I do spend quite a lot of time in the backcountry/wilderness especially off-trail and have been learning as I make corrections to OSM as I encounter them in the field.

I’d say the route is the most abstract - it’s like you say someone trying to get from A to B regardless of what form that takes.

One of those ways can be a path. That path can consist of a physical trail (which may or may not be visible, on a spectrum) and/or markers (which may or may not be present at all, and if they are visible on a spectrum). You can have a path without a trail, or a path without markers, or a path with both. A path without both (or with both that are severely degraded due to being abandoned, damaged, overgrown, etc) would in my mind just be a “route” where people having to use advanced self-orienteering aka pathfinding aka finding your own path because none exists in any meaningful real world sense even if you are still trying to get from A to B and there was some path that went from A to B 40 years ago.

At this point we can have a highway=path with trail_visibility=excellent that has no visible path/trail at all because there are bright tall markers every 10 feet (think long runs of posts/cairns/markers on sandstone or granite slabs). In this case the path is abstracted aside from the actual markers, as people have to visualize it in their minds and follow that visualization.

I don’t agree this makes trail_visibility intuitive, but that’s how I understand it.

edit: added the second half of this comment. ^^;

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!

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.