- Beiträge
Man kann durchaus darüber Nachdenken die via_ferratas extra zu rendern – so @Tobias irgendwann Zeit dafür hat.
Bis dahin bleibt die derzeitige Lösung.Ich kann aber auch mit dem Status Quo leben, da ich bei jedem T>=4 mir vorher Tourenberichte ansehe.
Ob ich meine Kletterausrüstung bzw Klettersteigset mitnehme, mache ich nicht von einem Mapper abhängig.So sehe ich das auch und genau so ist das auch gedacht. Wenn ich in einem Gebiet unterwegs bin dann habe ich vorher den Gebietsführer (Rother; AV-Führer, Ordnance Survey,..) komplett gelesen, die Karte ist eine Draufgabe.
Es ist für mich undenkbar _überhaupt_ einen Weg in den Bergen nur nach OSM-Daten zu gehen – dafür fehlt bei OSM einfach jedwede Qualitätsprüfung heikler Daten.
Wir gaukeln hier dem User eine Genauigkeit for die es definitiv nicht gibt – das war auch der Grund warum es fast ein Jahr lang gedauert hat bis ich mich habe breitschlagen lassen zB. die sac_scale überhaupt zu rendern, von meinem Bauchweh bez. rechtlicher Konsequenzen mal ganz abgesehen.Ich hatte schon einen Weg ohne sac_scale, ohne climbing=yes ohne alles – das war der Traunstein Ostgrat (ein astreiner 2er) , ich hab’s zufällig gesehen und rausgeschmissen.
Ob man mit dem Auto auf einem Waldweg landet oder ob es ein gemaptes Gasthaus nicht gibt ist (mit Verlaub) restlos egal und als Vergleich nur bedingt tauglich.
Also: Das getrennte Rendern von Klettersteigen ist vorgemerkt und wird OAM-Intern Diskudiert.
VG
ChristianMit den alten Karten ist noch eine Darstellung von T5/T6 mit via_ferrata=yes und Elevate möglich, da ich da die gestrichenen raw_sac_scale Werte verwendet hatte. Aber immer auch mit Klettersteigsymbol, nicht nur am Anfang sondern über den gesamten Bereich mit via_ferrata_flag=set (von Christian generiertes Sammeltag für Klettersteige). Von daher war der bisherige Stand sowieso schon ähnlich wie oben vorgeschlagen. Außer jemand schaltet das Outdoor Overlay ab. Ich könnte noch zusätzlich eine nicht abschaltbare Markierung einfügen, dann sollte das wirklich allen klar sein.
Im übrigen sehe ich das auch kritisch – leider wird das tatsächlich auch bei einfachen Seilsicherungen verwendet, daher gibt es false positives. Andersrum sollte es aber eigentlich gar nicht als highway=path zusätzlich markiert sein, da Klettersteige das nicht sind (wobei die höheren sac_scales dann auch nicht). Im Endeffekt könnte man diskutieren, ob alles mit via ferrata gleich ganz anders dargestellt werden sollte, aber allein wegen false positives eher nicht. Für Seilsicherungen auf normalen Wanderwegen gibt es ja sowieso safety_rope als tag.
Ich würde vorschlagen, das via_ferrata die sac_scale nicht beeinflusst, dafür mache ich noch eine dauerhafte Markierung an die fraglichen Wege.
Viele Grüße,
TobiasDeveloper of Elevate mapstyle
@Christian: wenn ich das hier richtig verstehe:
<translation> <name>set via_ferrata_flag</name> <description>set via_ferrata_flag and force highest mtb- and sac- scales</description> <match mode="or" type="way"> <tag k="via_ferrata" v=".*"/> <tag k="via_ferrata_scale" v="(^[1-9,a-z,A-Z][0-9,a-z,A-Z]*$)"/> <tag k="sport" v="via_ferrata"/> <tag k="highway" v="via_ferrata"/> </match> <output> <copy-all/> <tag k="highway" v="path"/> <tag k="mtb_scale" v="mtbs_6"/> <tag k="sac_scale" v="T6"/> <tag k="via_ferrata_flag" v="set"/> </output> </translation>dann erhalten alle via_ferrata auch ein k=“mtb_scale“ v=“mtbs_6″, das würde ich auch weglassen, da es auf den ersten Blick eher aussieht, als wäre da eine MTB-Strecke (da es meistens im Gegensatz zu sac_scale kein mtb_scale enthält).
Außerdem erhalten werden alle via_ferrata zu einem highway=path, das ist doch fast das Gegenteil, was sinnvoll wäre? Wenn jemand jetzt nur path darstellt sehen auf einmal alle wie ein path aus, selbst wenn sie im Original nur highway=via_ferrata haben.Developer of Elevate mapstyle
Hallo @Tobias,
Ja, die Tag-Transform Regel ist ein wenig wackelig, das MTB-Scale hätte ein paar Bedingungen mehr gebraucht.
Vorschlag:
<translation> <name>set via_ferrata_flag</name> <description>set via_ferrata_flag and force highest mtb- and sac- scales</description> <match mode="or" type="way"> <tag k="via_ferrata" v=".*"/> <tag k="via_ferrata_scale" v=".*"/> <tag k="sport" v="via_ferrata"/> <tag k="highway" v="via_ferrata"/> </match> <output> <copy-all/> <tag k="via_ferrata_flag" v="set"/> </output> </translation>und zusätzlich das highway=via_ferrata UND die via_ferrata_scale mit aufnehmen. Damit sind dann alle Daten vorhanden – was immer die Theme dann auch immer damit macht.
Ev könnte man noch absichern das sobald ein „via_ferrata_flag“ v=“set“ existiert vorhandene mtb_Routen Tags gelöscht werden?? Wobei das nicht ganz so einfach ist da diese Tags auf ways und relations verteilt sind. Hier müsste ich auch das Programm der Relationsauflösung umschreiben, checken ob ein via_ferrata=yes in den einzelnen Wegen der Relation existiert und die ganze Relation skippen…..
Ev. fällt Dir hier ein brauchbarer Weg ein.VG
ChristianVorschlag:
<translation>
<name>set via_ferrata_flag</name>
<description>set via_ferrata_flag and force highest mtb- and sac- scales</description>
<match mode=“or“ type=“way“>
<tag k=“via_ferrata“ v=“.*“/>
<tag k=“via_ferrata_scale“ v=“.*“/>
<tag k=“sport“ v=“via_ferrata“/>
<tag k=“highway“ v=“via_ferrata“/>
</match>
<output>
<copy-all/>
<tag k=“via_ferrata_flag“ v=“set“/>
</output>
</translation>Ist wahrscheinlich das einfachste und beste 🙂
und zusätzlich das highway=via_ferrata UND die via_ferrata_scale mit aufnehmen. Damit sind dann alle Daten vorhanden – was immer die Theme dann auch immer damit macht.
via_ferrata_scale würde ich wegen dem 15-tag-limit nicht mit aufnehmen, zudem weckt es Begehrlichkeiten, die in einer zweidimensionalen Karte nicht abbildbar sind. highway=via_ferrata braucht es nicht, man kann einfach für alle via_ferrata_flag ohne highway eine eigene Darstellung festlegen:
<rule e="way" k="highway" v="~"> <rule e="way" k="via_ferrata_flag" v="set">Ev könnte man noch absichern das sobald ein „via_ferrata_flag“ v=“set“ existiert vorhandene mtb_Routen Tags gelöscht werden?? Wobei das nicht ganz so einfach ist da diese Tags auf ways und relations verteilt sind. Hier müsste ich auch das Programm der Relationsauflösung umschreiben, checken ob ein via_ferrata=yes in den einzelnen Wegen der Relation existiert und die ganze Relation skippen…..
Ev. fällt Dir hier ein brauchbarer Weg ein.Also wenn eine MTB-Route auf einem korrekt getagten Klettersteig verläuft, stimmen die Daten der Route nicht. Und wenn die Route stimmt, ist das via_ferrata-tag falsch. Ich würde das gar nicht behandeln, dann fällt der Fehler eher auf und wird eher behoben. Zudem wird in Zukunft mit Elevate jedes via_ferrata_flag immer angezeigt.
Developer of Elevate mapstyle
highway=via_ferrata braucht es nicht, man kann einfach für alle via_ferrata_flag ohne highway eine eigene Darstellung festlegen:
Wäre sicher möglich, ich werde trotzdem das highway=via_ferrata zusätzlich mit ins tagmapping mit aufnehmen, das ist für alle Themersteller intuitiver – OK?
Also wenn eine MTB-Route auf einem korrekt getagten Klettersteig verläuft, stimmen die Daten der Route nicht. Und wenn die Route stimmt, ist das via_ferrata-tag falsch. Ich würde das gar nicht behandeln, dann fällt der Fehler eher auf und wird eher behoben.
Auch ein Gesichtspunkt – Gut machen wir das so.
Die anderen Dritt-Themes müssen dann eben nachziehen.Was möchtest Du als Testkarte gerendert haben?
VG, Christian
Wäre sicher möglich, ich werde trotzdem das highway=via_ferrata zusätzlich mit ins tagmapping mit aufnehmen, das ist für alle Themersteller intuitiver – OK?
Logisch!
Was möchtest Du als Testkarte gerendert haben?
Alps_Ost wäre super!
Developer of Elevate mapstyle
Mit der neuesten Elevate Version 4.2.0 und den Karten ab Oktober wird sowohl highway=via_ferrata dargestellt als auch die korrekte sac_scale bei highway=path, auch wenn sie mit via_ferrata Tags versehen sind.
Developer of Elevate mapstyle
2 users thanked author for this post.
Hallo Christian und Tobias,
habt ihr eigentlich auch assisted_trail in den Karten erfasst? Gibt es auf Wegen, aber auch in Relationen. Das ist ja gerade das Zwischending zwischen Wanderweg und echtem Klettersteig, quasi Wanderweg mit kürzeren gesicherten Passagen. Bei denen wäre es sicher sinnvoll, das Karabinersymbol für die gegebene Sicherungsmöglichkeit anzuzeigen, aber nicht die gesonderte Darstellung des Weges als Klettersteig.
Die meisten Wanderwege, die auf OSM mit T3 oder T4 und gleichzeitig als via_ferrata getagged sind, wären vermutlich eher assisted-trails.Ich versuche aufgrund der Diskussion hier die Unterscheidung beim Mappen inzwischen konsequent umzusetzen.
VG Reiner
assisted_trail=yes gehört da dazu:
http://wiki.openstreetmap.org/wiki/Proposed_features/Safety_measures_on_hiking_trails
Die Haupttags (safety_rope, ladder, rungs) sind in den Karten enthalten und werden dargestellt. assisted_trail ist zu diesen nur eine Ergänzung, siehe diesen Satz:
„If you don’t want to split a longer highway=path into several segments to tag their particular safety measures you can add the following tag to the whole highway=path:“
Mir ist da das genauere Markieren von den Haupttags lieber.
Vor kurzem wurde eine extra WIki-Seite zu assisted_trail erstellt, die das angenomme proposal verkürzt darstellte und dadurch assisted_trail aufwertete. Dazu habe ich nirgends was außer der neuen Seite gefunden, deshalb hab ich die englische assisted_trail Wiki-Seite um die für die Definition wichtigen Teile des Proposals ergänzt.Generell bleibt jeder Wanderweg mit Seilen/Ketten/Leitern/Sprossen etc. für mich ein Wanderweg/kein Zwischending, solange es kein expliziter Klettersteig ist. sac_scale ist auch so definiert, dass ab T3 diese vorkommen können. Deshalb macht es für mich mehr Sinn, die jeweiligen Hilfsmittel zu mappen/darzustellen, assisted_trail ist zu T3+ fast eine Doppelung.
Developer of Elevate mapstyle
- Sie müssen angemeldet sein, um zu diesem Thema eine Antwort verfassen zu können.