Although I am against further fragmenting the =path category, I could see a use for the =pathless case for the most pathological cases where people still insist on using the path value. And though I can see that highway=pathless or path=pathless sounds oxymoronic, to me e.g. the quite popular classification of =unclassified appears equally paradoxical. I think @Minh_Nguyen 's point is on the nose:
The pathless key also addresses the extremely wide use of the =path-value, on the extreme end. As I have proposed ad nauseam, one possible solution would be to add more descriptive tags (I propose at least surface, smoothness and width estimates) to categorize the dizzying variety of paths. I can understand most of the criticism to this idea, but not all.
The point (to mirror @Minh_Nguyen, and address the current discussion) is that the lower we go in the hierarchy of the highway= key, the less physical properties can be truth-preservingly inferred from the value of the key.
In Europe and North America (at least), most motorways are e.g. paved with asphalt/concrete. cycleway and footway are based on legal/suitability criteria, but their surface value can no longer be inferred (perhaps only that it is probably not in the =ground superset). Most people use paths for the absolute pariah category of ways. Therefore next to no physical properties can be inferred from the value alone (except that it must be somehow visible, hence the need for the pathless alternative).
As I pointed out on another thread, this is one argument to treat ways tagged with only a highway=path as near inpassable routes. If the data consumers would adopt this interpretation and start to dropâor severly penalizeâthem in their routing, this might solve the problem of motivating people to add the descriptive keys. It is one thing to use a =1 m wide path with =grass or =clay surface, and quite another to walk or cycle on a =2 m wide path with a =compacted or fine_gravel surface of =good smoothness.
Lastly,
this appears to me to be a bad idea. The pathless case would have to depend on some kind of waymarker present on the ground (cairns, wooden poles or spray-painted rocks to mark the route).
And thatâs what I would think is the most sensible approach. If thereâs a route and thereâs a pathless bit in between - let the route relation have a gap. If some stupid QA tool flags that as a problem, then maybe the QA tool (or the way people interact with it) needs fixing, instead of inventing a whole class of OSM objects that is only there to say ânot a bug, there really is a gap hereâ.
And as for routing of pedestrians along beaches - it is a shortcoming of the pedestrian router when it isnât able to plot a route across a beach; we shouldnât let that tempt us to criss-cross the beach with made-up âthere isnât a line hereâ lines.
As far as I know there has been a lot of discussion about this. The current situation with trail_visibility=no is not perfect (because, I agree, a lot of renderers ignore it), but still a pretty good solution.
If, and only if someone comes up with a good proposal that distinguishes between a pathless route and alpine paths, climbing routes etc, then it might work to create a new tag.
I certainly agree that real routes can be discontinuous, even where thereâs no gap in infrastructure. But I was under the impression that this desire for some new tag is about inferred route segments somehow supported by the on-the-ground rule, where the route markers say something like: âAnd now you go thataway through the quicksand â see you on the other end!â
Fortunately, if weâre already intentionally breaking backwards compatibility with respect to these ways, we can choose any key or value we want. We donât have to stick to something that alludes to paths. In fact, if we go with something more intuitive like route=foot or route=link or highway=bushwhack, then we reduce the likelihood that the tag will be misunderstood and diluted by other meanings in the future.
Exhibit A for me is still https://www.openstreetmap.org/way/637258230. It is part of a relation, and things that want to show that can. There is no highway there. Maybe in time an actual path will get established there that matches the legal right of way.
I do appreciate that this approach is consistent with the normal tagging of new-style boundary and multipolygon relation members as tagless ways â everything you need to know is on the relation already. On the other hand, any time I encounter a note=*, my first thought is whether thereâs a more structured representation of that note. Sometimes there isnât, but this note sounds like a combination of source=* and whatever we come up with as a result of this discussion.
In the case of my previous example, if I was to extend that it would be with designation=public_footpath only, and a source on the changeset saying that it wasnât from survey. Some people in England use highway=no for these, but I am not a fan of that - there is no âhighwayâ.
The South Coast Route, also known as the South Coast Wilderness Trail is a concrete example of a mostly pathless hiking route:
A general description of the hiking conditions along the route:
Hiking the Olympic Coast is unique in that the routes for the most part follow the natural land features found along the shore. Overland trails aid hikers in navigating sections of the coast that are not feasible or safe to hike at shore level. Certain sections of coastal routes are also only passable at mid-to-low tides; these sections should be identified and planned out prior to a trip.
While walking this route you will mostly be on beaches and intertidal rocky shores. These sections have no visible path. Sections where walking directly along the shore is not possible, or too dangerous, are bypassed by sections of visible path. A route relation including only the visible path sections would be missing large sections of the route.
A video tour for those interested in more detail:
Mapping this as a route relation with untagged member ways representing the pathless shore sections seems perfectly reasonable to me. The only problem is that some mappers will see this as an error and add highway=path to the untagged ways. not:highway=path to combat this may work, but I feel that a positive tag indicating a pathless route section would be even clearer.
I would like to thank @_MisterY for putting this forward. I am toying with writing a comprehensive proposal regarding highway=path as I think a global approach should be tried before a piecemeal one, but letâs see.
My general understanding is that the most opposition to doing changes to highway=path is from people who do not frequent trails much (which is what the majority of paths out there are). In the same way, most people opposing pathless seem to be people not ordinarily traversing such terrain. However, this observation might be wrong, it is just based on mentions by various people here and there.
My take would be that the proposal would redefine highway=path not to include pathless.
A secondary path= would be introduced, with several types of paths suitable for various vehicles (my preffered list is two_wheels (everything but cars), shared_use (bikes and pedestrians equally), single_track_mtb and snowmobile (which could also combine with pathless if winter only and not permanentlysigned)).
Then path=trail for hiking trails/mostly single track ways that are mostly for pedestrian used for transport in less developed parts of the world. An ideal bonus would be a specification that highway=footway should not be used for those, unless locally excepted.
Thenpath=unknown, which would be used for newly added paths when the subtype is not known (like highway=road). That would also be used to know if a path has been retagged yet (highway=path with nothing would still include pathless). path=unknown would make it explicit that it is unknown what it is. I think for practical reasons, it could not be eliminated that it can be also pathless, but people would know to beware. However, all QA tools should encourage its replacement by a more specific value and rendering should be discouraged.
path=pathless would not be in the highway namespace at all. It should require sac_scale=. It would imply trail_visibility worse then intermediate. There would be a grey area between paths that are marked but mostly pathless because they are on rocks and truly pathless ways. I think that is fine, there will always be grey areas. I think sac_scale=demanding_alpine_hiking and above (so T5 and T6) should default to pathless with T4 (alpine_hiking) being either, based on notoriety, frequency of use etc. (official trail marking are strong indication for highway=path, but I think they tend to end at T4 or less in most part of the world).
Benefits: difficult trails or trails that are very hard to follow would disappear from common maps, highway=path would have a much better meaning, for interested consumers it would be easy to know âbeware hereâ.
As has been said multiple types, OSM frequently depicts things not observable on the ground, like administrative boundaries. There needs to be a mechanism of verifiability, but that can also be shared knowledge (features do not have their name to be written somewhere to be included in OSM,for example, if everyone in an area agrees on a name).
I can imagine that, but âpathlessâ has the huge benefit on being meaningful on its own. A user can infer from it that there is no path there. From route=foot, I would assume there IS a path. So maybe route=pathless. However, I was under the impression that route= tends to apply to relations, not ways, so this way of thinking does not make much sense to me.
I think you need to include also horrible and bad for potential candidates.
The point is that typically orsometimes the proposed/sensible way to follow is not the shortest distance between the two (for example it might follow a curving valley, or a countour line on a curved sidehill). The router has not way to know how to render it.
As for beaches, riverways get tagged dually so we have a precedent for that. Yes, users should be smart enough to know that a river flows through a lake, but apparently that approach does not work well so the dual tagging was adopted. From my experince, paths are for this reason quite often marked over beaches anyway already, so moving them to pathless would only improve things. Most consumers will not bother with writing something to plot a path through curved beach so it does not lead you through water.
Without getting into the nitty-gritty of whether this tag is a good idea or not, âpathlessâ is a very Denglish construction[1] and makes little sense in actual English. If you said âthis is a pathless highwayâ to me Iâd assume you were talking about a motorway with no <american_english>sidewalk</american_english>.
If you want to call it highway=indistinct_passage then you do you. OSM tagging works best when it does what it says on the tin. But please do not call it âpathlessâ.
Another Denglish construct that would match the description would be Alpinweg, or alpine path/way. This would drag in another direction, however, and Iâm not sure if it makes sense for the rest of the world (outside the alpine areas).
But the sac_scale already uses alpine as the determinant between the âeasyâ group (T1-T3) and the âhardâ group (T4-T6), so it is a valid option.
Much as I am often frustrated by Denglish influence on OSM tagging, âpathlessâ is a realEnglishadjective. It does seem to be less common in recent years than in the past, but it sounds perfectly normal to my American English ear. That said, I can agree that âpathless highwayâ is a rather nonsensical phrase. Pathless route makes perfect sense though.
Which sounds almost perfect. It is an adjective indeed. However, is there a rule values cannot be adjectives? Already we have primary/secondoary/unclassified etc. â all adjectives (well, maybe the first two are numerals, but that is a question if numerals are not kind of adjectives if I remember my linguistic training well).
I panned the European Alps: From my observation, most of the length of it lies in glacier traversals. Followed by scrambles up rocky summits. Then there are a number of short sections over meadows and through woods which sometimes connect trails, sometimes lead nowhere specific.
the ârouteâ key is already established to specify the kind of route relation, we should not reuse it in a similar context with different intended meaning.
I once used route=mountaineering, along with not:highway=path, for a way that had previously been tagged highway=path. I didnât delete it because I didnât want an edit war, and I also didnât want it to be re-added as a path later by someone else. Much like the argument for mapping private paths (âWhy canât I delete this trail?â) I thought itâs better to add information to the map than remove it.
Itâs true that route= is normally used on relations, but some values are not, for example route=ferry is mostly used on ways.
But if the consensus ends up being something else, then my route=mountaineering will be easy to change.
Regardless, it isnât a word that would occur in everyday speech. Yes, you can say that a desert is pathless, or that an argument is clueless, or that a cake is eggless, or that a herd is dogless, and so on. But you simply wouldnât hear âoh Iâm following a pathless routeâ.
route=* does apply to ways in two specific cases: route=ferry and route=piste. Iâm assuming that data consumers are special-casing route=ferry and route=piste specifically, not treating any arbitrary route=* on a way as a ferry route or piste. So the idea would be to add a third case, for route=something. Iâm undecided on whether this would be better than not:highway=path or simply leaving the way untagged.
Yes, highway=* can be set to an adjective as long as the adjective describes a âhighwayâ:
Here, it does not describe a highway; it describes the absence of a highway. It cannot be a âpathless highwayâ if it isnât a âhighwayâ to begin with. In that sense, itâs as surprising as building=no, but at least that tag was considered a secondary attribute before it was deprecated. (For better or worse, it was supposed to mean that a feature described by some other tag, such as a leisure=sports_centre, isnât housed inside a building. You couldnât just go around randomly drawing rectangles and squircles, tagging them building=no.)
