You are being purposefully obtuse again by taking a single sentence out of context. Congratulations I guess?
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.
So you are rendering 6 levels of varying visibility on paths? None of those links indicate this, and neither does your legend.
I’m really not - I only quoted a couple of small bits to make it obvious which sections I’m broadly referring to - I did read all of it.
I combine trail_visibility with some other tags to create 3 levels of “visibility”. Some of the code is here, but look further down that file for more details of the combined tags.
The other rendered attributes are chosen on a “visibility on map” scale too - public footpaths and bridleways are more “in your face” than paths, and tracks get a longer dash (hence more visible) than narrower paths.
The problem is, the 3 or 4 sets of values that I use might be different to what someone else wants to use. I lump good and excellent together, and someone else might not want to do that.
The OSM US Trails WG talked to a couple of app developers and might have more info about what actual values and combinations they use. The OsmAnd rendering rules are likely public, but aren’t easy to understand without a bit of knowledge about the OsmAnd UI.
3 levels of rendered visibility seems about the reasonable maximum to me, but I can see the point in having a distinction between good and excellent for touristy destinations which would bring it to 4.
I’m not sure there’s any value into breaking visibility into 6-7 levels, and depending on where cutoffs are it shouldn’t massively impact renderers (and they could be given notice of an upcoming change, it would be pretty simple to change some simple if/then logic values).
I had tried to start some discussions on the Gaia GPS subreddit   about having a smarter mix of sac_scale, trail_visibility, and informal informing trail weight which it seems that they’re doing now though I don’t know the actual mix of what they’re doing. That’s actually how I found out the Trails WG on OSM.
I imagine imagine most renderers just put things in the following buckets in terms of rendering weight (though again this should be verified). None of the links you gave before showed any examples of someone rendering all 6 levels of visibility differently, which is the question you were answering.
strong: excellent + good
weak: intermediate + bad + horrible + no
strong: excellent + good
weak: bad + horrible + no
strong: excellent + good
weak: intermediate + bad
hidden/opt-in: + horrible + no
If it’d be relatively painless to collapse intermediate and horrible into bad, I personally think that makes a lot of sense. They are all just variations of “path sometimes not visible” - if you can handle that… you can handle that.
Excellent remains similar, and is tourist friendly.
no sense of direction or map required
Good remains similar, and is the lower end of casual hiker friendly.
a sense of direction or map recommended
The loss of intermediate doesn’t bother me, as it doesn’t make any sense IMO.
intermediate= Path mostly visible
bad = Path sometimes invisible, route partly pathless
These are describing the exact same thing, unless someone can explain how an invisible path isn’t pathless. You could literally just combine them to be: “Path mostly visible, path sometimes invisible, route partly pathless” and it would make more sense than having them separate.
Mostly visible = 51% of more of the time there is a visible path
Sometimes invisible = 49% of less of the time there isn’t a visible path (implied)
The worst case scenario is that some paths that were worse than good, but maybe not quite deserving of being rendered as faint as bad+horrible, are rendered fainter. That seems acceptable, as there’s a pretty fine line between needing a good sense of direction and a basic sense of orienteering which is the other criteria. If it is required to have a map because you can’t see a path, how is that not basic orienteering / routefinding?
Bad absorbs intermediate and horrible (and the current definition of no in some places) and is the “orientation / routefinding” required value.
The loss of horrible likewise doesn’t bother me, as the difference between “often pathless” and “partly pathless” isn’t clear, actionable, or meaningful. A path can be partly and often pathless. I would be genuinely surprised if clients out there render horrible visibility differently from bad.
No should mean no. If I order a vegetarian meal (meat=no) I don’t expect it to be “mostly meatless”, which could mean that it’s up to 49% meat.
Some paths that are “mostly pathless” being rendered as if they are pathless doesn’t strike me as a major issue. The majority of instances of this will likely be for paths that have a single digit percentage up to maybe a quarter of the route visible.
Changing a definition on a wiki page won’t magically remap path that haven’t been remapped in 3+ years.
It’s good to have porous limits in scales like this one trail_visibility : it gives more chance to capture the mapper best judgement. Then, any data user or consumer can reduce the scale at will. The opposite can’t be done remotely.
A node network (network:type=node_network) requires labeled nodes and marked two-way routes between adjacent nodes. I could think of a ‘network’ type with labeled nodes but without prescribed itineraries, though. network:type=grid_network or so. How you get from one node to the next one is your own pro…/ challenge. The node2node relations of the node network would just contain the two nodes, no ways. Or some ways, if there are necessary corridors. The gpx format can handle exchange of such routes and nodes, no problem. The software to export and import the gpx-files… would have to be developed, or not if you want to keep it adventurous.
No, but existing ones can be condensed, and in app help updated etc. Over time it’d be a simpler and more maintainable system. Over time trail visibility changes on the ground anyways, and it’s a tag which people will update over time as conditions change.
Is it? Doesn’t that go against the entire point of trying to have verifiable & consistent information?
What value is there in a mapper choosing between “Path mostly visible” and “Path sometimes invisible” to draw the line where weighting changes?
If the goal is just to have people look at the names of values and choose what they think feels right, why not just delete all documentation and have the system run on vibes?
I would assume that having less random / arbitrary information would be useful, given all the ambiguity and contradictions around this key.
I am in the opinion that the world we map is complex, and that what OSM can do is to describe it the best we can with a simplistic model.
So yes, there is plenty of occasion we’re down to the mapper vibe and that’s good.
The issue here is that if you collapse 6 tag values into 3, you take the risk to put some mappers into bad vibes and loose them, and that’s bad.
My map renders trail visibility through the stipple, and sac scale through colour. While it uses 6 colours, it only uses 3 stipples. I am fine with that, as 6 stipples are indiscernible any way. Actually the 6 colours also get close.
Still I am with @yvecai - the flattening is better done by the consumer. They know their users, where to set cutoff.
Excellent and good should be separate, as these two cover 60+ % of all paths. (And if tagged according to the Wiki, they would perhaps cover 90+%.)
Reason why? The scene shows demanding_mountain_hiking - and there are 6 degrees of visibility because there are 6 degrees of difficulty - nothing else comes to mind to explain this feature. Yet, that is an interesting property in itself.
If the trail went through just like in the background, wouldn’t this be mountain_hiking? Actually, I never understood why both got split. Probably because, OSM can do better than the SAC? The current documentation mirrors the split but somewhat skewed.
I have remained largely quiet here, as the discussion is good and the graphics (photos) are excellent (heh, see what I did with my choice of words there?). But the best summation I’ve seen about this whole kettle of fish is its most recent: “the current docs mirror the split (between mountain_hiking and demanding_mountain_hiking) though they are somewhat skewed.” (My quotation marks are both tight and loose).
Yes, they are going to be “skewed” because they are along two “coined” scales. (Some scales are open-ended and still evolve). What we seem to be doing here is harmonizing those in tagging (harmonizing is often a good first step towards improvements). These are different, created for different reasons and likely also “skew” along cultural and linguistic boundaries: even though we try to bind ourselves to British English usage, things wander to conform to “how Italian-Swiss denote bike routes” or “in Germany we are precise right down to the ‘this’ in how we denote hiking trails.” These helpful framings can steer a discussion like this one back onto a “we do (and document in wiki) this” right now. And there are differences in how we might better this, intentionally.
“Improvements” exist in discussion, something concrete (wet and slushy now, but it will harden firm) which might be proposed and compare to what is now in the map. That’s a pretty big nut to cram into a worldwide thread about a global map talking about subtle things which are being attempted to be described with precision. So, let’s have patience with one another. This might take weeks, months or even years. It could (and very well should) fragment up a bit (into separate thread topics, one-to-one emails, often-more-local “chat oriented” group discussions…). It’s quite a bit of work, really. It might seem slow and long, even tedious to some. I’ll say out loud right here and now that’s OK, as that’s what it takes sometimes. So far, what I’m seeing and reading is making me nod my head a lot, I’m liking it. And taking a drink from my water bottle of patience (and unwrapping an energy bar) for a longer haul about this (there will be quite a number of listeners and several good contributors). It’s not infinite to get where this goes, but it remains a hike into the distance.
Patience, please, everyone. This is going, but it is a hike.
Balsam auf meine Seele (balm for the soul?) - I learned through this discussion, that I am not a hiker, I am a rambler (and a scrambler, BTW) It was only late in my life, that I met hikers - having dinner at an Alpine Hut and witnessing the landlord dissuade hikers from a certain route - where I thought, what the heck? So one more shameless plug: This is T1 hiking, and trail visibility there is V1 excellent:
Now that’s what I call painting some easy, bright lines! (“V1 excellent, T1 hiking…”).
Appropriately (visually) it is all somewhat uphill from here, as things get subtle and less distinct quite rapidly. The precision enters in describing exactly how. Good luck to all, I think the paint can dry on this one but things remain wet and sloshy.
Sorry I haven’t reacted so far: just reading and considering all the responses takes time, which didn’t leave me enough time to respond.
I hope that we are all have a common aim: to create the world’s best quality map. One of the aspects of a quality map is its reliability, and for this we need to map consistently.
I think we found out that our interpretation of the wiki varied, which leads to inconsistent mapping of trail visibility. To improve consistent mapping of trail visibility, we need to narrow down our interpretations of it (as much as possible, variation will always occur but we can do our best to minimise it). This can be done by improving the text of the wiki. I think we should narrow it down so we reduce outlier interpretations and have more of the “middle” interpretations. In hindsight this “middle” interpretation may not be the best possible one, but we should also take into account the amount of work that needs to be spent on “correcting” mapping. Choosing the best interpretation instead of the “middle” one might be so much work it is not worth doing for a relatively small quality gain.
OK, let’s keep it short. There’s some additional info in the paragraph below, which I would also like to keep short.
I’d like to keep it shorter than what you proposed. I replaced “markers” with “on the ground evidence”.
Depends on where you set the limit. trail_visibility is somewhat subjective, so differences of evaluation may occur between mappers (or even between the same mapper on different days, depending on mood, etc.). But I think a path with trail_visibility=good is verifiably not trail_visiblity=bad. On the other hand map information that depends on a human review tend to be extremely useful and can be a matter of live or death (Concerns raised over crowdsourced maps used by popular hiking apps ). And even seemingly 100% verifiable tags can be evaluated differently by different mappers (how far is a path next to a lit road allowed to be to be considered lit by the street lights of that road?).
Me too, but I don’t think we should change the number of categories now because it’s not worth the amount of work needed to resurvey and retag. Let the users of our map data decide how they want to use it. Openandromaps, for instance, groups trail visibility as (excellent or good)/(intermediate)/(bad, horrible or no), which looks like this (SAC scale T1=dark yellow, T2=blue, unknown=brown; trail visibility good in the valley, western path up TV bad, eastern one first horrible, then intermediate).
Thanks! I like the additional pictures, but object to replacing the ones that have been there for a long time so they have been setting the standard. * if it ain’t broke, don’t fix it* so let’s keep the ones that work and add yours where they are an improvement. Especially your Trail visibility really good picture for trail_visibility=good looks very much like the Very goog visibility picture that was there for trail_visibility=excellent so if we would follow your proposal with this picture, many paths would have to be resurveyed and retagged from excellent to good. I don’t see the advantage, and I do see that it will be a lot of work. The trail descriptions in your proposal are quite unclear to me. Maybe they could be used for iD, where they need to be short but anyone in doubt can easily click on the link to the wiki and get more info?
I will make some edits to my Talk page proposal to reflect what I’m stating here. Hope we have consensus soon, before reaching 200 posts in this thread
This thread has been mostly about improving the text of the wiki, because I think it needs improvement. So far we haven’t discussed the pictures much, which I think are OK (ain’t broke). If you think they need improvement, we could start another thread about this.
I hope this a side thing, but reading over these types of discussions multiple times and multiple articles related to them, I find myself wondering what the point of these tags is in the first place? I mean, I get that they are classification schemes for hiking trails and paths, but is that something that’s really necessarily and/or serves a unique purpose? Like take the examples in the article for trail_visibility. The second value is for trail_visibility=good, which is defined as “A continuous path which is always visible, but may occasionally become faint or ambiguous.” OK cool. That sort of makes sense. But then take the picture, if it’s of a grassy, semi-legible path. I assume we would already know it’s a path because it’s being mapped as a way in the first place and you can tag the existence of grass along the route with surface=grass. So what exactly does adding trail_visibility=good add to the equation that’s not already being mapped with highway=path + surface=grass?
Maybe you could argue there’s grass “paths” that “could” be tagged as trail_visibility=no, but then I’d argue if they aren’t visible they wouldn’t and/or shouldn’t be mapped as a path in the first place. And no I don’t want to get into a meta side discussion about the meaning of the word “path.” The fact is that very rarely, if at all are people mapping invisible (one might even say imaginary) grass paths or if they are other people will delete quickly them. So trail_visibility seems like a tag without a purpose. One might even say it’s a solution for something that isn’t even a problem to begin.