OPENER-next Projekt Vorstellung und Tag Feedback

Hallo liebe OSM-Community,
wir von der TU Chemnitz arbeiten im Projekt OPENER next (https://www.openernext.de/) an einer Cross-Plattform-App, die dazu dienen soll, deutschlandweit Daten an Haltestellen vor allem bzgl. der Barrierefreiheit zu erfassen.

Im Personenbeförderungsgesetz wurde festgelegt, dass alle Haltestellen (von Ausnahmen abgesehen) bis Anfang 2022 vollständig barrierefrei zu gestalten sind (siehe https://dserver.bundestag.de/btd/18/111/1811160.pdf Seite 5 Punkt 6). In diesem Zuge ist es zunächst nötig, Merkmale zur Barrierefreiheit und deren Umsetzungsgrad zu erfassen, um so auch ein verbessertes barrierefreies Routing anbieten zu können.

Für die relevanten Merkmale dient für uns das DELFI-Handbuch (https://www.delfi.de/media/delfi_handbuch_barrierefreie_reiseketten_1._auflage_mai_2018.pdf) als Grundlage. Unser Ziel ist es, die Daten direkt in OSM zu speichern, da sie letztlich von der Allgemeinheit für die Allgemeinheit erfasst werden sollen. Dafür haben wir zunächst eine Überführung der DELFI-Attribute in OSM-Tags vorgenommen, welche ihr hier findet: https://wiki.openstreetmap.org/wiki/User:OPENER/DELFI_OSM_Tags
Bei einigen Attributen konnten wir kein OSM-Äquivalent finden, weshalb wir eigene Tag-Vorschläge entwickelt haben (Spalte „Offizieller Tag“ ist dann mit einem roten X markiert).

Zu den folgenden Tag-Vorschlägen hätten wir gerne Feedback aus der Community auch in Hinblick auf eine spätere Standardisierung.

announcement={yes, automatic, manual, mixed, no}

kerb:approach_aid={yes, no}

kerb:type=""

wheelchair:portable_ramp={yes, no}

wheelchair:portable_lift={yes, no}

wheelchair:lift={yes, no}

tactile_paving:guide={yes, no}
tactile_paving:entrance={yes, no}
tactile_paving:locate={yes, no}

Danke für euer Feedback!

Das klingt spannend. Habt ihr Bebilderungen für das ein oder andere Attribut?

Ich kenne keine Bordsteinnamen, die ich in kerb:type eintragen würde. Was wären Werte dafür?

Beispiele wären in der Tat hilfreich. Bislang kenne ich es von wheelchair:description, dass als Freitext eingetragen wird, ob zum Beispiel ein Kasseler Bord vorhanden ist oder nicht.

Hallo zusammen,

wenn ich tactile_paving:=, wheelchair:= oder kerb:= lese würde ich unter anderem zwingend auf https://wiki.openstreetmap.org/wiki/DE:Rollstuhlfahrer-Routing und z.B. auf https://www.routago.de/pedestrian-routing/?lang=de&map=49.0071084,8.404026,14verweisen und mit ihnen ein sauberes Tagging abstimmen.

Soweit, wie ich es beobachte, würde da das Tagging-Pendel ein stückweit weiter zum separaten Tagging von straßenbegleitenden Rad- und Fußwegen jeglicher Form schwingen…

Sven

Hi

ich würde mich mal Projekt am schon erprobten orientieren, hier klingt es sehr ähnlich nach StreetComplete.

https://wiki.openstreetmap.org/wiki/DE:StreetComplete

Bei wheelchair:portable_ramp und wheelchair:portable_lift wäre bei uns beides =no, weil eben bei der S-Bahn die Bahnhöfe schon so gebaut sind das man das nicht braucht

Gruß miche

Für was braucht es eine weitere Spezial-App? Haben wir nicht schon genug Apps, mit denen es immer wieder Probleme gibt?
Wäre es nicht sinnvoller, die wheelchair-App, StreetComplete ua. und Euer Vorhaben zu einer App zu verschmelzen und diese gemeinsam weiterzuentwickeln?

Das ist tatsächlich ein sehr spezielles Attribut. Wir wollen es Hauptsächlich dafür verwenden verschiedene Busborde zu beschreiben (https://de.wikipedia.org/wiki/Busbord).
Beispielwerte wären dann: Kasseler Sonderbord, Combibord, Sonderbord Plus
Ein paar Bilder sind im Wikipedia Artikel zu finden oder hier: https://www.kvv.de/fileadmin/user_upload/kvv/Dateien/Broschueren/KVV_Leitfaden_barrierefreie_Haltestellen.pdf

Prinzipiell wollten wir den Tag so generisch halten, dass er auch für andere Bordsteintypen (also nicht zwingend Busborde) verwendet werden kann.
Besonders bei diesem Tag sind wir allerdings offen für Vorschläge wir wir die Busbordtypen anderweitig taggen könnten. Grund des Freitextfeldes war, dass sich die Busborde vermutlich nur schwer auf wenige konkrete Werte herunterbrechen lassen.

Interessant, wir kennen zwar den wheelchair:description Tag, wussten aber nicht, dass er sogar dafür verwendet wird. Unser Tag wäre dann der Versuch diese Information in einen separaten Tag auszulagern.

Danke für den Hinweis. Diese Wiki-Seite kannten wir noch nicht, scheint aber sehr gut zu unserem Thema zu passen!

Dahingehend könnte man vlt. meinen, dass die Tags etwas irreführend verstanden werden können. “No” würde in diesem Fall negativ wirken obwohl es eig. etwas gutes ist. Solange mit wheelchair=yes beschrieben wird, dass die Plattform rollstuhlgerecht ist, sollte das hoffentlich kein Problem sein.

Grüße
Robin

“Spezial-Apps” braucht es unserer Meinung immer dann, wenn Bürger einbezogenen werden sollen die OSM noch nicht kennen oder nicht wirklich vertraut damit sind.
Dadurch erreicht man in der Regel eine größere (aber auch andere) Zielgruppe, nämlich die Menschen außerhalb von OSM die in ihrer Freizeit etwas beitragen wollen, denen aber vlt. die Hürden bisher zu hoch waren oder die einfach noch nicht auf OSM aufmerksam geworden sind. In diesem Zuge können diese “Speziel-Apps” auch als Werbung bzw. onboarding für neue OSM Nutzer gesehen werden. Wir glauben, dass durch gut reglementierte und simple Fragen auch OSM unerfahrene Menschen einen Beitrag leisten können.

StreetComplete deckt tatsächlich bereits einen Teil der von uns geplanten Funktionalität sehr gut ab. Allerdings benötigen wir mehr Funktionen als nur das reine hinzufügen von Tags. Das in StreetComplete zu integrieren würde aber der Stärke von StreetComplete entgegenwirken. Zudem ist die App nur für Android und sonst keine weiteren Plattformen verfügbar.

Die wheelchair-App fokussiert sich vor allem darauf die Zugänglichkeit für Rollstuhlfahrer zu erfassen. Obwohl das eine wichtige Rolle bei uns spielt versuchen wir eher “objektive” Informationen zu erfassen auf deren Basis dann abgeleitet werden kann ob eine Haltestelle rollstuhlgerecht ist oder nicht. Auch hier gilt wieder das selbe Argument wie bei StreeComplete: das reine Ergänzen von Tags reicht für uns leider nicht aus, da wir z.B. Fahrkartenautomaten mit erfassen wollen.

Grüße
Robin

Hi,

da laufen schon andere Projekte in der Richtung in BW und BY.

Setzt Euch doch bitte mal mit BEG und NVBW in Verbindung.

Was wir nicht gebrauchen können: unterschiedliche Ansätze aus diversen Bundesländern.

Ich will hier keinen Realnamen oder Mailaddressen von Ansprechpartner nennen, aber “BEG” für BY und “NVBW” für BW sollten schon mal ein Begriff sein. Ansonsten bitte eine PM an meinen gleichnamigen OSM-Account.

https://wiki.openstreetmap.org/wiki/Bayerische_Eisenbahngesellschaft_(BEG)

Haben wir eine Wiki-Seite für NVBW? Konnte nichts finden.

Nicht zwangsläufig; die eingangs erwähnten Attribute scheinen mir auch gut auf nur als Knoten erfasste Haltestellen (bus_stop) oder Wartebereich (platform) anwendbar.

Was auf keinen Fall passieren darf: Plattformen als straßenbegleitende Linien einzeichnen, wo keine separat gemappten Gehwege da sind, an die sie anschließen können. Die bilden dann Routinginseln in Längsrichtung, bzw. unüberwindliche Barrieren in Querrichtung, den pt=platform ist notorisch schwammig, meist ist es ein Stück glorifizierter Gehweg, es kann aber auch neben der Grube sein, in der die Seilbahngondel/der ICE einfährt.

Hallo zusammen,

ich arbeite für die Firma MENTZ und bin die OSM Ansprechpartnerin für die Bayerische Eisenbahn Gesellschaft (BEG) beim Projekekt Barrierefreiheit4ÖPNV. https://wiki.openstreetmap.org/wiki/Bayerische_Eisenbahngesellschaft_(BEG)
Wir sind momentan mit dem Team von OPENER next in Absprache. Wir sind auch daran interessiert, dass hier möglichst einheitliche Ansätze genutzt werden.
Die Wikiseite vom NVBW ist: https://wiki.openstreetmap.org/wiki/User:NVBWSeifert/Barrierefreie_Reisekette
Wir erfassen momentan nur einfache Bushaltestellen, greifen aber bald etwas komplexere Tramhaltestellen an.
Bei Rückfragen gerne melden!

Ähm, ich erlebe das eher als Standard. Ist doch das Gleiche wie mit dem Haltestellenschild. Haltestellenschild als Punkt, wenn es keine Bussteige gibt, Bussteigkante als Linie, wenn es einen Bussteig gibt. Unabhängig davon, ob die Gehwege seperat gemappt sind oder nicht. Bislang habe ich mit den üblichen Routern kein Problem damit gehabt.

Das sind dann wohl Router die nicht auf Barrierefreiheit achten. Wahrscheinlich ignorieren die querliegende Plattformen einfach. Genauso wie sie Zebrastreifen ignorieren bei der Wahl, wo die Straße überquert wird, und alles das sowieso, was Anliegen der Threadstarter ist.

Naja, es klingt für mich danach, dass jemand Neulingen sagt “Macht es nur nicht so wie es üblich ist” anstatt eine Diskussion zu straten, ob man die Taggingpraxis ändern sollte.

Hast du ein konretes Beispiel, wo ein Router ein Problem mit einem nicht angebundenen Bussteig hat?

Wenn mann ein Ziel außerhalb eines Weges angibt, so sucht sich doch jeder Roter einen passenden Punkt auf der nächsten Straße. Wenn das eine Zweipunkt-Linie ohne Anschluss ist, sollte diese sinnvollerweise ignoriert werden, insbesondere bei Bussteigen, wo das sehr häufig so ist.

Ich weiß nicht ob es umsetzbar wäre, für Bushaltestellen unterschiedliche Tagging-Schema einzuführen, jenachdem, ob die Gehwege seperat oder an der Straßenlinie getaggt sind. Da müsste doch viel Vorhandenes umgebaut werden mit viel Löschen vorhandenenr Bussteigkanten.

Nunja, ich hab das ja nur als Vorschlag gepostet, dass man, wenn man Eigenschaften erfasst, die auf Barrierefreiheit abzielen, und auch grundlegend Neues zu erstellen vorhat, dass man da zurückhaltend mit Plattformen als Linien vorgeht, sondern auch die Möglichkeit in Betracht zieht, diese als Punkt zu erfassen. Zumindest solange es sich bei den Plattformen um nicht mehr als Abschnitte von straßenbegleitenden Gehwegen handelt, die ja bereits als Attribut der Straße erfasst sein könnten.

Dass ein Router von einer “Insel” so einfach ins “Netz” springt oder diese gar ganz übergeht, das halt ich für bedenklich. Wie gesagt bin ich nicht sicher ob “Plattformen” eine Ausnahme davon sein dürfen. Die Dokumentation zu denen sagt dazu leider gar nichts.

Ok, ist bei mir anders rübergekommen, sorry.

Das stimmt, für mich ist das Verhalten der Router auch oft ein Rätsel und Fischen im Trüben

Ich finde das durchaus eine interessante Information. Damit das für möglichst viele Anwendungsfälle automatisiert auswertbar ist, wäre es hilfreich, dass zumindest die Schreibweisen standardisiert und die gängigsten Werte dokumentiert (auch wenn klar ist, dass die nur ein kleiner Teil aller möglichen Werte sind).