Bitte um Feedback zu Leitfaden für Barrierefreiheit an Haltestellen

Hallo!

Neben meinem Mapping in der Freizeit arbeite ich auch für das Projekt OPENER next, bei dem es darum geht, Daten zur Barrierefreiheit im öffentlichen Nahverkehr in Deutschland besser erfassbar und zugänglich zu machen.

Dafür arbeiten wir an mehreren Dingen, unter anderem an einer Anleitung, die als Hilfestellung bei der Erfassung von Barrierefreiheitsdaten an/um Haltestellen dienen soll. Diese Anleitung habe ich nun in den letzten Monaten erstellt. Ich habe zwar schon einiges an Mapping-Erfahrung, aber mit Wikiseiten habe ich noch nicht so viel zu tun gehabt und natürlich bin auch ich nicht der Weißheit letzter Schluss. Deswegen, und natürlich weil wir diese Anleitung gerne als Maßstab/Referenz in unseren anderen Projekten verwenden wollen, würden wir euch gerne um Feedback zu ihr bitten:

https://wiki.openstreetmap.org/wiki/DE:Leitfaden_-_Barrierefreiheit_an_Haltestellen

Was genau gemappt wird orientiert sich am sog. DELFI-Handbuch. Es gibt allerdings nicht für alle DELFI-Attribute eine 1:1-Entsprechung in OSM.

Wir würden uns sehr freuen, wenn ihr euch die Zeit zum Durchlesen nehmt und Feedback da lasst, gerne auf der Diskussionsseite oder in diesem Thread.
:slight_smile:

VG, Wieland

1 Like

Servus Wieland,

auf die Schnelle und ohne schon rein geschaut zu haben fielen mit sofort die Aktivitäten der BEG, DELFI, Mentz und NVBW in diesem Bereich ein:

VG Toni

Edit: die Suchfunktion im Wiki ist nach dem SW-Wechsel noch nicht wieder voll funktionsfähig

Auf die Schnelle:
height an Bahnsteigen scheint nicht in allen bisher verlinkten Dokumenten vorhanden.
Gibt es ein schon übliches Gegenstück dazu bei den Fahrzeugen, sprich: bei den Linien? Weil nur die Kombination ergibt ja die Rollstuhlgängigkeit …
Und dann gibt’s noch solche Spezialitäten wie hier in KA, wo es auf rund 80 m einen 34 cm hohen Bahnsteig für alle dazu passenden Linien gibt mit Einstieg auf ganzer Länge und nach 5 m Rampe nochmal über 15 m den verlinkten Bahnsteig mit 55 cm Höhe für nur die ersten beiden Türen von Zweisystemlinien (neben den dort erwähnten auch noch andere höhere Nummern), fröhliches Modellieren … :wink:

Hey :slight_smile:

Das mit den zweigeteilten Bahnsteigen kennen wir in Chemnitz auch nur zu gut. :confused: Allerdings ist es bei uns dann auch immer so, dass diese beiden Abschnitte des Bahnsteigs als separate Bahnsteige geführt werden. (z.B. 3A und 3B) Allerdings dürften auch getrennt modellierte Bahnsteige kein Problem sein, denn über die DHID müsste sich ergeben, welche Bahnsteig-Elemente in Wirklichkeit zu einer Plattform gehören.

Mit den Linien ist das natürlich so eine Sache… Man könnte, falls es einheitlich pro Linie ist, natürlich der Routenrelation eine entsprechende Eigenschaft geben. Allerdings sehen wir diese Information nicht in OpenStreetMap verortet, da zu verschiedenen Zeitpunkten, verschiedene Busse die Plattform anfahren können. Für eine vollständige barrierefreie Auskunft braucht es dafür Echtzeitdaten über das Verkehrsmittel von den Verkehrsverbünden.

Hey Toni :slight_smile:
Ja, mit vielen von denen arbeiten wir zusammen und haben uns auch abgestimmt. Nur sind die Leute dort ja, genau wie viele bei uns, eher “ÖPNV-Profis” als “OSM-Profis”, weswegen wir gerne nochmal euer Feedback wollten.

Oops und sorry, hatte das Thema und das eigentliche Feedback wohl vergessen.

Gute Frage. Ich habe schon ein height=* an route=train gesehen, aber ob das eine gute Lösung ist, sei dahingestellt.

Interessant finde ich auch das Tagging einer Informationssäule mit information=phone. Das kannte ich bisher noch gar nicht. Ist aber grundsätzlich eine super Sache. Passt auch super zu emergency=phone und railway=phone. Ich habe mich echt immer gefragt, wie man diese kombinierten Info- und Notrufsäulen taggen soll.

Bisher habe ich dafür immer nur emergency=phone verwendet.

Das mit der bewegbaren Rollirampe (wheelchair:portable_ramp=yes/no) ist auch eine tolle Sache.

Allerdings ist es in NRW z. B. soweit ich weiß, so, dass solch eine Rampe nur an größeren Bahnhöfen tatsächlich vor Ort irgendwo vorgehalten wird. Alle Züge (vor allem die S-Bahnen) haben diese Rampe stattdessen an Bord, sie muss dann im Fall der Fälle vom Zugbegleitpersonal oder durchaus auch vom Triebfahrzeugführenden bedient werden. Von daher wäre wheelchair:portable_ramp=yes/no auch für route=train interessant.

Kleiner Kritikpunkt: indoor=door für Aufzugstüren finde ich kritisch. Das ist schon damals von Mentz falsch verstanden worden, dass Aufzüge immer “indoor” seien. Ein Teil der Tür ist drinnen, ja, aber ein Teil ist auch draußen, bzw. kann zumindest draußen sein (auf mindestens einer Etage ist das in der Regel der Fall). Ich würde einfach entrance=yes zusammen mit door=* und automatic_door=button taggen.

1 Like

Müsste man btw ein paar (wenige) Tags aus dem Leitfaden nicht besser vorher eben noch zur Diskussion stellen?

Die wheelchair-Tgas wheelchair:portable_lift und wheelchair:portable_ramp halte ich wie gesagt für eine sehr gute Idee – habe sie aber vorher noch nirgendwo in der DB gesehen. Vlt müsste man sie daher noch zur Abstimmung oder so was stellen.

Ähnlich sieht es mit information=phone und information:public_transport=yes aus, was letzlich eine Erweiterung des tourism=information-Schemas darstellen würde.

announcement=* befindet sich gerade in einem Proposal-Prozess.

Auch die Competition amenity=locker vs. amenity=luggage_locker (und ggf. einem ameniyt=lockers, was ich auch schon oft gesehen habe), ist noch nicht geklärt. Da würde ich lieber noch etwas abwarten, bevor man eines der drei Tags empfiehlt.

1 Like

Überlege, ob Du evtl. noch maxwidth:physical mit einbaust. Ein Weg kann zwar eine gewisse Breite haben, aber an Engstellen wie Poller, Mülleimer oder durch in den Weg hineinragende Handläufe etc. verengt sein.

https://wiki.openstreetmap.org/wiki/DE:Key:maxwidth:physical

Einzelne Stufen erfasse ich als Node mit barrier=step:

https://wiki.openstreetmap.org/wiki/DE:Tag:barrier=step

1 Like

Vor ziemlich genau 10 Jahren habe ich für die PTv2-Relationen der Linie 10 in Zürich (nur Niederflurtrams vom Typ ‘Cobra’) den tag ‘entrance:height=0.35’ verwendet. Da ich in der Regel keine tags erfinde, sondern bereits verwendete tags kopiere, habe ich etwas gesucht: CS7039099 von 2011-01-21 hat diesen (für mich) logisch nachvollziehbaren tag verwendet. Ich bin mir relativ sicher, dass ich diesen tag damals für gut befunden und übernommen habe. Ich finde der tag ist auch heute noch verständlich.

1 Like

Dieses Tag wäre in der Tat eine Überlegung wert!

Ich glaube, ich hatte mit @Nakaner mal darüber gesprochen (bin mir aber nicht sicher?), dass die Einstiegshöhenangabe eventuell dann nachteilig ist, wenn auf einer Linie (= einer Relation) zwei (oder mehr) verschiedene Fahrzeugtypen mit unterschiedlichen Einstiegshöhen verkehren und man dann theoretisch nur wegen der unterschiedlichen Einstiegshöhe zwei PTV2-Relationen bräuchte.

Wie häufig das in der Praxis aber überhaupt vorkommt, vermag ich nicht zu sagen. Ich meine ja, dass – in aller Regel – auf den allermeisten Linien Fahrzeuge mit einer bestimmten Einstiegshöhe verkehren, zumindest, was Züge betrifft, gerade in DE.

Das ist bspw. im Netz der Karlsruher Zweisystemlinien relevant.
Die erste Serie Zweisystembahnen waren Hochflurer, erst paar Jahre später fiel die Entscheidung, zur Barrierefreiheit Mittelflurer passend zu 55 cm hohen Bahnsteigen einzuführen. Die alten Hochflurer fahren sicher noch einige Jahre auf Umläufen, die weder durch den Stadtbahntunnel (Hochflurer wurden nicht mehr bzgl. Brandschutz umgerüstet), noch über die Steilstrecke im Murgtal (keine Zulassung dafür) fahren, also bspw. auf der S31/S32.

Okay, verstehe. Aber sind dann auch zwei unterschiedliche Einstiegshöhen auf derselben Linie unterwegs? Also dass man zwei Relationen für dieselbe Linie (nur eben andere Umlaufnummern, aber gleicher Linienweg) bräuchte?

Oder sind die Hoch- und Niederflurbahnen auf unterschiedlichen Linien unterwegs?

Vielen dank für die rege Diskussion, Vorschläge und Ideen.

Ich versuche mal ein paar Dinge zu beantworten.

Allerdings ist es in NRW z. B. soweit ich weiß, so, dass solch eine Rampe nur an größeren Bahnhöfen tatsächlich vor Ort irgendwo vorgehalten wird. Alle Züge (vor allem die S-Bahnen) haben diese Rampe stattdessen an Bord, sie muss dann im Fall der Fälle vom Zugbegleitpersonal oder durchaus auch vom Triebfahrzeugführenden bedient werden. Von daher wäre wheelchair:portable_ramp=yes/no auch für route=train interessant.

Das entspricht auch unserer Erfahrung. Wir erfassen sie daher nur an Plattformen an denen Züge halten (leider sind Straßenbahn Haltestellen nicht immer einfach von Zughaltestellen zu unterscheiden).

Das mit der route Relation finde ich eine interessante Idee. Wir verfolgen bisher die Richtung fahrzeugspezifische Daten nicht in OSM an den Routen zu verorten. Für Züge und Straßenbahnen mag das noch ganz gut gehen, aber bei Bussen kann es doch schnell zu wechselnden und unterschiedlichen Fahrzeugen kommen. Mir würde auch eine Tramlinie einfallen, welche die selbe Route fährt aber einmal kommt ein älteres Modell und einmal ein neueres Modell. Dennoch könnte man den Tag definitiv dafür nutzen.

Kleiner Kritikpunkt: indoor=door für Aufzugstüren finde ich kritisch. Das ist schon damals von Mentz falsch verstanden worden, dass Aufzüge immer “indoor” seien. Ein Teil der Tür ist drinnen, ja, aber ein Teil ist auch draußen, bzw. kann zumindest draußen sein (auf mindestens einer Etage ist das in der Regel der Fall). Ich würde einfach entrance=yes zusammen mit door=* und automatic_door=button taggen.

Das stimmt. Wir würden da dem selbem Schema folgen wie wir es im Abschnitt „Tür“ beschrieben haben. Also liegt der Fahrstuhl in einem Gebäude dann indoor=door, sonst entrance=yes.

Müsste man btw ein paar (wenige) Tags aus dem Leitfaden nicht besser vorher eben noch zur Diskussion stellen?

Da sind wir gerade dran. Gestartet haben wir mit annoucement, passenger_information_display:speech_output=yes/no siehe proposal

und kerb:approach_aid ist derzeit in Arbeit. Als nächstes würden wir wheelchair_portable_lift + ramp angehen.

Auch die Competition amenity=locker vs. amenity=luggage_locker (und ggf. einem ameniyt=lockers, was ich auch schon oft gesehen habe), ist noch nicht geklärt. Da würde ich lieber noch etwas abwarten, bevor man eines der drei Tags empfiehlt.

Vlt. könnten wir in diesem Zuge das Proposal amenity=locker weiter voran bringen? Denn es steht ja schon eine ganze weile still und unserer Meinung nach ist amenity=locker in vielerlei Hinsicht die bessere Variante.

Überlege, ob Du evtl. noch maxwidth:physical mit einbaust. Ein Weg kann zwar eine gewisse Breite haben, aber an Engstellen wie Poller, Mülleimer oder durch in den Weg hineinragende Handläufe etc. verengt sein.

Das ist etwas das ganz oben auf unserer ToDo Liste steht. Wir sind uns nur noch nicht sicher wie Engstellen bzw. die engste Stelle einer Plattform am besten erfasst werden sollte. Wir haben dazu verschiedene Überlegungen bzgl der tags: narrow und maxwidth:physical

Ideen:
Hat die plattform eine engstelle (< 90cm?) > narrow=yes/no (narrow hätte also für Haltestellen eine andere Bedeutung als Straßen)
Wenn yes: narrow:width=70 cm oder narrow=70 cm oder maxwidth:physical=70 cm
ODER
separater node/barrier der den genauen Punkt der Engstelle lokalisiert. Für Plattformen die Wege sind würde das gut gehen aber für Flächen wäre das nicht möglich.

Einzelne Stufen erfasse ich als Node mit barrier=step:
https://wiki.openstreetmap.org/wiki/DE:Tag:barrier=step 2

Wir finden auch, dass das die naheliegendere Variante ist. Der einzige Vorteil bei highway=steps ist, dass man das incline angeben kann. Daher haben wir beide Varianten im Guide erwähnt.

1 Like

Super, vielen Dank für das Feedback zu meinen Äußerungen; ich werde die Proposals auf jeden Fall verfolgen und finde, da sind echt prima Ansätze drin.

Gute Idee :grinning:

Vielleicht sollte man später – wenn der Leitfaden fertig ist – irgendwie noch die Mentz GmbH darüber informieren (, z. B. darüber, dass es einige neue Tags gibt). Die machen ja auch viel mit indoor an Bahnhöfen usw.

Wie ToniE im Beitrag #2 bereits geschrieben hat, gibt es bereits ein paar Wiki-Seiten, deren Dokumentation ähnliche Aspekte des ÖPNV-Mappings aufgreift und ähnliche Ziele verfolgt, das müsste man nach und nach Tagging-mäßig ggf. noch untereinander abstimmen. Aber das kommt alles erst nach und nach, je nach dem, welche ggf. neuen Tags sich etablieren.

1 Like

Ich bin mit der S31/S32 nur sehr sporadisch unterwegs (zuletzt letztes Jahr genau 1x), aber im Prinzip dürfte auf dieser Linie ein solcher gemischter Betrieb stattfinden. Im Rolliliniennetz ist sie so gekennzeichnet. Im Fahrplan steht leider nicht, welche Umläufe wie gefahren werden …

1 Like

Unter anderem zum Taggen von tourism=information mit information=phone:

Ich habe by the way sowieso so das Gefühl, wir müssen uns noch einmal darüber unterhalten, wie wir Fahrgastinformationen jeglicher Art in Zukunft taggen möchten. Die sind für mich ganz klar mehr ein public_transport-Feature als ein tourism-Feature.

Das ist mir z. B. ab und zu auch ein kleines Dorn im Auge bei dem taggen einer analogen Fahrgast-Info-Vitrine:

tourism=information

information=board

board_type=public_transport

zusätzlich haben wir – hauptsächlich für die digitalen – für Infotafeln noch die Keys passenger_information_display

und

departures_board,

die hauptsächlich als Ausstattungs-Tags an public_transport=platform verwendet werden, manchmal aber auch als Main-Tags für ein entsprechendes Objekt (eine digitale Anzeigetafel).

Als Main-Tag für eine digitale Anzeige sind auch noch public_transport=info_board und public_transport=destination_diplay im Umlauf.

Dann haben wir auch noch den Key information:public_transport.

Puh, wie bekommen wir das nur alles unter einen Hut?




Ich persönlich würde ja einen Mittelweg vorschlagen, so etwas wie

public_transport=information (analog zu tourism=information)

information=board für (analoge) Info-Vitrinen

information=display für Displays – wobei das leider wiederum nicht zu den existierenden Keys passenger_information_display und departures_board passen würde

information=service_point oder information=information_desk für die kleineren Service-Points

information=office für die größeren Offices






Müsste an natürlich diskutieren. Fände ich aber auf jeden Fall definitiv sehr sinnvoll, bevor man ggfs. public_transport=service_center oder information=phone im Wiki dokumentiert.

Kleiner Kritikpunkt: indoor=door für Aufzugstüren finde ich kritisch. Das ist schon damals von Mentz falsch verstanden worden, dass Aufzüge immer “indoor” seien. Ein Teil der Tür ist drinnen, ja, aber ein Teil ist auch draußen, bzw. kann zumindest draußen sein (auf mindestens einer Etage ist das in der Regel der Fall). Ich würde einfach entrance=yes zusammen mit door=* und automatic_door=button taggen.

Danke für den Tipp, habe ich so geändert. :slight_smile:

1 Like