Imho müsste das aber an die route-Relation getaggt werden. Es gibt verschiedene Buslinien die verschiedene Fahrzeuge einsetzen. Wenn eine Haltestelle von zwei Buslinien angefahren wird und die eine rollstuhlgerecht ist und die andere nicht, wirst du Schwierigkeiten bekommen, das an die Bushaltestelle zu taggen.
Hallo,
nur als Hinweis: Mit dem Diskutieren brauchen wir uns nicht so arg beeilen. Die aktuelle Wochenaufgabe geht noch (wegen Verlängerung) bis zum 23. Februar, die nächste Wochenaufgabe (Bücherschränke) beginnt am 23. Februar und dauert zwei Wochen. Anschließend wäre dann die WA Bushaltestellen dran (d.h. vsl. Beginn am 9. März 2015). Die WA Bücherschränke hat einen schon fast fertigen Text.
Viele Grüße
Michael
Das sind ja auch nur noch 3 Wochen bis zum eventuellen Beginn, also gar nicht allzuviel Zeit.
Zum Thema Rollstuhltauglichkeit: Im Proposal zum Tag “kerb” ( http://wiki.openstreetmap.org/wiki/Proposed_features/kerb#Examples ) schlägt vor “kerb=raised” für erhöhte Bordsteinkanten an Haltestellen zu verwenden - das klingt für mich nach einer guten Idee.
Bei der proposal Seite werden wir nicht das gewünschte Ergebnis bekommen.
Die wird irgend ein Kontrollfreak nutzen um
alle Bordsteine über 3cm als raised zu markieren und
die Bindung an Nodes in den Vordergrund stellen.
Selbst die kerb:height mit direkter unit Angabe wird im Chaos der Abkürzungen enden.
Wir müssen für wheelchair an der public_transport= platform eine Definition haben und dem gemeinen Mapper (wie mir) eine Einstufungsregel an die Hand geben.
Ich betone public_transport= platform, weil highway=platform in die Mottenkiste gehört.
Baulich wäre erkennbar zu unterscheiden zwischen:
A unbefestigte Flächen
Z.B. Grasnarbe über die eingestiegen wird, die der Rollstuhlfahrer erst garnicht befahren kann.
Fällt damit eindeutig unter wheelchair=no in platform und route.
B. Kein Bordstein
Eigentlich klar wheelchair=no , könnte kann aber bei einer route wie Grayhound mit Ausziehrampe und dortigen Begleiterregeln wieder zu wheelchair=yes werden.
C. Abgesenkter Bordstein
Bushalt in Auffahrten. Beurteilung wie B
D. Normalbordstein
Bei uns etwa 11cm über Straßenbelag. (Höhenangabe ist noch durch von/bis zu ersetzen und zu illustrieren)
Ist für mich vom Fahrzeug abhängig ob rollstuhlgerecht, würde vermutlich unter wheelchair=limited fallen.
E. Erhöhter Bordstein
Das was bei uns als rollstuhlgerecht vermarktet wird, aber fahrzeugabhängig ist.
(Höhenangabe ist noch durch von/bis zu ersetzen und zu illustrieren)
Liegt für mich zwischen wheelchair=limited und wheelchair=yes
F. Ebenerdiger Zugang zum Regelfahrzeug
Nur dieser wäre für mich eindeutig wheelchair=yes. (Regelfahrzeug wäre auch noch zu definieren, da Reisebusse in der Regel nicht rollstuhlgerecht sind)
Mein Verständnis für rollstuhlgerecht bezüglich Höhenlage ist:
wheelchair=yes kann von einem Rollstuhlfahrer selbständig unter Einhaltung der Rampenneigung von xx Promille genutzt werden.
wheelchair=limited alles zwischen yes und no
wheelchair=no es ist eine Stufe von über xx cm vorhanden, die nur mit fremder Hilfe überwunden werden kann.
Empfehlenswert wäre eine Zusatzangabe, die bei Änderung der Fahrzeuge einer route die Neubeurteilung zulässt:
Eine Angabe der Bordsteinhöhe über Fahrbahn, ähnlich dem Höhe über Schiene im railwaymap-Konzept wäre etwas, was jeder Mapper mit einem Meßband feststellen könnte und wenig Interpretationsspielraum lässt.
Gruß axelr
Genau. Da man aber genauso Schwierigkeiten bekommt, wenn man es an die Route taggt, ist es eine Kombinationseigenschaft. Man kann also dafür weder an der Haltestelle noch an der Route eine Bewertung taggen – wheelchair=irgendwas ist solche Eigenschaften ungeeignet. Da müssen nicht Bewertungen sondern Eigenschaften getaggt werden, die in der Kombination eine Bewertung ergeben. Dass Routen aber zumindest zu Spitzenzeiten auch noch oft von Fahrzeugen unterschiedlicher Bauweise bedient wird, macht die Sache noch mal komplizierter. Ein schönes Beispiel sind auch noch Bahnsteige und Einstieghöhen der Züge: es ist nicht besser oder schlechter, wenn es 15cm höher ist … was zählt ist die Unterschied.
Weide
PS: Und bei dem Ganzen sollten wir auch nicht vergessen, dass verschiedene Rollstuhlfahrer sehr verschiedene Fähigkeiten haben.
Inzwischen gibt es aber bei vielen Ausschreibungen die Auflage, nur behindertengerechte Fahrzeuge einzusetzen. Und das gilt dann immer, auch zu Stoßzeiten.
Zumindest bei der RMV-Suche sieht man das dann: normale, nicht für Rollstuhlfahrer geeignete Linien haben das normale Bussymbol, behindertengerechte Linien ein unterstrichenes N.
Dass die Bahn für Rollis ziemlich ungeeignet ist (S-Bahnen vielleicht ausgenommen) dürfte aber kein Geheimnis sein.
Ich habe mal versucht, eine kurze Liste mit notwendigen Tags und ihrer Verwendung aufzustellen:
http://wiki.openstreetmap.org/wiki/User:Mueschel/WochenaufgabeHaltestellen
Ich würde euch bitten, die Seite nicht selbst zu editieren, sondern Änderungsvorschläge hier zu diskutieren.
Eine wichtige Frage habe ich schonmal: Wir werden um highway=bus_stop zur Kompatibilität nicht herumkommen, aber wie ihr schon disktutiert habt: Wohin?
highway=bus_stop wird bei public_transport=platform angegeben, wenn diese als Node getaggt wird. Wird die platform als way getaggt, dann wird er bei der stop_position angegeben. So haben wir es für den VRR am 29.03.15 festgelegt, da bus_stop nur auf Nodes ausgewertet wird.
Wo sich Harald mit seinem Umfragetool schon soviel Mühe macht wollen wir es doch einfach mal nutzen:
http://osm.haraldhartmann.de/umfrage/poll/15
Autsch, nein! Viel stärker wiegt bei bus_stop dass es neben der Straße getaggt wird. Hier herrscht in der Diskussion vom Standardstil Einigkeit. Auch wird darüber diskutiert ob man die Komplexität “Bushaltestelle komplexer als ein Node” überhaupt in der Karte möchte.
Durch die Verwässerung von bus_stop wird auch PTv2 geschwächt, es ist ein Argument gegen das Rendern von public_transport=platform. Es wird dann an PTv3 liegen endlich mal eine Übergangsmöglichkeit zu schaffen.
+1
So eine Regel gibt es nicht. highway=bus_stop ist ein altes Tag. Es wurde auf die Straße oder daneben gesetzt. Falls man es neben die Straße gesetzt hat, hat man gewöhnlich für die Gegenrichtung einen getrennten Node genommen.
Ist die Platform kein Node, dann hat man m.E. keine Wahl: highway=bus_stop muss in die stop_position, die ja immer ein Node ist. Einen zusätzliche Platform als Node lehne ich ab. Das wäre ja eine zweite Platform und da sind nunmal nicht zwei. Da man unmöglich beide Platforms in eine PTv2-Route stecken kann, wäre die Liste der Routen zu jeder der Platforms und der stop_position unvollständig. Macht man dagegen das highway=bus_stop in die stop_position, dann ist zumindest die komplett. Sie enthält dann alle PTv1-Routen und alle PTv2-Routen, da in PTv2-Routen die Angabe von bereits gemappten stops/platforms nicht optional ist.
Weide
Einfach Austauschen geht bei PTv1 nicht, da PTv1 nur Nodes als Haltestellen kennt.
Weide
Wie weide schon schrieb, wenn die plattform nicht als Node getaggt ist, dann hat meine keine Wahl, bus_stop muss zur stop_position. Auch dem Argument von weide, dass ein zweiter Node als plattform für bus_stop mehr als schädlich wirkt, stimme ich zu.
Der Versuch, nur einen Node mit highway=bus_stop für zwar zu der gewünschten Darstellung neben der Straße um die Richtung zu erkennen, aber z.B. alle andere Funktionen von ÖPNV-Karten wie direkte Verknüpfung mit Fahrplanauskunft etc. bringen nicht immer die gewünschten Ergebnisse.
Die Aussage, PTv2 würde dadurch geschwächt ist kompletter Unsinn, da bus_stop nur bei PTv1 existiert und für v2 vollkommen unnötig ist.
Die Angabe von highway=bus_stop zu einer platform die als way getaggt ist, führt zu unheimlichen Straßenmehrungen unter anderem bei Routing-Apps, und auf einer Platform fahren möchte man ja nicht.
Eine andere Frage: Legt man auf talk.de verbindlich fest, was und wie etwas auf die Karte kommt, oder waschen die sich dort nicht auch nur mit Wasser? Im VRR-Gebiet hat man sich nun auf das oben aufgeführte Schema geeinigt.
Und was soll es bedeuten “komplexer als ein node”? Eine Bushaltestelle ist nunmal in der Regel komplexer als nur ein Punkt auf der Straße. M.E. sind die eigentlichen Differenzen in dieser Frage weniger auf bus_stop begrenzt, sondern darauf, ob man die Karte realistisch, also das was man in der Realität auch sieht, dargestellt haben möchte oder ob man sie auf bestimmte “Funktionen” begrenzen will. Da dies Streitigkeiten sind, die unlösbar sind, muss man mit beiden leben. Eine Möglichkeit wäre z.B. festzulegen, dass bus_stop als eigener funktionaler Node mit einem anderen Tag als highway versehen wird. Aber an der Problematik der Darstellung in alten Karten ändert das auch nichts.
Neben dem globalen Streit über Funktionalität und Realität ist mit PTv2 nunmal eine vollkommene Änderung des ÖPNV-Taggings einhergegangen und die Problematik und unsere Diskussionen sind nur deshalb, weil die Kartenrenderer und App-Programmierer eben den Wechsel auf PTv2 nicht vorgenommen haben. Also, bevor wir uns im Kreis drehen, sollten die vielleicht etwas ändern…
v1 und v2 kriegt man nunmal nur schwer unter einen Hut, von daher bleibt für v2 der bus_stop immer nur eine Krücke.
Der aktuelle Stand der Umfrage und die Diskussion hier im Thread lässt wohl nur einen Schluss zu: Die Anweisung für die Wochenaufgabe bzgl. highway=bus_stop muss lauten “Macht doch was ihr wollt” 
Was spricht denn genau gegen: “Wenn die Plattform ein Node ist, dann an diesen. Ansonsten einen extra-Node an die Stelle des Haltestellenschildes innerhalb der Plattform”?
Ein Renderer muss für eine gute Darstellung ohnehin nahe beieinanderliegende Objekte zu einer logischen Haltestelle zusammenfassen (z.B. der Name der Haltestelle taucht pro Halteposition mehrfach auf, an der stop_position und an der Plattform).
Warum stört der zusätzliche Node innerhalb der Plattform? Die Zählung der vorhandenen Haltestellen wird damit zwar etwas aufwendiger, aber definitiv nicht unmöglich.
Dass zwei Platforms gemappt werden wo nur eine ist. Es wird etwas Falsches in die Datenbank eingetragen, damit das H-Zeichen auf der Karte frei plaziert werden kann. Das ist Mapping for the Renderer.
Es ist nicht nötig, etwas Falsches einzutragen: highway=bus_stop ist nicht darauf festgelegt, ob es auf oder neben der Fahrbahn angegeben wird. Wenn beides Nodes sind, hat man die freie Wahl. Wenn nur eines ein Node ist, dann hat man keine Wahl.
Die PTv2-Routen kommen nicht mit dem Doppelmapping der Platform klar. Man kann zu einem Haltestellenobjekt immer die Liste der Routen zusammensuchen, die dieses Haltestellenobjekt benutzen. Dann sind entweder diese Listen Müll oder die Haltestellenlisten der PTv2-Routen selbst (durch Angabe von zwei platforms zu einem Halt).
Weide
Wie immer widerspreche ich hier. Es ist durch langjährige Dokumentation im Wiki und Taggingpraxis (v.a. englischsprachig) als neben der Fahrbahn festgelegt.
Das Anpappen an die Platform nutzt bei PostGIS-basierten Karten (z.B. Standardstil) nichts da die Datenbank nicht weiß auf welchem Way sich ein Node mit Tags befindet. Daher ist es sicher besser als frei in der Wildbahn, aber nicht der Weisheit letzter Schluss.
Legen wir doch einmal den gewünschten Idealzustand für den Standardstil fest: Bus_stop und bei PTv2-exklusiven Mapping platform werden gerendert. Sind wir uns diesbezüglich einig?
EDIT: Verständlichkeit verbessert
Wenn da nur eine stop_position und keine platform gemappt wurde, dann würde da also nichts gerendert.
Weide
Wenn das Argument für das doppelte Eintragen von einfach vorhandenen Platforms genutzt wird, dann wird das Anlegen und Pflegen von PTv2 Routen reine Beschäftigungstherapie.
Weide