History of proposals to fix highway=path ambiguity – and a wayforward?

General talk
,
1

Many discussions here attest that highway=path is a mess on both ends of its scale. On one end, it is used for (hiking/scrmbling) routes that are either not visible on the ground or require the use of hands and might be dangerous.

On the other hand, it is used for ways that almost look like roads, albeit they are not used by cars, but almost by everything else.

(I think the only almost guaranteed meaning of highway=path is “you either cannot legally drive a car here or you practically cannot drive a car here” – note that these two do not need to hold at the same time)

I was looking into the history of proposals trying to solve this and found these:

From reading the discussions, I think there is some will (maybe strong, maybe not) to split highway=path into a few different segments. There is a controversy regarding whether the distinction between different non-car highways (cycleway,bridleway, footway,path) should be based solely on access or if it also should reflect what the individual ways look like (urban way open for both bikes and pedestrians and mopeds in Germany looks very different from a rural way in Southeast Asia used by the same group of users). It seems to me though that most people somehow accept that both aspects are somewhat relevant with the acceptance that the same tags migh have very different expressions in different part of the world.

Way forward

I think path should be split at least into three tags:

  1. highway=pathless – This would mostly cover also what highway=scramble wanted. It would imply trail_visibility=no (but possibly could have something like horrible or intermediate for scrambles marked by cairns or when some sort of trail comes and goes). Unlike scramble, it would not cover assisted trails and paths that are somewhere on the sac_scale, but are clearly marked and used and visible (so it would be duck tagging. It would however by definition include glacier travel. Sac_scale tagging would be required or heavily recommended. Almost by definition, there would be surface=ground (I think it should not be used on squares as a virtual connection for routing, but my opinion about that is not strong. It could however be used for connecting coastal trails that traverse tidal beaches as discussed here or shifting river beds or wetlands or possibly meadows. Mappers would be strongly recommended to only include routes that are habitually used (there would still be disagreements about what should be included, but with a new tag, that should lessen the confusion for consumers hopefully).

  2. highway path - what would remain, roughly what highway=path is used now for walking trails or ways that are primarily walked, though possibly also accesible for mountain bikes* or rugged motorcycles. Here the stress is more on practicallity than legality of access. Usually unbuilt and unpaved, but that would not be core fo the definition. Part of the proposal could be strenghtening the distinction between highway=path as something unconstructed, rural and not very regulated as opposed to footway/cycleway/bridleway being more purposeful and possibly constructed. This should be a tendency, no hard rule.

  • (for mountain bikes, I think there should be a separate tag for single tracks, but that is out of my scope, I am not a biker. For that matter, I think there should probably be a highway=snowmobile but again I am not a user so I would leave that for others)
  1. highway=two_wheels This would cover ways that are now either split into footway/cycleway/bridleway or, when the designation or access is not known, are coverred by path now. Not ridable by cars (though probably yes by ATV but easily usable (also legally) by bikes and motorcycles and horses. Usually paved or at least constructed, but that would not be core of the definition. Combination of access could be controlled with access= or designated=. This might either replace the highway=motorcycleway proposal or be in addition to it (I lean to being an addition).

I think highway=pathless is a good name but I am not sure about two_wheels and anyway I am open to suggestions. I would like to stress again that there would be a lot of bordercases. But that is the case already. It would ensure there would be more precise meaning to highway=path, however it would not be absolutely precise.

Transition

Of course, the current use of highway=path is massive. A good thing is that a lot of it could stay. It would definitely be multi-year effort to bring some order into this mess when changing the use on the margins of highway=path. Consumers would need to catch up. I think this should formally deprecate the use of path for what would be pathless and two_wheels with the caveat for certain communities (Germany?), should they insist on the current usage. Anyway, a long (decade?) transition period would be needed when the old and new tags would need to co-exist and documented. Not sure if any automated re-tagging should be done (I can see some sac_scale=difficult_alpine_hiking and trail_visibility=no or horrible without trailblaizing=*something_positive being changed en mass, the same with highway=path bycicle=designated foot=designated etc., but would leave that to more experienced mappers).
7 Likes
2

I think the evidence shows that it is useless to try to define highway=path as opposed to footway, brideway, public footpath, hiking trail, etc. And equally pointless to try and limit highway=path to a smaller spectrum. “In Mycountry paths are always half baked, half cooked and allow access to ground hog drivers” type of observations do not further the issue in this respect.

Let’s recognise that highway=path is extremely variable, it is not just one clear type of path, and that is precisely why it is used so abundantly.

The way forward IMO is to embrace the variation, and at the same time define one main type as the default, meaning all other types have to be tagged explicitly, even for places where the country specific default differs from the general (world wide) default.

E.g. If the main default type is defined as narrow (< 1m), unsmooth and unpaved, then regular German shared bicycle/foot paths will have to be tagged with width, smoothness and type of paving. Or else they will have to use country specific routers and maps, and endure general OSM maps and routers to underestimate their shared paths.

OTOH if the default would be defined as paved, 3m wide and smooth, Nederland would have to tag most of its highway=path objects with a smaller width, an unpaved surface type, and a smoothness value, or else endure that paths are overestimated for OSM-wide applications.

Personally, I would choose the default path conservatively, because when routing, missing a possible connection is the less evil, compared to directing people over unpassable or even dangerous trajectories.

6 Likes
3

That’s the problematic part. You can’t just redefine a tag that is used so widely. Many paths would have to be retagged. Automated solutions for retagging are not welcome. And even with automated solutions, most paths would probably have to be retagged manually. A mixed state between the old “path” or the new one is extremely obstructive when maintaining the data.

Either you discard highway=path completely (I do not give it a chance) or you simply add a more precise specification like path=subtype

you missed the regulated multi-use case (e.g shared foot/cycleway).

12 Likes
4

Why do we need to define a default at all? Shouldn’t we be adding surface and smoothness to all paths, width to all paved paths at a minimum, and sac_scale (or foot_scale) and trail_visibility to all unpaved ones? A focused mapping campaign to add these attributes to as many paths as possible could be useful, maybe more useful than another tagging discussion (@supsup make sure to read the other ones that we recently had on the subject).

3 Likes
5

As far as I remember from the foot_scale discussions, there was no solution to the question of how to tag the very lowest difficulty level. As it stands, using sac_scale at all implies it is at least a hiking trail, so doesn’t work for (say) a wide compacted path in an urban park. Trail_visibility is perhaps not so bad but even that was intended for informal paths and hiking trails.

1 Like
6

It would be great if all mappers always added surface, smoothness, width, etc to paths but this is far from reality. Across the four main path-like primary tags (footway, bridleway, cycleway, and path), surface is the most prevalent property key at around 30%. So around 70% of paths have no surface tag. For smoothness and width the missing percentage is more like 95%. Even if the majority of paths did have these property tags, data consumers would still have to decide what to do with paths that don’t have them. With no agreed upon default, data consumers each make different decisions about what they think the default is. Different map renderings then drive mapper behavior, and the data becomes as inconsistent as the varying interpretations.

Some sort of documented default meaning would improve the situation, but it can’t be too specific. I agree with @Peter_Elderson that a conservative default assuming a propertyless highway=path is probably a rather rough, undeveloped trail is best. Assuming a highly developed, accessible path where there is actually the opposite is a worse outcome. Adding more specific property tags in both cases is great, but I firmly believe we will never reach 100% coverage of supporting tags. There will always be some paths mapped with just one primary feature tag as a first pass.

8 Likes
7

Sure. When do you expect this to be done?
Seriously, I don’t think attribute tags should be made mandatory. I would say, “highly recommended if not default” is acceptable.

The fact of the matter is, that there are quite some highway=path’s without further tagging. So data users must ignore them or use defaults. Currently each and every data user picks defaults as best as possible. I think it is infinitely better to assign OSM-wide defaults. Still, data users are free to use there own, but they will have a better understanding of what is meant.
Mappers can then tag all default-ish paths (which should be the majority, world wide) with just highway=tag, and anything out of the ordinary will keep the highway=path tag and gets extra tags as needed.

8

Amen, brother. I’d vote Yes any time.

Pathless gets us closer to resolving a decent portion of Path misunderstandings. It would include scrambles (with sport=climbing and UIAA grade = I-III, probably). It would cover paths that are not visible, whether trailblazed(=cairns,poles,yes) or not, with surface=rock, routes that are under water, and so on.
The tag seems specific enough, covering ways that are not visible on the floor/ground.

highway=path should be defined on the wiki page as a clearly visible path. (Should visibility=no disappear?)

For single tracks and two wheels, I have no strong opinion right now. Other than Path (and eventually Pathless), Track covers most of the routes I come across.
I’m not sure why a minor road would not cover motorcycleways, with car=no, or motorcycle=designated, but I’d leave that to those concerned to debate.

Edit: I’m wondering if a climbing route is, then, Pathless or Path. It can be “marked” with bolts and therefore visible-on-the-ground. But can be way outside the SAC scale. It’s about time the climbing routes get some lovin’, too. Pathless could be a good default tag for them.

3 Likes
9

Let’s look at how highway=unclassified is defined (Only 29.19% have a surface-tag):

Really, we could just steal this introduction for highway=path, because the situation is pretty much identical.

I wonder this as well. If highway=unclassified can live with a vague definition like this …

This, for me, is an idea worth thinking further. Maybe we can “steal” designation=* for this, maybe we need a separate path=*. Either way, we could specify the type of path we’re looking at, which could then be tied to default values – if need be.

10

I think any attempt to somehow re-define the highway=path tag itself is doomed to fail. Its use is so widespread that you will never manage to eliminate all instances that do not match an intended new definition. highway=path without any other tags will always be the mess it currently is.

There are two main methods to move forward from here:

  1. Define new main highway=* tags for well defined portions of the space that is currently filled by highway=path. These new tags replace the main tag for specific uses. Changing the main tag implies a hard break with existing software support and interpretations by data consumers. This should be considered a feature of this method and should be used intentionally.
  2. Create new subtype tags (e.g. path=*) that are intended to be used with highway=path which further classify the path and provide more precise characterization. This method preserves the current support and interpretation of highway=path by data consumers and provides a gradual path forward (with the risk of [legacy/simple/…] data consumers not parsing these new sub-tags and interpreting highway=path as they currently do).

If we imagine current uses of highway=path placed on a scale from ‘high quality, easy to use’ to ‘rough, not suitable for everyone/requires experience/dangerous’, the first method involving a clean break is well suited for the rougher end of the scale. Current data consumers run the risk of inadvertently leading users onto paths that may not be usable by them or that might be dangerous for them to use if unprepared.
Examples for this are e.g. difficult scrambles on mountains that need considerable experience and are not suitable for normal pedestrians/unprepared hikers, or mountain bike trails that normal cyclists cannot use safely.

On the other end of the scale, we have paths that are perfectly usable by the average person and where there is little/less risk or inconvenience involved if current data consumers lead people onto these paths. The second method of gradually adding classification sub-tags may be more desirable here to preserve existing support.
Examples for this kind of path are e.g. shared foot- and cycleways

5 Likes
11

Prime example path=desire, in the data clearly superseded by informal=yes by a large margin. For me, these represent the same, a path that was not constructed on purpose but emerged from mere use of the terrain to pass there from A to B.

PS: path=* will invariably become a list, semicolon separated.

2 Likes
12

I’m not sold on highway=pathless being very a useful main tag or improvement over highway=path. It provides very little to no additional information compared to highway=path + trail_visibility=no.
Tagging scrambles on rocky terrain, trails on the beach or on grass, or even virtual connections on paved squares with exactly the same tag is no better than what we have now.

2 Likes
13

I am also not fully sold on highway=pathless, but it could be used to map the gaps in a highway=path with trail_visibility=good, that – when reading documentation – can vary from 50m itinerary with no visible path on the ground nor markers, to whatever somebody considered enough to find the next waypoint on some route. Seen that way, a mechanical edit would have quite some impact, a bit depending on how the documentation of trail_visibility is read.

BTW: First mention of highway=pathless here. Not in a position right now to link to the changeset where it was introduced.

1 Like
14

There is a third hybrid option:

  1. Create new feature tags for well defined portions of the space, but use a different key than highway=* (say pathway=* for example). These new feature tags would be intended to stand on their own, but dual-tagging with highway=path would be possible for backwards compatibility during their nascent period. This method would be an eventual hard break just like method 1, but with a bit of a gradual path forward like method 2.
3 Likes
15

There is also a fourth option, which is to do nothing, because the current tagging works well enough.

Is there a real problem that we’re trying to solve here?

2 Likes
16

Yes. The real problem has been discussed at length in many other topics.

6 Likes
17

For the same reason you’d want highway=pathless, you also want these paths to look different on maps so that inexperienced people don’t accidentally follow a scrambling route or end up lost.

Using motorcar=no, motorcycle=yes/designated only helps with routing, but those narrow paths will still show up like regular roads.

18

But as you probably know, except a few exceptions, almost all renderers, especially outdoor ones, don’t support extra tags like surface, smoothness, or width. The ones I’ve asked don’t plan to either. Basically, the defaults don’t matter much since most renderers only rely on highway tags and a few scales like mtb:scale and sac_scale.

That’s a great idea! It might actually make sense to phase out anything that doesn’t have road-like features (like hiking trails, scrambling routes, informal or pathless trails) under a new top-level tag. This would give us a clear distinction between urban/built-up areas and remote/outdoor environments.

2 Likes
19

First of all, thank you to @supsup for starting this thread!

I bet I’m not the only one who has wondered why all the proposals to ‘solve’ the path issue with new highway tags have failed. Until, that is, one thinks about these solutions further and realizes the point @Langlaeufer makes here:

I’d also argue that a new highway tag intended to replace some paths creates a worse outcome than the (undeniably bad) status quo. This conclusion is far from obvious, and it’s good to document it here too.

I’d argue that one way forward would be to educate, engourage and finally enforce mappers to add descriptive tags (like surface, smoothness, width, informal, etc.) to the existing paths. This wouldn’t disrupt the map even as the tags would be added gradually and in the course of many years.

Furthermore, as many have pointed out, the actual pathways are themselves exceptionally variable. Hence also, necessarily, the path tag. Introducing a new class means making arbitrary distinctions to a variable entity, that invite edit and revert wars. Conversely, most of the descriptive tags exist on a gradation. The smoothess values of bad and horrible can be argued over endlessly, but either one provides a rough (pun intended) and useful description. Since width is a real number, it actually exists on a continuum (modulo the size of the mantissa of the floating point used to store it).

The previous discussions on this subject have had good proposals on how to educate mappers on these tags. Regarding the enforcement of them, some have proposed presets. I personally don’t use them but that sounds like a good start! I think we should treat ways with only a highway=path tag as erroneously tagged ways. We could add an upload dialog to JOSM, so that whenever a mapper touches such a path without adding descriptive tags, it would ask them to resolve that particular conflict.

The other threads have winded up discussing what kind of assumptions data consumers can infer from the path tag alone. I think we should pivot that discussion onto what sets of descriptive tags (the presets mentioned above) would be most useful given the variability of the pathways.

Ceterum censeo: we should also treat ways that are Duck Tagged with only a highway=cycleway as similarly erroneously (or imperfectly) tagged ways and nag users to add descriptive tag to them!

1 Like
20

Well said!
Just one thing:

Problem is, they are not wrong, and the descriptive values are often simply unknown. Nagging about that isn’t going to persuade mappers, it will just put them off. Validations are easy to ignore, especially the ones expressing convictions rather then errors.

6 Likes