New siblings of foot/cycle/bridle/way

type=route has 99.27% coverage for route=*

5 Likes

This is also a very valid option. A sub-tag would allow for more-detailed specification (I.e. pathless?) while allowing for a fallback to path if not recognised.
I don’t know if that will prevent people trying to walk over vertical climbing routes but I guess that’s the risk we would have to accept.

That would depend on defining the right categiories, mappers mapping right, and applications using the mapped information in the right way. As always in OSM.
It would, however, make sure the whole range can be covered, so correct usage of the information will predictably reflect in updated applications.

Applications choosing not to use the information will be no worse off than now. Adding a correct subcategory leaves the current database intact, no information gets lost.

A logical progression of path types by difficulty and/or risk will not end all discussions, but they can likely be limited to choosing between two adjacent subcategories, instead of choosing between deleting or adding the path|route|probable_line_of_travel.

Defining categories path=* will not replace the need or wish to apply appropriate physical attributes, legal access tags, scales or hazards, but these could probably be handled more relaxed, mostly tagging exceptions/edge cases/special rules limited to a country or region or zone.

I also think it w|c|sh-ould not replace the existing main designation categories which are now main tags.

If I may put the quote out of context?

I trust in peoples situational awareness – I do not see the damage in people dying from wrong advice, I see the damage in bad advice and people having to back up to some other point to get to where they wanted and hating their router/map for sending them to such bad places. Of course, it will get harder when backing up includes 500 metres of altitude lost. Then some may overstep their abilities
 But such cases rather rare. Most misguidance will remain unnoticed by both press and openstreetmap contributors/consumers.

2 Likes

Just to mention, the latest addition to highway=* was ladder. I confirmed today, a highway=ladder mapped in 2024-03-03 still makes routing over it impossible in both valhalla and graphhopper. Of course, I you are in need to route over there, brouter always available, it treats anything highway=* as routable. And that I think is quite in line with what the documentation of key highway says.

1 Like

I have been forced to back up about that distance, though the altitude was at most 30 m. In a car, sent there by Google Maps. I still blame GM, though I have to admit I was pretty stupid to keep on thinking that the track would widen after the next tree.

Since you’ve asked for the default Path a few times already
 To me, The (default) Path is something like the initial photo on
https://wiki.openstreetmap.org/wiki/Tag:highway%3Dpath
except it is narrower. The one on the photo is more like a forest road, a track, as it is wide enough for a tractor to pass through. Surface=ground. The rest would probably have a more specific name, which would be used in the path= sub-tag (footway, cycleway, shared_way, 
).

As the highway=ladder seems to be coming up, shouldn’t that then be path=ladder instead? I don’t think vehicles use ladders.

1 Like

Since one climbs a ladder, would a ladder be a
 climbing route? :smile:

1 Like

:smiley:
Unfortunately not. Climbing routes are not made for aid-climbing. Ladder would be considered a man-made aid for climbing, so definitely not.

1 Like

Via ferrata?

1 Like

there is also https://wiki.openstreetmap.org/wiki/Key%3Aassisted_trail

BTW, highway=ladder was approved by nobody ever made a wiki page for it?

Good point. what is the requirement for something to be eligible as a highway tag? vehicles don’t use steps either.

Er


2 Likes

2.5 M parking=surface but 64.3 M surface=* surface | Keys | OpenStreetMap Taginfo :melting_face: :grinning: :grinning: :grinning:

???
surface=* is not really a classification key for parking=surface, it’s just a physical detail tag.

parking=surface is itself a secondary classification key for amenity=parking. You can more or less see it as a synonym for “parking lot” (as opposed to roadside parking, 
).

3 Likes

sorry, was obviously kidding with the parking example, actually there are two-key designs where the secondary key has a high level of coverage, for example
tourism=information
has almost the same number of uses as
information=* information | Keys | OpenStreetMap Taginfo

3 Likes

leisure=pitch and sport=* have a nice overlap. And highway=track + tracktype=*

I think there might be a correlation of usefulness of the secondary tag to the mappers. Tracktype is widely useful (thoughthe definition is not great, I think it should incorporate the type of vehicle that can usually traverse it or some other functional criteria) both to drivers and hikers. For me as a hiker, width, surface and smoothness is more or less irrelevant on a path - I assume it is ground (which is kind of obvious from the local geology and ecosystem), width enough for me to pass through and smoothness kind of ok if it is not mountain hiking and above. On a typical path, which is trail, most people will be like me. Plus anyway, I think one subtag is the most we can reasonably expect. I can see that path=* would work, though I still prefer deprecating path eventually and moving over to pathway=*

Ha, I wonder where I was looking, I swear I managed to land on an page that looked like empty page for ladder :-D. Anyway, I at least cleaned up Key:ladder - OpenStreetMap Wiki
and Key:assisted_trail - OpenStreetMap Wiki a bit.

BTW: most of (all?) the translations of ladder=yes do not reflect the new usage at all. Is there a way how to notify translators about changes in the English wiki?

2 Likes

You can manually add {{out of date}} to each of the translations. A more reliable system was approved by a supermajority of voters as a tagging proposal (long story), but it hasn’t been installed yet. You can follow the progress on GitHub.

1 Like