Darf ich die Aufmerksamkeit der geschätzten hohenlohischen OSM-Gemeinde mal auf https://www.openstreetmap.org/note/1548010 lenken? Offenbar bedürfen die Buslinien im Stadtgebiet SHA einer gründlichen Revision.
Ich halte es nur für unwahrscheinlich, dass das jemand aufgrund einer Note angehen wird, und versuche es daher hier etwas höher aufzuhängen. Oder ist da schon eine lokale Mappergruppe dran? Wenn’s eine gibt, was ich anhand von https://www.openstreetmap.org/note/1448317 fast an2feln möchte
Für eine Bestandsaufnahme der in OSM gemappten Routen könnte ich das Gebiet in PTNA https://ptna.openstreetmap.de konfigurieren, auswerten lassen und anschließend mit den Daten vom Verkehrsverbund vergleichen.
Im benachbarten Hohenlohekreis sieht es was Busrouten angeht auch nicht viel besser aus. Die Wenigen die vorhanden sind, sind teilweise defekt und wenn überhaupt nach dem alten Routenschema erfasst.
Habe mit dem Gedanken gespielt, die bereits vorhanden Routen nach PTv2 anzupassen. Aber das ist selbst für eine Linie (samt deren Variationen) extrem viel Zeitaufwand. Vor allem wenn man sich vornimmt die Route in Zukunft zu warten und aktuell zu halten.
Soweit ich das beurteilen kann, ist die Gegend recht dünn mit Mappen besetzt. Ich glaube da gibt es wichtigere Baustellen den man sich widmen sollte, bevor man sich dem “Luxusproblem” Busrouten annähert.
Im Hohenlohekreis habe ich z.B. die Bushaltestellen mit ref_name, network, operator und den PTv2-Tags ergänzt. So kann man potentiell einfacher die Bushaltestellen aus OSM mit externen Diensten verwenden.
z.B. ermöglicht openptmap.de bei klick auf eine Bushaltestelle die Abfahrtzeiten von der Bahn anzuzeigen. Vorausgesetzt ref_name ist aussagekräftig genug.
Zusammengefasst:
In ländlichen Gebieten wie Schwäbisch Hall, werden Busrouten wohl nie die nötige Abdeckung erreichen, um die Daten sinnvoll nutzen zu können. Deshalb halte ich es wichtiger die Haltestellen korrekt zu erfassen. Die können dann als Verknüpfung zwischen externen Datendiensten und OSM dienen.
Laut bahn.de müsste das Format für ref_name “Ortsteil Haltestelle, Gemeinde”, zumindest im Raum Frankfurt wird aber abweichend “Haltestelle, Gemeinde-Ortsteil” verwendet. Das müsste ggfs. im Wiki dokumentiert und flächendeckend geändert werden.
Ich habe mich beim ref_name am Haltestelle_lang Name der NVBW orientiert. Siehe: https://www.nvbw.de/open-data/haltestellen/
Also “{Übergeordneter Ort} {Haltestellenname}” ohne Komma. Wenn sich ein Konsens für Format von ref_name findet, ändere ich das bei den von mir bearbeiteten Haltestellen.
Meine Variante funktioniert bei den meisten Haltestellen bei bahn.de, aber nicht bei Allen.
Verlangt nicht mehr als nötig: Wenn die Haltestelle im Internet gefunden wird, dann ist der ref_name OK und muss nicht geändert werden. Und wenn es ohne ref_name gefunden wird, dann braucht man auch keinen.
PTv2 verlangt kein Operator-Tag. Es redet nicht einmal darüber
PTv2 verlangt kein Network-Tag. Es redet nicht einmal drüber.
PTv2 verlangt nicht, dass highway=bus_stop mit public_transport=irgendwas ergänzt oder ersetzt wird.
PTv2 verlangt nicht, dass es an jedem Halt zwei Objekte gibt.
PTv2 verlangt nicht, dass es eine stop_area gibt.
Man muss keine alte Haltestelle wegen der Umstellung auf PTv2 ändern. Es gibt nur Ergänzungen an Haltestellen, die man nur mit PTv2 machen kann.
wer im Kreis Schwäbisch Hall oder im Hohenlohekreis oder sonstwo eine Mappingparty zum Mappen von Bushaltestellen organisiert, kann auf die Unterstützung des FOSSGIS e.V. zählen. https://forum.openstreetmap.org/viewtopic.php?id=66615
