DELFI: Bediente Halte werden mit location_type exit/entrance angegeben
Beschreibe den Fehler Für mehrere bediente Steige ist im @delfi-fahrplandaten GTFS-Datensatz als entrance/exit (location_type=2) angegeben, obwohl location_type=0 (stop) sein sollte:
"stop_id","stop_code","stop_name","stop_desc","stop_lat","stop_lon","location_type","parent_station","wheelchair_boarding","platform_code","level_id"
"de:08236:2590:2","","Illingen",,"48.956161000000","8.920652000000",2,"de:08236:2590",0,"3","2"
"de:08316:6667:2:1","","Kollmarsreute Bahnhof",,"48.098586000000","7.886883000000",2,"de:08316:6667",0,"1","2"
"de:08326:8324:90:1","","Schwenningen Eisstadion",,"48.052855000000","8.529814000000",2,"de:08326:8324",0,"91","2"
"de:08326:8324:90:2","","Schwenningen Eisstadion",,"48.053061000000","8.529611000000",2,"de:08326:8324",0,"92","2"
"de:09676:99310:90","","Collenberg",,"49.771086000000","9.329489000000",2,"de:09676:99310",0,"","2"
Abgesehen davon, dass solche Probleme bereits technisch unterbunden werden sollten, könnten die fehlerhaften de:08-Daten teilweise durch die NVBW bereinigt werden, @NVBWSeifert?
Referenz https://developers.google.com/transit/gtfs/reference/#stopstxt
Aktualisierungszeitpunkt der GTFS-Daten: 03. September 2021
Downloadlink der GTFS-Daten: https://www.opendata-oepnv.de/ht/de/organisation/delfi/startseite?tx_vrrkit_view%5Bdataset_name%5D=deutschlandweite-sollfahrplandaten-gtfs&tx_vrrkit_view%5Bdataset_formats%5D%5B0%5D=ZIP&tx_vrrkit_view%5Baction%5D=details&tx_vrrkit_view%5Bcontroller%5D=View
Problem besteht mit Datensatz vom 26.11.2021 weiterhin
Ich kann den Fehler in den Daten nachvollziehen. Wir bereiten für die betroffenen Lieferanten Listen vor und verteilen sie nächste Woche.
Mit dem DELFI-Datensatz vom 21.03.2022 und gtfs-via-postgres:
SELECT
DISTINCT ON (stop_id)
stops.stop_id, stop_name, location_type
FROM stops
JOIN stop_times ON stop_times.stop_id = stops.stop_id
WHERE stops.location_type != 'stop' -- 0
| stop_id | stop_name | location_type |
|---|---|---|
| de:05158:19054:1 | Erkrath Nord Bf | entrance_exit |
| de:05314:61101_G | Bonn Hbf | station |
| de:08236:2590:2 | Illingen | entrance_exit |
| de:08316:6667:2:1 | Kollmarsreute Bahnhof | entrance_exit |
| de:08326:8324:90:1 | Schwenningen Eisstadion | entrance_exit |
| de:13076:9062:2:1 | Blankenberg Bhf | entrance_exit |
| de:13076:9062:2:2 | Blankenberg Bhf | entrance_exit |
Im Datensatz Stand 31.10.2022 handelt es sich um die folgenden Stops:
| stop_id | stop_name | location_type |
|---|---|---|
| e:08236:2590:2 | 2 | |
| de:08215:1835:1:1 | 2 | |
| de:08215:1834:1:1 | 2 | |
| de:08215:1833:1:1 | 2 | |
| de:08215:1833:2:2 | 2 | |
| de:08215:1834:2:2 | 2 | |
| de:08215:1835:2:2 | 2 | |
| de:08316:6667:2:1 | 2 | |
| de:13076:9062:2:1 | 2 | |
| de:13076:9062:2:2 | 2 | |
| de:05158:19054:1 | Erkrath Nord Bf | 2 |
| de:05162:20390:40 | Neuss Am Kaiser | 2 |
| de:05314:61101 | Bonn Hbf | 1 |
| de:08326:8324:90:1 | 2 |
ich kann die Ursache, warum location_type=2 gesetzt ist bei den BW-Stops, nicht nachvollziehen. In unserem lokalen GTFS-Export ist =0 gesetzt und im Fahrplansystem sind auch keine Auffälligkeiten vorhanden. Wir versuchen das mit DELFI zu klären.
Mit dem DELFI-Datensatz vom 20.03.2023 und gtfs-via-postgres 4.5.1:
SELECT
DISTINCT ON (stop_id)
stops.stop_id, stop_name, location_type
FROM stops
JOIN stop_times ON stop_times.stop_id = stops.stop_id
WHERE stops.location_type != 'stop' -- 0
ORDER BY stop_id
| stop_id | stop_name | location_type |
|---|---|---|
| de:05158:19054:1 | Erkrath Nord Bf | entrance_exit |
| de:05314:61101 | Bonn Hbf | station |
| de:08118:5723:90 | Kirchheim (N) | entrance_exit |
| de:08215:1834:1:1 | Heidelsheim | entrance_exit |
| de:08215:1834:2:2 | Heidelsheim | entrance_exit |
| de:08215:1835:1:1 | Helmsheim | entrance_exit |
| de:08215:1835:2:2 | Helmsheim | entrance_exit |
| de:08236:1090:2 | Birkenfeld | entrance_exit |
| de:08236:1794:2 | Remchingen / Wilferd.-Singen | entrance_exit |
| de:08236:2590:2 | Illingen | entrance_exit |
| de:08315:6517:2:3 | Ihringen Bahnhof | entrance_exit |
| de:08316:6667:2:1 | Kollmarsreute Bahnhof | entrance_exit |
| de:08326:8324:90:1 | Schwenningen Eisstadion | entrance_exit |
| de:13076:9062:2:1 | Blankenberg Bhf | entrance_exit |
| de:13076:9062:2:2 | Blankenberg Bhf | entrance_exit |
Ich bin auch auf diesen Fehler gestoßen, durch den leider ein Import der GTFS Daten in OpenTripPlanner abbricht. Der Fehler ist im Datensatz vom 05.06.2023 noch immer enthalten.
Bevor ich diesen Issue hier fand, hatte ich eine E-Mail an Delfi gesendet, die folgenden Ausschnitt beinhaltet:
Ich habe die zip Datei vom 05.06.2023 heruntergeladen und bin über den Import in den Routenplaner OpenTripPlanner auf einen Fehler in den Daten gestoßen:
stops.csv hat in der Zeile 410798 folgenden Eintrag: "de:08326:8324:90:1","","Schwenningen Eisstadion","Eingang","48.052858000000","8.529818000000",2,"de:08326:8324",0,"91","2"
Dort ist als "location_type" eine "2" gesetzt. Gemäß der Spezifikation folgt, dass dieser Ort einen Eingang/Ausgang einer Station markiert. (https://gtfs.org/schedule/reference/#stopstxt)
Jedoch gibt es in stop_times.csv in der Zeile 6197 den folgenden Eintrag, der für ebendiesen Ort eine Fahrzeit angibt: 2139241921,24:09:00,24:09:00,"de:08326:8324:90:1",14,0,0,""
@NVBWSeifert was hat der Klärungsversuch mit DELFI ergeben? Das Problem ist nun seit bald 10 Monaten bekannt.
Wir werden das prüfen und mit unserem Systemhaus besprechen. Sobald ich dazu nähere Informationen habe werde ich das hier kommentieren.
Das Problem tritt mit dem Datensatz Stand 12.08.2024 weiterhin auf. Gibt es hierzu neue Erkenntnisse @CM-RMS ?
SELECT distinct s.stop_id, location_type, a.agency_id, a.agency_name
FROM agency a
JOIN routes r ON a.agency_id = r.agency_id
JOIN trips t ON r.route_id = t.route_id
JOIN stop_times st ON t.trip_id = st.trip_id
JOIN stops s ON st.stop_id=s.stop_id
WHERE NOT location_type=0
ORDER BY s.stop_id;
┌────────────────────┬───────────────┬───────────┬─────────────────────────────────────┐
│ stop_id │ location_type │ agency_id │ agency_name │
│ varchar │ int64 │ int64 │ varchar │
├────────────────────┼───────────────┼───────────┼─────────────────────────────────────┤
│ de:05158:19054:1 │ 2 │ 7764 │ Rheinbahn Bus │
│ de:05758:4907:1 │ 2 │ 14361 │ Lippe5 │
│ de:05766:3060:1 │ 2 │ 11016 │ DivVgl/Waldorf1 │
│ de:05766:3073:1 │ 2 │ 14361 │ Lippe5 │
│ de:08116:1905:95 │ 2 │ 14248 │ 04 │
│ de:08118:5723:90 │ 2 │ 8096 │ Regional-Busse RBS │
│ de:08236:1794:2 │ 2 │ 7676 │ SEV R+S (R-Bahn + S-Bahn) │
│ de:08236:2590:2 │ 2 │ 8009 │ Privatunternehmer-Bus (Enzkreis) │
│ de:08315:6517:2:3 │ 2 │ 13022 │ Externe Leistungen │
│ de:08316:6667:2:1 │ 2 │ 10443 │ DB Regio AG Baden-Württemberg │
│ de:08326:6537:90 │ 2 │ 14248 │ 04 │
│ de:08326:6537:91 │ 2 │ 14248 │ 04 │
│ de:08326:8324:90:1 │ 2 │ 14652 │ SBG - BUS1 │
│ de:08326:8324:90:2 │ 2 │ 14652 │ SBG - BUS1 │
│ de:08436:98:2 │ 2 │ 14248 │ 04 │
│ de:13076:9062:2:1 │ 2 │ 10434 │ DB Regio AG Nordost │
│ de:13076:9062:2:2 │ 2 │ 10434 │ DB Regio AG Nordost │
│ de:15003:8012289 │ 1 │ 10376 │ Nahreisezug │
│ de:15003:8012289 │ 1 │ 11961 │ Abellio Rail Mitteldeutschland GmbH │
│ de:15083:8012572 │ 1 │ 11961 │ Abellio Rail Mitteldeutschland GmbH │
├────────────────────┴───────────────┴───────────┴─────────────────────────────────────┤
│ 20 rows 4 columns │
└──────────────────────────────────────────────────────────────────────────────────────┘
│ de:08236:1794:2 │ 2 │ 7676 │ SEV R+S (R-Bahn + S-Bahn) │ │ de:08236:2590:2 │ 2 │ 8009 │ Privatunternehmer-Bus (Enzkreis) │
In den beiden Fällen geht es relativ sicher um SEV Ersatzhaltestellen. Mangels Detailkenntnisse, welche konkreten Haltesteige infrage kommen, wurden Bereiche ausgewählt. Wir werden das mit dem zuständigen Datenlieferanten abklären
Ich schreibe das mal hier dazu, auch wenn es sich um location_types 1, 2 und 3 handelt, die ja aber alle in stop_times.txt nicht zulässig sind. Besonders prominent gerade mit zahlreichen nach Hamburg verkehrenden ICEs an stop de:02000:10950:5:2549012, z.B. ICE 578, trip_id 2766990100 oder 2766990098. Gewisse GTFS libraries, z.B. gtfsparser, ignorieren solche stop_times ganz, wodurch besagte ICEs nur bis Hannover zu fahren scheinen (z.B. hier).
Das zugrundeliegende Problem ist wahrscheinlich eher die Zuordnung, weil die ICEs sicher in Hamburg nicht am "ZG Mönckebergtunnel" und Gleis 82 (platform_code) halten – und dort ist derzeit auch kein SEV. Bei den anderen stops mögen die Ursachen natürlich wieder ganz andere sein.
Alle im DELFI Feed vom 24.02.2025 betroffenen stops
de:02000:10950:5:2549012 (Hamburg Hbf)
de:02000:10950:6:2549014 (Hamburg Hbf)
de:05114:21089 (Krefeld Uerdingen Bf)
de:05158:18634_G (Ratingen Ost S)
de:05766:3060:1 (Detmold, Blomberger Straße)
de:05766:3060 (Detmold, Blomberger Straße)
de:05766:3070 (Detmold, Landesmuseum)
de:05766:3073 (Detmold, Hasselter Platz)
de:05914:2059 (Hagen Hohenlimburg Bf)
de:05962:6 (Lüd., Bahnhof)
de:06414:11131 (Wiesbaden-Biebrich Bahnhof)
de:06414:6903 (Wiesbaden-Mainz-Kastel Bahnhof)
de:06414:6906 (Wiesbaden-Biebrich Bahnhof Wiesbaden Ost)
de:06414:6907 (Wiesbaden Hauptbahnhof)
de:06431:236:3:10 (Bensheim, Bahnhof)
de:06431:236:3:8 (Bensheim, Bahnhof)
de:06431:4526:2:RT (Zwingenberg, Bahnhof)
de:06433:6999 (Mainz-Bischofsheim Bahnhof)
de:08111:6128 (Ruhbank (Fernsehturm))
de:08128:12005 (Bad Mergentheim, Bahnhof)
de:08222:2386 (Luzenberg)
de:08225:6343 (Mosbach, Westbahnhof)
de:08226:2986:3 (Neckargemünd, Bahnhof)
de:08226:4252 (Wiesloch-Walldorf, Bf)
de:08315:6517:2:3 (Ihringen Bahnhof)
de:08316:6667:2:1 (Kollmarsreute Bahnhof)
de:08326:8324:90:1 (Schwenningen Eisstadion)
de:08326:8324:90:2 (Schwenningen Eisstadion)
de:09373:17750:70 (Parsberg)
de:09375:22000:2 (Regenstauf)
de:09375:559 (Beratzhausen)
de:09564:1431 (Nürnberg-Mögeldorf)
de:09779:6459 (Otting-Weilheim)
de:13075:4374:91:1 (Ückeritz Bahnhof)
de:14522:60813:90 (Dittersbach)
de:14612:28:16:93 (Dresden Hauptbahnhof)
de:15086:8011294 (Burg(Magdeburg))
Wir monitoren mittlerweile Verkehr an Zugängen und melden die Probleme unseren Datenlieferanten zurück. Mit der Zeit sollten zumindest diese Fehler weniger werden.