Von allen railway=platform_edge weltweit, die auch public_transport=platform getaggt sind, befinden sich über 72 % (990/1369) in Österreich. Über diese Kombination hab ich aber nirgends Dokumentation gesehen. Ich halte die Kombi für eine schlechte Idee:
Die Vermischung von den Tags, die ja unterschiedliche Bedeutungen haben, verringert grundsätzlich mal die Datenqualität und -Konsistenz.
Die Präsenz vom public_transport-Tag lässt Apps wie StreetComplete Quests vervielfachen, was zu einer ordentlichen Datenredundanz führt.
Außerdem sind daraus entstehende Kombinationen etwas missverständlich; ich hab bisher noch keine Bänke oder Mistkübel auf Bahnsteigkanten selber stehen sehen, nur auf den Bahnsteigen.
Öfters hab ich auch schon gesehen, dass die Taggings dann widersprüchlich sind, z. B. ist der barrierefreie Zugang auf den Bahnsteigkanten gegeben, aber auf dem Bahnsteig selbst nicht.
Natürlich verstehe ich, dass man Fehlermeldungen über ein Element mit platform-Tag, aber ohne public_transport=platform schnell mal „wegdrückt“ und das Problem weiterschiebt. Aber längerfristig trägt das ja zur Lösung nix bei.
Dass ich die Lösung zwar nicht schön finde, den Grund aber verstehe: PTv2-Routen verlangen ‘platform’ und können mit ‘platform_edge’ nichts anfangen. Für PTv2 interessiert uns die Bahnsteigfläche aber absolut nicht, sondern nur die Kante. Einerseits halten bei systematisiertem Bahnbetrieb die Züge nicht an “Kante 2;3”, sondern entweder 2 oder 3, was im Fahrplan vermehrt auch exakt so hinterlegt ist.
Andererseits interessiert die Bahnsteighöhe, und die ist nicht nur kantenabhängig, sondern kann auch sektorabhängig sein – aber um es nicht zu kompliziert zu machen: in Liestal halten am selben Bahnsteig/Perron Normalspurzüge an Gleis/Kante 5, und Meterspurzüge an Gleis/Kante 6. Dasselbe Perron ist an Kante 5 ein modernes P55 (550 mm über Schienenoberkante), während es an Kante 6 ein modernes P35 (oder P30) ist, welches jeweils einen ebenerdigen Einstieg in die entsprechenden Fahrzeuge ermöglicht. Dies kann mit ‘platform’ für den gesamten Bahnsteig nicht ansatzweise sauber abgebildet werden.
Und sonst ist meine Meinung, dass ich mich möglichst nicht in die Tagging-Usanzen meiner Nachbarn einmische. Und dass StreetComplete sich zu einer unsäglichen Landplage entwickelt, die gesunden Menschenverstand mit stumpfen Klickaktionen ersetzt. Wenn ich auf einem Bahnsteig sämtliche Sitzbänke, Mülleimer, Wartesäle, Dächer, Snackautomaten, Ticketautomaten, Infoterminals und Fahrplanaushänge erfasst habe, dann finde ich es selten dämlich, wenn SC als nagware dümmlich fragt ob es dort einen Mülleimer hat. Oder eine Sitzgelegenheit. Oder… Sehe ich aber nicht als mein Problem, sondern das des Entwicklers und seiner binären Welt.
Aber zurück zur Ausgangsfrage: die Lösung ist nicht schön, für meine Nachbarn scheint sie zu funktionieren, und StreetComplete sollte man kastrieren.
Dass man beim Ein- und Aussteigen eine Bahnsteigkante queren muss, ist ja nicht davon abhängig, ob die jetzt extra getaggt ist.
Aber zumindest lässt sich die railway=platform_edgepublic_transport=platform Kombination mit den Eintragungen von Bahnsteigkanten als platform in PTv2-Routen korrelieren. Das ist aber nicht nur in Ö der Fall, sondern auch in der dänischen Tarifregion Seeland, wo @1993matias letztes Jahr einiges verfeinert hat. Dort haben die „Validierenden“ aber noch nicht zugeschlagen. Mal schauen, wann das passiert …
Hoppala, ich wollte eigentlich das Wort ‘Fläche’ betonen – das Mappingschema selber ist mir bestens bekannt.
Es hat eben den Vorteil, dass man kantengenaue Angaben machen kann. Und dem Durchschnittsfahrgast muss nicht einleuchten, warum platform_edge gemappt wird, oder gar jemand die Kantenhöhe erfasst. Rollstuhlfahrende oder gehbehinderte Fahrgäste dürften dies anders sehen. Und denen hilft die ‘wheelchair’-Angabe ohnehin herzlich wenig, wenn plötzlich Fahrzeuge mit “falscher” Einstiegshöhe am Perron halten.
Von daher ist die Überlegung schon mal nicht komplett falsch. Ein offensichtliches Problem mit dem Schema kann ich auf die Schnelle auch nicht erkennen (ausser Validator und Tools).
Also… das Problem hier ist, dass der Standard ist, public_transport=platform an railway=platform anzuhängen, nicht an railway=platform_edge und die ganzen Bilder auf der Seite des Letzteren zeigen ebenfalls, dass die Hauptinformationen am gesamten Bahnsteig stehen und die Bahnsteigkanten höchtens die Gleisnummer und Kantenhöhe haben. Zu sagen, dass für PTv2 die Bahnsteige an sich uninteressant sind, ist m.M.n. falsch, inbesondere, dass es sonst anders definiert wäre.
StreetComplete mit den gleichen Standard und wenn du möchtest, dass StreetComplete keine Fragen zu railway=platform_edge stellen soll, schreibe es dem Entwicklerteam an anstelle hier im Forum wild rumzuärgern.
Das wäre einfach zu implementieren, indem man die Element-Filter für die Quests (z.B. hier) anpasst. Wenn das gewünscht wird, dann gerne dazu eine Issue oder einen Pull Request im Repository aufmachen. Kann ich auch gerne machen, wenn hier Konsens herrscht.
Das kann man natürlich machen. Aber während diese „Symptombekämpfung“ auch wichtig ist, muss man diese unorthodoxe Tag-Kombi dann überall rausfiltern.
Mittlerweile bin ich dabei, die als Bahnsteig in Routen eingetragenen Bahnsteigkanten, die ich für die Ursache für die von den Validatoren vorgeschlagenen Hinzufügungen von public_transport=platform und dem daraus folgenden Aufploppen von SC-Quests halte, mit den Bahnsteigen zu ersetzen.
