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.
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.
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. 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 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
- Keep
trail_visibility
as is (an effectivepath_visibility
given itās about the overall visibility of thehighway=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. - Create a new tag
trail_surface_visibility
that fulfills the original intent of the tag and explicitly exclude markers/trailblazed from it, referencingtrailblazed
on thetrail_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ā¦
- Create a
path_visibility
tag as mentioned above but have it perform the same function astrail_visibility
currently does (an alias in effect) and deprecatetrail_visibility
at some point merging things over topath_visibility
. Some logic around picking the higher of eithertrail_visibility
andtrailblazed: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 keeptrail_visibility
to itās original intention and then have people start usingpath_visibility
. This would also play well withhighway=demanding_path
potentially in the future. - Create a new tag
trail_surface_visibility
that fulfills the original intent of the tag and explicitly exclude markers/trailblazed from it, referencingtrailblazed
on thetrail_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.
??
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.
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?
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.
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.