Thank you! I think that is a fair assessment of where we are now. But I think it is certainly something that can (and should) be discussed further.
So let me try again:
Problem statement: unlike any other feature (top-level) tag, highway=path on its own makes abolutely no promises as to suitability for any mode of transport it is legal for (chiefly foot, bicycle and mtb). This is in contrast to, say, unclassified, cycleway or even track (which pretty much creates an expectation that a regular car or bicycle ride will be between uncomfortable and impossible).
Apart from renderers and routers, this vagueness creates a problem even for humans trying to interpret the map and find a good way through an area. If you plan your easy stroll in an unknown area, you might end up scrambling across meter-high rocks. If you plan to have a nice bike ride in a countryside, you might end up carrying it on your back across mud or 30% inclines.
One suggested solution was to somehow divide the whole scope of path quality into three categories:
- well-maintained urban highways for shared use of pedestrians, bicycles, motorcycles, horses and/or carts
- countryside trails suitable for hiking and mtb, but hardly for biking
- mountainous trails requiring advanced terrain skills.
5 Likes
Ok, these are currently mapped as highway=path.
Is that (a) a problem in itself, is it (b) a problem for mappers, or is the problem (c) that a highway=path without further specs (extra tags) does not cover it, making maps and routers (and, by consequence, people) display and use it in unacceptable ways?
If a) Alternative main tag is needed specifically for this kind of route/path/passage, after which it can be taken out of the spectrum, and all occurrences need to be located and retagged. Until then, highway=path can still be this kind. Highway=path will still be ambiguous.
If b) I don’t know. Confusing? Counterintuitive? Unverifiable? Too much work? => clear tagging scheme, documentation and tooling.
If c) The main tag stays highway=path, but suitable attributes should be added as secondary tags. If there is no suitable tagging scheme: then this can be worked out and proposed. After, all occurrences need to be located and retagged. Until then, highway=path without further tags can still be this kind.
The problem that data users can’t know what a way tagged highway=path actually represents, can’t be solved by fixing this mountain route problem, or any individual path type/class problem.
Based on a poll, it seems that almost half of the mappers don’t know that, either. Or, wait, is it the other half?
No. The first one is. It is a T6 path and a hiking trail.
There are some routes like this where people attempt to go, fail, and then subsequently delete the path from the map. The author is clearly upset. More details in
The second does not have any paths on the map. I’ve mapped it with a Path during preparation, based on trails from websites but it was deleted almost instantly. When I actually went there, I’ve found some cairns marking certain sections as safe.
This thread has more details on that:
Who decides on this? That’s the whole point of discussions. If I can just introduce a new tag, then I might start mapping these pathless routes and climbing pitches with a new main tag instead of climbing=route, for example.
There are other discussions about introducing scrambling as a separate way, as well as motorcycleway. All currently mapped as a Path, or not at all, depending on if it gets deleted.
Also, if you simply scroll to the first post, there’s a bunch of related threads with more details already linked. Each explains a particular problem in more detail than is worth repeating here.
End users get the information through rendering and routing, so this comes down to: highway=path in itself contains, apart from default access for foot, bicycle and horse, no further usability information to properly display it and use it for trip planning and routing. This can result in unexpected unpleasant and even dangerous situations, because renderers and routers will apply there own ideas (application-level defaults) of what a highway=path is.
Would this be a commonly shared problem statement?
5 Likes
That is what I tried to do here. The reaction to it was muted. I am not sure if it is because everybody is exhausted from the discussions or if it does not strike anybody as patently wrong (which would be a great thing) so they do not feel the need to object.
Perfect, I implemented it into the other thread, thanks!
2 Likes
We just started waking up in North America 
.
Correct. It sounds like a reasonable summery of the problems stated so far.
1 Like
Are we not reinventing the wheel here. Could we not use all the options used for highway=track and apply them to path. viz tracktype, smoothness, visibility, surface, width, access. With additional tracktypes for special environments.(leaving highway=footway etc as it is for now but maybe allowing the same to be added as appropriate). This would be far simpler and more consistent.
1 Like
and is, therefore, causing all sorts of problems because everything else, other than 20 types of roads, is crammed into it. Adding specialized sub-categories (tags) would help separate what is obvious, leaving the dubious pool smaller.
My question, which nobody has answered yet, is - is there a problem with adding new tags?
Should we just go ahead and implement the obvious ones? Changing the obvious problems into the new tags and updating the documentation (wiki) until it gets traction?
1 Like
That is one possibility that I and other people have suggested in the discussions.
Would you say the following “paths” should use the same tag and that sub-tags can clarify all the differences?
There’s probably many more different versions of what gets tagged as a path.
7 Likes
I think there are several suggetions out there:
- Just add surface, width, etc. and don’t invent something like templates or new tags
- Use something like
tracktypebut for path to specify the quality of the build, visibility and surface all in one - Use
path=*or similar to apply a “template” which would classify the path into a logical category - Create new top-level highways like
highway=two-wheels,highway=shared_use, and so on.
The only thing that we know is, that we currently have (1) and there are still issues, some of which can’t be solved using existing tags, because we can’t express if a path is suited for a mode of transport, just if it’s allowed.
We could also use (2) and (3) at the sam time, but I’m not sure this is going to make things easier, because a “scramble” is by design of a completely different build (quality) than a shared-use path. I just don’t want to rule it out.
I wouldn’t oppose a vote on this, because if (2) wins, then it would be very easy to move forward compared to designing categories or top-level-tag-values.
1 Like
Could you, please, elaborate on why is it easier to separate a path with inclination 90 degrees, visibility horrible, uiaa scale VI, surface rock, than if it was tagged as a pathway=climbing, given the photos above?
1 Like
Well, it is a solution, however, some people (me including) think it is suboptimal. I assume you suggest keep using highway=path indefinitely and just add different path=motorcycleway/…/scramble/pathless. For sure, it has the advantage of being completely backwards compatible. But that also means it would solve the problem only partially if at all for two reasons:
- Would there be enough motivation for people to add the secondary tags?
- Would the data consumers ever stop being lazy and start interpreting those tags so that situations like this would be prevented: Dangerous 'path' on Table Mountain needs removal
I think such subtags should be a transitional solution and should eventually be promulgated into primary tags (so they would be encouraged to be used without highway=path) so that consumers would be forced to deal with the change.
2 Likes
I dont know what you mean, but I was saying that if we come to the conclusion, we just want the analogy of tracktype for paths, then there wouldn’t be much discussion, because it’s already established tagging and meaning.
As for your examples, a lot of them, I would not map as a path, or even a way in OSM. Picture 4, for example, I would rather put into a relation of the marking-nodes. But that’s a completely different problem, I don’t come from a mountaineering background.
I wasn’t suggesting using subtags but actually think that adding new tags would be the best option. There will be an overlap, of course, for a foreseeable future.
However, if the path description is updated with the links to the pathway= classes and then the paths we know fit the new categorization get updated, I’d assume people will start updating them.
Path, as something of a dirt track, fairly narrow, and potentially difficult, as well as a 1m space between the buildings where one can walk or ride a bicycle or fly a Red Bull plane sideways, will always remain because not everything will fit into the current solution. Then we can create specific solutions for those problems. However, no solution will fix all problems at once and forever.
I’d be happy if we introduce a separate climbing “path”, then a pathless “path”. That already takes a number of issues away. Then a motorcycleway, then a … You get the point.
2 Likes
Thank you. That’s exactly what’s preventing me mapping them in OSM.
As far as I can see, 4. is the only solution to the highlighted problems. The great majority of renderers only support the top-level tags (e.g. highway) and do not have any interest in supporting additional tags, besides maybe sac_scale and mtb:scale for some outdoor apps. Dangerous situations, and rescue operations happened because end-users relied on general-purpose apps (not the outdoor ones) and followed along a path they expected to be a hiking trail, not e.g. a climbing route requiring equipment.
I favor this approach because we can move forward step by step. The main challenge, besides agreeing on the scope of each new tag, will be to get enough votes since there seem to be quite a few members opposing categorically new tags.
1 Like
Yet none of them can really say why.
4 Likes
Human don’t like changes. We know what we have, we don’t know what we will get.
2 Likes