SAC_scale, why not on relations?

I just opened a discussion, Talk:Key:sac scale - OpenStreetMap Wiki - I’d say, use on relations is perfectly sensible, don’t you think?

Can you add some explanation why this would be useful?

The SAC scale defines a property of a particular way. A way always has the same SAC scale, independent of which hiking route you are currently following. Just like a surface which you wouldn’t add to a relation either.

6 Likes

No, I don’t think so. If a hiking routes is tagged with a high level of “sac_scale”, it would prevent me from following the route, although I just only want to reach for a restaurant which is easily accessible after 30% of the total length.
Different “sac_scale” might be appropriate for parts of a route (ways), as “surface” does. No one would tag a motor_way relation with the surface=bad just because there is a 200 m stretch under construction.

6 Likes

and what you would put there? maximum value over route? median? average?

how it would be beneficial over getting this info from individual ways?

3 Likes

First impressions were to agree with @scai and @ToniE, but I think the way that wiki text is formulated (with the proviso of no alternatives) does makes sense. Also, I know the author thinks deeply about such issues as they encounter them in their local area. My reading though would be that they are suggesting applying the difficulty to all ways in a route not to the route relation.

As a potential user there is nothing worse than planning a route only to find that part of it is too hard for me. It’s well established that hikers often continue in such circumstances and then get into inextricable difficulties. Tagging only on the way whereas undoubtedly correct, may not be picked up by some data consumers making intensive use of hiking relations, and although such a value is derivable, this may not be as easy in practice as in theory. In many areas entire hiking networks are covered by relations, and the likelihood of consumers only using these may increase. It is clear that the purpose of this change to the text is to minimise this issue.

tldr: It’s a reasonable suggestion, but probably needs clarification.

The OSM-US Trails Working Group may have input based on their experience.

I’m not that much into hiking mapping but I know that in Italy we have a different tag for relations: Proposed features/cai scale - OpenStreetMap Wiki
The value is decided by CAI (as far as I know) so it can’t be used outside Italy, but maybe can be an inspiration for a new tag?

This would avoid tagging ways with a wrong SAC scale. Did you read the change to the wiki article I linked?

The recent change to the wiki article recommends against that. I agree with you on this.

The route shall get the maximum. That is how the SAC itself uses its scale. The idea perhaps: If you use the route, you do so to reach the POI where it ends.

Thank you. This is the heart of this topic. Who is in charge of Generalisation? Is it the mappers, is it the cartographers, the routers?

The SAC uses its scale, that the OSM scale is based on just the same. It is only in openstreetmap, where the scale is not allowed on routes, only on ways.

E.g. Relation: ‪Zustieg Guggihütte‬ (‪12822598‬) | OpenStreetMap is a T5 route, that only contains T4 ways. One of those T4 ways is T2 at most. You will find many more routes, where the start is easy, but it will get difficult somewhere, that once maybe got mapped as a single way, later got split, surface, trail_visibility and other such, and sac_scale remained that of the route, not of the way.

IIUC, there are 4400 hiking routes with an sac_scale tag. Does that make it de-facto?

1 Like

Personally, I do not consider a change in difficulty, as measured by sac_scale, worth a split of a way. If on a route there lies a POI, eg. a viewpoint, where on arrival I can turn back and not think of myself a loser, that might merit a split. The wording “alternative” restricts such POIs to branching nodes. I think that is too narrow.

2 Likes

The same happens with nordic ski routes: piste:difficulty is de-facto sometimes mapped on ways and sometimes globally on routes.
As a result, in OSM there are ‘easy’ routes containing ‘advanced’ ways and every counterintuitive combination you can imagine.

Asking some mappers how they map the difficulty of a route, I had at least two people replying that they can’t possibly remember each and every section of a 50km run, so they map an average.

This results in you can’t really say if the route difficulty is a maximum or an average or what.
On the other hand, if a mapper has taken the time to split and tag each and every way accordingly, then there’s no question at all.

As a data consumer, I just prefer to ignore piste:difficulty on routes at opensnowmap.org because I can’t trust this mapping enough to be certain not to send novice skiers where they shouldn’t.

2 Likes

Yes, there are plenty of reasons for choosing an out-and-back hike along part of the route, most of mine would be those of a naturalist: to find rare plants, or butterflies which use a specific plant, to look at a geological exposure etc. This is one reason why where I have added SAC scale I’ve given different values to different parts of the route: this is very applicable in the UK, often only quite short sections of a route will be above T2, and even then many are avoidable.

I think there is maybe a misunderstanding shared among some participants in this thread.
A hiking relation in OSM is a complete route, sure. If some of us like to ‘do’ a complete route, officially from A to Z, fine.
However this is not the single use of a hiking route relation.
Any hiker is of course free to hike as she/he please and follow a route only for a short part, yet knowing on which route they are, if only to get directions.

As a driver I often take the A1 motorway, but very rarely go to Geneva or Zurich.

4 Likes

From my point of view: When showing the route in an app, the app should do an analysis of the member ways and decide on sac_scale, length, difference in altitude, … how difficult the route will be.

Background: We planned a hiking tour L'Ardèche à Ruoms – Ardèche cirque de gens Loop from Pradons | hike | Komoot
At the time of planning, Komoot said, based on single highway=path tagging on the relevant ways, that this would be an easy, fits for all tour - it wasn’t! See picture #12 @ 3.75 km added by Radidruide

After adding sac_scale, incline, surface, smoothness, … to parts of the ways: Komoot now more or less tells the truth: “Sure-footedness required” and you should be “free from giddiness” (my suggestion).

This should be the way to evaluate the difficulty of a route and not adding sac_scale to the route-relation. sac_scale of the route relation may differ from maximum sac_scale of the ways after some time: someone simply forgot to adapt the sac_scale of the route relation after modifying some member ways.

1 Like

One more use of tagging the relation is when you only know the sac_scale of the whole route. Then tagging the relation is infinitely better than tagging nothing.

Tagging both is a bit more contentious, but I think data consumers should be able to ignore the route tags if ways are tagged.

1 Like

@yvecai Please, if you quote, do so correctly. Or abstain from using my nick, if all you need is a scapegoat.

@Hungerburg Sorry, that wasn’t my intention. I removed the quote.
I just wanted to be sure everyone is aware of different use people have of hiking relations, and that going trough the entire route is just one of those.

Hello Toni, Not everybody is using a router. Some people use plain maps, some with overlays and such, some even use printouts. It would be a pity, if they went on a route, because they failed to spot the 5m T6 section invisible in an overview zoom. Therefore I have some sympathy with the recent addition to the sac_scale wiki article. My thinking was, wouldn’t that actually better be held in relations?

In addition to the sac_scale on ways? Yes, but not as a replacement.

1 Like

Of course in addition. I never thought otherwise. Should I have mentioned that? The linked route above does so. Current practice, to tag all segments of a route the difficulty of the route made me prompt the topic: Why is it not allowed to tag sac_scale on the relation (in addition), and tag ground-truth on the ways?

That would avoid confusion, at least for me.

At least, and as I pointed out, this information can be derived from analysing the sac_scale of the member ways - even renderers can do that. This would avoid potential differences of sac_scale in relation and maximum sac_scale of member ways - which could of course be found by QA tools.

Redundancy is OK, but who will check for errors?

1 Like

I come back to the wiki page edit linked from the talk page bullet linked on the first message above:
https://wiki.openstreetmap.org/w/index.php?title=Key:sac_scale&diff=2374874&oldid=2374872

Someone added the following text:

Apply the same (greatest difficulty) value for all ways that form a route, unless alternative routes are available that avoid the greatest difficulty.

With this thread, the topic of Tagging sac_scale on relation is still under discussion.

Meanwhile, it seems to me that the wiki page edit does not meet consensus. Anyone bothered if we remove this addition for the time being ?

2 Likes