Nicht zum Thema, aber: oh, danke für den Tipp! 
Ich finde es toll, wenn/dass keepright weiterentwickelt wird! Die neue Version scheint, wenn ich das richtig sehe, auch sonst ein paar Fehler mehr zu finden, z.B. findet „missing tags“ jetzt auch Objekte, die als einziges Tag name=* haben – das ist ein sehr nützlicher Test! Habe gleich mal ein paar solcher Objekte gefixt, und da bleibt noch viel zu tun …
Es gibt sehr viele Wartungs- und Fluchtwege:
- viele Gebäude haben außenliegende Fluchttreppen
- große Gebäude haben oft zahlreiche Fluchtwege, teils sogar als Tunnel unter dem Gebäude
- auf Dächern gibt es Trittsteine zu Klimaanlagen und Schornsteinen
- fast jedes Silo und jeder Großtank haben Außentreppen
- große Strommasten haben Leitern oder sogar Treppen
- lange Straßen- und Eisenbahnbrücken haben Wartungswege an der Seite
- lange Verkehrstunnel haben oft mehrere Röhren mit Querstollen
- an Fluchttüren in Wildzäunen und Lärmschutzwänden gibt es manchmal einige Betonsteine auf beiden Seiten
- selbst Schilderbrücken über der Autobahn sind oft begehbar.
Wenn wir diese Wege als “highway” erfassen, macht das alle auf OSM basierende Karten sehr unübersichtlich.
Wenn man dabei die access-Tags nicht oder falsch setzt provoziert man Routingfehler.
Sobald ein Router einmal vorschlägt, über die Autobahn zu fahren, an der Brücke auszusteigen und über die Treppe zum Ziel zu gehen, macht sich OSM wieder als Hobbyprojekt lächerlich.
Weder Straßenwärter, noch Handwerker oder Flüchtende werden diese Wege bei OSM suchen.
Ich würde solche Wege daher nicht erfassen.
Man könnte auch ein neues Taggingschema für Wartungswege einführen (z.B. “highway=maintenance”, “maintenance=steps”) und so die Probleme umgehen.
Wenn man die Treppen unbedingt in die OSM-Karten bringen will, sollte man zumindest auf den Verbindungsweg zur Autobahn verzichten. Die meisten Treppen enden ohnehin hinter der Leitplanke.
Wenige Wartungstreppen sind zur Benutzung freigegeben (“Betriebsweg - Zugang auf eigene Gefahr - kein Winterdienst”).
Diese erfasse ich auch als “highway”.
Solche Not- und Wartungstreppen sind keine Verkehrswege.
Ich würde sie überhaupt nicht mappen. Falls man es unbedingt einzeichnen muß dann auf keinen Fall mit highway=*. Verwechslungen mit echten Wegen sind vorprogrammiert und gefährlich.
Dann lieber ein eigenes Taggingschema.
bye, Nop
Wie wäre es mit emergency=evacuation? Dazu könnte man dann noch mit evacution=* verfeinern, um die Art des Fluchtweges zu definieren (ladder, stairs, tunnel, door…).
Reine Wartungswege könnten analog mit maintenance erfasst werden.
Ich stelle mir gerade mal bildlich vor, wie ein Autofahrer nach einem Unfall am Rande der Autobahn steht und versucht in mittels Navi-App auf seinem Smartphone den nächsten Fluchtweg zu finden 
+1
Bitte vergiss nicht, dass wir hier eine Datenbank füllen, aus der man unter anderem Karten generieren kann. Eine spezielle Auswertung könnte sein, dass für Rettungskräfte entsprechende Karten oder sonstige Informationsquellen zur Einsatzvorbereitung über Flucht- und Rettungswege dargestellt werden.
Danke für eure Antworten. Es ist wirklich nicht so einfach, hier eine Lösung zu finden und die meisten Argumente hier sprechen auch für sich. Support für Rettungs- und Einsatzkräfte ist tatsächlich ein sinnvoller Grund für mich, an OSM mitzuarbeiten.
Warum soll es den im witzig gemeinten Kommentar von Galbinus genannten Anwendungsfall nicht auch in der Praxis geben? Wenn die Leute nach einem Unfall durcheinander sind, kommen sie auf die irrationalsten Ideen. Dann lieber eine(n) Vermisste(n) auf der Landstraße suchen als dass er/sie auf die Autobahn läuft und dort Schlimmeres verursacht. Im Übrigen sind bereits Leute von der Autobahnbrücke gefallen, weil sie nach einem liegengebliebenen Auto oder Unfall nachts an der falschen Stelle über die Leitplanke geklettert sind.
Nach den Grundsätzen “We map what’s on the ground” und “Wir mappen nicht für Renderer” finde ich es sinnvoll, solche Wege zu mappen. Ich denke, übertrieben viele Objekte darzustellen oder in den Routingprozess einzubeziehen, ohne sie anhand ihrer gemappten Merkmale auf Eignung zu untersuchen, ist ein Fehler des Renderers/Routingprogramms. Ein Fehler in der OSM-Datenbank liegt für mich nur vor, wenn wir falsch mappen oder wichtige Merkmale weglassen.
Ich habe an die Wege, Treppen und Tore wie oben vorgeschlagen das Tag access=emergency angehängt.
Das ist leider keine gute Lösung. Dieses Tag dürfte von den meisten Renderern und Routern nicht ausgewertet werden und ist damit praktisch wirkungslos.
Du hast somit gefährliche Pseudo-Verkehrswege geschaffen.
Du solltest sowas nicht mit highway= sondern mit emergency= taggen, dann ist es für Rettungskarten auswertbar und für alle anderen Karten harmlos.
bye, Nop
Router, die access-Tags nicht auswerten dürften sehr selten sein. Wenn da ein Weg ist, darf er auch als Weg gemappt werden. Routing-Gefahr geht von einem solchen Weg nicht aus, schließlich endet er für Fußgänger im Nichts, weil die Autobahn ohnehin ein implizites foot=no hat.
In der Spec zu access ist emergency kein definierter Wert.
https://wiki.openstreetmap.org/wiki/Key:access
Als key jedoch erlaubt.
Richtig wäre also:
access=no
emergency=designated
Du hast allerdings Recht, dass im vorliegenden Fall die Gefahr von Fehlrouting klein ist.
emergency=* wird aber als “emergency motor vehicles” beschrieben, das passt nicht für einen Fußweg.
access=emergency steht nicht explizit im Wiki, wird allerdings auch schon ein paar tausend Male verwendet (inkl. vehicle=emergency etc.)
Das lese ich hier aber anders:
http://wiki.openstreetmap.org/wiki/Key:emergency
Da sind sogar Sammelpunkte erwähnt.
emergency=(yes, no, designated etc.) gehört aber zu den access-Tags. Unter https://wiki.openstreetmap.org/wiki/Key:access findet sich eben diese Beschreibung.
emergency=(Objekt) ist unabhängig davon und unter http://wiki.openstreetmap.org/wiki/Key:emergency beschrieben.
Warum da irgendwer den gleichen Key für beides eingeführt hat, ist natürlich eine ganz andere Frage…
emergency = escape_path wäre eine Objektbeschreibung und demnach in Ordnung
emergency = designated wäre eine access-Regel und würde sich auf Fahrzeuge beziehen
Ich denke, irgendein Wert für den Schlüssel emergency geht schon in die richtige Richtung, allerdings scheint das nirgendwo so richtig definiert zu sein.
Für access=emergency leuchtet mir ein, dass da nur Rettungskräfte entlang sollen. Allerdings beschränkt sich das Wiki auf “Einsatzfahrzeuge” und die dürften mit einer Treppe oder einem schmalen Weg nichts anfangen können.
Taginfo liefert mir zu emergency=evacuation genau 1 Eintrag, zu emergency=escape_path nichts, aber zu emergency=escape_route immerhin 11 Einträge, darunter den Fluchtweg in einer Schule. Das scheint ja zu passen. Ansonsten würde ich mich für das unspezifische emergency=yes zusätzlich zu access=emergency entscheiden, damit klar wird, dass hier Rettungskräfte und nur diese entlang dürfen.
Sind diese Treppen überhaupt als Flucht- oder Rettungsweg vorgesehen?
Die Böschungstreppen, die ich kenne, sind meist schmal, unbeleuchtet, ohne Geländer und oft recht steil. Damit sind sie als Fluchtweg nicht sonderlich geeignet. Sind diese Treppen als Rettungsweg beschildert oder in der Planung dafür ausgewiesen?
In einer Notlage darf man natürlich jeden möglichen Weg nutzen, aber wir können nicht deshalb jedes begehbare Objekt als “emergency” erfassen.
Auf dem Luftbild erkennt man an der im Eingangspost verlinkten Stelle, dass wenige Meter neben den Treppen die Auf- und Zufahrtsrampen beginnen, die sich als Flucht- oder Rettungsweg anbieten.
In den Leitplanken vor den Treppen erkenne ich keine Lücke. Falls es zutrifft, ist der “highway=path” definitiv falsch.
Ich halte die Treppen dort für betriebsinterne Wartungszugänge, die ich nicht oder allenfalls mit einem anderen Tag erfassen würde.
Natürlich werden diese benötigt und ich habe diese auch schon eingetragen.
Ich finde es gut, wemm man sich zu einem einheitlichen Tagging entscheidet.
Vorallem bei längeren Brandeinsätzen (zwischen zwei Tunneln) war ich schon dabei wie diese Information als Zufahrt für einen Wassertank benutzt wurde…
Manche “Tore” in Wildzäunen neben Straßen habe ich bisher ohne Pfad eingezeichnet. Ich denke, das sollte man so auch im Taggingschema vorsehen,
denn überall gibt es tatsächlich keinen Weg.
Danke, pos_ei_don, für deine Schilderung aus der Sicht derer, denen so eine Information mit am meisten nützt.
Wie die Diskussion zeigt, lässt sich dazu wohl keine einvernehmliche Lösung finden und bzw. weil das vorhandene Mapping-Schema nichts Handfestes hergibt. Deshalb habe ich vor ein paar Tagen diese Wege wieder entfernt.
Warum? Nur wegen der paar Stimmen hier? Ich finde das traurig…
Gelöscht hätte ich sie jetzt auch nicht - auch wenn das Tagging nicht völlig passt, ist es doch eine gute Information. Umtaggen nachdem ein besseres Schema gefunden ist, ist ja kein Problem. Durch das Löschen muss erst wieder jemand vor Ort vorbeigehen und die Türen finden.