A recent forum post discussion reminded me the ambiguity about via_ferratas. I can see more or less clearly two distinct groups:
purpose build leaisure/sport via_ferrata build mostly as tourist attractions, usually reasonably near population centers, quite oftenin cliffy valleys. They are not used to get somewhere (to a top of a mountain) but for fun by people who usually come to them specifically to climb on them. Almost always they lead to nowhere or there is an easy way to get where they lead.
via ferratas that are part of larger trails, usually in the mountains, meant to get from place A to place B. It canbe the only way to get there.
(of course, there is the middle ground of purposefully build via ferratas in the mountains that just add harder alternatives to get somewhere, as always with OSM, there is always a grey area).
It is not certain how to map these two. Organically, there is Tag:route=via_ferrata - OpenStreetMap Wiki (I wrote that page based on the discussion here: Changeset: 154274339 | OpenStreetMap ) used mainly to the first case. To me it seems it would be useful to add sport=via_ferrata to these (or leisure=via_ferrata) relations. There is also a question how to map the subroutes in such places. To me it seems quite natural to use relations for individual routes and a superrelation consisting of these individual realtions. However, it breaks the only renderer in the form of www.xctrails.org.
I am tagging @cehceh who said he or she would look into it.
(I also cleaned up Tag:highway=via_ferrata - OpenStreetMap Wiki - if anybody dislikes my edit, please do not revert but tell me what I removed that is missing, I tried hard to only remove duplicit information, which there was alot of)
Where do you see the actual difference between the two routes? Both kinds are clearly via_ferrata, with the only difference being the objects around the path - be it a POI at its end or additional, easy paths leading to both ends of the via_ferrata.
As the two via_ferrata ways themselves are identical, I don’t see a need to tag them differently.
I’m only concerned about the overlap. Some easier ferratas (A, B) are frequently used without any equipment. Sometimes they have simply evolved from a harder path with security ropes and/or ladders.
I’m in doubt what tag they should have. Some people might get upset if their favourite paths disappear from the map. However, when renderers support this tag, it is very useful to clearly identify secured sections on a map. Which OsmAnd does as of recently. Having a grade displayed would be even better. A/B ferratas are also a decent way to come down after climbing.
As for the distinction, I don’t see much point in separating. After all, should we have a category for the original ferratas, that were built for military purposes? They are a climbing aid. Some routes can be passed around on foot, some not. But there’s no distinguishable feature that would separate them.
Basically, there are the two variants mentioned with a gray area in between.
The question is not whether it is a gorge or rock face without an actual destination or a summit tour or an ascent or descent of climbing routes, but whether special equipment is absolutely necessary.
In the latter case, highway=via_ferrata is used and thus (hopefully) no mountain hiker is guided by the standard maps to routes that are not feasible without equipment. In this case, route=via_ferrata and sport=via_ferrata are added as tags.
The second case is usually mapped as highway=path and at individual passages via_ferrata_scale=xx .
I believe this is largely the consensus and the renderers handle this correctly.
These days I have looked at this and decided to remove my self-created super relation at this point, because this is redundant and is not used in the sense of a large coherent route with individual sections anyway. Instead, there are now three individual relations with the same starting point, including the color coding. I think this approach is the best for now and it’s not bad if the renderers display/list this as three individual via ferratas.
Well, what I think would be sensible would be applying leisure=via_ferrata and sport=via_ferrata to the first ones (the ones built as attractions). They can sometimes be paid, they form a unit, they are now being mapped as relations. They fit very well:
The leisure=* key generally denotes places where people go in their spare time ― for sport, recreation, relaxation or entertainment.
The sport=* tag is used to identify one or more sports which can be played within or on some physical feature. A list of sports is given below.
Though it could be argued that this applies to via_ferratas in general.
I am basically at a loss how exactly these relations should be mapped and what properties should be used for them? Are the leisure= and sport= tags useful here? For all via_ferrata relations? Or are they implied? To me it seems the ones built as attractions (unlike via_ferrata in the mountains, they are often at places where people would otherwise not go) from one unit, so it makes sense to put them into a superrelation.How should that superrelation be tagged? There are 366 sport=via_ferrata to about 4 thousand highway=via_ferrata. What do these mean?Are they deprecated?
However, if the consensus is that such superraltions should not be tagged and each individual route should just gets its own relation, than my point is probably meaningless.
As for the easiser via_ferratas, I think highway=path and via_ferrata=yes would be a good solution (basically as long as such a path would fall under assisted trail and most people walking there are not using a set).
My personal opinion: “sport=via_ferrata” says everything necessary. The tag “leisure=…” implies for me: you can go there/travel there and just get going (or: pay and get going). This doesn’t apply to via ferratas, where you have to know what you want to do and (often) have to bring your own equipment. The same applies to climbing routes, which are usually not tagged with “leisure=…”.
I myself always put the tag “sport=via_ferrata” at the starting point together with “natural=cliff”, “via_ferrata=start” and “description=…”.
A general note: I have occasionally seen via ferratas mapped as “attraction”. I think this is completely wrong - these are places where tourists want to drive to in their camper vans and take photos.
On the subject of “sport=via_ferrata”: I have adopted this tagging and consistently applied it to all via ferratas that I work on myself (France, Czech Republic, Saxony). But only for the starting points. Hence the discrepancy, because a via ferrata often consists of 5 - 20 individual routes. In my opinion, this is not outdated, but rather useful. This means that every renderer can also use starting points instead of routes if they want.
For questions according XCTrails we should also consult @Arminus .
Well, what about via_ferratas that are commercial and have attached an equipment rental like: Velká dohoda - Ferratový park ? That would indicate leisure to me:-). So maybe that could be a distinction?
I have not much of an opinion on the distinction any more. Whether I can do it without the equipment or whether I need it, this perhaps out of scope tor openstreetmap to tell apart - Though I observed ways that were signed “kit=mandatory” vs. ways signed “kit=recommended”.
Anyways, the new key in route=* might be of interest for @lonvia - some Via Ferratas here perhaps mapped route=hiking, solely lacking a more descriptive tag.
Hm, I think natural=cliff is problematic. That is something that should typically be mapped as a way independent of the via ferrata and not all via_ferratas start on a cliff.
I also think that using description for the name of the ferrata is kind of abusing the tag.
Furthermore, it is kind of weird to map vertical ferratas like Kavárnička
as ways - at least the two middle ones are in reality nodes, they just go up. But I understand mapping them this way is useful for displaying purposes.
Then there is the question of grouping them. At this particular one, there are 4 different routes, with Moribundus and Brute force sharing part of the way. Hence my suggestion with superelation.
This one has two segments of different difficulty. There is noe more route, whichI think canbe mapped as one way as the difficulty is the same prettty much all the way. It would make sense to group them now, but that would require a superrelation.
Why you think natural=cliff is problematic? According to Tag:natural=cliff - OpenStreetMap Wiki mapping as point or path is possible. The main reason is that an starting point of the via ferrata, if tagged with additional information such as sport=, name= or description= an physical feature is needed, otherwise this will result in an Osmose issue. I don’t know of any via ferrata that doesn’t start on a rock face.
The description tag can be used to provide additional information about the related element to the end map user. Why this should be abusing? If used, it is possible not to use the name tag (because otherwise it will be displayed in many renderers in contrast to the ferrata itself) and still keep the information available.
Ans yes, the mapping of nearly vertical ferratas is problematic (although I don’t know of any via ferrata that is really only exactly vertical). In France, for example, there are some via ferratas where the outward and return routes on the same wall run a few meters above each other - this is only understandable if the upper route is slightly offset towards the rock. Because also the satellite images are not real vertical, I think this is no problem.
In my opinion, the use of a super relation is not necessary, as I have already written. This does not result in any additional information. The combination of several variants/routes at one location was previously only done because there was no detailed information on the individual routes (name, color) available.
In your example of Křivý šev I think no super relation is neccesary. You have two relations with names and/or colors, but the different difficulties are defined in the different ways in an relation. Renderers of via ferratas recognize this and display the individual difficulties of the parts!
By the way: The use of via_ferrata_scale=0 makes no sense! This level of difficulty does not exist in reality. If there is a safety rope there, then it is at least via_ferrata_scale=1 (=easy) and if not, then it is a path.
Addendum: We are currently considering whether and how the accessibility and temporary closures of via ferratas can be taken over from OSM. At the moment there is little or no maintenance in OSM and there are extra functions for this in renderers such as XCTrails. @Arminus has planned to adopt at least “access=no” in the foreseeable future.
But of course it would be important if these and the seasonal closure times were also maintained in OSM!
I may be missing something here, but this is mentioned in Proposal:Via ferrata - OpenStreetMap Wiki since 2018 (I know, proposal…), actually in use on many ways and relations and supported at least by XCTrails, as is access=no (finally) since about a month.
Beware that foot=* overrides access=no. Only foot:conditional=yes can do that in one more tag, the opposite of “seasonal closure”, that is seasonal opening.
mapping it to the starting point is a duplicity. And the ferrata does not start on a cliff, the first ten meteres are in a steep gulley over roots, not on a cliff, you walk on ground steeply up. If this is done because of Osmose, one should not map for Osmose! A report should be filled for osmose rather.
Or look at Kavárnička, you have three cliffs mapped there:
however in reality I think (based on survey) there is only one cliff. Does this not break rendering (and common sense of mapping one thing only once when possible) for renderers not aware of this convention for via_ferrata?
Description here does not proide additional information. It just links the node to the appropriate relation (or way), as far as I understand it. Much more sense would be via_ferrata_start=“name of the related_via._ferrata”.
Or look at this commercial ferrata: Velká dohoda - Ferratový park – it should/could probably have fee=yesopening_time=*operator=* etc. What OSM element would you tag that to?