Should keys like trail_visibility & sac_scale etc exist, given difficulties with verification / some interesting thoughts on trail_visibility

The reason I indulged the hotel stars tangent above is that it does a good job of illustrating the tradeoffs around ensuring consistency. Because stars is a single key that’s guaranteed to be inconsistent across countries, data consumers can’t do anything more intelligent with it than display its value verbatim when selecting a search result. That’s not necessarily a bad thing: a user looking for lodging in their country will understand this system better than any other. But a user from abroad would need to adjust to this system.

I’m not experienced enough with outdoors pursuits (other than field-mapping) to comment intelligently on either trail_visibility=* or sac_scale=*, but I have often seen trails signposted with a difficulty level according to an ad-hoc system, sometimes inspired by piste difficulty markings.

If this difficulty level is useful enough to signpost, it’s probably worth exposing to the user, probably via a separate key. Otherwise, I don’t know how a data consumer could confidently derive the same succinct, intuitive rating from OSM’s SAC-esque scale. As it is, mappers are stuffing the ad-hoc ratings in name tags because they expect the ratings to appear in map labels:

Globally harmonized classifications can help data consumers make better automatic decisions: prioritizing a major city’s label over a nearby town’s based on place=*, color-coding roads based on highway=*, penalizing a smoothness=very_horrible trail, or preventing a route from going down a T4+. Meanwhile, recording verifiable, locally recognizable classifications can help users make decisions of their own: choosing a three-star hotel over a one-star motel, patronizing lgbtq=welcome establishments, or deciding against a “difficult” trail in favor of an “easy” one. It all adds to the quality of the map.

4 Likes