Ich hab das eben geprüft. Die Geometrien decken sich mit denen aus der DTP Quelle, dort wurden sie vom LRA GAP am 21.1.2026 so aktualisiert. Allerdings habe ich festgestellt, daß in DTP keinerlei Informationen zu den Schutzzeiten (mehr) vorhanden sind, d.h. die aktuellen access:conditional tags in OSM sind u.U. outdated. Dazu hake ich mal bei DTP nach.

Und mangels Zeit habe ich den Tag-Vergleich im aktuellen "Abgleichs-Lauf" noch nicht komplett durch, dort sollte sowas dann auch auffallen, ist halt alles leider nur semi-automatisiert Richtung OSM.

> Der Alpenverein kann keine Betretungsverbote verfügen.

Ich hatte ja gesagt, DAV nur für WWSschongebiete mit freiwilliger Beschränkung. Von daher ist das schon getrennt.

Die Daten kommen für den Abgleich dann zusammen mit den WWSchutzgebieten von DTP und werden gemäß osm.wiki/DE:Betretungsverbote_f%C3%BCr_Gebiete_im_Winter getagged bzw. abgeglichen.

Bzgl. der 1/3 Reduktion: Kannst Du mir ein Beispiel nennen? Siehe ggf. auch https://www.xctrails.org/schongebiete/SchongebieteWMSLayer.html - dort müsste an allen Gebieten eine dtp_url hängen, bei DTP lässt sich dann auch der "Verantwortliche" feststellen.

Der Umfang der Änderungen hat hier nichts mit der Qualität zu tun.

Die Quelle der Daten für WWSGs mit freiwilliger Beschränkung ist die GIS Datenbank des Deutschen Alpenvereins der diese nach digitizetheplanet.org überträgt von wo ich sie abhole, abgleiche und über JOSM ggf. in OSM anpasse. Weitere quellen sind UNBs etc. welche Daten ebenfalls über digitizetheplanet.org bereitstellen.

Dieses Prozedere ist mit allen betreffenden Daten-Ownern abgesprochen.

Falls anderweitig begründete Zweifel bestehen, dann kann ich gerne einen direkten Kontakt mit dem DAV oder anderen Daten-Ownern herstellen.

Das Gebiet gibt es definitiv noch. Also kein Handlungsbedarf.

Laut DAV/Digitizetheplanet wurde das way/1258176864 Gebiet aufgehoben. Da die ursprüngliche Quelle nicht DTP war, lösche ich es aber (noch) nicht. @map per - ggf. prüfen?

May I ask why you tagged the entire relation/2227233 as via_ferrata while in fact only parts of it (way/76618437) is a via ferrata?

changeset/166868437

m.e. ja: https://rosengasse.bayern/

You changed the via tag to via_ferrata_scale in this changeset - which seems not right at all?

Hi,

sorry, I obviously missed that there is already a relation changeset/59148665 - which is kind of strange because it includes much more than the *actual* ferrata (climbed it myself twice so I have some onsite knowledge).

Can we agree that I delete the new relation again but also combine the 2 ways of the actual ferrata (way/76618462 and way/76618437) into one way?

Point is: It would be nice to either have a relation (or a single way) which only includes the actual ferrata, not an entire trail where only ~ 20% of it is the actual ferrata (which in this case can also be climbed from Biacesa and not only like relation/2227233 maps it.

The linked website classifies this ferrata as "F" - which could by the french F which would translate to via_ferrata_scale=0, but from looking at the images, I'd say this is at least 1 or maybe more, so I've set it accordingly in changeset/160167019 for now since nothing happened here in 2 months.

According to via%20ferrata%20scale=* via_ferrate=yes is not a proper value. Can you set the actual difficulty for it? Otherwise safety_rope=yes would be a less optimal tag.

via_ferrata_scale=yes on way/114791610 is not a valid value for that tag. I'm going to set this to safety_rope=yes, if anyone knows the actual scale of this, please set the scale accordingly, see via%20ferrata%20scale=*

My bad, sorry.

Sorry, I disagree. Putting discrete data, which is also clearly defined in its meaning, into a text field (which a data consumer would then need to parse!) is bad database practice.

Besides, as I said, this approach is also used for piste:type=nordic#The_piste_as_relation and route=mtb - these are clearly established practices and in much wider use compared to the ferratas.

The fact that the ferrata proposal hasn't been voted upon doesn't make the reuse of an existing and agreed upon mapping pattern for this case "unofficial" IMHO.

"great advantage of specifying the difficulties in each section"

=> of course, and I didn't remove the scales on any way

What I did was add a scale to the entire ferrata relation. This could theoretically be calculated by picking the highest difficulty of all its ways, but in reality, this might not always be correct, hence the tag.

"find a top" -> find on a topo

I agree on your last comment, nevertheless, every ferrate as a whole typically has an overall scale. In other words, tags on individual ways classify the "sub scales" (which you typically find a top), while the scale on the entire ferrata classifies the ferrata in its entirety. This is also common practice for other relations like cross country tracks for example.

Anyway, I would kindly invite you to add to the discussion in the referenced wiki-page, this "discussion" here will eventually get lost.

Sorry, I forgot the comment on the change record, please see osm.wiki/Proposal:Via_ferrata#Tagging_as_route=via_ferrata_relation - the via_ferrata_scale tag on relations is used since many years

Hier noch die Strava Heatmap:

https://i.postimg.cc/3xk8CmR8/Snowfarmingloipe-Leutasch.png

ich hab die Relation eben wieder angelegt: changeset/146713727