I’d like to propose a best practice for tagging pistes (route=piste) that could reduce redundancy and improve data consistency.
Current Situation
Currently, each underlying element (ways/areas) of a piste needs to have attributes like:
piste:type
piste:difficulty
piste:grooming
piste:name
piste:ref
piste:status
piste:oneway
piste:certifications
piste:lit
piste:abandoned
This often leads to duplicate data because, in most cases, all elements of a piste share the same attributes. If an attribute changes (e.g., piste:difficulty), mappers have to update every single element, which increases the risk of inconsistencies.
Proposed Best Practice
Instead of duplicating tags across multiple elements, I propose:
Tagging the relation (route=piste) with common piste attributes (difficulty, grooming, name, etc.).
Tagging individual ways/areas only when they differ from the relation.
Data consumers (renderers, routers, etc.) should assume inheritance—if a tag is missing on a way, it should inherit it from the relation.
Why This Makes Sense
Some renderers already do this! For example, mapy.cz correctly reads piste:difficulty and other attributes from the relation.
OSM Wiki already hints at this approach: The documentation for piste:grooming states:
“This property is used with piste:type=* on way ways or area areas and route relation relations of route=piste.”
Less redundancy & easier maintenance: A single change at the relation level updates the entire piste.
More consistency: Avoids cases where some elements are left with outdated or conflicting attributes.
Next Steps
If there is agreement, we could:
Update the OSM Wiki to explicitly recommend this practice.
Encourage validation tools (e.g., JOSM, Osmose) to suggest tagging the relation instead of duplicating data on every element.
Engage with renderer and router developers to ensure they properly interpret inherited piste attributes.
Would love to hear your feedback! Is this a practice we could officially recommend?
I’m a fervent proponent of detailling piste:difficulty on ways for crosscountry skiing to show exactly where some piste is steep and often icy, for instance.
Other are happy to map piste:difficulty on route relation, either for the average difficulty, or the one of the worse section. Or the colour if it’s standardized in a particular country (Germany ?), or where colour is more related to the piste length (France), totally ignoring a simple tag like colour=*.
Now you propose yet a new alternative.
As a data consumer I can only trust piste:difficulty on ways for cross-country ski pistes to denote a particular difficulty somewhere along a piste.
The elephant in the room being such Winter_sports tagging has seldom contributors, and relying more on relations instead of simply tagging ways won’t help in that respect.
Moreover, redefining the wiki certainly won’t change the original intent of the past contributors to >150’000km of pistes, whatever it may have been, and at the current pace any remapping probably won’t take less time than the ellapsed 20 years.
Yves - Opensnowmap.org
Waymarked Trails do that for hiking, rinding… routes.
This isn’t new
This “old” practice probably was the only one before the creation of relations in OSM, especially (route relations).
There is a lot of issue with this practice, especially when the way is shared by many real routes.
For hiking, we found osm ways with descriptive names, name of the route instead of the road, old route “names”…
A big mess (and I talk just for this tag ).
So @AlesKubr go ahead, we could recommend this practice.
Are you really sure using “data inheritence” helps attracting more skiers mappers ?
This is very much logical to go this way for us ‘power mappers’ or data consumers, no doubt. But to find more skiers mapping in OSM, such concept is a barrier of entry.
All thing considered, for difficulty, I’d prefer the introduction of tag like:
piste:average_difficulty
piste:highest_difficulty
piste:lowest_difficulty
and promoting piste:colour or just colour on route=piste relations for the complete avoidance of doubt.
For tag like piste:oneway, such tag inheritance is definitely a bad idea .
For piste:grooming , this could be easier as the tag has a single meaning.
I certainly concur with the intention, and with many parts of the proposal! The same principles could indeed be applied to other practices (hiking, mtb, etc) or even to other kinds of route relations. It seems to me that some logical consequences of introducing relations as a first class object have not yet been drawn, particularly for piste relations.
I agree with @yvecai that there are questions and obstacles to address, including:
convincing app developers that inheritance systems are not harder to define and to implement in OSM than in the dozens of object-oriented systems that have been developed in the last decades
deciding how we want to deal with “local difficulties”. For hiking, I recall from other threads that there was a debate about readability on maps; POIs are more visible than short ways, for instance.
addressing the elephant in the room: can we make winter sports a more active part of OSM, both in terms of contributors and in terms of uses?
But we must remember that the concept of inheritance, in computing, comes from an explicit search of intuitive concepts to organize data and software components. Therefore I suspect that, even if it’s not exactly the same concept of inheritance (more the concept of scope, actually) a lot resides in our ability to explain and illustrate. And also our ability to avoid shooting ourselves in the foot by creating inconsistencies…
The suggestion to use relations to “save on tag duplication” on ways comes up very regularly and has generally turned out to be not a good idea. It’s difficult to handle for mappers, makes data processing more difficult and creates a lot of difficult-to-handle corner cases. (Insert 200 word rant about associatedStreet relations at this point to make the case.) It is also a case of relations are not categories.
As a general rule, the tags on a way should ideally refer directly to the way, while tags on the relations should refer to the route. In that sense, many of the tags you are listing have very different meanings when viewed in the context of ways or relations, e.g.
difficulty will either relate to the difficult of a certain section when used on a way and to the maximum difficulty, or the officially designated difficulty, when used on route (the latter is better known as the black-red-blue-green classification for a downhill piste)
oneway means that you cannot use the way in the opposite direction, while on a relation the necessary information is that the route should be followed in a given direction (e.g. because it is only signed in one way) or that you need to use different ways when following in different directions (forward/backward distinction)
type is the physical makeup (on a way) vs. the usage type of a route (on a relation)
for lit I’m not even sure what it would mean on a relation
grooming is a physical condition of the way. Applied to a relation, I’d interpret it as: all ways in the route have this grooming, although some might feature additional other grooming. (Think of a route with classical grooming that goes along a way made for classic+skating.)
Just to be clear, I’m not against route=piste relations. On the contrary, there should be more of them where there are actual routes. I’m just against the concept of putting physical properties of the members in route relations in the expectation that these members then inherit the properties.
This seems odd as an example. Why would the physical difficulty of a whole group of ways suddenly change? You somewhat might be able to make that argument for piste:lit but even then your basic information is about the ways. Determining if these ways with newly installed lighting are in a common relation and if there are ways in the relation which might still not be lit, requires in fact an additional step of validation.
Most certainly not. waymarkedtrails ignores all properties on ways for hiking, cycling and riding routes. The winter sports map is a notable exception there because ski routes traditionally weren’t mapped as routes where they should be. To be fair, this has improved a lot in the last years.
If I ever have too much time on my hands, I will add a feature to waymarkedtrails which shows physical way properties for a route but these properties will then be derived only from the ways.
).
.