Feature Proposal - Voting - highway=scramble

General talk Tagging general discussion
, , ,
165

I appreciate the amount of information added by trail mappers. My issue is with families with multiple ability levels and reduced mental bandwidth to read it all. Along with less experienced hikers who don’t fully understand some of the finer point of all the information available.

Could you provide a list of applications that show this information.I would love to see if a map geared to that audience presents it in a easy to understand way. Maybe we can solve part of the problem by working with applications to present path data in a clearer way.

166

sac scale information is in the database as a secondary tag, and I’m sure there are applications showing it.

Exact information on scrambles is not yet in the database in a uniform way. If it were present in a uniform and unambiguous form, e.g. scramble=yes as a secondary tag, it would enable data users to use it for maps and routers. Comparable to bridge=yes, which is generally shown on maps.

Renderers and other data users are not in the habit of using not (yet) established tags. They tend to wait until the tag is established by either approval or increasing actual usage.

1 Like
167

To tell its members what to expect from the routes they manage in a single term, the Swiss Alpine Club developed its mountain hiking scale. It combines multiple aspects that are of concern when hiking in mountainous terrain. A committee graded all their routes a long time ago. There is some value in it. Same as in the UIAA rock climbing scale and many other difficulty scales, CAI, YDS come to mind. Where I live, a system aligned with downhill skiing piste difficulties gets used officially.

Sometime in the past, mappers decided to apply this to so-called paths mapped in openstreetmap. They called the key sac_scale. The SAC has several scales, but the OSM one got taken directly from the mountain hiking scale.

To me, the gist of what you write is: sac_scale is not in any way the Swiss Army Knife to grade demands, that hikers observe in places other than the Swiss Alps. I doubt, a sak_scale key will ever be possible.

Second, both grading after sac_scale and learning something from the term when reading it from a map needs intimate knowledge of the graded matter. This is a very delicate task.

At last, I consider all those “sac_scale does it all” comments wholly preposterous. I recently learned, that the developers of the foot-profile for the router on the www.openstreetmap.org website have no clue about sac_scale and seemingly even cannot be bothered to read the wiki documentation. How then are we to expect the myriad of other consumers to be up to that?

1 Like
168

Whatever the specifics are, OpenStreetMap is always at a disadvantage when it’s trying to shoe horn an outside standard that wasn’t created by cartographers/mappers into a tagging scheme. The same goes for isced:level with schools. It’s never worked well or been widely adopted because it wasn’t made for maps and doesn’t work well as a tag. Sure renders could technically just adopt them anyway, but why force them to when tags based on standards we haven’t created ourselves clearly isn’t the best way to do things?

1 Like
169

I have no problem with grade/scale tags, I always assume some people have use for them. I do have a problem with grade values like “horrible” for a perfectly hikeable track. In that case I would rather use a well known and documented existing scale (assuming there is one, because there is an authority for everything). So I simply ignore that kind of scale. “invisible” is fine with me, even though most of the time I can see the path. I simply know that most people wouldn’t see it, just as many people don’t see waymarked routes at all because they simply ignore all the symbols and signs that stare me in the face. Dancing bear on stage kind of thing, I guess.

Speaking of scrambling, though, no scaling or grading was proposed. Just tag the scramble as a way or an area on the location of the scramble, so it can be shown on maps, included in route relations, handled by routers, and selected using overpass and sparql queries.

How to tag? I think a simple scramble=yes on a path section would be acceptable for most people.

Approval is nice but not required. Any tag you like, as long as it doesn’t break anything, right? If the tag is correct i.e. records a verifiable feature, removing it just because it is not approved, would be vandalism. The important thing is, will it gain usage? I have seen much support, so I guess it will be used, but only time will tell if it sticks.

170

I think the purpose in it being approved is that approval would give it an edge over sac_scale. Although it would be a superficial one at best, but there has to be an incentive for people to use and implement the tag in their software beyond just the raw numbers. Otherwise, why not just go with sac_scale since it has like a 100/1 advantage? At least that’s how I see it.

171

sac_scale does not give you the exact locations of scramble sections and does not even say there are any. It’s not either sac_scale or scramble; the tags give different information and complement each other.

1 Like
172

I’m aware of that. I meant it more rhetorically as far as if an app developer or end user goes. Like if I’m an app developer and I’m considering implementing scramble or sac_scale, the only edge scramble would have is being approved if it is. Since doesn’t sac_scale already have a rating that includes scrambles anyway?

173

Even if both were true, I would still like to ask the following questions:

  1. Who is the target audience of the default foot-profile?
  2. What is the most likely reason that no one has added sac_scale evaluation yet?
1 Like
174

That’s possibly a little harsh - my understanding of the routing examples available there is that they are just that - examples. The different routers there have different foibles, but they are more about showing that “it is possible to perform routing using OSM data” than saying “this route is a good route for you”, given that basic questions like “what are your capabilities” are not asked.

1 Like
175

Since it has been asserted that data consumers don’t bother with sac_scale I’ll just make a side note that two renderers I’m familiar with do at least do something with it. GaiaGPS and AllTrails choose not to render a path at all if the sac_scale is too high. One sets the cutoff at T4 and the other at T5. Unfortunately this can lead to some awkward looking gaps in trail networks when one path is tagged T4 and a connecting trail is tagged T3, but at least they are making an effort to not display challenging mountaineering routes in the same exact style as smooth flat paths in a city park.

3 Likes
176

Similarly cycle.travel uses it as a (very mild) influence on routing weightings.

3 Likes
177

The map at https://map.atownsend.org.uk takes sac_scale into consideration too. See this diary entry that I wrote last week.

3 Likes
178

There are various data consumers that use sac_scale, but most are specialized for hiking, e.g. see this comparison:
https://wiki.openstreetmap.org/wiki/Hiking_maps
And also BRouter web client is using it for routing (depending on the profiles).

So sac_scale has its uses, but less in maps for general usage. That’s why changing the highway value would be the way to go if something should change there, but as we’ve seen that’s no walk in the park.

scramble=yes is a no-brainer for me and would at least solve this case; I would probably add it to OpenAndroMaps as I already have done with ladder=yes/rungs=yes/safety_rope=yes which are kind of similar - in adding additional information to a hiking trail that is more micro-mapping and specific than sac_scale and complements it.

4 Likes
179

Do we have analytics available, how often routing is called from the osm homepage? The routing interface on the osm web page directs me here - GitHub - fossgis-routing-server/cbf-routing-profiles: Experimental routing profiles for OSRM. instead. The profile there does account for sac_scale in code. There the key has only five values, not six. From the looks of it, it should not route anything with sac_scale except “hiking”, but from black-box-testing the interface on osm, no sac_scale value on a path has any effect on the routes produced. Only distance counts. Maybe this has not made it into production yet?

Maybe it also targets software developers, that build services based on OSRMF? Though it is quite hidden for that. I wager to say, lots of router developers pay little attention to such a niche thing; so this is kind of exemplary, isn’t it? And it is right in front of the public.

True, I went there to explain a bit, hopefully in friendly tone.

Curiously, some of those hide the higher grades:

AllTrails seems to grade “hard” in their own scale starting from T2. It is a bit the same with all those scales. Some later introduce “very hard”, then “extremely hard”, what next, “insanely hard”?

180

I’d like to test but the hiking area here is infested with bicycle=no tags, so not much chance.

If I may add: sac_scale=hiking in my view does not prohibit cycling. The path my be a rumble-strip, but there should not be steep sections, where elevation from terrain model is way off, or roots and rocks where hikers have to lift their legs above the knee. If mapped not in a route relation like way, mountain_hiking though should mean lots of pushing, even haul and carry. demanding_mountain_hiking even more so and alpine hiking will inspire artistic behaviour with a bike :slight_smile:

Out of curiosity: Why is this Way: 149419322 | OpenStreetMap shown as a pushing section?

181

Thanks for adding that information, it is useful!

I would like however to add that such behaviour is exactly opposite of the one I would want:

  • in current case (parsing of secondary tag like sac_scale=* (or suggested scramble=yes), by default routers and renderers will lead people into danger, and they need special effort and programming in order to be safe (as vast majority of them will not have support for quite well established sac_scale=*, not to mention ATYL scramble=yes and similar solutions), as shown by your example.

  • however in highway=demanding_trail case (or highway=scramble case, or anything changing primary tag value) the situation is exactly opposite – by default, renderers and routers will have no idea what new value is, so won’t render it or route over it – i.e. they would be safe by default (and it would take extra effort and programming by authors of apps designed for hiking mountaineering to add support for it - where those few authors so inclined, as you note, will add proper support: i.e. different rendering/routing depending on difficulty and/or user preferences etc.)

So to me, only sensible solution is something that is safe by default – that consideration simply cannot be something optional that only a few app authors might have resources, knowledge, will and time to implement.

And that means using separate highway=* value instead of adding a secondary (more-or-less trolltag) to highway=path (e.g. if I need special equipment / skills to pass this “path”, than it is not really a “path” – it is borderline in scramble case, but even worse in other cases like mountaineering and others which would be covered by more generic highway=demanding_trail or similar primary tag value).

Of course, secondary tag like demanding_trail=scramble or demanding_trail=mountaineering or demanding_trail=jungle or whatever might be used to add extra details to that ignored by default primary tag value highway=demanding_trail.

4 Likes
182

Why do you think so? sac_scale=* OSM tag (as opposed to other meanings of words “SAC scale” you may have encoutered) is defined exactly as pertaining to exact locations / sections, and not on whole route (“relation” is OSM parlor, where it is forbidden to be used).

So if there is hikeable part of the route, that OSM way element will be marked with sac_scale=hiking, and if after that there is 50m way element that requires use of hands, only that way section will be marked as say sac_scale=demanding_mountain_hiking (or sac_scale=alpine_hiking) indicating use of hands is potentially needed (or required in latter case).

It’s not either sac_scale or scramble; the tags give different information and complement each other.

I’ve heard that several times, but always vaguely, and never explained exactly - even if that would be primary thing to consider when proposing new tag - how you envision it being used. Without such information, there is much less chance of accepting a tag (if not even proponents have an idea how it will be used by data consumers!)

So, assuming that something scramble=yes gets approved, how would you (propose to) modify your favorite router (and renderer) to use it?

In this thread there was example for cbf-routing-profiles/foot.lua at master · fossgis-routing-server/cbf-routing-profiles · GitHub; how exactly would you want it to change its behaviour for your “I want scrambling” profile, and how for your “I want to avoid scrambling” profile? (line 177 is example for sac_scale; for reference of how to use similar feature).

Feel free to use some other router and renderer which you use or would consider using instead, for showing what configuration changes exactly would you like, if you dislike one linked above.
Contrast that new handling of scramble=yes with its current handling of sac_scale (hopefully it handles that; because if it does not, there is likely even less chance it would support some new tag - if that popular one is unsupported!)

For example, here is how I would handle it in my I'm old and fragile and want to survive (AKA “no scrambling wanted, just give me a leisurely walk in the park”) profile:

    speed_path = {
+     scramble = { yes = 0 },
      sac_scale = { hiking = 0.5,
                    mountain_hiking = 0,
                    demanding_mountain_hiking = 0,
                    alpine_hiking = 0,
                    demanding_alpine_hiking = 0
                  },

So @Peter_Elderson how would you modify it for your “I’m a scrambler and I wanna scramble” profile instead? Question is also for @Hungerburg and other proponents of “scramble is totally different from sac_scale” philosophy – how exactly (i.e. show me the config code change like above!) would you want this (or some other) data consumer (e.g. router/renderer) to use your data?

2 Likes
183

This is exactly what I would expect from these profiles. Namely, to be a minimal working example that demonstrates all the relevant functions. This assumption holds true for the foot profile I linked, but not for the bicycle profile in the same repository.

To be honest, if I wanted to develop an APP built on top of OSRM, the foot.lua linked above would have been the first thing I would have copied and pasted.

My guess (after a quick glance at the code) would be that routing and time estimation is done in two steps and the code you linked only refers to the latter. If you wanted to exclude certain ways from routing you would have to add it to

    avoid = Set {
      'impassable'
    },

which is ultimately handled here: cbf-routing-profiles/lib/way_handlers.lua at 16453fa5ded78671560dba15e124ea5bac6d52d3 · fossgis-routing-server/cbf-routing-profiles · GitHub, or implement a a new sac_scale_whitelist (which would probably be the most reasonable approach).

The problem is, that this is not true. Here two BRouter examples:

And the guy behind BRouter Web is a cautious person. He once said in an interview that he intentionally does not have an MTB profile on his website because he does not want to be held responsible when people do stupid things because his router tells them to.

184

But we should also keep in mind that even specialized routers that strive for the “perfect” hiking or biking profile will always have to perform the balancing act of maintaining a high fault tolerance for bad data without losing the ability to capture all the fine details that OSM has to offer.

A trustworthy router doing everything right would just as easily throw you off a cliff if the underlying data was only bad enough.

My naive assumption would be that adding scramble=yes combined with a concerted effort to make the available default profiles of the major routers (valhalla, osrm, graphhopper, brouter) more robust could satisfy almost everyone.

1 Like