Incremental Refinement of highway=path

General talk
,
21

Absent more specific tagging, that would be what a multiuse path is.

22

I voted for, at the time, but since then the broader path discussions took place. Now would I favour highway=path + path=scramble. If a path=… subdivision is still too controversial, I would opt for a simple highway=path + scramble=yes. Maybe mountain_scramble instead of just scramble, because of the pedestrian_scramble and bicycle_scramble thingy.

2 Likes
23

Out here in the woods, we use highway=track for two track vehicles (atv, possibly utv) and highway=path for single track vehicles (motorcycles, deer)

1 Like
24

I’d also favor this approach. It would be minimally intrusive to the current tagging. Furthermore it would and allow a gradient of values, also to the higher end of paths.

In Germany, for example, it seems that most combined footways and cycleways, or designated multi-use ways, (even with a Vienna convention traffic sign like this) are tagged with highway=path. These paths can be recognized (though not necessarily singled out) by additional descriptive tags like bicycle=designated + foot=designated, and a surface value usually in the paved superset, but it would be nice to have a path=-value that would identify them as traffic-signed bicycling-walking ways.

1 Like
25

But exactly that was not the point (to be minimally intrusive). The point was to introduce tagging that would require actively adapting your rendering/routing/whatever if you wanted to consume the tag and not to introduce even more troll tagging.

At the time my only concern was that “scramble” might be too specific a term for everything more difficult/exposed than a hiking path that doesn’t require use of hands etc. and we would end up with people arguing (because it is OSM) that something is not a scramble and falling back to path, but even that would be better than the current situation.

The one thing that is very clear, is that “incremental refinement of highway=path” will not do anything to resolve the well known issues.

5 Likes
26

Sure, that would be the other approach. However, I was replying to a thread with the subject “Incremental Refinement of highway=path”.

You may notice that there are currently two other threads on changing and introducing basic highway values. One, “Let’s talk about highway classification in OSM”, has over two hundred comments with no end or solution (or a clear and concise statement of the problem) in sight, and the other, " Let’s not talk about highway classification in OSM" is fixin’ to be equally inconclusive.

Again, good luck with that on such basic tags as highway!

27

We have seen many examples of paths, many issues, and some suggestions how to tackle the issues. Basically, the solution approaches are:

  1. More highway=… values (e.g. highway=scramble, highway=mountain_path)
  2. Breakdown highway=path using a subdivision tag (path=scramble, path=mountain_path)
  3. Tag more secondary attributes (width, incline, surface, smoothness, visibility, SAC-scale, access/designation, …)

Approach 1 has very little mapper support, I think.
Approach 2 has mapper support, but also opposition, mostly because some mappers don’t see necessity
Approach 3 has mapper support in that it is already available to anyone, but little trust that it solves the issues, current state of affairs is the reality check.

My observation is that 2 and 3 are compatible, and even complement each other. If a highway=path is tagged path=german_footcycle_path (not a proposal! better values welcome), tags like width, incline, smoothness, visibilty are only required for specific sections, e.g. an intermediate inclining section over compacted ground with some roots. (Actual experiences in Germany).

My take would be to see if we could come up with a limited set of path archetypes to cover all the examples in a few clusters. Let’s not worry about the exact values yet, I’m sure someone will come up with proper values for each path archetype. Also, let’s not discuss edge cases.

28

The problem is that both 2) and 3) are

  • troll tagging (in the context that we are discussing): that is, something that clearly isn’t a path is being tagged as a path, and the only way to know that is to consume secondary tags.
  • don’t achieve the intended outcome in real life, because if they did we wouldn’t be having this discussion yet another time.

PS: and wrt 1) as already pointed out: not having support is the whole point of the exercise.

4 Likes
29

You didn’t understand the objective: the less support the tag gets the better.

1 Like
30

Why do you think that? (I assume you mean “support from mappers as in OSM Contributors”, not “support from applications that use OSM”).

From a quick count, when the highway=scramble vote was suspended, there were about 41 in favour and 34 opposed.

But an important point is that several of the opposing votes, and some comments with abstentions, agreed with the idea of adding at least one highway value, but wanted more or different values such as demanding_path or mountaineering.

Sure, it is likely there is not enough support to get over the 75% threshold for approval. But as we have seen, a proposal will be opposed by (a) mappers who are against the whole idea (b) mappers who think the proposal goes in the right direction but that it doesn’t go far enough, and (c) mappers who broadly agree with the idea but object to something specific like the tag value. Keeping the total of those three groups below 25% is a huge challenge, perhaps close to impossible for a major change to a widely used tag.

But to go from “not enough support to meet an extremely demanding threshold” to a claim that the approach “has very little mapper support” seems disrespectful to the many mappers - quite possibly a majority - who did support this when asked and would likely do so again.

6 Likes
31

Sorry, again I wasn’t clear enough. This was one proposal for one extra highway type covering one specific feature currently not mapped, not a proposal for several highway types covering the existing path spectrum. I did not mean to discard it. I do think a proposal for let’s say 5 extra highway values would get more opposition and less support from OSM-mappers/contributors.

32

While I favor this approach, the level of opposition is (was?) high. An alternative long term strategy could look something like this:

  1. Introduce various path=* sub-tags of highway=path for types of paths and also things that aren’t really paths like scrambles (yes it’s troll tagging, but read on to the next steps).
  2. Grow support over time. Advocate for use of these tags by mappers and data consumers.
  3. Build support for the idea that path=* can be a standalone tag rather than a refinement of highway=path.
  4. Promote path=* to a top level key. Advocate for data consumers to support it without the presence of highway=path
  5. Build support for the idea that highway=path should generally be avoided whenever a more specific tag can be used instead.
  6. Demote highway=path to a similar status as highway=road

This process would take some number of years. Perhaps many. But it could go faster than expected. It would depend on the determination and leadership skill of the advocates.

5 Likes
33

Indeed, that is the phenomenon that killed many sensible proposals, not just on OSM but in pretty much any community with a voting feature. Whenever a major problem is identified, people can’t select one among many possible solutions and as a result we’re eternally stuck with it.

1 Like
34

Exactly!

As I see it, both introducing new top-level highway values and new path=⟨pathtype⟩ values suffer from the chicken-and-egg problem, though for different reasons.

On the one hand “requiring” consumers to just accept the totally new highway value you happen to come up with is not a very viable plan, as there is no way to coerce all or even most renderers to your[1] will. When the existing highway=paths start to disappear from The Map™,[2] users will most likely simply revert your edit to the previous value. On the other hand the new sub-tags for path-types will also at least initially remain abstruse and esoteric. They wouldn’t, however, break anything right away and precisely therefore give a possible way forward and a way to break the impasse.

My idea exactly matches @ezekielf’s. Given time (probably years and years) and promotion, the new sub-tags that actually add value to the map will surely gain traction. Once they actually do start to cover the vast majority of the ways they should apply to, it would make sense to try to get a new top-level tag working. Before an automatic edit that changes all highway=path + path=⟨pathtype⟩ ways to highway=⟨pathtype⟩ we could try to convince as many renderers as possible aboard to render them differently, arguing that there are thousands or tens of thousands such segments already in the data.

  1. you understood here as a metasyntactic variable. Presumably there would be dozens of new highway values appearing as anyone dissatisfied with the status quo would like their idea and new value to win. ↩︎

  2. I’m using the definite article here in a sarcastic way meaning any particular rendering of OSM data that a user is married to for some reason. ↩︎

35

A major reason to go for the path=… refinement strategy is that it doesn’t break anything, it requires no mass re-editing, it just adds an opportunity for easy improvement.

I would settle for this, for the moment. That is why I’d like a shortlist of typical path types which can be easily recognised. For me, I would start with e.g.

  • Combined footway+cycleway, or paved multi-use path
  • Walk-in-the-park
  • ‘Bear trail’
  • mountain trail

Scramble I would probably position as path=mountain_trail + scramble=yes.

1 Like
36

There would be no need make this change if the long term plan was for path=⟨pathtype⟩ itself to eventually become a top level tag. That is why I wrote this in step 4 above:

1 Like
37

That is exactly the point, which was what @SimonPoole wrote in the post that you linked to.

“Lazy” map creators will start to see inappropriate highway=path disappear from their maps, which is good - they’d currently show these paths near Everest in the Himalayas (or worse, all these) as no different from this path (in a park in Retford, near a restaurant called Everest).

Map creators who actively want to show difficult things that can still do so of course.

38

And this won’t work for exactly the point I mentioned (sorry, hidden in a footnote), which is that there won’t be just one new pathtype sub-tag, but dozens. The list @Peter_Elderson came up with is a good start:

And there would be others as well. I say we vote for a set of such ways and see which ones actually gain traction and as years go by, and actually start to saturate the ways they would be supposed to contain.

A lot hinges on which paths are considered “inappropriate”. I consider traffic signed multi-use (or pedestrian-bicyclist) ways to be inappropriately tagged as highway=path, for example. In your and @SimonPoole’s suggestion, most highway=paths would disappear from almost all maps, which—arguably—would not be good, or at least be highly suboptimal.

True, that would also work.

39

Here we’re only thinking about “ones that you might get killed on if you attempt with inadequate preparation” (see first post in this topic), not perfectly-safe-but-perhaps-not-the-best-OSM-tag examples (however you define that).

5 Likes
40

Chiming in again: This very case (from top post) got solved by prefixing the highway key, “until when somebody walks up the location and determines actual ground truth.” Seems to me, “incremental refinement” postponed? From looking at the photos in the press, this is anywhere between SAC T3 terrain (if there was a path there) and SAC T4 terrain (if there was no path there.) Happily the media echo prompted a local with intimate knowledge of the area to get involved. It did not stay one single “path” that got prefixed. Nobody knows how many of those still lurking out.

My main observation from this: Openstreetmap is understaffed. There are too few people doing the “incremental refinement” that we are so proud of.