Not expects bulletproof, at least I’m not. I am looking for a descriptive tag that give the average user a general idea of the path’s level of difficulty. Much like sidewalk implies a path separated by a barrier from a nearby road. So that anyone familar with the concept will recognize it even if the exact construction method is different.
In the case of the fossgiss foot routing profile, I’d then call that a greylist instead. It might make sense there, if this is exemplary code, then the enumeration is just in place to give pointers to the base canonical tagging to ease refining. Of course, the logic employed fails on the wrong side with erroneous tagging like e.g. difficult_mountain_hiking. Should be solvable in code though. Who is to file the issue?
Of the routers tested so far, only BRouter seems to route anything in the highway=* key. Most others select for complete tags, like highway=path, unless there is e.g. a hiking relation on top of it. Martinswand is a true via_ferrata. In my eyes, routing there will not bring anybody into doing something stupid, it will only make people angry at the router, and that starting on the approach paths Who is to file the issue?
I remember you calling sac_scale a local thing. I wholeheartedly agree with you on this. Still I ask: Can you come up with a universal scheme?
I think OsmAnd does look at secondary tags in its router profile. It also has an option to “see” that a way is part of a relation, but that is not really true: OsmAnd does not know relations. When transforming osm into the OsmAnd database (which is part of an update), membership of a relation is ‘translated’ to a tag of the way itself, which can be handled by the render style and by the router profile.
FWIW my sense is that the “I got sent on a lethal mountain pass” issue is mostly a rendering problem, not a routing problem. Even routers using their engine’s default profile are typically much more sophisticated than most renderers, and router profiles are less sclerotic than deat old osm-carto.
BRouter basically does it the same way: brouter/lookups.dat at 1e542d19b7c45a4ee685acf20a858934bb4e2f6c · abrensch/brouter · GitHub
OSM Carto already takes surface attributes on footpaths into account, so maybe it is not too far-fetched to also consider
trail_visibility or even
Don’t hold your breath.
OSM Carto is a general purpose map, so I don’t think so.
I would argue that a path (in the context of OSM) is something some people can walk on. So even if all scrambles were tagged
highway=scramble we would still have lots of paths which are probably way too difficult to be walked on by average Joe, yet would still render on basically all maps and yet would still be included in routers with non sophisticated tag evaluation.
Guessing the likelihood of a segment being dangerous (or unwalkable by average Joe) and adjusting the rendering accordingly should be within the scope of a general purpose map.
One of their main things is to only render tags that have global or semi-global usage, which unfortunately you just can’t get with a tag like sac_scale that is based on a mainly German and alpine hiking use case. There’s only so many dangerous alpine hiking routes out there and most of them are in the Alps.
Sure, there’s lower sac scales for safer trails that could technically be applied outside of Eastern Europe, but it’s pretty obvious nobody wants to use sac_scale for them. Anyone who thinks otherwise is trying to fit a square peg in a round hole. I assume the developers of the style know that and don’t want to encourage the tag being used where it’s unsuited to be by rendering it. The same goes for rail_visibility and mtb:scale to some degree. Although admittedly less, but at the end of the day they have the same problems as sac_scale.
OK, this is about carto, but I read several times some misconceptions about sac_scale, so: yes, it’s for mountain hiking (not just alpine hiking) and was originally from Switzerland; but it’s use in OSM is different (it also spilt of trail_visibility which is part of the original sac_scale). Its proposal from 2008 suggested a “classication scheme for hiking trails” in OSM; from the rationale of the proposal:
“As far as I know, there is no internationally standardized classification schema. Thus, I propose to incorporate the [classification of the Swiss Alpine Club](source in german). Not because I am from Switzerland (I am not), but because in my humble opinion this one is easy to understand and well defined.”
Although the use density is highest in Europe, keep in mind that only in Switzerland hiking trails are marked on the ground with it (and something closely related in Allgäu/Germany and Vorarlberg/Austría, but those are really small areas). So outside of Switzerland it’s used as a standardized classification scheme, although quite often local ones exist - e.g. in the german OSM Wiki you can find this to convert local schemes to sac_scale:
I haven’t counted, but it’s probably more used in OSM outside of its original area than inside. And I don’t really know of any other hiking classification scheme in OSM that is widely used outside of its original use area.
So back to carto - I don’t think that it’s the usage of sac_scale that prevents it from being used for rendering; probably more the specialized tag category which doesn’t fit the general purpose map - which brings us back again to a first level tag which could change this…
It took nine years and countless dissertation-length issue comments for osm-carto to render surfaces - a cartographic decision for which there is plenty of precedent to draw on. So I’d estimate sac_scale might be supported c. 2032.
I don’t have the time to read through the 124 comments just in issue #1500 that it would take to figure out exactly why it’s not rendered. But here’s a comment from Imagico from February, which I think has essentially been his opinion about it for a few years now if not from the beginning of people asking for sac_scale to be rendered.
- sac_scale: is documented to provide an aggregate of specific dangers of hiking in alpine environments but is evidently used also in non-alpine environments with obviously different semantics - which are unclear and, from looking at the data in a few places, evidently vary.
So yes, your technically correct that the tag is used in non-alpine environments, but it’s not all the same. IMO treating it otherwise would be like saying a tag has global usage when it is used correctly in Europe but everywhere else the usage was due to vandalism. Well, maybe not that extreme, but it’s a difference without a purpose as far as if it will be rendered or not. At the end of the day if alpine environments are the only places that are tagged in a semantically correct and consistent way then wherever it is mapped literally doesn’t matter.
Oh that’s a different thing; I didn’t say that it should be used outside of mountains (alpine areas), but it doesn’t matter where those mountains are. I agree that it’s often used outside these, but there are tons of tags which aren’t used as defined but that are rendered by carto.
From the comments on the proposal page in the Wiki, especially the one by @Mateusz_Konieczny I gather, that some opponents considered the threshold too low, so it would affect too much, e.g. some favourite paths in the Tatras.
Please do not cite this. It is wrong. This is just a copy of what somebody at the DAV, probably a graphic designer, came up with some time in the past. This is comparing apples and oranges. See the paragraph before: There I made a table of what I observed on the ground from signpost markings with what openstreetmap data contains. This got replaced and ridiculed with this copycat chart under pretence of quoting “authoritative sources”, as if this was wikipedia?
@Hungerburg, one of the criteria for distinguishing between
via_ferrata in the
via_ferrata proposal is:
If we merge this with one of the statements in your proposal:
we end up with the conclusion that a scramble is a path.
I interpret Mateusz’s criticism in such way that
highway=scramble cannot be delineated sharply enough. And in my opinion the threshold is certainly too low to justify that such segments are no longer shown on the standard map and at the same time too high to really catch all non-walkable (from the perspective of average Joe) paths.
At the Wiki article isn’t really clear about that since while it says “The key sac_scale=* is used to classify hiking trails in mountainous areas”, there’s nothing that stops someone from using T1 in whatever environment they want to. Really though, “mountainous” is kind of an ambiguous misnomer anyway. That’s a lot of the problem.
Most or all of those tags were rendered back in the day before Imagico started being the main maintainer of the project a few years ago. I’m not it’s 100% his doing, but they have been a lot less lenient about those types of things in the last couple of years since he mostly took over. There’s actually been some discussion to remove rendering for the less well defined tags, but it’s always easier to add rendering for something then to remove it. Either way, you can’t just point to a tag that was rendered 15 years ago as a justification to do the same with sac_scale. Obviously projects and the priorities of maintainers change over time.
Lacking own hands on experience, I cannot decide this File:Krywan podejscie.jpg - Wikimedia Commons from the photo. One commenter here even said, we should not create tags, that are not verifiable from aerial. So yes,
this might qualify as a scramble. Perhaps a uiaa=0, yds=1 scramble? All I can see on the photo, there is no path there.
Judging from the photo T4 probably would not be all that wrong.
I would strongly disagree with that and I also don’t think that the fuzzy threshold is the main problem with
Most definitely, and I would even go so far as to say that this would already be a big no-no from the perspective of average Joe.
If the people on the photo aren’t average Joes and Janes, then I do not understand what the reference means From the picture alone the location could very well lie on a “occasionally you might have to use hands for balance” demanding mountain hiking route combined with “intermediate” to “bad” trail visibility, because the trail/route, even though invisible on the photo, might be easily found from assessing the terrain on site?
So, after some search: Here the path to Node: Kriváň (260278694) | OpenStreetMap is a T6 (the grade evolved over time, look at the changesets history), here Krivan (2494m) - Nationalberg der Slowaken [hikr.org] a T3+ and some more photos with lots of Joes and Janes. Such a difficult alpine hike is too prominent to not show on the openstreetmap standard view