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.