I already told, whats my beef with the key - it does not give you the means to tag excellent or good visibility for eg. front-country paths. The proposed changes wont’t help me with this and neither in the other occasions, where I posted pictures here.
When I wrote the last reply, I just flew ober https://wiki.openstreetmap.org/wiki/Talk:Key:trail_visibility#New_text_proposal and noticed the extra change in content. Verifiability is one of the key concepts in OSM, trail_visibility never has and never will achieve that. The original authors at least tried to bind it to the ground truth, but the proposed changes will turn it into a purely subjective usability attribute.
Left on site dangling ropes (Reepschnürln) do save lives
Given that the proposed changes don’t have gaps for good I’d assume he was referring to the old / existing definitions. This is the proposed text as it stands.
I still think it’s wrong that trail_visibility=no is listed as mostly pathless. No should mean no, as the text in the iD editor indicates. If there is a visible path part a minority of the time (which could be 49% of the path as it stands), it isn’t no - that should fall under horrible.
I can see breaking out the caveat for no into a separate section below and keeping it clean, but I’d change it to
trail_visibility=no
No visible path or meaningfully useful trail markers.
Excellent orientational skills
This I think covers the “path” that just consists of a two or three stacked rocks every kilometer or w/e with no visible impacts of use or construction on the ground.
Good point, there’s also junctions that are just marked with colored marks in the US. It is still worth adding to the See Also / related section at the bottom IMO.
Should there be some sort of vote on this as a proposal? It’s not a massive change, but it does impact things and we really have four or so active voices here, 3 for and 1 against which isn’t a huge consensus.
Taking into account some of the feedback I’d change the following to:
To add a path with trail_visibility=no to the map, it should be Verifiable, for instance because there are markers but they are so bad quality that they are useless and don’t help trail visibility, or that the path position has been published by an official authority. One can also use it to tag small pathless sections of a longer path with generally better visibility.
To add a path with trail_visibility=no to the map, it should be verifiable by OSM community standards. For instance the path has been published by an official authority, it is commonly used and known within a community, or it is used to tag small pathless sections that connect to visible paths to allow for routing.
If a path is strong aside from a small section, it can be useful to create a new path for that section with reduced visibility, especially if it includes more difficult terrain. An example would be a path which is sac_scale T1 or T2 and visibility of good or excellent, aside from a short section which is no or horrible and is SAC T4 or T5. That would be more descriptive of ground truth than saying the entire path is intermediate or bad, which would be more useful for a path which regularly had areas of reduced visibility or gaps in it.
I think just keeping " there are markers but they are so bad quality that they are useless and don’t help trail visibility" can lead to people adding a path because they found a couple of random 50 year old cairns, and that is covered in the description I proposed.
I added in a paragraph to help clarify when to shift from an overall rating of a trail to making a new path as that’s something which has come up here a few times.
I don’t see the original proposal being any more grounded in truth than the current one, if anything it allows for more room in interpreting visibility - do you have any concrete examples of how you think the current proposal could be made more objective? If you want to shift the direction, propose some changes.
I wrote, they at least tried, not that they convinced me, and seemingly you neither. I do not think that they even convinced a sufficient number out of a small number of people back then - as this got approved in the by-luggage of sac_scale. Therefore I propose to not change anything. This will invalidate tens of thousands of mappings, albeit of little use, such for even less gain.
I’d only remove the mention of markers from the top classes. These paths are the ones least likely to be marked, because the path is clear in itself.
I don’t think that the proposed wording changes are radically different - the majority of ratings will still map.
I’d personally just have less ratings if I could do it from scratch - 6 seems like too many with overlap, where 4-5 would probably be clearer.
Trail visibility is something that changes over time time as well - a trail which was excellent 5 years ago could be intermediate now due to heavy rains washing out parts of it, and excellent again in two years after maintenance has been done. The passage of time will invalidate existing ratings more so than the changes here, except perhaps for trails so well maintained it doesn’t really matter.
That’s a significant change which impacts existing ratings, as well as the text in the iD editor which includes markers at all levels. The majority of people are currently using both surface visibility and markers with the key (whether I think that’s a good idea or not, it’s the current reality).
Either the wiki or the iD editor need to be changed, unless we think supporting mutually exclusive conflicting definitions is the best way forward.
I’m obviously somewhat biased, but I feel the new descriptions bring more clarity to the ratings than the terse wording before.
That said I completely agree that at a certain level this is subjective, like sac_scale, and is more of a convenience than something to be absolutely relied upon. A mountaineer would be more likely to tag T5 as T4, and a casual hiker T5 as T6 etc due to perceptions of difficulty and risk.
If something is tagged good I wouldn’t be shocked if I felt it was excellent or intermediate - however it shouldn’t be bad or horrible. I feel like keeping excellent very explicit, and then good noticeably different but still useful for casual hikers is more important than the differences between bad and horrible.
Given the current system has multiple interpretations as it exists, and directly contradictory explanations it seems like it’s due for change, even if that change does break a few things. It’s already broken, and it will continue to be broken, and it will continue to generate information which is more broken than it has to be.
Lest we forget: global consensus on map tagging in OSM is difficult. This goes without saying, really, but there, I said it.
Sometimes we really do support mutually exclusive conflicting definitions. And you might hear lots of “mm, mmm, mmmm.” (Hand-wringing, exasperation, what’re we gonna do…?)
And it is shrugs all around. I’m not saying “discontinue working on it,” I wouldn’t do that; it’s good discussion here. More like “there are twisty little passages where it’s dark and we seem to get stuck…”, yes? Disagreements happen. Sometimes we can improve things, sometimes we reach an impasse (and even after that, sometimes we improve things). Please don’t be discouraged. Though, it can be good to pause and consider.
I’ve experienced “syntax breakthroughs” before, where, because of collaboration, the many interpretations of things have to get hashed out in a messy, community-wide way, discussed in the open and more-widely. Though after they do, then the pearls of wisdom begin to fall out as simplicity itself. That doesn’t seem to have happened here (yet?) but it could. Please persevere.
There is a largely-consensus with things (map data tagging, things in wiki…) as they are. To me, that says “more discussion about improving, and here is how…” can be fruitful. There is nothing wrong with “gear fitting” (and a few grinds and question marks along the way) until things go “click” and spin nicer. So, “try things” and see. Tagging (design, especially, and within existing schemas / paradigms, whew!) can be hard. Sometimes, pearls of simplicity emerge. Seek them, you may find them.
So it’s considered normal to have the definition of values of a key on the wiki be mutually exclusive of how those values are described in the iD editor?
Is this some kind of territorial / jurisdictional issue then? It doesn’t seem very functional, and also seems to invalidate ‘we can’t change things because mapping will break’ when there are multiple different systems running at the same time mapping the value differently.
I’d assumed that there’d be some consensus reached by voting on a proposal, and that would be considered solid, and everything else flows out from that. Obviously how to truncate a wiki definition into an editor takes some more work, but they shouldn’t (IMO) exist in isolation.
From first principles, off the top of my head I’d suggest something simple like the following:
unambiguous continuous path which is easy to follow
a continuous path which may become faint or indistinct, or has minor gaps with the next section clearly visible (stream crossings that aren’t well marked, a very short area with more vegetation, etc). It doesn’t require routefinding to follow but someone might have to stop and look for it occasionally
a path which mostly exists, but requires routefinding to find the next section at times
a path which mostly doesn’t exist, and requires routefinding the majority of the time
no path exists in any meaningful way
Simple and non-overlapping, aside from defining the ‘small gaps’ in good in a clear way.
Trying to break this into 6 (actually 7 if no doesn’t mean no but ultra_horrible) definitions causes a lot of arbitrary break points.
It’s pretty normal to have things in the wiki directly contradict things elsewhere on the wiki, so if iD takes only one of those views it wouldn’t surprise me.
This isn’t just an OSM thing either - I can think of lots of commercial software where when reading the documentation you have to ask yourself “was this help page written before or after feature XYZ was added?”.
I don’t know about “normal”, but it’s certainly not uncommon. OSM exists in a state of semi-organized anarchy and it is inevitable to have tags described differently in different places. There is no central authority or clear, agreed upon system to form consensus out of disagreements so these mismatches can persist for years. It’s also not just the wiki description vs the iD description. There are many other editors that may describe a tag differently as well. Map renderers and other data consumers may also interpret and describe tags in slightly different ways which also influences how mappers use and think about the tags. This is a difficult problem.
So I fired up the iD editor and I learned: With this key, that is the current situation, and it has been like that for years.
Your list reads a bit like I imagine, the SAC Hiking Scale works: Starting from T3 (small gaps) the ratio of pathless and pathful sections shifts to the pathless. This resonates here Key:trail_visibility - OpenStreetMap Wiki - Works perfect when describing routes.
Now, how do they separate excellent from good? Just asked google to translate “gebahnt” (the German term in SAC scale that sets out excellent), guess what it told me? It translates to “paved” That is certainly not right. The SAC themselves translate as “constructed”.
How does that sound to native speakers?
Continuous well cleared path.
Continuous trodden path.
The idea on my mind: excellent is sharply delineated, all the time, good blends into the surroundings, so it can get murky. Let people figure out the details from the pictures.
Still hitting the brake pedal, before the Wiki documentation gets adjusted to more closely match the iD editor presets. As has been said, there are other editors. Sampling my local area, trail-visibility is rarely tagged by iD users. No wonder, it is not available without searching. Most stem from JOSM, but there are also Go-Map! and even potlatch. No idea about the latter, but JOSM does not explain the trail vis values, it just states them, yet in the path preset, no searching necessary. People might have consulted the wiki? Or just understood the terms as presented?
If the sac_scale and trail_visibility keys want to derive from the SAC Hiking Scale, excellent (TV 1) should look like what is expected from hiking (T 1), and not from mountain_hiking.
How many paths do you see? What would you give the mapped one?
PS: I did not follow any further, was just in the area, and this path is the preferred one by some OSM routers, although the guideposts say, it will take you nearly double the time there.
SPOILER: None of the (possible as observed on the ground, least the trailblazed) paths there matches the mapped path.
The trail was graded T3, due to winter aftermath, it turned out T7
UPDATE: This is different from the one currently showing for TV2, but the problem is the same - Here on the lower left you can see the path, but you have to look carefully (TV2), then there is the gap (TV3, in the blocky terrain.) On the TV2 Wiki picture, there is no gap, but you have to look carefully, where the path is (it is in the right there.)
Those don’t sound very clear to me - a continuously trodden path can be unclear due to the surface it goes over. A well cleared path makes me think of a forest, but isn’t well suited for the alpine or desert.
The markers clearly show the path to the left, but it looks like there are a few more that dead end on the right though that is probably an illusion caused by leaves being caught by a bulge in the slope of terrain. With the markers I’d probably put that at good.
This seems like a bad idea. Does the visibility of a path somehow change just because the terrain is more difficult? This is sometimes the case, but not always.
Here’s a genuine question - what is the worth of having all these levels of visibility in terms of actual real world impact? Who actually uses them? What map renderers actually use this data? What could map renderers realistically do with this data?
I imagine most map renderers just take into account excellent+good, then intermediate+bad+horrible, and then no at best. Perhaps some make a distinction between good and excellent, but I feel like there’s many trails advertised and maintained by formal agencies that would fall under good visibility at times.
How many people look at a path on OSM and think “oh no it is marked bad, but I’m only comfortable with intermediate” or “well I’d do that hike, but it’s only good visibility instead of excellent”?
To me the point of this is to show trails which:
don’t need any maps or sense of direction (this can be a bit dangerous, as trail conditions can change over time).
need some basic sense of direction or a map, but not what mountaineers or experienced hikers would call routefinding or orienteering.
require orienteering / pathfinding to find the path at times because there are times where it isn’t visible / doesn’t exist.
I personally don’t know if it’s worth breaking out intermediate and horrible - if someone knows they have to routefind on a path that’s useful, but having someone else’s take on that doesn’t seem useful. Why not just collapse them into bad - I don’t think this will break any renderers out there though I obviously haven’t checked them all.
Essentially:
excellent: a tourist which has never set foot on dirt can follow this good: a moderately experienced trail hiker can follow this without any major issues, but might get confused at times. bad: off-trail hiking experience or mountaineering background recommended as someone will need to read terrain and “make their own path” in between sections of it that are visible.
I think good might be misleading, it’s really more “eh ok” or “fine” - but bumping down from excellent to intermediate isn’t the best thing and creating a new value would mess with migration more.
I honestly wouldn’t mind collapsing excellent down into good myself, and just having good, bad, and no.
That is certainly not right. The SAC themselves translate as “constructed”.
