@micheleOSM3 recently changed the wiki page of Tag:route=via_ferrata - OpenStreetMap Wiki to say that via_ferrata_scale it should not be applied to it. I reverted it, as about ten % of that key is applied to a relation.
We exchanged several e-mails about it, but since we do not really agree, we decided to invite the wider community for discussion. My stance is that wiki should document current usage, and if there is controversy, document it.
However, the text in question is this:
typically, the relation should also have a via_ferrata_scale tag for the entire ferrata (which is not necessarily always the highest difficulty of its sub segments)
I think it is documenting current usage, but maybe the modality (“should”) can be modified. To my mind, it is similar to Key:sac_scale - OpenStreetMap Wiki.
Data consumers can choose whether to digest the via_ferrata_scale on ways, relations or both.
Hi @supsup and everyone, thanks for opening this discussion to the wider community. I’d like to clarify my perspective and the sequence of events that led to this disagreement. My stance is based on long-standing wiki documentation and the need for data modeling consistency.
1. The tag “via_ferrata_scale”
When it comes to the “via_ferrata_scale” tag, the main source of documentation is Key:via_ferrata_scale.
For years, the Key:via_ferrata_scale has clearly stated that this tag should only be applied to "way", and my mapping practice has always scrupulously followed this established guideline.
2. Recent changes toKey:via_ferrata_scaleduring our discussion
During our private email exchange, the Key:via_ferrata_scale wiki page was modified to suggest that it can also be used on relations. This recent edit changed the baseline of our discussion. I encourage everyone to check the history of that wiki page to see how the documentation evolved right as this debate was happening.
3. The ambiguity of the route=via_ferrata page
I agree with @supsup that the sentence on the Tag:route=via_ferrata page (“typically, the relation should also have a via_ferrata_scale tag for the entire ferrata…”) was ambiguous. However, an ambiguous sentence on a relation page should not override the specific, historical “key:via_ferrata_scale” documentation.
4. Data modeling and real-world accuracy
From a practical cartographic perspective, a via ferrata route can be heterogeneous. Not only can the difficulty vary (for example, an easy section followed by a difficult crux), but there can also be un-equipped connecting sections that are part of the same route (better described by the sac_scale tag).
Applying a single via_ferrata_scale to the entire “relation” could be an approximation that potentially provides misleading data to data consumers.
I believe it is more correct to follow the same logic as the sac_scale tag, which is explicitly intended to be set only on “way”. This approach is fundamental to accurately represent reality. If the mapper does not know the reality, they simply should not use the via_ferrata_scale tag, exactly as happens with sac_scale.
Conclusion
I think the wiki should clearly specify that the “via_ferrata_scale” tag should only be used for “way”. Its use for “relation” should be discouraged (or marked as obsolete/ambiguous), to ensure consistency and accuracy of the data for end users.
I just confirm that indeed I added ways to the table and sidebar on the wiki. I think it is unfortunate that the page does not discuss what type of segments it applies to. The table for example allows nodes, but they are 10 times less likely than relations. I assume they are meant to be for vertical segments.
Unfortunately that post looks like you let AI loose on it. Could you try editing it so that there was only 10% or less of the text (what you actually wrote) and no additional stuff?
Don’t worry if your first language isn’t English; just write whatever you are comfortable with.
Sorry, I’m using Google Translate from Italian to English and then from English to Italian to check for errors in the first translation. But perhaps I didn’t check thoroughly. I’ll try editing the text.
If you try to sum up the scale of the whole ferrata, there’s two ways to do it:
Put the highest scale on the relation
Put the minimal scale that is needed to pass the ferrata, if you can bypass the hardest bits
The first one is good for adventurers who want a challenge, the second one is good for hikers who just want to get through the ferrata to get to the top of the mountain.
If you try to sum up the scale of the whole ferrata, there’s two ways to do it:
Put the highest scale on the relation
Put the minimal scale that is needed to pass the ferrata, if you can bypass the hardest bits
The first one is good for adventurers who want a challenge, the second one is good for hikers who just want to get through the ferrata to get to the top of the mountain.
Considering this ambiguity, perhaps new, more prescriptive, tags could be created for use on relations?
Something like:
via_ferrata_scale_max, which would only be used for the first option
via_ferrata_scale_bypass_max, which would only be used for the second option
These would be separate tags from via_ferrata_scale (thereby avoiding the possible data consumer issues highlighted by micheleOSM3 and maintaining the original strict usage of via_ferrata_scale), and might even provide a new and useful data source for data consumers.
Are we sure that using tags like “via_ferrata_scale_max”, or similar on the “relation” is actually useful?
Aren’t we risking creating redundant or subjective data?
If the information can be deduced from the data on the individual “way”, why duplicate it manually? It’s the software’s job to calculate the aggregate values, not the mapper’s.
Or, if the data used on the “relation” depends on an overall assessment, it seems to me that the value becomes a bit too subjective. In these cases, I’d prefer to write something in the “description” tag.
I still believe that using “via_ferrata_scale” only on the “way” is simpler, more verifiable, and more maintainable. Similarly, the “sac_scale” tag.