im Gebirge gibt es Wege die mit Drahtseilen oder manchmal auch Leitern gesichert sind. Es wäre toll wenn man solche Stellen auch in Openstreetmap aufnehmen könnte. Da es meines Wissens nach dafür noch kein Tag gibt, wie fändet ihr securing als Key (weiß jemand ein besseres Wort?) mit den möglichen Werten rope und ladder. Eventuell könnte man auch noch iron pin als Wert hinzunehmen, aber dann wäre es sicherlich besser nicht jeden einzelnen Metallstift aufzunehmen, sondern nur eine Stelle mit Stiften als ganzes. Das Tag könnte als way oder Node benützt werden. Kurze Stellen als Node, sehr lange Seilsicherungen (zum Beispiel bei Klettersteigen) als Way. In beiden Fällen denke ich das dies eine zusätzliche Eigenschaft des bestehenden highway=path Weges ist oder gäbe es Gründe so etwas als parallelen Weg einzuzeichnen? Übrigens: Manche Wanderkarten (zum Beispiel Kompass) zeichnen an Wegen mit derartigen Sicherungen ein zusätzliches Symbol ein. Openstreetmap könnte hier noch etwas weiter gehen und die genaue Position der Sicherungen aufnehmen.
Einzelne Pins, oder Leitern einzutragen, muss genau abgewägt werden, oft ist der Enpfang an Bergwänden deratig schlecht, dass sich keine genaue Position ergibt.
Daher sollte es reichen - wie in den Karten - einen Weg als Klettersteig, oder gesichert, oder als “tritsicher” zu kennzeichnen.
Das ist ein Tag für einen reinen Klettersteig. Aber es gibt viele Wege die kein Klettersteig sind und dennoch einzelne Seil- oder Leitergesicherte Abschnitte haben.
Einzelne Pins wäre vielleicht übertrieben, aber Abschnitte mit Pins oder Leitern oder Seile sollte durchaus genau genug gehen. Es stimmt zwar das an Felswänden die Genauigkeit von GPS Geräten etwas schlechter ist, aber mein eTrex 20 ist meist auch da noch genau genug um etwas auf sagen wir 5 m genau einzutragen. Hilfreich zur Tourplanung ist so etwas in jedem Fall. Übrigens ist mein GPS an einer Felswand meist genauer als in der Häuserschlucht einer Großstadt (an der Felswand ist die Abschattung auch meist nur einseitig).
Ein Klettersteig und ein gesicherter Abschnitt sind auch 2 verschiedene Dinge und werden in Wanderkarten auch unterschiedlich ausgewiesen. Klettersteige sind meist durchgehend gesichert und führen auch schon mal durch sehr schwieriges Gelände, während Wanderwege meist nur an besonders gefährlichen Stellen gesichert werden. Beispiele: Gjaidsteig, Alpspitze Ostgrat, Alspspitze Nordwandsteig, Toni-Gaugg-Höhenweg, Weg über die Ödkarspitzen oder die Wolfsschlucht, wobei die Wolfsschlucht auch schon mal als sehr leichter Klettersteig gehandelt wird.
Es geht nicht um die Schwierigkeit, es geht darum auszuweisen welche Wegabschnitte gesichert sind und welche nicht. Sonst könnte man auch sagen tracktype, smoothness und surface sind redundant und man bräuchte nur eines davon.
Hallo,
ich denke, dass es hier eher sinnvoll ist =yes dem Weg hinzuzufügen. Bei ladder gibt es schon ladder=<Länge in m> (laut dem proposal), in den Daten befindet es sich aber mehrheitlich mit yes/no.
Tags für solche Wegeigenschaften halte ich für sinnvoll. Angaben wie sac_scale sind viel zu grobkörnig, um solche für Bergwanderer wichtigen Eigenschaften zu erfassen.
Das Tag sollte IMHO auf jeden Fall an den Weg selbst, beim Schlüsselwort finde ich “secured” besser.
Evtl. wäre es sinnvoll, bei Mappern aus den benachbarten Bergvölkern nachzufragen, um mal ein genaueres Tagging-Schema für Attribute von Wanderpfaden auszuarbeiten. In diesem Bereich gibt es ja noch viele weitere Fakten, die hohen Informationswert haben. Z.B. gibt es Stellen, auf denen Tritthilfen aus Eisen in den Fels geschlagen sind. Oder die Art der Seilsicherung (Stahlseil, Hanf, habe auch schon Gartenschläuche gesehen) und auf welcher Seite sie vorhanden sind (bei Steilstücken auch manchmal auf beiden Seiten).
Wie oben schon erwähnt gibt es bereits ladder=yes|no|<Länge in m> über 450mal in der DB. Das sollte ja schon irgendwie kompatibel sein, denke ich. daher würde ich den Namensraum erstmal weglassen. Wenn es bei manchen Keys dann unklar ist, würde ich eher securing_rope nehmen.
Aber meine Meinung ist nur die eines Laien und bezieht sich eher auf die Integration in das bestehende “Ökosystem”. Wenn das unsinnig ist und nichts mit dem ladder=* zutun hat, ist ein eigener Namensraum durchaus sinnvoll.
Da es ladder bereits gibt, wäre ich dann auch eher für securing_rope als neuen Key. Das ganze dann jeweils als zusätzliche Eigenschaft des Weges oder alternativ als Eigenschaft eines Nodes des Weges (aber in jedem Fall am Weg selbst). So wie das bereits vorhandene ladder könnte man dann analog als Werte für securing_rope yes, no oder Länge in Metern nehmen. Zwecks der anderen vorgeschlagenen Attribute kann man ja Zusatztags machen wie securing_rope_side=(left|right|both). Wie soll man Tritthilfen (Metallstifte oder ähnliches) nennen? Iron pins?
Mein Vorschlag wäre, erstmal allgemein ein Wort für Fußtritt zu suchen, es denn es ist wichtig, ob es Holzpflöcke, Eisenstäbe, Eisenplatten, Schlaufen… sind.
Könnte das vielleicht jemand mit besseren Englisch als ich übernehmen? Ich verstehe englisch wenn ich es lese, aber beim selber schreiben, wäre es mir lieber das macht ein anderer (wobei hinzu kommt, daß ich die Mailingliste nicht aboniert habe)?
Ich tagge einzelne Leitern als highway=steps + name=Leiter. Denn in Wahrheit ist eine Stiege nur eine Leiter mit breiteren Sprossen, und so gibt es zwischen Stiegen und Leitern alle Übergänge. Zudem passen die Stiegensignaturen auch auf Leitern ganz gut. Manche werden einwenden, dass name=Leiter kein richtiger Name ist, aber das ist mir egal, solang die Anwender einen Nutzen haben. Tags sind nicht für die Ewigkeit. Wenn die Zeit reif ist, kann man sie immer noch umtaggen.
Fließende Übergänge gibt es auch zwischen Wanderwegen und Klettersteigen, daher halte ich das vorgeschlagene highway=via_ferrata für eine Schnapsidee. Anfreunden kann ich mich mit ferrata_scale=*, denn das kann man auch auf highway=path setzen.
Einzelne Versicherungen zu taggen kann dort sinnvoll sein, wo nur wenige vorhanden sind. Auf einem senkrechten Klettersteig, wo hundert Klampfen und Trittstifte übereinander sind, geht das nicht. Da müsste man hundert Nodes an die selbe Stelle setzen.
An Versicherungen gibt es u.a.:
Leitern
Steigbäume
Drahtseile (schlecht verankerte zur Kennzeichnung einer Gefahrenstelle, besser verankerte zum Anhalten, noch besser verankerte zum Sichern und/oder zum Hochziehen oder gar als Drahtseilbrücke)
Klampfen = Klammern
Tritteisen
Trittstifte
Griffeisen
Man kann sie alle auf Englisch übersetzen und Tags dafür erfinden, aber auswerten wird das wahrscheinlich keiner. Das wär eine Sache von Spezialanwendungen für Klettersteige, doch gerade diese Anwendungen können OSM aus dem weiter oben genannten Grund nicht nutzen. Klettersteig-Topos zeigen das Gelände üblicherweise im Aufriss! Darum würde ich euch raten, in das Tagging von Versicherungen keinen Aufwand hineinzustecken. Es gibt genug anderes zu tun.
Wie in diesem Thread bereits mehrfach erwähnt gibt es bereits ladder=(yes|no|länge in m).
Ich halte highway=via_ferrata durchaus für eine gute Idee, da dies dann von “allgemeinen” Renderern die solche Gebirgstags nicht auswerten nicht angezeigt wird. Sonst verirren sich noch Normalwanderer ohne Klettersteigausrüstung auf einen Klettersteig, nur weil es in OSM als path eingetragen ist. Was die Übergänge angeht: Manche Wanderwege werden sowohl als (anspruchsvolle) Wanderwege angesehen, als auch als sehr leichte Klettersteige. In diesem Fall würde ich auch eher highway=path taggen, da solche Wege eigentlich immer als Wanderweg offiziel angesehen werden (und so markiert sind) und von vielen Leuten ohne Klettersteigset benutzt werden.
Nein, nur einen Node und den mit mehreren Tags versehen. Ich sehe da eigentlich kein großes Problem. Allerdings sehe ich die Nützlichkeit dieser Tags auch eher an Wanderwegen, mit eher weniger Sicherungen, als an Klettersteigen, die ohnehin komplett voll mit Sicherungen sind.
lit zum Beispiel existiert auch schon lange und wurde lange Zeit von niemanden ausgewertet. Seit kurzem existiert eine Lichtkarte. Immer wenn man ein neues Tag einführt wird dies erst mal nicht ausgewertet. Wer sagt das es nicht in wenigen Jahren schon eine Spezialkarte für den Alpenraum gibt, die alle hochgebirgsrelevanten Details darstellt. Man kann den 2. Schritt nicht vor den ersten machen. Bevor es eine Anwendung gibt, müssen erst mal die Daten da sein, damit die Daten da sind muß erst mal ein Tagging dafür ausgearbeitet werden.
Dieser Thread zeigt doch, das es von einigen Leuten Interesse gibt. Wenn es dich nicht interessiert, sondern du andere Dinge als wichtiger ansiehst dann tagge eben andere Dinge bevorzugt.
Da sich bislang niemand gemeldet hat zwecks englisch Übersetzung noch mal: Ich bin bereit ein Proposal zu erstellen etc. Aber ich bräuchte jemanden der mir beim englisch übersetzen hilft. Wäre hier jemand bereit dazu?
Klar, die Übersetzung mache ich dir gerne. Ich kenne nicht immer die bergsteigerischen Fachbegriffe (im Deutschen übrigens auch nicht alles), aber bei Bedarf wird sich da hoffentlich ein Muttersprachler finden, der die Lücken füllt. Auf Mailing-Listen bin ich allerdings nicht zuhause, ich lese dort zwar mit, poste aber nicht.
