S15 Berlin fehlt in ptna

Hier der route_master: Relation: ‪S15: S+U Hauptbahnhof <=> S+U Gesundbrunnen‬ (‪20982800‬) | OpenStreetMap

Wird nicht erkannt:

Ich hab dann für das Network “DE-BE-VBB” eine neue Analyse angefordert, die ist fertig, S15 fehlt weiterhin.

diff

Mittels Texteditor und manuell sortierten Zeilen, dann git diff --no-index a b. Rot ist ptna-Vorschlag, grün wie es jetzt in OSM ist.

route_master – ptna vs. osm

diff --git a/ptna_route_master b/osm_route_master
index 3d1c9b9..93268c8 100644
--- a/ptna_route_master
+++ b/osm_route_master
@@ -1,12 +1,11 @@
 type=route_master
 route_master=light_rail
 ref=S15
-name=Stadtbahn S15
+name=S15: S+U Hauptbahnhof <=> S+U Gesundbrunnen
 network=Verkehrsverbund Berlin-Brandenburg
-network:guid=DE-BE-VBB
 network:short=VBB
+network:metro=s-bahn
+network:wikidata=Q315451
 operator=S-Bahn Berlin GmbH
-colour=#DA6BA2
-colour:text=#FFFFFF
-website=https://www.s-bahn-berlin.de
-gtfs:route_id:DE-BE-VBB=28572_109
+colour=#D474AE
+wikidata=Q100985389

route – ptna vs. osm

diff --git a/ptna_route b/osm_route
index d0c9013..83acd20 100644
--- a/ptna_route
+++ b/osm_route
@@ -1,18 +1,17 @@
 type=route
 route=light_rail
 ref=S15
-name=Stadtbahn S15: S+U Berlin Hauptbahnhof => S+U Gesundbrunnen Bhf (Berlin)
+name=S15: S+U Hauptbahnhof=> S+U Gesundbrunnen
 network=Verkehrsverbund Berlin-Brandenburg
-network:guid=DE-BE-VBB
 network:short=VBB
+network:metro=s-bahn
+network:wikidata=Q315451
 operator=S-Bahn Berlin GmbH
-colour=#DA6BA2
-colour:text=#FFFFFF
-website=https://www.s-bahn-berlin.de
-gtfs:route_id:DE-BE-VBB=28572_109
-gtfs:trip_id:sample:DE-BE-VBB=295888809
-gtfs:shape_id:DE-BE-VBB=5705
-ref_trips=295888809
-from=S+U Berlin Hauptbahnhof
-to=S+U Gesundbrunnen Bhf (Berlin)
+colour=#D474AE
+roundtrip=no
+start_date=2026-06-15
+from=S+U Hauptbahnhof
+to=S+U Gesundbrunnen
+via=S+U Wedding
 public_transport:version=2
+wikidata=Q100985389

Was davon ist ein Problem, bzw. was muss man ändern (das fehlt?), damit ptna das erkennt?

Andere Fragen

Ich kenne mich mit public transport mapping und Routen nicht besonders aus, hab das nur mal für Busse versucht, bzw. beim Auftrennen von Fahrbahnsegmenten wo diese drüber gehen die auch mal manuell angefasst. Kann also sein, dass manches im Wiki beantwortet wird;

Sollte man die Variante Hauptbahnhof<=>Wedding auch in OSM als einzelne Relation anlegen? die wird ja wohl nur Abends/Nachts so bedient, aber eigentlich ist das ja eine andere Route als die bis Gesundbrunnen. Jedoch hab ich anderswo auch nur die Jeweils längsten Varianten in OSM gesehen.

Warum gibt es im GTFS zwei Versionen der S15?
PTNA - GTFS Analysen und PTNA - GTFS Analysen
Dabei hat eine die zwei Varianten für Hin- und Rückfahrt, die andere aber zusätzlich noch welche ohne Gesundbrunnen.
Liegt das einzig daran, dass der Fahrplan das nur so hergibt das abzubilden? Oder könnte man (also der VBB, der die GTFS herausgibt) die eine in die andere überführen und die Zeiten zusammenführen? Die Shape-id ist dieselbe bei jeweils derselben Fahrtrichtung, nur die Abfahrzeiten sind halt andere.

Was macht der physische Zug nach der Endhaltestelle in Gesundbrunnen? Der kommt auf Gleis 3 an, und die Rückrichtung fährt auf Gleis 2 ab, laut Fahrinfo. Hauptbahnhof ist es beides mal Gleis 22.
Ein kurzer Blick in die Abfahrten bei Gesundbrunnen lässt mich auch nicht vermuten, dass daraus eine andere Linie gemacht wird ab dort, das erscheint mir aber am schlüssigsten. Oder aber diese fährt dann nicht ab Gesundbrunnen, sondern der Zug wird dann woanders eingesetzt, aber man lässt diese Strecke halt keine Fahrgäste mitfahren, warum auch immer.

Gefunden wird die S15 von PTNA schon, aber nur unter “Nicht eindeutig zugeordnete Linien” (ziemlich am Ende davon). Das liegt vmtl. auch an der Dopplung.

Üblich ist ein route_master pro Linie, der bekommt dann alle Fahrtvarianten. Meistens werden dann der Einfachheit halber nur die längsten Varianten mit gleichem Fahrweg gemappt.

Kurze Antwort:

Wie @onterof schrieb: liegt das an der Doppelung, d.h. der Eintrag “S15;light_rail;.....” ist in den CSV-Daten VBB Linien doppelt drin und PTNA kann nicht ermitteln zu welchem Eintrag die S15 Relationen gehören.

Lange Antwort:

In DE-SN-VMS gibt es die Linie z.B. ‘A’ 11 mal in verschiedenen Gemeinden, daher versucht PTNA die richtige Zuordnung anhand ‘operator’, ‘from’ und ‘to’ sobald mehr als ein Eintrag in den CSV-Daten vorhanden ist.

Beim DE-BE-VBB werden die CSV-Daten (aber!) aus den gtfs -Daten der VBB erzeugt, die doppelten und mehrfachen Einträge kommen also aus den (fehlerhaften) GTFS-Daten.

Dieser Import von GTFS in die CSV-Daten kann aber (in den CSV-Daten) manipuliert werden.

Ich würde als schnelle Lösung die Import-Anweisungen ‘@ … @@’ in den Zeilen 156 - 209 löschen (auskommentieren) und die Zeilen darunter (210-288) reaktivieren und ergänzen.

Danach könnten wir überlegen, wie wir mit den fehlerhaften GTFS-Daten weiter verfahren.

Doppelte und mehrfache Einträge zu analysieren wird durch die Option ‘--multiple-ref-type-entries=analyze’ gesteuert.
Hier könnte auch ‘--multiple-ref-type-entries=allow’ stehen, aber dann bekommst du z.B. die S3 7 mal analysiert - bring auf Dauer nichts.
Es könnte auch ‘--multiple-ref-type-entries=ignore’ sein, aber dann bekommst du evtl. Probleme mit doppelten Bus-Nummern, die so tatsächlich existieren.

Macht es einen Unterschied, wenn ich dem route_master gtfs:route_id:DE-BE-VBB=28571_109 anfügen würde? Das ist dann die Version mit 4 Varianten, also sind auch die kurzen dabei.
Dann wäre das doch eineindeutig was gemeint ist, aber klar, dann würde die andere Version “fehlen”.

Das kannst du machen, dann kommt in der 3. Spalte zumindest das “GTFS vs OSM”-Vergleichssymbol.

Bzgl. CSV und doppelte Einträge wird das nichts verbessern, da PTNA das bei ‘--multiple-ref-type-entries=analyze’ nicht auswertet. Ein entsprechende Vorschlag kam aber mal aus AU-NSW-All Ecke.
Den “Inject GTFS in CSV” haben wir eingeführt, da sich in IL GTFS route_ids häufig ändern und wir das im CSV automatisiert anpassen wollten. Wenn die route_ids sich aber häufig ändern, dann macht bzgl. doppelter Einträge eine Berücksichtigung der route_id nur Sinn, wenn das in OSM auch entsprechend zeitnah nachgezogen wird. Aber dann ist wohl eher die Frage: macht es generell Sinn, GTFS route_ids in OSM zu mappen, wenn die sich häufig ändern?

BTW: Laut “GTFS best practices” soll man (zumindest) die route_id von einer GTFS Version zur nächsten stabil halten. Aber nicht alle Verkehrsverbünde halten sich daran.

Bleibt noch die Frage, wie man doppelte GTFS-Einträge wie z.B. S15 (2 mal) beim Import/Inject zu CSV vermeidet oder zusammenfügt?

  • Wenn, wie bei DE-BY-MVG Bus 51, zwei Einträge sich zeitlich überschneiden
  • Wenn sich zwei Einträge zeitlich nicht überschneiden (Mai-Sep, Okt-Apr)
  • Wenn zwei Einträge bzgl. Zeitspanne identisch sind (S15 bei VBB)
  • Wenn, wie bei DE-BY-MVG Bus 144, drei Einträge existieren, einer (der 3.) vollständig im 1. enthalten ist, sehr kurz existiert (Baustellenumleitung) und nicht gemapped werden sollte

Eine allgemeingültige Antwort habe ich nicht