Introduce Pathless / Alpine Path / Off-Path?

General talk Tagging general discussion
1

In order to move ahead with resolving issues with path

and based on perceived consensus

it seems that, while the disagreements on path still exist, almost everyone agrees that a pathless route should be a separate entity to a, usually-visible, path.

By following the “this is a small step for a man” logic, I would suggest that we go ahead and implement the Pathless way. It would be the first step, from which we could draw conclusions for the implementation of the other tags which may be separated out of path. It would also chip away a portion of the problems, making the rest of them potentially easier to resolve.

Let’s try to focus on concrete issues in this thread. Which tag/subtag would work best? Should we use highway=pathless or highway=path with pathway=pathless or path=pathless?
What exactly would be the scope of Pathless and (how) would it differ from Paths, especially the ones in the upper sac_scale?

I would also note that there will be an overlap, like there already is, between a path, hiking path, via ferrata, climbing route. However, this is not necessarily a problem, because I’ve also been on paths that have 15 different route relations on it so perhaps we can also learn something from that.
I.e. a (section of a) path/pathless can also be marked as climbing=route, or something like that.

Suggestions on the characteristics that differentiate a T5 path from pathless - not a known route, no visible path on the ground, no official trail markers.

Edit: Some references that came up in the discussion.

Alpine Route, Wikipedia
Starting from Alpinist routes marked as footpaths - #117 by Hungerburg, there are several examples of mapping these routes on maps.
Several more examples on online maps: Introduce Pathless / Alpine Path / Off-Path? - #76 by Road_Runner

2 Likes
2

Personally, I am against any form of way object for something that is “pathless”. A relation with a start and end point is fine for me, but a way object is not, because it is generally assumed to depict something that exists continuously between its consecutive nodes.

I would also recommend to avoid the “highway” namespace altogether.

12 Likes
3

I can’t quite get over how a “pathless” is neither a thing nor a description of a “highway”. An uncovered concrete pad isn’t a “roofless” that we’d tag as building=roofless; at most, it might be tagged not:building=yes to avoid confusion by armchair mappers.

Here are a couple alternative ideas off the top of my head:

“Pathless” is an adjective, which makes it a natural secondary key. If we’re wedded to the term “pathless”, could the way be tagged pathless=yes and nothing else?

The overall idea of mapping these indefinite route segments reminds me of mapping ferry routes, which are technically just point-to-point information but conventionally represented on maps as definite routes. Using that as precedent, how about mapping an indefinite route segment as a route=foot way and, if it is part of an otherwise formally defined route, adding it to a type=route route=foot relation? It would confirm that highway=path does not apply while affirming that there is something present, just not something we can map to the usual precision.

Some have argued that we should simply come to terms with the fact that highway=path on its own doesn’t convey enough information to be routed over with confidence anyways, therefore these ways should continue to be tagged as highway=path but with additional keys to communicate its physical qualities. In case these physical qualities are difficult to determine, how about combining highway=path with indefinite=yes or indeterminate=yes? This would at least convey some degree of imprecision. The same approach would be useful for indefinite boundaries, which we must also map as ways somehow in order to close gaps in boundary relations.

7 Likes
4

Using the route=* key makes sense to me. In plain language I describe one of these things as a “pathless route”, “pathless walking route”, or “pathless hiking route”. I’m not so sure about =foot as the value though. Since that is already used for walking routes following visible paths and roads this may not really solve the current problem where segments of both visible and non-visible routes both end up tagged highway=path and data consumers can’t differentiate. A new value like route=pathless_walking, route=pathless_hiking, or route=pathless_foot[1] would be only for pathless routes, making it easier to omit or explicitly include them depending on each data consumer’s needs.

While I don’t entirely disagree with you, the fact is that many such pathless way objects currently exist in the database. They are tagged highway=path and those who would remove them are not finding success. Since you’ve specifically mentioned this as a personal opinion, I’ll assume that the DWG will not be supporting and enforcing the removal of these pathless way objects any time soon. Barring that, a different way to tag these things is needed so that it is possible for data consumers to display paths on their maps without unknowingly displaying a bunch of non-paths as well.

  1. Yes this last one sounds quite awkward :smile: ↩︎

5 Likes
5

I assume any data consumer that supports route=foot only does so for type=route relations, whereas the idea is to tag route=foot on individual ways, where this tag is currently invalid and unsupported. That said, I’m half-expecting someone to discover a need for route=foot;bicycle;horse;mule;mobility_scooter before too long. I would suggest a different route=* value, but I’m drawing a blank as to how to describe it without making reference to a particular mode of transportation. Maybe route=yes would suffice?

6

Just help me understand:
You want to tag ways with route=foot and then add them into a separate relation, or would you want to just add ways and not necessarily a relation for them?
In either case: having the transport mode as a value won’t work, but you’ve pointed this out yourself.

While I support @woodpeck’s idea of using a relation of nodes, because it feels right, I don’t think this is going to be used, or picked as a solution, simply because of the complexity.

I’m also in agreement that highway=* seems to be the completely wrong namespace to use, but so is path=*. My suggestion would be to distinguish by how you are supposed to find your “personal” route through the individual nodes, which is probably going to be waymarks most of the time? So maybe waymarked=* could work? I’m not someone walking on these, so I’m really just throwing in some ideas

1 Like
7

The suggestion was to tag route=foot on a way and also add it to whatever designated route relation requires the way, if any. This idea is predicated on the notion that someone is going to map a way regardless, so having a descriptive tag would keep it from getting inaccurately tagged as highway=path. But I don’t have much of a stake here; I would be just as content with not:highway=path.

8

That key is trail_visibility=no, and in combination with highway=path it perfectly describes a pathless path. We don’t need to invent any new tag for describing it.

4 Likes
9

“Perfectly” might be overstating it, judging from all the discussion about how to ensure that renderers and routers distinguish these inferred paths from well-defined ones. There does seem to be something approaching consensus that these are fundamentally different than, say, formal shared use paths. trail_visibility=* has been around for a long time, but there’s a long way to go in terms of software support.

4 Likes
10

And it suffers from the same problem that I and others have mentioned in other contexts:

A lot of people want renderers and routers to interpret highway=path using secondary tags. But the specific tags mentioned by various people include surface, smoothness, width, est_width, sac_scale, mtb_scale, incline, and trail_visibility. Plus all the access tags. There must be 1000s of possible combinations. It seems a lot to ask of a general purpose renderer to classify those combinations into a few distinct categories to be rendered differently. Especially as most of them will be missing on any given highway=path.

11 Likes
11

I’ve already tried that. Didn’t work well.

12

There isn’t a tagging recommendation at the top of this thread, just a bunch of should-it-be-X-or-Y questions. Like all the other path threads, there isn’t exactly a consensus yet.

If someone was to (for example) change a bunch of existing trail_visibility=no to some tag that they’d just invented, we’d probably take a dim view of that. However, if someone changed somewhere they’d just been to (some other tag) on the grounds that the previous tag simply didn’t reflect reality, that’s a different matter.

Personally (not with a DWG hat on) I’m perfectly happy to render route relations on ways with literally no tags at all - no need to invent tags for the way at all.

2 Likes
13

That discussion seems to be about whether to map them at all. I think in a few cases pathless paths could be mapped (for instance when they are part of a hiking route relation, so that gaps in the relation are avoided). However, IF they are mapped, THEN they can be mapped as highway=path + trail_visibility=no.

2 Likes
14

I’m at the point now that I consider opening yet another path thread vandalism.

14 Likes
15

True, although are we confident the situation will be any better for a newly-invented tagging scheme?

Organic Maps and OsmAnd seem to take trail_visibility into account. AllTrails and GaiaGPS don’t unfortunately, and I assume they have a much larger user base.

Perhaps we’d be better off simply hounding the developers of these apps to support trail_visibility? To me that feels like it has a better chance of success vs. starting from scratch with a new scheme and zero software support.

3 Likes
16

As of 2024-10-14 there are 11178 km of type:way in the openstreetmap database carrying the trail_visibility=no tag, according to ohsome dashboard. This is not a lot. 10326 km of that combine with highway=path. I panned around doing overpass. These are not the footways over urban plazas. Germany has more of them (520 km) than all of the US (440 km). Austria, despite quite little in comparison, clocks in at 400 km, curiously, Italy – mentioned above #4 an astounding 1300 km of them.

What do people see in their local area tagged with that? overpass turbo

17

It comes back to the question of what problem we’re trying to solve. If we’re trying to solve the problem that people get misled into following “paths” in quotation marks and get lost or hurt, then indeed, we could hound developers to recognize that highway=path and trail_visibility=no cancel each other out. We could’ve been doing that all along. Has the lack of momentum been an oversight, dissent from the developer community, the inherent difficulty of getting data consumers to do anything right, or something unnatural or counterintuitive about this tagging approach?

Ideas such as highway=pathless rely on the fact that novel highway=* values and novel keys are unsupported by default. To their proponents, this is a feature, not a bug. After all, most software developers have a limited amount of resources to spend implementing support for edge cases. Niche use cases would need to account for a novel tag, but the scope of any developer awareness campaign would be much smaller, on a less urgent timeline.

8 Likes
18

In my area, stuff like this. The on-the-ground path is signed as a legal right of way at the east end. The trail_visibility=no bit is where the path basically “runs out”, even though the legal right of way continues. The bit that is truly “pathless” isn’t mapped in OSM as there is no path.

19

Yes, good point. To clarify my post was more aimed at the approaches that involve adding new subtags to highway=path (pathless=yes, path=pathless, etc).

1 Like
20

“Paths” along the beach, so walkers can be routed along there, rather than back up onto adjoining streets.

1 Like