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:
DE:Tag:barrier=step - OpenStreetMap Wiki 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.
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.