Neue Karte für Klettersteige / Via Ferratas

Hallo,

auf https://www.xctrails.org/ferrata/ gibt es jetzt eine Karte für alle gemäß dem http://wiki.openstreetmap.org/wiki/Proposed_features/via_ferrata Proposal erfassten Klettersteige, incl. Routing Funktion.

Verwendete tags sind im Grunde lediglich via_ferrata_scale entsprechend der vorgeschlagenen Klassifizierung. Im Zuge dessen habe ich ebenfalls eine Handvoll highway=via_ferrata auf highway=path und via_ferrata_scale=… korrigiert, da IMHO der weitestgehende Konsens ist, dass nicht path highways in dem Zusammenhang problematisch sind (für Renderer, Router etc.)

Außerdem (und das geht über das Proposal hinaus) gab es bereits ein paar Relationen welche Einzel-Wege (ggf. mit unterschiedlichen via_ferrata_scales) zusammenfassen. Das entspricht der Vorgehensweise bei den Langlauf und MTB Relationen und macht IMHO sehr viel Sinn. Visualisiert wird so eine Relation aktuell so: https://www.xctrails.org/ferrata/index.html?trail=6229711

Feedback gerne - die Diskussion auf dem Proposal scheint etwas eingeschlafen zu sein…

Armin

Finde ich cool. habe ich gespeichert und werde es benutzen. Schön!

Da bin ich mir nicht sicher, ob das so richtig ist. Gerade Klettersteige können im Verlauf eines highway=path problematisch werden, wenn nicht alle wichtigen Zusatztags ausgewertet werden. Entsprechende Streckenabschnitte können nur mit Ortskenntnis besonders im Hinblick zweier Zeilen aus dem Proposal sicher getaggt werden:

-use highway=via_ferrata where people commonly use ferrata kits
-use highway=path where a ferrata kit is not required/recommended or none or very few people use ferrata kits

Außerdem:

do not use highway=path instead of highway=via_ferrata just for the (mapnik) renderer

@Garmin-User:
Das Proposal für Klettersteige ist von 2010 und stand bisher nicht zur Abstimmung, weil es in der bisherigen Form (highway=via_ferrata + via_ferrata_scale=) aus vielen Gründen nicht konsensfähig ist, eine neue highway-Klasse für die vernachlässigbar geringe Zahl von Klettersteigen zu schaffen. Es wäre aber für die Mehrheit wohl OK, Klettersteige mit "highway=path + via_ferrata_scale=" zu erfassen.

Daher der Hinweis von Armins im OP, “Verwendete tags sind im Grunde lediglich via_ferrata_scale entsprechend der vorgeschlagenen Klassifizierung.” und “dass nicht path highways in dem Zusammenhang problematisch sind (für Renderer, Router etc.)”.

Danke an Arminus für die Initiative, auf diesem Weg die Kuh vom Eis zu bringen :wink:

Seh ich anders - bzw. stimme an der Stelle mit dem Kommentar “I do not appreciate highway=via_ferrata, because it does not solve any problems. It only generates problems (unclear definition, compatibility with existing data and applications)” in der discussion page überein.

In meinem Fall betrifft das auch den Router (Graphhopper).

Aber wenn der Konsens hier ist, dass highway=via_ferrata erhalten bleiben muss, dann mach ich die Änderungen rückgängig - was allerdings dazu führt, dass de facto highway=via_ferrata Wege existieren die auf keiner mir bekannten Tiles tatsächlich auftauchen. (für meinen Router kann ich ggf. post-processen - aber ich werde keine Tiles generieren).

Zitat: “I do not appreciate highway=via_ferrata, because it does not solve any problems. It only generates problems (unclear definition, compatibility with existing data and applications)”

Dem kann ich nicht zustimmen. highway=via_ferrata löst geradezu das mögliche Problem, dass Router “via_ferrata_scale” gar nicht kennen und somit nicht über gefährliche Strecken routen, das ist einfach sicherer. Das Argument der unklaren Definition gilt auch nicht, da “via_ferrata_scale” auch bei highway=via_ferrata angegeben werden soll. Und was die Kompatibilität mit existierenden Programmen betrifft: Genau das Gegenteil ist der Fall: Es wird gefählich, weil “via_ferrata_scale” bei highway=path aufgrund des Proposal-Status nicht ausgewertet wird. Nichtmal das einfache highway=via_ferrata wird bis dato ausgewertet (Mapnik zeigt aber den Namen an).

Bisher konnte man highway=via_ferrata als “ausgelagert” betrachten - somit für normales Routing (Fußgänger, Radfahrer) unsichtbar. Wenn highway=path in Verbindung mit “via_ferrata_scale” grundsätzlich Einzug findet, müssen alle Router/Renderer informiert sein. Sprich: Alle Wiki-Seiten mit Bezug zu highway=path müssten angepasst werden - normale Wanderausrüstung reicht bei höheren “via_ferrata_scale” nicht und Fahrräder sind auszuschließen.

Komplett via_ferrata_scale von highway=path fernhalten würde ich nicht.

Nicht jedes Stahlseil macht aus einem highway=path ein highway=via_ferrata

Beispiel http://www.openstreetmap.org/way/305407089

Nach DAV-Beschilderung vor Ort ein normaler roter Weg (d.h. mittelschwer). Hier gehen auch Kinder drüber und halten sich mit einer Hand am Stahlseil fest.

Bis via_ferrata_scale=2 (d.h. nix, A, B) fände ich highway=path mit via_ferrata_scale UND entsprechendem sac_scale in Ordnung. Für via_ferrata_scale > 2 fände ich highway=via_ferrata sinnvoll.

Bis via_ferrata_scale=2 gehen meiner Erfahrung nach die meisten ohne Klettersteigset.

Zur Karte von Armin: Weiter so ! :slight_smile:

Grüße
Andreas

PS. via_ferrata_scale=0 finde ich sinnvoll, da es sehr ängstliche Naturen gibt, die bereits beim Anblick es Stahlseils in Panik geraden und damit solche Weg (via_ferrata_scale >=0) erkennen können.

Der Einzug hat auch ohne meine Handvoll Änderungen statt gefunden, laut overpass gibt es aktuell

363 way[“highway”=“via_ferrata”]

und

437 way[“highway”=“path”][“via_ferrata_scale”~“.”]

Ja klar, deshalb befindet sich auch bei vielen Klettersteigen > via_ferrata_scale 1-2 ein entsprechendes Schild in der Landschaft. Wer das auf Grund eines Routings das aus OSM rausfällt ignoriert ist m.E. selbst schuld.

Abgesehen davon: Es kann auch nicht jeder eine > 20% Steigung (Forst-)Straße mit dem (nicht-E)Bike hoch fahren, dennoch wird jeder Router den way in eine Bike Route einbinden - tags in OSM werden nie den gesunden Menschenverstand ersetzen…

Womit alle diese “paths” sukzessive aus den Tiles verschwinden würden (ich seh schon die Fragen der Leute mit den Garmins in den Bergen, warum ist da kein Weg eingezeichnet??), ist das wirklich was wir wollen?

Aber wenigstens haben wir hier eine Diskussion ;-), das Wiki ist wie gesagt eingeschlafen…

Und zur Sicherheit als Disclaimer: Ich steh “nur” vor dem Problem Daten mit inkonsistenten Tags einigermaßen sinnvoll zu visualisieren, letztendlich habe ich keinen Blutdruck in die eine oder andere Richtung. Meine Entscheidung die Handvoll ways zu ändern resultierte letztendlich nur aus den oben genannten Zahlen und dem geringeren Aufwand beim pre-processing für meine Karte (und kann jederzeit wieder Rückgängig gemacht werden).

dafür gibts “safety_rope”: http://wiki.openstreetmap.org/wiki/Key:safety_rope
Ich hab eh das Gefühl das einiges was als Klettersteig eingezeichnet ist eigentlich ein versicherter Steig ist.

So, um Keinem an den Karren zu fahren habe ich eben meine Änderungen an “fremden” ways von highway=path auf highway=via_ferrata rückgängig gemacht.

Hallo,
allgemein denke ich ebenfalls, dass Wege wo man mit laufen an sich nicht mehr weiter kommt (also klettern nötig ist) sich schon im Haupttagg von “normalen” Wegen unterscheiden sollten.

An der Stelle muss ich mich selbst korrigieren, auf den Thunderforrest Landscape tiles werden sie tatsächlich gerendert - und meinen Router habe ich für den nächsten Update Lauf am Wochenende mit entsprechenden tag translation rules geimpft.

Ansonsten hab ich heute ebenfalls mal die diversen values der via_ferrata_tags entsprechend des Wikis aufgeräumt, sobald sich taginfo aktualisiert hat, werde ich mal was zur Verteilung scale/path vs. via_ferrata posten.

Du hast recht, dass man für solche einfacheren Stellen zusätzlich auch safety_rope taggen kann.

Aber warum sollte sich via_ferrata_scale und safety_rope&sac_scale gegeneinander ausschießen?

Ich finde, dass unter der “Klettersteigsetgrenze” durchaus beides am path getaggt werden kann. Es sind unterschiedliche Sportarten mit unterschiedlichen Bewertungsscalen. Bergsteiger und Klettersteiggeher können so die ihnen geläufigen Schwierigkeitswerte an den Wegen unterbringen.
Machen wir bei mtb:scale und piste:difficulty ja auch so.

Grüße
Andreas (der auch dafür wäre, dass ab der Klettersteigsetgrenze highway=via_ferrata verwendet wird, damit keine Router oder Kartenbenutzer in die Irre geführt werden).

Zur weiteren Meinungsbildung noch ein Hinweis auf eine halbwegs rezente Diskussion in talk-at, wo die wesentlichen pro + contra-Argumente im Januar 2016 ausgetauscht wurden. Es lohnt sich, den Thread komplett zu lesen.

https://www.mail-archive.com/talk-at@openstreetmap.org/msg08023.html

@RicoZ: Ist absehbar, wann voraussichtlich das RFC/voting beginnt? Du hattest dies ja im Januar mit “last call before …” angekündigt; http://wiki.openstreetmap.org/wiki/Talk:Proposed_features/via_ferrata

Andreas, der Gedanke kam mir auch schon, aber vermutlich wird es keine allgemein gültige Definition für “Klettersteigset-Grenze” geben. Schon “Klettersteig” ist nicht eindeutig definiert und findige Fremdenverkehrsämter vermarkten hier alles was irgendwo mit Drahtseil versichert ist :wink:

Das primäre Argument für die Einführung von highway=via_ferrata war ja Klettersteige vor dem Rendern (z.B. in Mapnik) zu verstecken.
Für mich ist ein Klettersteig ein Weg (via ferrata!) aka path mit via_ferrata_scale und OSM eine Datenbank. Es ist Aufgabe der Applikationen und Renderer, diese Informationen so auszuwerten und darzustellen, dass Kartennutzer damit nicht in die Irre geführt werden.

Für mich passt openstreetmap und “verstecken” nicht zusammen.

Der Übergang zwischen Klettersteig und (Anspruchsvollen) Steig sind durchaus fließend und daher macht doppeltes tagging vermutlich durchaus sinn, aber nicht alles wo eine Kette rumhängt ist automatisch ein Klettersteig. Irgendwie muss man am schluss vernünftig nach Klettersteigen(Anfänger/Fortgeschritten), (Versicherte) Steige, Steige, Wege mit stück Kette unterscheiden/suchen/darstellen/auswerten können.

Auf der verlinkten talk-at Diskussion wird eine route=ferrata Relation vorgeschlagen, das finde ich eigentlich ganz gut!

Also ich würde das Problem gerne ein für allemal klären, da es alle paar Monate wieder aufkommt und immer mal wieder irgendjemand irgendwas umtaggt.

Ich musste schon öfter jemanden aus einem Klettersteig abseilen, da er sich auf die Karte verlassen hat und meinte, den Weg könne man gehen.
Unterschätzt auch nicht das Gebirge: Wenn ich mir da einen Weg geplant habe und dann merke, dass der Weg schwierig wird, kann ich nicht immer einen Alternativweg nutzen. Nicht immer gibt es einen.
ich selbst wurde schon mal von Grashopper über einen Abseilweg geroutet, was natürlich nicht geht. Das bedeutete 3 Stunden Umweg, was für manche Bergsteiger schon das Einleiten eine Rettungsaktion bedeutet.

Vor diesem Hintergrund ist es wichtig, dass unerfahrene Bwergwanderer zumindest wissen, wenn sie einen Klettersteig mit einplanen.
Dies geht nur über eine korrekte Kennzeichnung.

Von daher mein Plädoyer:
higway=path NICHT für Klettersteige nutzen
jedoch bei renderern UND bei Programmen wie OSMAND darauf drängen, das andere Tagging endlich zu unterstützen. Ob das highway=via_ferrata sein muss, wäre mir weniger wichtig.
Die Klettersteige sollten dann endlich also solche erkennbar sein. Ob man dazu eine Leiter oder einen Karabiner in die Karte zeichnet, ist dann wieder eine Nebensache.

Hier geht es um Sicherheit, und die Karte kann (mit-)schuld am Unfall von Menschen haben, daher sollte das nicht auf die leichte Schulter genommen werden.

Aber sorry, hab ganz vergessen: Danke für die neue Karte, die freut mich sehr :smiley:

FWIW, hier mal die aktuellen Zahlen der Verteilung zwischen highway=path / highway=via_ferrata incl. der verwendeten scales (+ und - ignoriert):

way[“highway”=“path”][“via_ferrata_scale”~“.*”]

Scale 1 count = 61
Scale 2 count = 110
Scale 3 count = 131
Scale 4 count = 50
Scale 5 count = 19
Scale 6 count = 1

→ Sum 372

way[“highway”=“via_ferrata”][“via_ferrata_scale”~“.*”]

Scale 1 count = 22
Scale 2 count = 55
Scale 3 count = 87
Scale 4 count = 53
Scale 5 count = 14
Scale 6 count = 3

→ Sum 234