Aktualisierung der MVV-Buslinie 451 nach Fahrplanwechsel

Communities Deutschland (Germany)
, , ,
1

Hi zusammen :slight_smile:

Ich bin heute in der Gemeinde Vaterstetten die Buslinie 451 abgeradelt und habe die Haltestellen fotografiert, da die Busse jetzt nach dem heutigen Fahrplanwechsel in beide Richtungen verkehren, statt wie bisher nur in einer großen Schleife im Uhrzeigersinn und einer kleinen Schleife gegen den Uhrzeigersinn. Da es meine erste ÖPNV-Routen-Bearbeitung auf OSM war, beschreibe ich meine Schritte mal im Detail. Geholfen hat mir sehr die Wiki-Seite DE:Leitfaden - Barrierefreiheit an Haltestellen - OpenStreetMap Wiki, dort sind auch gute Schaubilder mit entsprechenden Tags zu finden.

Für den neuen Zweirichtungsverkehr gibt es an vielen Haltestellen jetzt auch einen neuen zweiten „Mast“ (public_transport = platform) auf der anderen Straßenseite. Die hab ich als erstes mit iD neu eingetragen (z.B. Changeset 144970241).

Dann hab ich als nächstes (auch wieder in iD) zusammengehörende Masten + Stop-Positionen (ggf. neu erstellte für die andere Richtung) in je eine Haltestellen-Relation (public_transport = stop_area) gepackt (z.B. Changeset 144972551). Das ist zwar wahrscheinlich nicht nötig (hat auch bei bisherigen Zwei-Richtungs-Stationen gefehlt), aber schadet sicher nicht.

Und dann hab ich mich mittels OSM Relatify dran gewagt, die bisherigen Routen-Relationen 3049383 (im Uhrzeigersinn) und 3049384 (gegen den Uhrzeigersinn) zu bearbeiten (z.B. Changeset 144978976). Danach hab ich mit iD noch die Informationen der Routen und des Routen-Masters aktualisiert (z.B. Changeset 144979127).

Allerdings musste ich dann feststellen, dass die Start-/Endhaltestelle Vaterstetten (S) (stop_position und platform) gar nicht mehr Teil der Routen ist. Anscheinend ist das bei OSM Relatify verloren gegangen. Vielleicht weil es mit Ringlinien nicht klarkommt? Ist das Problem bekannt, oder hab ich was falsch gemacht?

Um das zu reparieren, hab ich in iD Stop-Position und Mast je einmal als *_entry_only am Anfang und einmal als *_exit_only am Ende der Route hinzugefügt. Nur zum Testen hab ich die Route dann nochmal mit OSM Relatify aufgemacht, da kamen aber einige Fehler und die Start-/Endpositionen waren irgendwo eingetragen. Das kann ich aber nicht mehr reproduzieren, also waren das vielleicht nur veraltete Daten.

Jetzt glaube ich sollte alles passen. Die detaillierte Darstellung in PTNA (für 3049384 und 3049383) schaut auf jeden Fall gut aus. Nichtsdestotrotz: Möchte da vielleicht mal jemand drüber schauen?

@ToniE, wann werden denn voraussichtlich die neuen GTFS-Daten für den MVV auf PTNA verfügbar sein? Dann kann ich damit nochmal validieren, was ich gemacht habe. Auf jeden Fall muss ich noch die GTFS-Tags der Relationen anpassen.

2 Likes
2

Das ist bekannt, ich glaube, ich hatte auch einen Issue bei GitHub aufgemacht.

Ich weiß nicht, ob das mit entry/exit bei Ringlinien notwendig ist. Aus-/Einsteigen kann ich ja überall. In diesem Fall, wo die selbe Haltestelle doppelt drin ist, ist entry/exit eher als OSM-spezifisches Merkmal zu sehen.

Für die meisten MVG/MVV Linien sind die 2024er Daten seit 05.12.2023 bei PTNA sichtbar.
Der MVV kämpft ja häftig (Personalanzahl, Größe der Aufgabe) mit der Integration der Landkreise Rosenheim, Miesbach, der Stadt Rosenheim, des südlichen Teils des Landkreises Bad Tölz/Wolfratshausen. Hier sind z.T. noch keine GTFS-Daten vorhanden - es wurden ja “eigentlich nur” die RVO- und RoVG-Linien neu nummeriert - eigentlich nur. Ist aber dennoch einen Mordsarbeit. Respekt für den MVV übrigens.

3

Da ist auch was schief gegangen:

da ist eine Node als platform in der Relation drin… statt der platform daneben…

https://www.openstreetmap.org/node/11407645572

1 Like
4

Und wie bekomme ich in JOSM den Rundkurs lückenfrei, wenn der Bus an der Haltestelle Richtung Süd-West losfährt, auf dem turning_circle wendet und Richtung Nord-Ost seine Fahrt fortsetzt?

PTNA meldet hier auch eine Lücke

grafik
grafik967×693 122 KB

5

… eigentlich wohl nur, wenn man das kurze Stück unten links in zwei Teile schneidet: split-of-way für die QA?

6

Diese Issues hier sehen auf jeden Fall relevant aus:

Stimmt, aber macht es für Daten-Konsumenten vielleicht etwas einfacher, oder? Oder ist durch die Reihenfolge der Haltestellen in der Routen-Relation eh schon alles gesagt?

Ahh tatsächlich. Da ich mich noch nie so tief mit ÖPNV-Relationen beschäftigt habe, habe ich auch PTNA nicht so ganz durchdrungen :sweat_smile:

:+1:

7

Oh richtig, danke! Ich hatte die Haltestelle aus dem Weg herausgetrennt (wie das sonst so üblich ist im Ort), aber nicht bedacht, dass die Relation noch den anderen Knoten enthält. Danke an @ToniE fürs schnelle fixen (Changeset: 145037678 | OpenStreetMap)! :slight_smile:

8

Wenn das Probleme macht, würde ich den pragmatischen Weg gehen und das kurze Wegstück und den Wendekreis wieder aus der Relation rausnehmen, so wie das vorher war.

1 Like
9

Der Vollständigkeit halber: Ich habe die GTFS-Daten der Buslinie (beide routes + route_master) nun aktualisiert: Changeset: 145085741 | OpenStreetMap. Ich hoffe das passt so. Wenn mir keiner zuvor kommt, aktualisier ich dann die nächsten Tage die anderen Buslinien durch Vaterstetten.

1 Like
10

Bus 452 ist jetzt auch aktualisiert, hat mich auch nur 11 Changesets gebraucht :sweat_smile:
(1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11)

Eine fehlende Haltestelle ist mir aufgefallen, die wird PTNA wahrscheinlich beim nächsten Update auch bemängeln: Note: 4029530 | OpenStreetMap

Bei Bus 465 hab ichs in einem Changeset geschafft: Changeset: 145168498 | OpenStreetMap, da fehlen aber noch ein oder zwei Trips.

11

Hmm, fehlende Haltestellen werden nicht gefunden, da der Abgleich zwischen GTFS und OSM noch nicht realisiert ist. Die Qualität der GTFS-Daten ist nicht so toll: PTNA würde u.U. viele fehlende Routen melden, die in GTFS jedoch Leerfahrten sind (erkennt mau u.U. nur wenn man Ortskenntnisse hat).

Fahrten 1, 4 und 7 sind solche zum Teil nicht sofort erkennbare Leerfahrten, die für OSM irrelevant sind.

1 Like