DOI: 10.24053/ IV-2024-0032 Internationales Verkehrswesen (76) 2 ǀ 2024 76 bereitgestellt. Im Rahmen der gesetzlichen Verpflichtungen wird über den Nationalen Access Point Mobilithek [4] auf die bereitgestellten Fahrplandaten auf der Open Data ÖPNV-Plattform verwiesen. Beziehbar sind der zum Zeitpunkt der Abfrage aktuelle der wöchentlich aktualisierten Datensätze sowie die Sammlung aller Datensätze für das vergangene Kalenderjahr, wobei dieses Archiv im Januar des Folgejahres erzeugt wird. Diese Ausarbeitung bezieht sich auf das statische GTFS Schedule-Archiv des Jahres 2022 und soll einen Überblick über die Datengüte dieser GTFS-Datensätze geben sowie auf die gängigen Fehler bzw. Unvollständig- 1. Einleitung Auf Basis der Delegierten-Verordnung (DelVo) 2017/ 1926 der Europäischen Union [1] sollen seit dem 01.01.2020 die SOLL- Fahrplandaten für das TEN-V-Gesamtnetz bzw. seit dem 01.01.2023 die kompletten nationalen SOLL-Fahrplandaten Deutschlands im Network Timetable Exchange (NeTEx)-Format veröffentlicht werden. Auf Basis des NeTEx-Formats lässt sich ein vollwertiger General Transit Feed Specification (GTFS)-Datensatz erstellen. [2] Seit 2019 werden in Deutschland beide Datenformate durch DELFI e. V. auf der deutschlandweiten Open Data ÖPNV- Plattform [3] keiten hinweisen. Ziel ist es, systematische Defizite hinsichtlich der Datenqualität zu identifizieren, damit diese in zukünftigen Datenbereitstellungen vermieden werden. Zum besseren Verständnis werden dazu zunächst die Unterschiede zwischen den NeTEx- und GTFS-Datenformaten, deren typische Einsatzzwecke sowie die gängige GTFS-Spezifikation dargelegt (vgl. Kapitel 2). Darauffolgend wird eine makroskopische Betrachtung zur inhaltlichen und räumlichen Vollständigkeit dargelegt, mit der für ganz Deutschland ein erster Überblick der Vollständigkeit der, außerhalb der ÖPNV-Branche typischerweise genutzten, Datendefizite frei zugänglicher SOLL-Fahrplandaten in Deutschland Open Source, Mobilitätsdatengesetz, Öffentlicher Personenverkehr, Datenqualität, Datenbereitstellung Auf Grundlage der Delegierten Verordnung 2017/ 1926 EU sollen SOLL-Fahrplandaten des Öffentlichen Personenverkehrs (ÖPV) bereitgestellt werden, die die Grundlage für verschiedenste Informationssysteme (z. B. neue europaweite Fahrplaninformationssysteme), Analysemöglichkeiten über die Güte des ÖPV-Systems und Planungstools z. B. zur besseren Integration des ÖPVs in der räumlichen Planung bilden. Dieser Beitrag betrachtet die von Dritten (z. B. Start-ups, Wissenschaft) i. d. R. genutzten GTFS-Fahrplandaten in Deutschland und zeigt anhand beispielhafter Analysen die Qualität der räumlichen Abbildung sowie die der mitgeführten Informationen auf. Tim Holthaus, Holger Bruch, Bert Leerkamp TECHNOLOGIE  Digitalisierung DOI: 10.24053/ IV-2024-0032 Internationales Verkehrswesen (76) 2 ǀ 2024 77 lich der Anbindungs-, Bedienungs- und Verbindungsqualität ab und können darüber hinaus - sofern Informationen zum Tarif enthalten sind - auch im Rahmen von z. B. Modalwahl-Modellen genutzt werden. Ein deutschlandweiter GTFS-Datensatz wird durch den Verein zur Förderung einer durchgängigen elektronischen Fahrgastinformation (DELFI) e. V. bereitgestellt. Ergänzt werden GTFS Schedule-Daten durch Echtzeitdaten zum Fahrplanstand aus GTFS Realtime, wobei diese Schnittstelle noch nicht bundesweit verfügbar ist. 2.3. NeTEx-Spezifikation Die DelVO 2017/ 1926 [11] unterscheidet ebenfalls zwischen statischen SOLL- und dynamischen IST-Reisedaten. Die systematische und detaillierte Spezifikation unterteilt die bereitzustellenden Daten in drei unterschiedliche Service-Level, wobei die Daten des ersten Service-Levels wesentlich für die multimodale Reiseinformationen sind und die Service-Level 2 und 3 darüber hinausgehende Informationen enthalten. [12] Service-Level 1 deckt alle Informationen, die auch in GTFS-Daten enthalten sind, sowie darüberhinausgehende, wie z. B. Informationen über die Zugänglichkeit von Zugangsknoten und Wege innerhalb von Verkehrsknotenpunkten (vorhandene Aufzüge, Rolltreppen usw.), ab. Theoretisch sind sogar Emissionskennziffern sowie Informationen über die Kapazität der eingesetzten Fahrzeuge bei Erfüllung des Service- Levels 3 enthalten, womit u. a. die Emissionen der enthaltenen Fahrzeuge ermittelt werden können (Anzahl Linienumläufe ∗ Länge eines Umlaufs ∗ Emissionsfaktor/ km). Anders als bei GTFS-Daten, deren Auf bau einer relationalen Datenbank entspricht, werden die umfangreicheren Informationen bei NeTEx-Daten in einer hierarchisch strukturierten Textdatei mittels Extensible Markup Language (XML) gespeichert. bei in den folgenden fünf Textdateien abgebildet (vgl. auch Bild 1). y agency.txt: Verkehrsunternehmen, die im jeweiligen GTFS-Datensatz abgebildet werden. y routes.txt: Linien, die im GTFS-Datensatz abgebildet werden. Ein Linienumlauf wird meist in der Datei trips.txt in Form zweier Trips in Hin- und Rückrichtung abgebildet. Variationen von Linien, z. B. Wegfall von Haltestellen zu einer bestimmten Uhrzeit, werden als eigener Trip abgebildet. y trips.txt: Eine Linie wird am Tag durch mehrere Trips bedient. Jede einzelne Bedienung der Linie wird hiermit erfasst. y stop_times.txt: Information, welcher Trip zu welcher Uhrzeit einen Stop (Haltestelle) bedient. y stops.txt: Informationen (u. a. Name, Koordinaten) über Haltestelle und zu den einzelnen Haltepositionen (z. B. Gleis, Bussteig). Mit dieser Information kann der Fahrplan tageweise abgebildet werden. Werden mehrere Tage in einem GTFS-Datensatz abgebildet, sind die wochentagsbzw. feier- und ferientagsbedingten Fahrplananpassungen über die calendar.txt und die calendar_dates.txt unterscheidbar, wobei die calendar_dates.txt die Bedientage nennt und die calendar dates.txt Ausnahmen formuliert. Wird ein Feiertag abgebildet, nennt letztere Datei eine Ausnahme und weist damit auf den gesonderten Fahrplan einer Linie hin. Darüber hinaus können Informationen zum geografischen Linienverlauf (shapes. txt), zum Zeitbedarf für den Umstieg von einer Haltestelle bzw. Halteposition zu einer anderen (transfers.txt) und zum Tarif (fare_rules.txt und fare_attributes.txt) mitgeführt werden. GTFS-Daten bilden somit alle notwendigen Informationen für Analysen hinsicht- GTFS Schedule-Datensätze [5] abgeschätzt werden kann (vgl. Kapitel 3). Unter Vollständigkeit wird dabei die Güte der Abbildung des zum Zeitpunkt gültigen Fahrplans verstanden. Anschließend werden anhand von ausgewählten Beispielen strukturelle sowie inhaltliche Fehler in den Daten dargelegt. Die Idee der dargelegten Auswertungen ist u. a. im Projekt „VerBindungen“ [6] des Bundesministeriums für Digitales und Verkehr (BMDV) sowie im Austausch im Open Transport Meetup [7] entstanden; sie sind außerhalb jedes Projektkontextes durchgeführt worden und haben deswegen keinen Anspruch auf Vollständigkeit einer ganzheitlichen Prüfung aller Qualitätsaspekte. Die Analysen sind daher als Anstoß einer öffentlichen Aufarbeitung und Entwicklung eines systematischen Prüfverfahrens bereitgestellter SOLL-Fahrplandaten zu verstehen. 2. Unterschied und Einsatzzweck der Dateiformate 2.1. Wesentliche Einsatzgebiete frei verfügbarer SOLL-Fahrplandaten SOLL-Fahrplandaten stellen die Basis für verschiedenste Anwendungen dar. Hier sind neben Angeboten zur Fahrgastinformation, wie diese z. B. von Routingdiensten auf ihren Webseiten und Apps angeboten werden, auch Anwendungen zum Aufzeigen der Qualität im öffentlichen Personenverkehr zu nennen. Die Spannweite reicht dabei von einfachen Benchmarks zur Angebotsqualität (z. B. AGORA ÖV-Atlas 2023 [8]), über Planungstools zur Unterstützung von Neuansiedlungen bis hin zu Analysen im Rahmen der Daseinsvorsorge (z. B. das Erreichbarkeitsportal der Metropolregion Hamburg [9]). GTFS-Daten sind anpassbar, wodurch die Wirkung von geplanten Fahrplananpassungen anhand zuvor definierter Qualitätsmerkmale evaluiert werden kann. So können sie z. B. bei der Gestaltung von Nahverkehrsplänen unterstützen. Durch die Einfachheit der Datenstruktur sind GTFS-Daten bereits in einer Vielzahl von proprietären und Open-Source- Programmen nutzbar. Hier reicht die Bandbreite von einfachen GIS-Anwendungen, diversen Bibliotheken und Paketen unterschiedlichster Programmier- und Skriptsprachen bis hin zu vollwertigen Fahrplanauskunftssystemen ganzer Länder [10]. 2.2. GTFS-Spezifikation GTFS Schedule-Daten stellen eine Sammlung von mehreren Textdateien (*.txt) dar, die in der Gesamtheit als *.zip-Datei gebündelt sind und den SOLL-Fahrplan abbilden. Der Kern der Fahrplaninformation wird da- Bild 1. Bestandteile, Notwendigkeit und Interaktion der einzelnen Datenbank-Bestandteile eines GTFS-Datensatzes Digitalisierung TECHNOLOGIE DOI: 10.24053/ IV-2024-0032 Internationales Verkehrswesen (76) 2 ǀ 2024 78 TECHNOLOGIE  Digitalisierung eine maschinenlesbare Dokumentation der Metadaten wünschenswert, damit entsprechend die Information der potenziellen Vollständigkeit des hinterlegten Fahrplandatensatzes in Abhängigkeit des Ortes an den Endnutzer weitergegeben werden kann. Bild 3 zeigt je GTFS-Datensatz das Datum der Veröffentlichung (Sternchen) sowie für jeden abgebildeten Tag die Anzahl enthaltener Trips mit Stops. Es ist erkennbar, dass am Tag der Veröffentlichung die Anzahl der Trips pro Tag höher ist als mehrere Tage nach der Veröffentlichung. Zudem stechen die Wochenenden heraus, an denen erwartungsgemäß weniger Trips pro Tag im Fahrplan enthalten sind. Darüber hinaus ist erkennbar, dass GTFS sich zeitlich an zwei Stichtagen orientieren: Ende Juni sowie Ende Dezember. Veröffentlichte GTFS-Datensätze vor Mitte Februar enthalten Informationen bis zum 30.06. des jeweiligen Jahres. Veröffentlichungen danach enthalten Daten bis Ende des Jahres. Bild 4 zeigt dieselben Daten in einer anderen farblichen Skalierung ab 700.000 Trips pro Tag. Es ist erkennbar, wie stark die Anzahl an Trips innerhalb weniger Tage variiert. So sind z. B. im Juli und August 2022 mehrere GTFS-Daten veröffentlicht worden, wobei der jeweils neuere Datensatz eine Verbesserung aus Sicht der Anzahl an Trips pro Tag darstellte. Anders verhält es sich im November 2022, wo ein Abfall der Anzahl an Trips im Datensatz erkennbar ist (Übergang vom 07.11.2022 auf den 14.11.2022). Bei der automatischen Verarbeitung der Daten durch Dritte (z. B. von Startups) sind dementsprechend Prüfschritte über die zeitliche Konsistenz von Daten notwendig, damit z. B. der mit höherer Wahrscheinlichkeit vollständigere Datensatz genutzt wird. 3.2.2. Räumlich wiederkehrende Datenlücken Das zHV [21] führt für alle Haltestellen in Deutschland eine Koordinate für den Halten GTFS-Datensätze von der deutschlandweiten Open-Data-ÖPNV-Plattform einzeln betrachtet. Für jeden Datenbestand wird für jeden einzelnen Tag untersucht, wie viele y Stops mit Fahrten am Tag, y Stops mit Fahrten zwischen 05: 30 und 09: 00 Uhr und y Fahrten am jeweiligen Tag im Datensatz enthalten sind. Das Ergebnis ist dem Bild 2 zu entnehmen. Alle im Jahr 2022 bereitgestellten Datensätze führen rd. 800.000 unterschiedliche Stops, wenngleich Schwankungen auftreten. Werden nur Stops mit Trips am Tag [20] betrachtet, sind nur rd. 450.000 der 800.000 enthaltenen Stops auch fahrplanrelevant. Das Delta der Stops ist durch Sonderfahrpläne, falsche Abbildung von Stops (z. B. nicht realgetreue Abbildung der Haltepositionen und dadurch ungenutzte parentstations) sowie durch die fehlende Abbildung von existierenden Linien im Datensatz erklärbar. Eine weitere Reduktion des betrachteten Zeitfensters auf pendelrelevante Abfahrtszeiten reduziert die Anzahl der angefahrenen Stops erwartungsgemäß weiter. 3.2.1. Zeitliche Vollständigkeit der Daten Im Folgenden wird die Anzahl an Trips je Tag in den vorliegenden GTFS-Datensätzen analysiert. Damit GTFS zuverlässig durch Dritte genutzt werden können, muss die zeitliche Gültigkeit der enthaltenen Daten bekannt sein. Zwar sind in den mitgelieferten Metadaten, in Form einer *.PDF-Datei, Informationen zur zeitlichen Gültigkeit der Abbildung des Fahrplans in den einzelnen Verbundgebieten bzw. der einzelnen liefernden Verkehrsunternehmen enthalten. Diese Information ist aus Sicht der Autoren jedoch nicht vollständig. Hier sollten vertiefende Analysen hinsichtlich der Dokumentationsgüte durchgeführt werden. Zur höheren Automatisierung bei der Einbindung der Daten in Tools und Analysen wäre zudem 3. GFTS-Datenqualität in Deutschland 3.1. Strukturelle Korrektheit Voraussetzung für eine automatisierte Verarbeitung der DELFI-Daten ist deren syntaktische und strukturelle Korrektheit. Auch 2023 waren einige GTFS-Datensätze und auch das Zentrale Haltestellenverzeichnis (zHV) syntaktisch fehlerhaft. Formatfehler, wie z. B. eine fehlerhafte Implementierung des CSV-Formats [13] oder eine falsche Kodierung von Sonderzeichen in Haltestellennamen [14], müssen vor Verarbeitung der Daten korrigiert werden. Andere Fehler, wie z. B. fehlerhafte Referenzen [15], fehlende Pflichtangaben, mit (0,0) angegebene Haltestellen-Koordinaten oder falsche Verkehrsmittel- oder Haltestellen- Typ-Angaben [16] lassen sich mit Open- Source-Validierungswerkzeugen wie dem GTFSVTOR [17] feststellen. Diese Fehlangaben führen zu Fehlern bei der Verarbeitung mit gängigen Werkzeugen (u. a. OpenTrip- Planner, ArcGIS Pro) und müssen mittels individuell entwickelter Programme/ Skripte oder bereits vorhandener Open-Source- Programme wie gtfstidy [18] mit mehr oder minder großem Aufwand und teilweise unter Datenverlust korrigiert werden, damit der GTFS-Datensatz nutzbar ist. Nicht der GTFS-Spezifikation folgende Attributierungen im GTFS-Datensatz führen mitunter zu vollständigem Datenverlust bzw. fehlerhafter Vergleichbarkeit von Räumen. Beispielhaft seien hier Bedarfsverkehre genannt, die teilweise als Buslinie ohne Hinweis auf die notwendige Anforderung des Fahrzeuges [19] und bei anderen Datenbereitstellern - richtigerweise - gar nicht im statischen GTFS-Datensatz, sondern über GTFS-Flex bereitgestellt werden. 3.2. Vollständigkeit der Datensätze Im Rahmen der makroskopischen Betrachtung werden alle im Jahr 2022 bereitgestell- Bild 2. Anzahl der Stops je GTFS-Datensatz im Jahr 2022. Je Datensatz wurde der Tag mit den meisten Stops, die durch einen Trip angefahren werden, ausgew¨ahlt (s. Kapitel 3.2.1) DOI: 10.24053/ IV-2024-0032 Internationales Verkehrswesen (76) 2 ǀ 2024 79 Digitalisierung TECHNOLOGIE Ebene der 5 km-GeoGitter die Anzahl an GTFS-Datensätzen, bei denen das Verhältnis kleiner ist als der über alle 49 Datensätze gemittelte Wert aus arithmetischem Mittel abzüglich der Standardabweichung. Es ist erkennbar, dass viele Regionen in mindestens einem der 49 GTFS-Datensätze nicht enthalten sind. Nur wenige Regionen mit einer flächenhaft geringeren Ausdehnung fehlen in mehr als 15 von 49 GTFS-Datensätzen. Ein räumlich sehr ähnliches Bild zeigt sich bei der Nutzung der maximalen (.8653) bzw. minimalen (.7856) Standardabweichung aller Datensatze. 3.3. Inhaltliche Fehler Neben den zuvor ausgeführten strukturellen Fehlern und Datenlücken weisen die GTFS- und zHV-Daten auch eine Reihe inhaltlicher Fehler auf, die ihre Gebrauchstauglichkeit einschränken. 3.3.1. Lageabweichungen von Haltestellen Aus Fahrgastsicht besonders gravierende Fehler in Haltestellendaten sind Lageab- Hierzu wird für jeden GTFS-Datensatz der Tag mit den meisten Trips genutzt (vgl. Kapitel 3.2.1). Im Rahmen einer pragmatischen Prüfung auf Ebene der 5 km-GeoGitter des Bundesamtes für Kartographie und Geodäsie (BKG) wird anschließend das Verhältnis aller Stop-Koordinaten der einzelnen GTFS- Datensätze zu allen Koordinaten, die im zHV den Namen der Haltestelle abbilden, berechnet. Hier gilt es zu beachten, dass im GTFS-Datensatz eine Haltestelle mit zwei Steigen durchaus mit drei Koordinaten in die Berechnung eingeht. Ein Abgleich beider Datensätze untereinander wäre auch auf Basis der deutschlandweiten Global ID [22] jeder Haltestelle bzw. Halteposition möglich. Da diese Kennung aber nicht konsequent in den Teildatensätzen genutzt wird, wird über die räumliche Information geprüft. Für jeden GTFS-Datensatz wird über alle 5 km-GeoGitter die Standardabweichung berechnet. Diese wird zur Identifikation von wiederkehrenden räumlichen Lücken als Grenzwert genutzt. Bild 5 zeigt auf testellennamen sowie je eine Koordinate je Haltepunkt an der Haltestelle (z. B. Gleis, Steig). GTFS-Daten führen diese Informationen definitionsgemäß auch (vgl. Kapitel 2.2). Jedoch unterscheidet sich je Region die Güte der hinterlegten Information (vgl. Kapitel 3.2.2), sodass teilweise nur die Haltepunkte oder nur der Haltestellenname ohne weitere Differenzierung in Haltepunkte als Stop-Koordinate geführt werden. Als Beispiel sei hier die Haltestelle Nordhorn Elsternstraße genannt, die im zHV-Datensatz mit zwei Steigen verortet wird. Im GTFS- Datensatz vom 26.09.2022 wird diese hingegen nur durch eine Koordinate abgebildet. Das zHV speist sich u. a. aus Daten des DELFI e. V. und wird kontinuierlich aktualisiert. Inwieweit auch Daten aus NeTExbzw. GTFS-Daten in das zHV einfließen ist den Autoren nicht bekannt. Gleiches gilt für die Vollständigkeit des zHV. Zum Vergleich der Güte der räumlichen Abdeckung der GTFS-Daten wird im Folgenden auf die Koordinaten der Haltestellen im zHV (Stand 03.01.2023) zurückgegriffen. Bild 3. Trips pro Tag je GTFS-Datensatz im Jahr 2022 Bild 4. Trips pro Tag je GTFS-Datensatz im Jahr 2022 - Arbeitstage; graue Farbgebung mit weniger als 700.000 Trips pro Tag DOI: 10.24053/ IV-2024-0032 Internationales Verkehrswesen (76) 2 ǀ 2024 80 TECHNOLOGIE  Digitalisierung 3.3.3. Fehlerhafte Steigzuordnungen / unplausible Routenverläufe Weiterhin enthalten die Daten teilweise fehlerhafte Steigzuordnungen, bei denen ein Bus z. B. von der auf der gegenüberliegenden Straßenseite abfährt [26] der Schienenersatzverkehr am Gleis hält [27], oder die Regionalbahn auf dem Bahnhofsvorplatz. [28] Liegen zu einer ÖPNV-Linie in den Ursprungsdaten keine geographischen Routenverläufe (in GTFS shapes genannt) vor, führt dies bei der Berechnung von Routenverläufen mittels Routing-Algorithmen zu unplausiblen Verläufen/ Schleifen etc., welche vom tatsächlichen Fahrtverlauf stark abweichen können. [29] 4. Fazit Gemäß der Eckpunkte zum Mobilitätsdatengesetz [30] will der Bund eine aktivere Rolle als „Datenkoordinator für Mobilitätsdaten“ in enger Vernetzung mit den Ländern einnehmen. Weiter heißt es, dass die Nichtbereitstellung von Mobilitätsdaten durch eine weitere Behörde, die mit der zentralen Datenaufsicht beauftragt ist, sanktioniert werden soll. Die durchgeführten Analysen zeigen existierende Unsicherheiten der Datenqualität an beispielhaften Auswertungen zur räumlichen Abdeckung und der zeitlichen Vollständigkeit sowie beispielhaft inhaltliche Fehler der bereitgestellten SOLL-GTFS-Daten. Dies verdeutlicht die Notwendigkeit zur Unterstützung der Datenlieferanten bei der Datenbereitstellung und die Notwendigkeit einer kontinuierlichen inhaltlichen und syntaktischen Kontrolle der bereitgestellten Daten. Die GTFS- und NeTEx-Datenformate sind im hohen Maße ausdefiniert. Letzteres bekommt durch die DelVO 2017/ 1926 in Deutschland einen verbindlicheren Charakter als die bisher freiwillige Bereitstellung von GTFS-Daten. Inhaltliche Fehler, wie die Mehrfachführung einer DHID in einem Datensatz, sollten daher zukünftig vermeidbar sein, wenngleich die dazu notwendigen Schritte dieselben wie bei einer Bereitstellung im GTFS-Datenformat sind. Zur Identifikation von Fehlern in den bereitgestellten Daten sollte, unabhängig vom Datenformat, ein Fehlerverfolgungssystem eingeführt werden, damit die Vielzahl der Datennutzenden und -bereitstellenden identifizierte Qualitätsprobleme verfolgen und an die dazu zuständige Behörde bzw. den Datenbereitsteller melden können. Zudem sollte über die Zusammenarbeit mit Datennutzern bei der Entwicklung von Skripten/ Tools zur Integritätsprüfung der Daten nachgedacht werden, da hier ein großes Interesse sowie Know-how vorliegt. Idealerweise wird dabei auf das von den Datennutzern üblicherweise genutzte GTFS-Datenformat Verwenden Verkehrsunternehmen nicht exakt identische Angaben (sinnvollerweise die des zHV) für eine durch die deutschlandweite, einheitliche Haltestellen- Identifikation (DHID) eigentlich eindeutig beschriebene Haltestelle, so führt dies zu weiteren Artefakten in den GTFS-Daten: Haltestellen sind teils in bis zu fünf Varianten mit mehrfach angehängtem Suffix ’_G’ in den Daten enthalten, sie bedienen Fahrten und deren Linien als Duplikate z. T. mit abweichenden Abfahrtszeiten [24]. Für den Endnutzer bedeutet dies mitunter die Anweisung eines Umsteigens in dieselbe Linie - bei marginal unterschiedlichen Koordinaten in den Datensätzen entstehen dabei sogar Umsteigezeiten. Hier sei angemerkt, dass im DELFI-Datensatz Stops in der DHID-Syntax geführt werden, die zum selben Zeitpunkt nicht dem zHV zu entnehmen waren. Dabei kann es sich sowohl um fehlende Steige im zHV, als auch um abgebildete aber nicht existente Steige handeln. [25] weichungen zwischen Haltestellen-Koordinaten laut zHV/ GTFS und der realen Lage. Hieraus resultieren z. B. fehlerhafte Wegführung, falsch angenommene Auf bruch- und Umsteigezeiten und eine fehlerhafte Beauskunftung der Barrierefreiheit. Bei einem Abgleich der zHV-Haltestellen mit der offenen Karte OpenStreetMap haben wir für einzelne Landkreise für über 3 % mutmaßlich einander entsprechender Bushaltestellen eine Abweichung der Lage von mehr als 200 m, in Einzelfällen sogar bis 2.000 m, festgestellt. [23] Dabei muss die Lage der Haltestellen in OpenStreetMap nicht notwendig korrekt sein, ist es jedoch in der überwiegenden Zahl der untersuchten Fälle. 3.3.2. Haltestellen-, Trip-, Routen-Duplikate Neben diesen offensichtlichen Auswirkungen haben falsche Haltestellenpositionen noch weitere Konsequenzen. Bild 5. Anzahl von GTFS-Datensätzen auf 5 km-Geo-Gitter mit einem Verhältnis μ − σ DOI: 10.24053/ IV-2024-0032 Internationales Verkehrswesen (76) 2 ǀ 2024 81 Digitalisierung TECHNOLOGIE ren GTFS-Datensätzen veranschaulichen, z. B. dem der NVBW (vgl. https: / / github.com/ mfdz/ GTFS-Issues/ issues/ 101, zuletzt abgerufen am 10.03.2024). [30] Vgl. Bundesministerium für Digitales und Verkehr (2023). LITERATUR Agora Verkehrswende. 2023, ÖV-Atlas Deutschland 2023. https: / / www.agora-verkehrswende.de/ veroeffentlichunge n/ oev-atlas-deutschland/ j Brosi, P., & Buchholz, M. 2024, gtfstidy: Tidy (and validate) GTFS feeds. https: / / github.com/ patrickbr/ gtfstidy Bundesministerium für Digitales und Verkehr. 2023, Eckpunkte Mobilitätsdatengesetz. https: / / bmdv.bund.de/ SharedDocs/ DE/ Anlage/ K / eckp unkte-mobilitaetsdatengesetz.pdf Dowle, M., & Srinivasan, A. 2023, data.table: Extension of ‘data.frame‘ Europäische Kommission. 2017, DELEGIERTE VER- ORDNUNG (EU) 2017/ 1926 DER KOMMISSION vom 31. Mai 2017 zur Ergänzung der Richtlinie 2010/ 40/ EU des Europäischen Parlaments und des Rates hinsichtlich der Bereitstellung EU-weiter multimodaler Reiseinformationsdienste. https: / / eur-lex.europa.eu/ eli/ reg del/ 2017/ 1926/ oj Grolemund, G., & Wickham, H. 2011, Journal of Statistical Software, 40, 1. https: / / www.jstatsoft. org/ v40/ i03/ Grégoire, L., Bruch, H., & R, J. 2023, GTFSVTOR: An open-source GTFS validator. https: / / github.com/ mecatran/ gtfsvtor Peter, M. 2021, Die Berechnung kleinräumiger und multimodaler Erreichbarkeiten auf regionaler Ebene, doi: 10.15480/ 882.3673 Poletti, F., Herszenhut, D., Padgham, M., Buckley, T., & Noriega-Goodwin, D. 2023, tidytransit: Read, Validate, Analyze, and Map GTFS Feeds. https: / / github.com/ r-transit/ tidytransit Verband Deutscher Verkehrsunternehmen. 2016, VDV-Schrift 432 - Identifikation von Haltestellen. https: / / www.vdv.de/ downloads/ 3855/ 432SDS/ forced Wickham, H., Averick, M., Bryan, J., et al. 2019, Journal of Open Source Software, 4, 1686, doi: 10.21105/ joss.01686 Eingangsabbildung: © iStock.com/ VladGans [10] Vgl. u. a. Norwegen https: / / om.entur.no/ aktuelle-saker/ opentri pplanner-2-0-is-here/ , zuletzt abgerufen am 17.11.2023. [11] Vgl. (Europäische 2017). [12] Vgl. (Europäische 2017, Anhang). [13] Beispielhaft sei hier das zHV mit Stand 08.05.2023 genannt, in dem ungeschützte doppelte Anführungszeichen in Haltestellennamen existieren (vgl. https: / / github.com/ mfdz/ zhv-issues/ issu es/ 21, zuletzt abgerufen am 10.03.2024). [14] Beispielhaft sei hier das zHV mit Stand 04.03.2024 genannt, in dem ein fehlerhaftes Encoding (A˜Y¨ , A˜¶) für Haltestellennamen vorliegt (vgl. https: / / github.com/ mfdz/ zhv-issues/ issues/ 18, zuletzt abgerufen am 10.03.2024). [15] Vgl. ungültige shape id-Referenzen (vgl. https: / / github.com/ m fdz/ GTFS-Issues/ issues/ 84, zuletzt abgerufen am 10.03.2024). [16] Buslinien des VGN mit route_type Straßenbahn im Datensatz vom 30.01.2023 (vgl. https: / / github.com/ mfdz/ GTFS-Issues/ issues/ 127, zuletzt abgerufen am 10.03.2024) oder bediente Halte mit Typ Eingang/ Ausgang (Datenstand 28.11.2022, https: / / github.com/ mfdz/ GTFS-Issues/ issues/ 72, zuletzt abgerufen am 10.03.2024). [17] Vgl. Grégoire et al. (2023). [18] Vgl. Brosi & Buchholz (2024). [19] Im DELFI-Datensatz vom 19.12.2022 fehlen Informationen für Rufbusse und werden mit dem route type 3 (Bus) statt 715 (Rufbus) angegeben (vgl. https: / / github.com/ mfdz/ GTFS-Issues/ issues/ 114, zuletzt abgerufen am 10.03.2024). [20] Je Datensatz wird der Tag mit den meisten Trips betrachtet (vgl. Kapitel 3.2.1). [21] Datenbestand am 17.01.2023 über https: / / zhv. wvigmbh.de/ abgerufen. [22] Vgl. VDV Schrift 432 (Verband Deutscher Verkehrsunternehmen 2016). [23] Im DELFI-Datensatz vom 04.03.2024 weichen > 2.300 Haltestellenpositionen mehr als 400 m gegenüber dem OpenStreetMap-Datensatz ab (vgl. https: / / github.com/ mfdz/ zhv-issues/ issues/ 16/ , zuletzt abgerufen am 10.03.2024). [24] Vgl. z. B. N44 Nachtbuslinie der Verkehrs- und Tarifverbund Stuttgart GmbH (VVS) im Datenbestand vom 29.01.2024 (vgl. https: / / github.com/ mfdz/ GTFS-Issues/ issues/ 140, zuletzt abgerufen am 10.03.2024). [25] Vgl. z. B. DELFI-Datensatz vom 02.01.2023 (vgl. https: / / github.com/ mfdz / G T FS - Issues/ issues/ 121, zuletzt abgerufen am 10.03.2024). [26] Vgl. z. B. Trips mit referenzierten Steigen in GegenrichtungimDELFI-Datensatz vom01.02.2023 (vgl. https: / / github.com/ mfdz/ GTFS-Issues/ issues/ 122, zuletzt abgerufen am 10.03.2024). [27] Im DELFI-Datensatz vom 16.01.2023 werden 1933 Stops sowohl von Bussen als auch von der Bahn angefahren (vgl. https: / / gi thub.com/ mfdz/ GTFS-Issues/ issues/ 124, zuletzt abgerufen am 10.03.2024). [28] Im DELFI-Datensatz vom 19.12.2022 halten Züge an Bus- Haltestellen (vgl. https: / / github. com/ mfdz/ GTFS-Issues/ is sues/ 118, zuletzt abgerufen am 10.03.2024). [29] Der DELFI-Datensatz enthält keine detaillierten Routenverläufe. Das sich aus falschen Halt-Koordinaten ergebende Problem lässt sich an andezurückgegriffen, da dieses bereits im internationalen Kontext weit verbreitet ist, Prüfroutinen existieren und GTFS alle zur Abbildung eines SOLL-Fahrplans notwendigen Informationen enthalten und damit für eine größere Zielgruppe von Interesse sind. Zur Überführung der Daten aus dem NeTExin das GTFS-Datenformat sind die entsprechenden Spezifikationen zu berücksichtigen. Zur Vermeidung manueller Fehler (z. B. fehlerhafte Koordinaten) sollte der Prozess der Datenbereitstellung vollständig automatisiert sein. Dies bedeutet auch die Sicherstellung der dezentralen Verwendung der Daten aus dem zHV, damit einheitliche Informationen zu den Haltestellen (u. a. die Lage der Haltestelle) über die beim Datenbereitsteller hinterlegten DHID automatisiert aus dem zHV abgegriffen werden kann und somit z. B. Koordinaten-Korrekturen im zHV bei allen Datenbereitstellungen entsprechend gleich berücksichtigt werden. Neben der DHID ist der bereits initiierte Auf bau einer vollständigen Datenbank aller Linien in Deutschland (DLID) zur Überprüfung der Datenvollständigkeit und zur Vermeidung von Liniendopplungen in einem aggregierten Datensatz mehrerer Datenlieferanten zu begrüßen. ■ GENUTZTE SOFTWARE UND DATEN Software: R mit tidytransit (Poletti et al. 2023), tidyverse (Wickham et al. 2019), data.table (Dowle & Srinivasan 2023), lubridate (Grolemund & Wickham 2011) Daten: GTFS für das Jahr 2022 sowie zHV für die Jahr 2022-2024, bereitgestellt vom DELFI e. V. und beziehbar über https: / / www.opendata-oepnv.de. [1] Vgl. https: / / eur-lex.europa.eu/ eli/ reg del/ 2017/ 1926/ oj, zuletzt abgerufen am 26.11.2023. [2] Vgl. https: / / netex-cen.eu/ faq/ how-does-netexcompare-with-gtfs/ , zuletzt abgerufen am 26.11.2023. [3] Die Plattform ist unter https: / / www.opendataoepnv.de (zuletzt abgerufen am 26.11.2023) erreichbar. Zum Datenbezug ist eine Registrierung erforderlich. [4] Die Mobilithek ist unter https: / / mobilithek.info/ (zuletzt abgerufen am 26.11.2023) erreichbar. [5] Neben diesen SOLL-Fahrplandaten werden vereinzelt bereits GTFS Realtime-Daten angeboten. Mit diesem Angebot können die statischen SOLL- Daten mit Echtzeitinformation angereichert werden [6] Vgl. https: / / bmdv.bund.de/ SharedDocs/ DE/ Ar tikel/ G/ for schungsprojek t-verbindungen. html, zuletzt abgerufen am 10.03.2024. [7] Vgl. https: / / github.com/ transportkollektiv/ meetup, zuletzt abgerufen am 10.03.2024. [8] Vgl. Agora Verkehrswende (2023). [9] Vgl. Peter (2021) i. V. m. https: / / metropolregion. hamburg.de/ erreichbarkeitsanalysen/ 9458264/ anwendung/ (zuletzt abgerufen am 26.11.2023). Hier sind das Erreichbarkeitsportal der Metropolregion Hamburg sowie der dadurch entstehende Praxisnutzen aufgeführt. Tim Holthaus, Lehr- und Forschungsgebiet für Güterverkehrsplanung und Transportlogistik, Bergische Universität Wuppertal Pauluskirchstraße 7, 42285 Wuppertal, GER https: / / orcid.org/ 0000-0002-8281-4838 Bert Leerkamp, Lehr- und Forschungsgebiet für Güterverkehrsplanung und Transportlogistik, Bergische Universität Wuppertal Pauluskirchstraße 7, 42285 Wuppertal, GER Holger Bruch, systect Holger Bruch Systemanalyse und IT-Beratung Steigstraße 84B, 70565 Stuttgart, GER