Daten teilen – aber richtig
Standards, Qualität und Governance in der Praxis
Intro
Intro
Die folgenden Kapitel vertiefen die im Vorgehensmodell beschriebenen Schritte fachlich und stellen zentrale Grundlagen für die praktische Umsetzung bereit. Sie richten sich insbesondere an die mit der Erfassung, Aufbereitung, Bereitstellung und Pflege von Mobilitätsdaten befassten Organisationseinheiten.
3.1 Bedeutung europäischer und nationaler Regelwerke für die Datenbereitstellung
Die für Kommunen relevanten Anforderungen an die Bereitstellung von Mobilitätsdaten ergeben sich aus verschiedenen europäischen und nationalen Regelwerken. Diese legen abhängig von der jeweiligen Datenart insbesondere fest,
- welche Daten bereitzustellen sind,
- ob lediglich bereits digital vorliegende Daten veröffentlicht oder bestimmte Informationen künftig auch digital erfasst werden müssen,
- für welche Teile des Verkehrsnetzes die Vorgaben gelten,
- innerhalb welcher Fristen die Anforderungen umzusetzen sind und
- welche Datenstandards für die Bereitstellung zu verwenden sind.
Die rechtlichen Vorgaben wirken sich damit unmittelbar auf die in den folgenden Kapiteln behandelten Fragen zu Datenarten, Datenstandards, Metadaten, Datenqualität und Veröffentlichungsprozessen aus. Dieses Kapitel gibt einen Überblick über die wichtigsten Zusammenhänge. Die konkreten Anforderungen für einzelne Datenarten werden im Datenkompass und in den Datenarten-Steckbriefen dargestellt.
Eine zentrale Grundlage bildet die europäische Richtlinie über intelligente Verkehrssysteme, die IVS-Richtlinie 2010/40/EU einschließlich ihrer Fortschreibung durch die Richtlinie (EU) 2023/2661.[21] Sie schafft den europäischen Rechtsrahmen für den koordinierten Einsatz intelligenter Verkehrssysteme sowie für die Bereitstellung und grenzüberschreitende Nutzung interoperabler Verkehrs- und Mobilitätsdaten. Die konkreten Anforderungen werden durch die Delegierten Verordnungen ausgestaltet.
In Deutschland wird dieser Rechtsrahmen durch das Intelligente-Verkehrssysteme-Gesetz (IVSG) umgesetzt. Das IVSG regelt insbesondere den nationalen organisatorischen Rahmen für die Bereitstellung von Verkehrs- und Mobilitätsdaten, die Funktion des Nationalen Zugangspunkts und die Aufgaben der Nationalen Stelle.
Die Mobilithek bildet den Nationalen Zugangspunkt für Mobilitätsdaten in Deutschland. Die Bundesanstalt für Straßenwesen nimmt die Funktion der Nationalen Stelle wahr. Weitere Informationen zur Mobilithek enthält der Abschnitt Die Mobilithek – was ist das?.
Der durch IVS-Richtlinie und IVSG geschaffene Rechtsrahmen soll insbesondere dazu beitragen,
- Verkehrs- und Mobilitätsdaten über den Nationalen Zugangspunkt zugänglich zu machen,
- inter- und multimodale Informations- und Mobilitätsdienste zu ermöglichen,
- Qualität, Standardisierung und Interoperabilität von Mobilitätsdaten zu verbessern,
- sicherheitsrelevante Verkehrsinformationen bereitzustellen,
- die Voraussetzungen für kooperative, vernetzte und automatisierte Mobilität zu schaffen und
- eine verlässliche Grundlage für datenbasierte Verkehrssteuerung und digitale Mobilitätsdienste bereitzustellen.
Diese Ziele bedeuten jedoch nicht, dass jede Kommune sämtliche genannten Daten selbst erheben oder alle beschriebenen Dienste anbieten muss. Welche konkreten Pflichten bestehen, hängt von der jeweiligen Datenart, der Rolle der Kommune, dem räumlichen Anwendungsbereich und den einschlägigen Fachregelungen ab.
[21] Vgl. Europäisches Parlament; Rat der Europäischen Union (2023). Richtlinie (EU) 2023/2661 des Europäischen Parlaments und des Rates vom 22. November 2023 zur Änderung der Richtlinie 2010/40/EU zum Rahmen für die Einführung intelligenter Verkehrssysteme im Straßenverkehr und für deren Schnittstellen zu anderen Verkehrsträgern, URL: https://eur-lex.europa.eu/legal-content/DE/TXT/?uri=CELEX:32023L2661 (zuletzt abgerufen am 29.07.2026).
Die konkreten Anforderungen an einzelne Bereiche der Mobilitätsdatenbereitstellung werden insbesondere durch delegierte Verordnungen zur IVS-Richtlinie festgelegt. Dazu gehören:
- RTTI – Echtzeit-Verkehrsinformationen: Delegierte Verordnung (EU) 2022/670[22]
Die Verordnung regelt die Bereitstellung dynamischer Straßenverkehrsdaten in Echtzeit. Dazu gehören unter anderem aktuelle Informationen zu Verkehrsfluss, Staus, Sperrungen, Baustellen, Geschwindigkeitsbeschränkungen oder der Verfügbarkeit von Parkplätzen. Die Daten bilden die Grundlage für Navigationsdienste, Verkehrsmanagement und digitale Mobilitätsdienste und müssen von den jeweils zuständigen Stellen über den Nationalen Zugangspunkt bereitgestellt werden.- SRTI – sicherheitsrelevante Verkehrsinformationen: Delegierte Verordnung (EU) Nr. 886/2013[23]
Die Verordnung betrifft sicherheitsrelevante Ereignisse im Straßenverkehr, die Verkehrsteilnehmende unmittelbar warnen sollen. Hierzu zählen beispielsweise Falschfahrer, ungesicherte Unfallstellen, Hindernisse auf der Fahrbahn, extreme Witterungsereignisse oder plötzlich auftretende Gefahren. Ziel ist eine europaweit einheitliche Bereitstellung dieser Informationen, um die Verkehrssicherheit zu erhöhen.- SSTP – Informationen zu sicheren Lkw-Parkplätzen: Delegierte Verordnung (EU) Nr. 885/2013[24]
Die Verordnung regelt die Bereitstellung von Informationen über sichere und geschützte Lkw-Parkplätze. Dazu gehören sowohl statische Angaben, beispielsweise zur Ausstattung, Sicherheitsstufe und Lage, als auch – soweit verfügbar – dynamische Informationen zur aktuellen Auslastung. Die Daten unterstützen den Güterverkehr bei der Routenplanung sowie der Einhaltung von Lenk- und Ruhezeiten.- MMTIS – multimodale Reiseinformationen: Delegierte Verordnung (EU) 2017/1926, zuletzt geändert durch Delegierte Verordnung (EU) 2024/490[25]
Die Verordnung schafft die Voraussetzungen für die Bereitstellung von Daten, die multimodale Reiseinformationsdienste ermöglichen. Hierzu gehören Informationen zu öffentlichen Verkehrsangeboten, Bedarfsverkehren, Sharing-Angeboten sowie weiteren Mobilitätsdiensten. Die bereitgestellten Daten unterstützen sowohl den Vergleich verschiedener Verkehrsangebote (multimodale Reiseplanung) als auch die Planung durchgängiger Reiseketten über mehrere Verkehrsmittel hinweg (intermodale Reiseplanung). Anforderungen an Buchungs-, Ticketing- oder Abrechnungssysteme sind hiervon zu unterscheiden und nicht Gegenstand der Verordnung.
Die Delegierten Verordnungen beschreiben jeweils bestimmte Kategorien von Verkehrs- und Mobilitätsdaten. Sie regeln unter anderem, welche Daten über den Nationalen Zugangspunkt zugänglich gemacht werden müssen, welche Datenstandards zu verwenden sind und für welche Netzbereiche und Fristen die Vorgaben gelten.
Die MMTIS-Verordnung schafft beispielsweise gemeinsame Voraussetzungen dafür, Informationen zu unterschiedlichen Verkehrsmitteln in multimodalen Reiseinformationsdiensten zusammenzuführen. Sie betrifft unter anderem Informationen zu öffentlichen Verkehrsangeboten, Bedarfsverkehren, Sharing-Angeboten und weiteren Mobilitätsdiensten. Anforderungen an durchgängige Buchungs-, Ticketing- und Abrechnungsprozesse sind hiervon zu unterscheiden und bislang nicht in gleicher Weise europaweit harmonisiert. [26]
[22] Vgl. Europäische Kommission (2022). Delegierte Verordnung (EU) 2022/670 der Kommission vom 2. Februar 2022 zur Ergänzung der Richtlinie 2010/40/EU des Europäischen Parlaments und des Rates hinsichtlich der Bereitstellung EU-weiter Echtzeit-Verkehrsinformationsdienste, Amtsblatt der Europäischen Union, L 122 vom 25. April 2022, S. 1 ff., URL: https://eur-lex.europa.eu/legal-content/DE/TXT/?uri=CELEX:32022R0670 (zuletzt abgerufen am 28.07.2026).
[23] Vgl. Europäische Kommission (2013). Delegierte Verordnung (EU) Nr. 886/2013 der Kommission vom 15. Mai 2013 zur Ergänzung der Richtlinie 2010/40/EU des Europäischen Parlaments und des Rates in Bezug auf Daten und Verfahren für die möglichst unentgeltliche Bereitstellung eines Mindestniveaus allgemeiner für die Straßenverkehrssicherheit relevanter Verkehrsinformationen für die Nutzer, Amtsblatt der Europäischen Union. L 247/6 vom 18. September 2013, S. 1 ff., URL: https://eur-lex.europa.eu/legal-content/DE/TXT/HTML/?uri=CELEX:32013R0886 (zuletzt abgerufen am 28.07.2026).
[24] Vgl. Europäische Kommission (2013). Delegierte Verordnung (EU) Nr. 885/2013 der Kommission vom 15. Mai 2013 zur Ergänzung der IVS-Richtlinie 2010/40/EU des Europäischen Parlaments und des Rates in Bezug auf die Bereitstellung von Informationsdiensten für sichere Parkplätze für Lastkraftwagen und andere gewerbliche Fahrzeuge. Amtsblatt der Europäischen Union, L 247/1 vom 18. September 2013, S. 1 ff., URL: https://eur-lex.europa.eu/legal-content/DE/TXT/HTML/?uri=CELEX:32013R0885 (zuletzt abgerufen am 28.07.2026).
[25] Vgl. Europäische Kommission (2022). Delegierte Verordnung (EU) 2022/670 der Kommission vom 2. Februar 2022 zur Ergänzung der Richtlinie 2010/40/EU des Europäischen Parlaments und des Rates hinsichtlich der Bereitstellung EU-weiter Echtzeit-Verkehrsinformationsdienste. Amtsblatt der Europäischen Union, L 122 vom 25. April 2022, S. 1 ff., URL: https://eur-lex.europa.eu/legal-content/DE/TXT/?uri=CELEX:32022R0670 (zuletzt abgerufen am 28.07.2026).
[26] Vgl. Bundesministerium für Verkehr und digitale Infrastruktur (Hrsg., 2021). Nationale Plattform Zukunft der Mobilität: Daten und Vernetzung - Standards und Normen für intermodale Mobilität. URL: https://www.acatech.de/publikation/daten-und-vernetzung-standards-und-normen-fuer-intermodale-mobilitaet/ (zuletzt abgerufen am 29.07.2026).
Neben der IVS-Richtlinie und ihren delegierten Verordnungen sind weitere europäische und nationale Regelwerke relevant.
Hochwertige Datensätze und INSPIRE
Die Durchführungsverordnung (EU) 2023/138 zu hochwertigen Datensätzen – kurz HVD-Verordnung – legt fest, dass bestimmte besonders wertvolle öffentliche Daten mit möglichst geringen rechtlichen und technischen Einschränkungen sowie grundsätzlich kostenlos zur Weiterverwendung bereitgestellt werden müssen.
Im Bereich Mobilität betrifft dies insbesondere Verkehrsnetzdaten gemäß Anhang I der INSPIRE-Richtlinie 2007/2/EG. Die HVD-Verordnung verlangt für diese Daten unter anderem eine Bereitstellung über Programmierschnittstellen und gegebenenfalls als Massendownload. Verkehrsnetze sind in allen verfügbaren Auflösungen bis mindestens zum Maßstab 1:5.000 beziehungsweise in einer höheren Auflösung bereitzustellen.
Die INSPIRE-Richtlinie und ihre Durchführungsregelungen enthalten darüber hinaus Vorgaben zur Beschreibung, Harmonisierung und technischen Bereitstellung von Geodaten. Für kommunale Mobilitätsdaten sind insbesondere die Vorgaben zu Verkehrsnetzen von Bedeutung.
Weitere Hinweise enthält der Abschnitt INSPIRE-Datenspezifikationen.
Personenbeförderungsgesetz
In Deutschland regelt insbesondere das Personenbeförderungsgesetz die Bereitstellung bestimmter Mobilitätsdaten im öffentlichen Personenverkehr. Die Vorgaben richten sich unter anderem an Verkehrsunternehmen, Verkehrsvermittler und weitere Akteure des öffentlichen Verkehrs.
Bestimmte statische und dynamische Daten sowie die dazugehörigen Metadaten sind über den Nationalen Zugangspunkt bereitzustellen. Die im Personenbeförderungsgesetz verwendeten Datenkategorien stehen in engem Zusammenhang mit den Anforderungen der europäischen MMTIS-Verordnung.
Eine Übersicht über die Zuordnung der Datenkategorien bietet das vom Bundesministerium für Verkehr bereitgestellte Mapping zwischen Personenbeförderungsgesetz und MMTIS-Verordnung LINK.
Lade- und Tankinfrastruktur für alternative Kraftstoffe
Weitere Anforderungen ergeben sich aus der Verordnung über den Aufbau der Infrastruktur für alternative Kraftstoffe – AFIR, Verordnung (EU) 2023/1804. Sie betrifft unter anderem die Bereitstellung statischer und dynamischer Daten zu öffentlich zugänglicher Lade- und Tankinfrastruktur.
Dazu können beispielsweise Informationen über Standorte, Anschlüsse, Zugänglichkeit, Betriebszeiten, Preise und die aktuelle Verfügbarkeit von Ladepunkten gehören. Welche Stellen für die Erhebung und Bereitstellung verantwortlich sind, hängt von der jeweiligen Rollen- und Aufgabenverteilung ab.
Bei der Anwendung der Regelwerke ist zwischen Veröffentlichungspflichten und Digitalisierungspflichten zu unterscheiden.
Veröffentlichungspflichten beziehen sich grundsätzlich auf Informationen, die bereits in digitaler, maschinenlesbarer Form vorliegen. Sie verlangen, dass diese Daten entsprechend den jeweils geltenden Anforderungen über den Nationalen Zugangspunkt zugänglich gemacht werden.
Mit der Fortschreibung der IVS-Richtlinie durch die Richtlinie (EU) 2023/2661 wurden für zahlreiche Datenarten zusätzlich Fristen eingeführt, ab denen bestimmte Informationen auch digital verfügbar sein müssen. Für einzelne Datenarten kann dies bedeuten, dass
- neu entstehende Informationen künftig von Beginn an digital erfasst werden müssen oder
- bislang nur analog vorliegende Informationen nachträglich zu digitalisieren sind.
Eine Pflicht zur Bereitstellung bedeutet somit nicht in jedem Fall automatisch, dass sämtliche analogen Bestände sofort digitalisiert werden müssen. Ob und ab wann eine Digitalisierung erforderlich ist, muss für jede Datenart anhand der einschlägigen Vorschriften geprüft werden.
Für Kommunen stellen sich insbesondere folgende Fragen:
- Liegen die betreffenden Informationen bereits digital vor?
- Handelt es sich um Daten, für die eine Veröffentlichungspflicht besteht?
- Besteht zusätzlich eine Verpflichtung zur digitalen Erfassung?
- Ab welchem Zeitpunkt gilt die jeweilige Anforderung?
- Für welchen räumlichen Bereich beziehungsweise welche Netzebene gilt sie?
- In welchem Standard und über welchen Bereitstellungsweg müssen die Daten veröffentlicht werden?
- Ist die Kommune selbst Dateninhaberin oder erfolgt die Bereitstellung durch einen beauftragten Betreiber, ein kommunales Unternehmen oder einen Datenmittelnden?
Die Antworten werden im Datenkompass und in den einzelnen Datenarten-Steckbriefen zusammengeführt.
Zudem differenzieren die Regelwerke nach der jeweiligen Netzebene: Während Anforderungen häufig zunächst für das transeuropäische Verkehrsnetz (TEN-V bzw. auf Englisch TEN-T) gelten, werden sie schrittweise auf weitere Teile des Verkehrsnetzes ausgeweitet. Für Kommunen bedeutet dies, dass je nach Lage im Netz und betroffener Datenart unterschiedliche Fristen und Umsetzungsanforderungen gelten können.
Exkurs: Bezugsbereiche der IVS-Verordnungen nach TEN-V Verordnung (Verordnung (EU) 2024/1679)
- TEN-V-Gesamtnetz: Bis 31.12.2050 fertigzustellendes, überregionales Netz von Verkehrskorridoren, das wichtige europäischer Verkehrsknoten und “Stadtknoten” miteinander verbindet
- TEN-V Kernnetz: Bis 31.12.2030 fertigzustellendendes Teilnetz des TEN-V-Gesamtnetzes
- TEN-V erweitertes Kernnetz: Bis 31.12.2040 fertigzustellendendes Teilnetz des TEN-V-Gesamtnetzes
- Autobahnen
- Fernstraßen bezeichnet Straßen außerhalb von Stadtgebieten, die große Städte und/oder Regionen miteinander verbindet und weder als Teil des transeuropäischen Gesamtstraßennetzes noch als Autobahn eingestuft ist." Für Deutschland versteht dieser Leitfaden hierunter Bundesstraßen (außerorts).
- Städtischer Knoten: Ein ‚städtischer Knoten‘ ist in der TEN-V Verordnung definiert, als ein städtisches Gebiet, in dem die Verkehrsinfrastruktur des transeuropäischen Verkehrsnetzes, mit anderen Teilen dieser Infrastruktur und mit der Infrastruktur für den regionalen und lokalen Verkehr verbunden ist. Die TEN-V Verordnung definiert für Deutschland 78 "städtische Knoten". Von wenigen Ausnahmen abgesehen handelt es sich für Deutschland dabei um Städte mit mehr als 100.000 Einwohnern und Einwohnerinnen.
- Zentrum städtischer Knoten: Für einige Datenarten sind Fristen für die Veröffentlichung der Daten für den Bereich des Zentrums städtischer Knoten festgesetzt. Der Begriff des "Zentrums" ist hierbei nicht explizit definiert.
Die im Leitfaden verwendete Struktur von Datenkategorien und Datenarten bildet eine Grundlage, um solche regulatorischen Anforderungen systematisch zuzuordnen und anschließend in den Datenarten-Steckbriefen konkret zu beschreiben. Jeder Datenarten-Steckbrief verweist auf die jeweils geltende Verordnung und weist darüber hinaus auch geltende Veröffentlichungspflichten aus, und, falls gefordert, Erhebungspflichten aus.
3.2 Datenarten
Mobilitätsdaten entstehen in den unterschiedlichsten Kontexten der kommunalen Verwaltung und des Verkehrssystems. Von zentraler Relevanz sind Informationen zu Baustellen, Verkehrsregelungen und Straßensperrungen, aber auch zu Parkmöglichkeiten oder zur Ladeinfrastruktur für Elektrofahrzeuge.
Bei der weiteren Beschreibung der Datenkategorien und –arten orientiert sich dieser Leitfaden am durch den MobilityDCAT-AP Metadatenstandard definierten Vokabular für Mobility Themes, welches in Version 1.1.1 19 Datenkategorien (“Data content category”) über hundert diesen zugeordneten Datenarten (“Data content sub category”) umfasst. Diese Zuordnung liegt auch der Datenarten-Zuordnung der Mobilithek zugrunde.
Eine Datenkategorie bündelt thematisch zusammengehörige Mobilitätsinformationen auf einer übergeordneten Ebene. Sie dient als Ordnungsrahmen, um Inhalte einheitlich zu strukturieren und Anforderungen aus Regelwerken konsistent zuzuordnen. Innerhalb einer Datenkategorie werden einzelne Datenarten unterschieden.
Eine Datenart bezeichnet eine klar abgegrenzte Art von Mobilitätsinformation mit vergleichbaren inhaltlichen Eigenschaften und Anforderungen an ihre Bereitstellung. Durch die Einteilung in Datenarten wird es möglich, Anforderungen an Struktur, Datenformate, Aktualisierung und Qualität systematisch zu definieren und unterschiedliche Datensätze miteinander kompatibel zu machen. Gleichzeitig erleichtert sie es Datennutzenden, gezielt nach bestimmten Informationen zu suchen oder diese automatisiert zu verarbeiten.
Beispiele für typische Mobilitätsdaten in Kommunen
- Baustellen und Sperrungen
- Verkehrsregelungen (z. B. Zulässige Höchstgeschwindigkeit)
- Parkrauminformationen
- Ladeinfrastruktur
- Sharing-Angebote
- ÖPNV-Daten
Im Datenkompass lassen sich Datenkategorien und Datenarten durchsuchen, filtern und sortieren. Vereinfacht lassen sich die Datenkategorien folgenden Themenfeldern zuordnen:
- Datenkategorien im Leitfaden
Der Leitfaden nutzt eine strukturierte Übersicht der Datenkategorien, die verschiedene Bereiche mobilitätsrelevanter Informationen abdecken. Jede Kategorie umfasst mehrere konkrete Datenarten.
Beispiele für Datenkategorien aus der Übersicht sind unter anderem:
- Infrastrukturdaten (z. B. Geometrie, Straßenbreite, Fahrstreifen, Ladeinfrastruktur),
- Daten über Vorschriften und Beschränkungen (z. B. Geschwindigkeitsbegrenzungen, Zufahrtsbeschränkungen, Überholverbote),
- Daten zum Zustand des Netzes (z. B. Verkehrsbedingungen oder temporäre Einschränkungen),
- Daten über die Nutzung des Netzes (z. B. Verkehrsgeschwindigkeit, Staus oder Reisezeiten),
- Parkplatzdaten (z. B. statische und dynamische Informationen zu Parkplätzen oder Prioritätszonen),
- Reisedaten (z. B. Informationen zu Mobilitätsdiensten, Reiseplanung oder Verkehrsmitteln).
Neben der thematischen Einordnung lassen sich Datenarten auch über Anforderungen gruppieren, die aus der zeitlichen Veränderlichkeit relevanter Aspekte resultieren. Die grundsätzliche Unterscheidung erfolgt dabei zwischen statischen und dynamischen Datenarten.[27]
Statische Datenarten
Statische Daten beschreiben in der Regel dauerhafte Eigenschaften von Infrastruktur oder Verkehrssystemen. Änderungen treten selten oder nur bei strukturellen Anpassungen auf. Dies gilt beispielsweise für:
- Geometrie des Straßennetzes
- Straßenbreite
- Anzahl der Fahrstreifen
- Straßenklasse
- Standorte von sicheren Parkplätzen oder Rastanlagen
- Standorte öffentlicher Ladepunkte oder Tankstellen für alternative Kraftstoffe
Da diese Daten Infrastruktur und Netzstruktur beschreiben, bilden sie häufig die Grundlage für weitere Mobilitätsinformationen.
Dynamische Datenarten
Dynamische Daten beschreiben Zustände oder Ereignisse, die sich laufend ändern können. Dazu gehören beispielsweise Informationen über
- Verfügbarkeit von Ladepunkten für Elektrofahrzeuge,
- Verkehrs- und Reisezeiten,
- aktuelle Verkehrsgeschwindigkeiten oder Staus,
- Belegung von Parkplätzen oder Parkanlagen
- Auslastung und Pünktlichkeit von Fahrzeugen des öffentlichen Verkehrs.
Dynamische Daten stellen deutlich größere Anforderungen an die Aktualisierungsfrequenz als statische Daten, weshalb sie häufig über automatisierte Schnittstellen bereitgestellt werden.
[27] Vgl. Eisenrauch et al. (2025). Data Governance für multi- & intermodale Mobilität: Einordnungen, Praxisbeispiele und Handlungsempfehlungen. Bitkom e.V., URL: https://www.bitkom.org/sites/main/files/2025-01/bitkom-leitfaden-data-governance-fuer-multi-und-intermodale-mobilitaet.pdf (zuletzt abgerufen am 29.07.2026). Teilweise werden in der Literatur historische Daten von den statischen und dynamischen Daten abgegrenzt. In der Regel handelt es sich hier um rückwirkende Aufzeichnungen dynamischer Daten (z.B. Verkehrsaufkommen oder Fahrgastzahlen). Insbesondere für Prognosen sind Zeitreihen historischer Daten sehr wertvoll.
Der Datenkompass bietet eine Übersicht aller Datenkategorien und Datenarten und ermöglicht sowohl eine erste Orientierung zum Einstieg als auch die detaillierte Suche nach konkreten Inhalten. Über Filter- und Suchfunktionen können Nutzende schnell erkennen, welche Datenarten für ihren Anwendungsfall relevant sind, und die entsprechenden Datenarten-Steckbriefe direkt öffnen. Für jede Datenart enthalten die Steckbriefe unter anderem Angaben zu:
- Fristen für Veröffentlichung und gegebenenfalls Digitalisierung, abhängig von der Netzebene – also der Einordnung eines Verkehrswegs etwa in das transeuropäische Verkehrsnetz (TEN-V) oder das übrige Straßennetz
- typischen datenhaltenden Stellen,
- relevanten Datenformaten und Standards,
- Mindestinformationen und Beispieldatensätzen,
- sowie datenartspezifischen Qualitätsanforderungen.
3.3 Datenstandards, Spezifikationen und Profile
Damit Mobilitätsdaten von unterschiedlichen Akteuren gemeinsam genutzt werden können, müssen sie in einer strukturierten und interoperablen Form bereitgestellt werden. Datenstandards und ihre Nutzung konkret beschreibende Profile spielen hierfür die zentrale Rolle. Sie definieren, wie bestimmte Informationen aufgebaut sind, welche Attribute enthalten sein müssen und in welcher Struktur sie zwischen Systemen ausgetauscht werden können.
Im Kontext von Mobilitätsdaten existieren bereits mehrere etablierte Rahmenwerke, Standards und darauf basierende Spezifikationen und Profile, die sich jeweils auf bestimmte Themenbereiche oder Verkehrsträger beziehen.
Von zentraler Bedeutung für Mobilitätsdaten sind die folgenden -Spezifikationsreihen:
- INSPIRE: eine europäische Richtlinie und Spezifikationsfamilie für die standardisierte Bereitstellung und Harmonisierung von Geodaten, die auch für mobilitätsrelevante Basisdaten wie Verkehrsnetze, Standorte oder administrative Grenzen genutzt wird.
- DATEX II: eine Reihe europäischer Spezifikationen für den Austausch straßenverkehrsbezogener Daten, etwa zu Verkehrslage, Baustellen, Straßensperrungen oder Ladeinfrastruktur.
- TN-ITS: Die ebenfalls in EU DelVO 2022/670 genannte Spezifikation zum inkrementellen Austausch von statischen Informationen zu Straßennetzen wird derzeit in den Datenstandard DATEX II als Teil 14 integriert.
- NeTEx: Spezifikation für Fahrplan- und Haltestellendaten im öffentlichen Verkehr sowie SIRI: eine Spezifikations-Familie für den Austausch von Echtzeitinformationen des öffentlichen Verkehrs.
EU DelVO 2022/670 fordert, dass die zur Erfüllung der Bereitstellungspflichten der durch sie verpflichtend zu veröffentlichenden maschinenlesbare Daten die Formate INSPIRE, DATEXII, TN-ITS verwendet werden sollen.
EU DelVO 2017/1926, zuletzt geändert durch EU DelVO 2024/490, führt darüber hinaus aus, dass auch andere Datenstandards (als “Normen” bezeichnet) zulässig sind, sofern ihre Interoperabilität und Kompatibilität durch Konverter oder Validatoren nachgewiesen werden kann. In den Datensteckbriefen werden für konkrete Datenarten existierende Alternativformate und verfügbare Konverter benannt.
Norm:
Eine Norm ist ein in einem formal geregelten Verfahren erarbeitetes Dokument, das Anforderungen, Begriffe, Schnittstellen oder Verfahren festlegt. Normen werden von anerkannten Normungsorganisationen wie DIN, CEN oder ISO unter Beteiligung verschiedener Interessengruppen entwickelt und im Konsens verabschiedet. Ziel ist es, eine einheitliche Grundlage für die Interoperabilität, Qualität und Vergleichbarkeit von Produkten und Dienstleistungen zu schaffen. Normen haben einen hohen Reifegrad und langfristige Stabilität.Spezifikation:
NeTEx und DATEX II sind zwei Beispiele für eine (in diesem Fall europäische) technische Spezifikationen im Bereich Mobilitätsdaten. Sie wurden als CEN/TS 16614 bzw. CEN/TS 16157 vom Comité Européen de Normalisation (kurz CEN) gemeinsam mit den nationalen Normungsorganisationen entwickelt, veröffentlicht. Sie werden in öffentlichen Ausschreibungen verlangt, wobei darauf geachtet werden sollte, spezifische für den Einsatzzweck geeignete Profile vorzugeben (siehe unten).Branchen- oder Industriestandard:
Ein Branchen- oder Industriestandard wird von Unternehmen, Verbänden oder Fachgremien einer bestimmten Branche entwickelt. Er dient dazu, innerhalb eines Fachgebiets einheitliche technische oder organisatorische Vorgaben zu schaffen. Im Gegensatz zu einer Norm entsteht er nicht zwingend in einem offiziellen Normungsverfahren. Branchenstandards können sich jedoch aufgrund ihrer breiten Akzeptanz zu etablierten Regeln entwickeln und später sogar in formale Normen überführt werden. Die VDV-Schriften 453 und 454 zum Austausch von Echtzeitinformationen, Anschlusssicherung, dynamische Fahrgastinformation sowie Fahrplan- und Prognosedaten sind ein gutes Beispiel für einen Branchenstandard, da sie vom Verband Deutscher Verkehrsunternehmen (VDV) veröffentlicht wurden, breit angewendet werden und nicht in eine Norm überführt wurden.De-facto-Standard:
Ein De-facto-Standard entsteht nicht durch einen formalen Beschluss, sondern setzt sich in der Praxis durch seine weite Verbreitung und Akzeptanz durch. Er wird genutzt, weil viele Marktteilnehmer ihn anwenden und dadurch ein hoher Nutzen entsteht. De-facto-Standards können später ebenfalls Gegenstand einer offiziellen Normung werden.Unter Umständen kann auch ein De-facto-Standard zu einem Branchen- oder Industriestandard oder gar zu einer internationalen Norm werden, das Format pdf für den plattformunabhängigen Austausch von Dokumenten ist hierfür ein gutes Beispiel. Ursprünglich von Adobe entwickelt, hat es sich am Markt durchgesetzt, wurde also zum De-facto-Standard und ist inzwischen in einer internationalen Norm (PDF 2.0 in der ISO 32000-2:2020) beschrieben.
Profil:
Daten-Spezifikationen beschreiben, wie Daten ihres Anwendungsbereiches zu veröffentlichen sind. Dabei bestehen mitunter unterschiedliche Möglichkeiten, die gleichen Inhalte darzustellen oder es ist nicht für alle Inhalte zwingend festgelegt, ob sie verpflichtend bereitzustellen sind oder nicht. Darüber hinaus besitzen viele Spezifikationen Möglichkeiten zur Erweiterung, die in Anwendungsfällen genutzt werden können, die noch nicht standardisiert wurden. Profile konkretisieren Spezifikationen für spezifische Einsatzzwecke, indem sie konkrete Festlegungen treffen, und so die Freiheitsgrade von Spezifikationen einschränken.[28] Im Download-Bereich der Mobilithek werden in Deutschland gebräuchliche DATEXII-Datenprofile zum Download bereitgestellt. Bei Vergaben sollten konkrete Profile für Datenbereitstellungen festgelegt werden, um die angestrebte Kompatibilität zwischen Systemen zu gewährleisten.
Ergänzend existieren weitere, teils standardisierte und in der Praxis weit verbreitete Spezifikationen, die für die Bereitstellung von Mobilitätsdaten eine wichtige Rolle spielen, auch wenn sie (zumindest derzeit) nicht vollständig kompatibel zu den vorgenannten Spezifikationen sind. Zu den wichtigsten zählen:
- GTFS (General Transit Feed Specification): ein international verbreiteter De-facto-Standard zur Bereitstellung von Fahrplan- und Angebotsdaten im öffentlichen Verkehr.
- GBFS (General Bikeshare Feed Specification): eine offene Spezifikation zur Bereitstellung von Echtzeitinformationen zu Bike- und Mikromobilitäts-Sharing-Angeboten, insbesondere Verfügbarkeiten und Standorte.
- MDS (Mobility Data Specification): eine Spezifikation zur standardisierten Bereitstellung von Daten aus Sharing-Systemen (z. B. E-Scooter), insbesondere für die Nutzung durch Kommunen zur Steuerung und Analyse.
- OCPI (Open Charge Point Interface): ein offener Standard für den Austausch von Daten zur Ladeinfrastruktur für Elektrofahrzeuge, insbesondere zwischen Betreibern, Plattformen und Mobilitätsdiensten.
Für Kommunen ist dabei nicht entscheidend, alle Details dieser Spezifikationen zu kennen oder selbst vollständig umzusetzen. In vielen Fällen werden diese Spezifikationen bereits von bestehenden Fachanwendungen, Plattformlösungen oder Dienstleistern unterstützt. Wichtig ist jedoch, dass bei der Auswahl von Softwarelösungen, der Beauftragung externer Dienstleister sowie der Abnahme ihrer Leistungen darauf geachtet wird, dass diese Systeme eine standardisierte Datenbereitstellung ermöglichen (Bausteine für Ausschreibungen) und - falls vorhanden - vorgegebenen Spezifikationen/Profilen genügen.
Ein häufiges Hindernis in der Praxis ist die Wahrnehmung, dass Daten-Spezifikationen sehr komplex und technisch anspruchsvoll sind. Tatsächlich enthalten viele Spezifikationen umfangreiche Datenmodelle, die eine Vielzahl möglicher Anwendungsfälle abdecken. Für die konkrete Umsetzung auf kommunaler Ebene wird jedoch in der Regel nur ein kleiner Teil dieser Strukturen benötigt. Häufig existieren daher sogenannte Profile oder Implementierungsleitfäden, die festlegen, welche Teile eine Spezifikation für eine bestimmte Datenart relevant sind. Solche Profile reduzieren die Komplexität der zugrunde liegenden Spezifikation erheblich und ermöglichen eine praxisnahe Umsetzung.
Für Kommunen empfiehlt es sich daher, bei der Umsetzung von Mobilitätsdaten folgende Grundsätze zu beachten:
- etablierte Spezifikationen nutzen und bei eigenen Datenmodellen Kompatibilität sicherstellen, z.B. durch Nutzung etablierter Attribute und Werteliste
- vorhandene Profile oder Implementierungsleitfäden nutzen,
- bei der Beschaffung von Fachanwendungen oder Dienstleistungen die Unterstützung relevanter Spezifikationen bzw. Im Idealfall konkrete Profile als Anforderung festlegen
- und nach Möglichkeit auf automatisierte Schnittstellen zurückgreifen.
Die konkrete Wahl der Spezifikation hängt dabei in der Regel von der jeweiligen Datenart ab. Welche Spezifikation für eine bestimmte Datenart relevant sind, wird in den Datenarten-Steckbriefen dieses Leitfadens näher erläutert.
Durch die konsequente Nutzung standardisierter Datenformate können Kommunen sicherstellen, dass ihre Daten den Vorgaben des IVSG-Gesetzes und europäischer Verordnungen genügen und in nationale und europäische Mobilitätsdateninfrastrukturen integriert werden können. Dies ist eine wichtige Voraussetzung dafür, dass Mobilitätsdaten langfristig in digitalen Diensten und Anwendungen genutzt werden können.
[28] Vgl. NAPCORE (2024). An updated list of requirements concerning the use of data standards, profiles and metadata, Milestone 2.7, Version 1.2, insbesondere Kap. 3, S. 31–41. URL: https://www.napcore.eu/documents/M2.7_Updated_list_requirements.pdf (zuletzt abgerufen am 29.07.2026).
Die INSPIRE-Initiative (Infrastructure for Spatial Information in Europe) ist ein zentraler Baustein der europäischen Daten- und Umweltpolitik. Ihr Ziel war es, einen einheitlichen Rahmen für Geodaten in Europa zu schaffen, damit räumliche Informationen zwischen Staaten und Behörden interoperabel genutzt werden können. Grundlage ist die EU-Richtlinie 2007/2/EG, die den Aufbau einer europäischen Geodateninfrastruktur (Spatial Data Infrastructure, SDI) regelt.
Diese wurde 2009 mit dem Geodatenzugangsgesetz in deutsches Recht umgesetzt. Da Geodaten zumeist unter Länderkompetenz fallen, haben die Bundesländer eigene Geodaten- oder Geoinformationsgesetze erlassen. Darüber hinaus wurden Verwaltungsvereinbarungen zur Geodateninfrastruktur Deutschland getroffen und eine Koordinierungsstelle GDI-DE beim Bundesamt für Kartographie und Geodäsie eingerichtet.
Umfassende Hintergrundinformationen hierzu liefert die INSPIRE-Seite des BMLEH.
Zu den 34 Geodatenthemen, welche durch INSPIRE auffindbar, interoperabel und zugänglich gemacht werden sollen, zählen mit den Basisdaten Adressdaten, geografische Namen und Verkehrsnetze auch Datenkategorien, welche mittlerweile unter die Europäische IVS-Richtlinie fallen.
Für diese Datenkategorien wurden zudem Datenspezifikationen erarbeitet, die ein Datenmodell und damit die zu veröffentlichenden und über Downloaddienste bereitzustellende Informationen beschreiben. Für Verkehrsnetze (dies umfasst Straße, Wasser, Schiene und Luftverkehr) ist dies die INSPIRE DS TN (INSPIRE Data Specification on Transport Networks).
Die INSPIRE Datenspezifikation Verkehrsnetze umfasst für Verkehrsnetze zwei verschiedene Repräsentationsformen: eine flächenhafte Repräsentation oder alternativ in Form einer linienhaften Beschreibung der Mittellinie der Verkehrswege. Letztere Form der Beschreibung ist für die Verwendung in Routing-Anwendungen für Wegeberechnungen und die Veröffentlichung von Verkehrsnetzen nach der MMTIS-Verordnung nutzbar.
In Deutschland hat die GDI-DE sich intensiv mit der Bereitstellung von Daten nach INSPIRE beschäftigt. Da in der deutschen Straßenbauverwaltung vielfach die Anweisung Straßeninformationsbank und das Datenaustauschformat OKSTRA die IT-technische Grundlage bildet, hat die GDI-DE ein Mapping, also Abbildungsregeln aus dem OKSTRA-Format in die INSPIRE Datenspezifikation Verkehrsnetze (auf Englisch INSPIRE Data Specification Transport Networks, kurz INSPIRE DS TN) erarbeitet.
Insgesamt hat sich die Nutzung von INSPIRE DS TN in Deutschland bisher aufgrund empfundener Komplexität und geringer Unterstützung in Standard-Software-Werkzeugen weder seitens der Datenbereitstellenden noch der Konsumierenden durchgesetzt (siehe hierzu GDI-DE Bericht 2025 an die EU).
Auch aus diesem Grund stehen im Zuge des europäischen OMNIBUS Projekts zur Verwaltungsvereinfachung derzeit auch Vorgaben der INSPIRE Richtlinie und zugehöriger Umsetzungsverordnungen auf dem Prüfstand. Einige spezifische technische Vorgaben sind entfallen und die Mitgliedsstaaten erhalten mehr Freiheiten in der konkreten Umsetzung.
In den Steckbriefen zu den verschiedenen Datenarten macht dieser Leitfaden dennoch Vorschläge, wie Daten INSPIRE-konform aufbereitet und bereitgestellt werden können.
DATEX II ist der zentrale europäische Standard für den Austausch straßenverkehrsbezogener Daten im Kontext intelligenter Verkehrssysteme. Er wird insbesondere im Rahmen der delegierten Verordnungen zur IVS-Richtlinie (ITS Directive) eingesetzt und ist in vielen Anwendungsfällen verpflichtend.
Der Standard wurde speziell für die strukturierte Bereitstellung und den Austausch von Informationen zum Straßenverkehr entwickelt. Dazu zählen unter anderem:
- Verkehrslage und Verkehrsfluss
- Baustellen und geplante Maßnahmen
- Straßensperrungen und Zugangsbeschränkungen
- Verkehrsstörungen und Ereignisse
- Verkehrsregelungen und -beeinflussung
DATEX II basiert auf einem standardisierten Datenmodell und wird typischerweise in XML oder zunehmend auch in JSON-basierten Profilen umgesetzt. Die Spezifikation definiert sowohl die semantische Struktur der Daten als auch deren Austauschformate.
Für die praktische Anwendung werden häufig sogenannte Profile genutzt, die den Standard auf konkrete Anwendungsfälle zuschneiden. In Deutschland stellt die Nationale Stelle für Verkehrs- und Mobilitätsdaten über die Mobilithek entsprechende Profile und Umsetzungshilfen bereit, um eine konsistente Nutzung sicherzustellen.
Für Kommunen ist DATEX II insbesondere dann relevant, wenn sie Daten zu straßenverkehrsbezogenen Ereignissen und Maßnahmen über den nationalen Zugangspunkt bereitstellen, beispielsweise zu Baustellen, Sperrungen oder Verkehrsregelungen. Wenn Kommunen ihre Daten über Datenmittelnde (dies können Landesplattformen wie z.B. MobiData BW und MOBIDROM sein, aber auch regionale oder kommerzielle Anbietende) veröffentlichen, können eventuell auch andere Datenstandards oder individuell vereinbarte Formate genutzt werden. Die Nutzung von DATEX II ermöglicht es, diese Informationen standardisiert bereitzustellen und in überregionale Systeme – etwa Navigationsdienste oder Verkehrsinformationsplattformen – zu integrieren.
Der TN-ITS Standard ging aus einem von ERTICO koordinierten Förderprojekt ROSATTE (Road Safety ATTributes exchange infrastructure in Europe) hervor. Es hatte zum Ziel, eine effiziente und qualitätsgesicherte Lieferkette für Informationen zu sicherheitsrelevanten Straßenmerkmalen – von Behörden über kommerzielle Kartenanbietende bis hin zu anderen Nutzenden von Straßendaten – aufzubauen. Dabei lag und liegt weiterhin der Schwerpunkt eher auf Änderungen der betreffenden Merkmale als auf vollständigen Datensätzen.
Seit EU DelVO 2022/670 bietet TN-ITS neben INSPIRE und DATEXII eine alternative Möglichkeit der Datenbereitstellung, die bisher insbesondere für die Übermittlung von Daten zu Verkehrszeichen genutzt wird.
Derzeit erfolgt eine Integration des TN-ITS-Spezifikation als Teil 14 in die DATEXII-Spezifikationsreihe.
NeTEx und SIRI sind europäische Standards für den Austausch von Daten im öffentlichen Verkehr und werden insbesondere im Kontext multimodaler Reiseinformationen eingesetzt.
NeTEx (Network Timetable Exchange) dient der strukturierten Bereitstellung von statischen Daten des öffentlichen Verkehrs. Dazu gehören insbesondere:
- Fahrplandaten (Linien, Fahrten, Zeiten)
- Haltestellen und deren Eigenschaften
- Netzstrukturen und Linienverläufe
- Tarifinformationen und Angebotsstrukturen
SIRI (Service Interface for Real Time Information) ergänzt NeTEx um den Austausch von Echtzeitdaten. Typische Anwendungsfälle sind:
- aktuelle Abfahrts- und Ankunftszeiten
- Verspätungen und Ausfälle
- Fahrzeugpositionen
- Betriebszustände und Störungsmeldungen
Beide Standards sind eng miteinander verknüpft: NeTEx bildet die statische Grundlage, während SIRI die dynamische Aktualisierung dieser Informationen ermöglicht.
Die Standards basieren auf dem gemeinsamen Datenmodell Transmodel und werden typischerweise in XML umgesetzt. Sie sind in europäischen Regelwerken, insbesondere im Rahmen der delegierten Verordnung zu multimodalen Reiseinformationen (MMTIS), fest verankert. In Deutschland übernimmt der DELFI e.V. grundsätzlich die Rolle eines Datenmittelnden im Sinne des IVS-Gesetzes für die Daten des öffentlichen Verkehrs und stellt an ihn übermittelte Daten gemäß der NeTEx- und SIRI-Spezifikationen bereit beziehungsweise beabsichtigt dies.
Die Übermittlung der Daten an den DELFI erfolgt üblicherweise über Landessysteme an welche Verkehrsverbünde und –Unternehmen ihre Daten übermitteln. Für diese internen Datenübermittlungen sind in der Regel in VDV-Schriften festgelegte Spezifikationen zu nutzen. ÖV-Aufgabenträger sollten bei ihren Vergaben entsprechend mit den Verkehrsverbünden beziehungsweise Betreibern der Landessystem abgestimmte Vorgaben zu bereitzustellenden Datenformaten machen.
Unabhängig von der Inanspruchnahme eines Datenmittelnden sind Dateninhabende weiterhin für die aktuelle und korrekte Datenbereitstellung verantwortlich (siehe EU DelVO 2017/1926, zuletzt geändert durch EuDelVO 2024/490, Artikel 3 Absatz 6).
Die Nutzung dieser Standards ermöglicht es, Fahrplan- und Echtzeitinformationen interoperabel bereitzustellen und in Reiseinformationssysteme, Mobilitätsplattformen und andere digitale Dienste zu integrieren.
3.4 Metadaten
Neben der Bereitstellung der eigentlichen Datensätze bedarf es auch der Bereitstellung von Metadaten. Metadaten sind strukturierte Informationen, die einen Datensatz beschreiben und einordnen. Sie stellen sicher, dass Mobilitätsdaten effektiv gefunden, verstanden und weiterverwendet werden können.
Während der Datensatz selbst beispielsweise Informationen zu einer Baustelle, einer Straßensperrung oder einem Sharing-Angebot enthält, beschreiben Metadaten unter anderem, wer die Daten bereitstellt, für welches Gebiet und in welchem Format sie vorliegen, wie aktuell sie sind oder unter welchen Bedingungen sie genutzt werden dürfen.
Metadaten erfüllen damit eine ähnliche Funktion wie ein Katalogeintrag in einer Bibliothek. Sie ermöglichen es Nutzenden und Datenplattformen, Datensätze systematisch zu erfassen, zu durchsuchen und miteinander zu verknüpfen. Sie stellen damit ein zentrales Element in Phase 4 Technische Aufbereitung und Qualitätsmanagement des Vorgehensmodells zum Teilen von Mobilitätsdaten in Kommunen dar.
Warum Metadaten entscheidend sind
- machen Daten auffindbar
- ermöglichen automatisierte Verarbeitung
- schaffen Vertrauen in Datenqualität
- sind Voraussetzung für Mobilithek / NAP
Für Kommunen bedeutet dies in der Praxis, dass bei der Veröffentlichung von Mobilitätsdaten nicht nur der eigentliche Datensatz bereitgestellt werden muss, sondern auch eine strukturierte Beschreibung dieses Datensatzes. Typische Metadaten umfassen beispielsweise:
- Titel und kurze Beschreibung des Datensatzes,
- verantwortliche Organisation oder Kontaktstelle,
- räumlicher Bezug der Daten,
- Aktualität oder Aktualisierungsfrequenz,
- verwendetes Datenformat,
- Lizenz- oder Nutzungsbedingungen,
- thematische Zuordnung
Im Kontext von Mobilitätsdaten sind Metadaten insbesondere für die Veröffentlichung über nationale Zugangspunkte (National Access Points, NAP) von zentraler Bedeutung.
In Deutschland wird diese Funktion durch die Mobilithek wahrgenommen, die als nationaler Zugangspunkt für Mobilitäts- und Verkehrsdaten dient. Datensätze, die über die Mobilithek bereitgestellt werden, werden dort über ihre Metadaten beschrieben und katalogisiert. Nur wenn ein Datensatz mit geeigneten Metadaten versehen ist, kann er von Nutzenden gefunden und korrekt eingeordnet werden.
Datengebende, die ihre Daten direkt über die Mobilithek bereitstellen, können mit der Veröffentlichung der Daten auch direkt die Metadaten mit dem komfortablen Eingabe-Formular der Mobilithek erfassen. Details beschreibt der Blog-Post “Gute Metadaten: Die Visitenkarte für Ihr Angebot” der Mobilithek.
Stellen Datengebende die Daten über ein eigenes Portal oder ein Drittportal (z. B. DELFI oder Landesdatenplattformen) bereit, muss dieses System selbst die Metadaten in standardisierter Form bereitstellen. Die verschiedenen Anlieferoptionen an die Mobilithek werden in Kapitel 3.7 Lizenzen erläutert. Dann können andere Portale, wie z.B. bündelnde Landesportale, das OpenData-Portal des Bundes GovData oder die Mobilithek diese übernehmen (“harvesten”). Um eine einheitliche Beschreibung von Mobilitätsdatensätzen zu gewährleisten, sollten die Portale d die von der Mobilithek zur Kategorisierung genutzten Datenkategorien und Daten-Unterkategorien als Schlüsselworte umfassen. Details hierzu sind in den Steckbriefen beschrieben.
Falls Sie ein eigenes Portal oder ein Dritt-Portal verwenden: häufig bieten solche Datenplattformen Editoren an, um Metadaten komfortabel zu erfassen. Wichtig ist jedoch, dass die zugrunde liegenden Informationen korrekt und aktuell gepflegt sind, da sie maßgeblich darüber entscheiden, ob ein Datensatz auf Plattformen wie der Mobilithek auffindbar und nutzbar ist. Beachten Sie ggf. Anleitungen Ihres Portals bzw. des Dritt-Portals zum Anlegen und Pflege von Metadaten, und prüfen Sie, ob und wie dieses Portal Metadaten an die Mobilithek übergibt.
Exkurs: Räumlicher Bezug der Daten
Für einen Datensatz sollte in den Metadaten der räumliche Bezug angeben werden, der durch die Daten abgedeckt wird. Für Bundesländer, Kreise und kreisfreie Städte können hierzu die europaweit vergebenen NUTS-Codes verwendet werden. Alternativ lässt sich in der Mobilithek (und in der Regel auch anderen Datenportalen) das Bezugsgebiet durch eine Flächengeometrie umschreiben. Diese sollte nicht zu grob sein und das abgedeckte Gebiet näherungsweise beschreiben. Für aggregierte Datensätze, welche nur manche Verwaltungsgebiete umfassen, ist eine explizite Angabe der abgedeckten Gebiete – entweder als NUTS-Codes oder als Flächen - einem auch nicht enthaltene Gebiete überdeckenden Polygons vorzuziehen.
Dieser Leitfaden unterstützt Kommunen hierbei, indem in den Datenarten-Steckbriefen für jede Datenart die relevanten Metadatenfelder aufgeführt werden. Dadurch kann nachvollzogen werden, welche Metadaten für die Veröffentlichung eines bestimmten Datensatzes erforderlich sind und wie dieser im Kontext nationaler Zugangspunkte eingeordnet wird.
Langfristig tragen konsistent gepflegte Metadaten wesentlich dazu bei, dass Mobilitätsdaten über Plattformen hinweg auffindbar und interoperabel bleiben. Sie bilden damit eine zentrale Grundlage für die Nutzung kommunaler Mobilitätsdaten in digitalen Diensten, Verkehrsmanagementsystemen und multimodalen Mobilitätsplattformen.
3.5 Automatisierung
Die im Rahmen der IVS-Richtlinie erlassenen Delegierten Verordnungen sehen vor, dass Daten in einem Zeitrahmen aktualisiert werden, der eine zuverlässige und wirksame Verwendung der Daten ermöglicht, und nach Möglichkeit im Voraus erfolgen sollen Berichtigungen sollen “rechtzeitig” erfolgen (siehe EU DelVO 2022/670 Artikel 8-10 jeweils Absatz 2 und 3, EU DelVO 2017/1926 Artikel 6).
Eine Automatisierung ist der hierfür entscheidende Schritt der Veröffentlichung von Mobilitätsdaten. Ohne Automatisierung müssen Daten manuell aus Systemen oder Listen abgerufen, aufbereitet und zur Veröffentlichung bereitgestellt werden. Dies ist zeitaufwändig und fehleranfällig. Oftmals kann dies nur eine oder wenige Personen durchführen, d. h. während Abwesenheiten wie Urlaub oder Krankheit findet die Aktualisierung nicht statt. Vielleicht ist der Prozess nicht dokumentiert und die Bereitstellung variiert daher immer etwas, d. h. die veröffentlichten Daten unterscheiden sich aufgrund von Varianzen im Veröffentlichungsprozess in der Folge immer wieder mal in Form und Umfang.
Weil fehlende Automatisierung Aufwände und auch Kosten erzeugt, findet eine Aktualisierung selten und häufig nicht regelmäßig statt. In der Konsequenz sind die veröffentlichten Daten dann schnell veraltet und büßen einen großen Teil des Mehrwerts für Datenkonsumierende ein.
Es gibt viele unterschiedliche Punkte, an denen eine Automatisierung scheitern kann und die daher adressiert werden müssen:
- Fehlende Schnittstellen von (Fach-)Systemen
- Proprietäre Formate in der Ausleitung
- Fehlende Infrastruktur/Wissen/Ressourcen/Werkzeuge um eventuell notwendige Aufbereitungen/Transformationen/Validierungen in einen automatisierten Datenbereitstellungsprozess zu integrieren und überwacht auszuführen
- Netzwerk-Strukturen, die eine sichere Übermittlung der Daten zum Veröffentlichungssystem blockieren
Viele Fachanwendungen verfügen heute noch nicht über Schnittstellen zum automatisierten Datenabruf. In der Folge müssen Daten teilweise in aufwändigen manuellen Schritten aus einem System exportiert und oftmals noch nachbearbeitet werden.
3.5.2.1 Empfohlene Maßnahmen
- Führen Sie – am besten gemeinsam mit der IT-Abteilung – eine Inventur der verwendeten Fachanwendungen durch[29]. Leitfragen:
- Welche Systeme und Anwendungen werden genutzt?
- Von welchen Anbietenden stammen diese?
- Welche Daten werden in diesen führend gepflegt?
- Verfügen die Systeme über Schnittstellen zum Export der Daten?
- In welchen Formaten werden die Daten exportiert, insbesondere in proprietären Datenformaten oder offenen Datenstandards?
- Wie können diese Schnittstellen angesprochen werden?
- Sind sie zugangsbeschränkt? Wer hat Zugriff?
- Lassen sich (falls erforderlich) Sichtbarkeitsregeln für Attribute/Datensätze je Zugang regeln?
- Welche Stelle verwaltet die Zugänge?
- Falls Systeme noch keine Schnittstelle haben: Klären Sie mit den Anbietenden, ob die Systeme nachrüstbar sind, z. B. durch Zusatzmodule oder explizit vorgenommene Erweiterungen und zu welchen Kosten.
- Falls keine Erweiterungsmöglichkeit besteht: Prüfen Sie, ob eine Ersatzbeschaffung sinnvoll ist oder gegebenenfalls bereits andere, existierende Systeme genutzt werden können.
- Wenn Sie die Neuanschaffung von Systemen planen, berücksichtigen Sie Schnittstellen in der Leistungsbeschreibung und machen Sie diese zu Pflichtkriterien in der Ausschreibung. (Siehe auch Kapitel Ausschreibungsbausteine)
- Nur eingeschränkt empfehlenswert: Wenn das System eine Datenbank zur Datenhaltung nutzt und Sie technisch (und lizenztechnisch) Zugriff auf diese haben, können Sie einen Daten-Export womöglich selbst umsetzen. Beachten Sie jedoch, dass Datenbankmodelle von Herstellern in der Regel nicht als stabil bleibende "Schnittstelle" unterstützt werden und sich z. B. bei Versionsänderungen auch Anpassungsbedarf ergeben kann.
3.5.2.1.1 Einstiegsmaßnahmen
Erstellen Sie gemeinsam mit der IT-Abteilung eine Systemliste in Form einer tabellarischen Aufstellung. Neue Lösungen sollen sich in die vorhandene IT-Infrastruktur der Kommune integrieren lassen und Doppelterfassungen vermieden werden.[30] Eine solche Übersicht der Software-Landschaft kann auch im Verbund mit anderen Kommunen erstellt werden.[31] Führt die IT der Kommune bereits ein Konfigurationsmanagement-System, lassen sich hieraus schon Informationen ableiten. Falls nicht, kann eine solche erstellte Liste der erste Schritt zu einem systematischen Konfigurationsmanagement sein.
3.5.2.1.2 Fortgeschrittene Maßnahmen
Grundsätzlich sollten Behörden an den Standards und Empfehlungen des BSI folgen. Für die Beschaffung von (Fach-)Systemen sollte insbesondere BSI-Grundschutz Baustein APP.6 Allgemeine Software beachtet werden.
In der Regel führt der IT-Betrieb bereits ein Software-Bestandsverzeichnis, das bereits die eingesetzten Software-Systeme enthält (eventuell bereits in einem IT-Inventar-Verwaltungs-System). Dieses kann als Grundlage für eine Erhebung der verfügbaren Schnittstellen dienen. Idealerweise werden im System gepflegte Datenarten und Schnittstellen direkt im Bestandsverzeichnis gepflegt.
[29] Vgl. Ministerium für Heimat, Kommunales, Bau und Digitalisierung des Landes Nordrhein-Westfalen (2025). Praxisleitfaden für die Datensouveränität im Kontext von Open Data: Für eine nachhaltige Beschaffung und umfassende Bereitstellung von Verwaltungsdaten, URL: https://open.nrw/system/files/media/document/file/praxisleitfaden_datensouveraenitaet_im_kontext_von_open_data.pdf (zuletzt abgerufen am 29.07.2026).
[30] Vgl. Schürzinger, H., Edenharter, F., Geisberger, M., & Ruscheinski, T. (2024). Digitalisierungsleitfaden – eine praxisnahe Schritt-für-Schritt-Anleitung zur Entwicklung einer maßgeschneiderten kommunalen Digitalisierungsstrategie. Bayerische Verwaltung für Ländliche Entwicklung. URL: https://smarte-gemeinde.bayern/nachrichten/217/digitalisierungsleitfaden-fuer-laendliche-kommunen-erschienen (zuletzt abgerufen am 29.07.2026).
[31] Vgl. Sächsischer Städte- und Gemeindetag (2024). Leitfaden interkommunale Zusammenarbeit in einer digitalisierten Welt, Abschnitt 4.2 Software-Landschaft konsolidieren. URL: https://www.ssg-sachsen.de/de/projekte/ikz/veroeffentlichungen/ikz-in-einer-digitalisierten-welt-leitfaden/2024-09-10-ikz-leitfaden-interkommunale-zusammenarbeit-in-einer-digitalisierten-welt-final.pdf (zuletzt abgerufen am 29.07.2026).
Häufig entsprechen Export-Formate von (Fach-)Systemen nicht den erforderlichen Datenstandards. Stellt das System keine Ausleitungen gemäß erforderlichen Datenstandards zur Verfügung und lassen sich diese auch nicht nachrüsten, so müssen Daten nach der Ausleitung geeignet aufbereitet (in der Regel transformiert, gefiltert, oder angereichert) werden. Solche Transformationen sind teilweise “sehr komplex, könnten aber eine kurzfristige Lösung bieten und zur Rückwärtskompatibilität neuer Standards beitragen”.[32] Wie bereits erläutert, sind offene, standardisierte Schnittstellen zu bevorzugen, da diese den Datenaustausch deutlich vereinfachen. Für die Urban Data Platform[33] der Freien und Hansestadt Hamburg sowie die Datenplattform der Stadt Leipzig werden offene, standardisierte Schnittstellen als wichtiger Erfolgsfaktor benannt.[34]
3.5.3.1 Empfohlene Maßnahmen
- Prüfen Sie, ob es eventuell von übergeordneter Stelle regionale Unterstützungsangebote gibt, die Sie bei der Transformation unterstützen können. Im Datenkompass sind Datenart-spezifisch uns bekannte Unterstützungsangebote gelistet.
- Prüfen Sie, ob es für das ausgeleitete Format womöglich bereits existierende Werkzeuge zur Datenformat-Transformation gibt. Einige listet dieser Leitfaden in den Beschreibungen der Datenformate auf oder nennt Quellen zur Recherche. Auch im Forum (LINK) finden Sie eventuell Empfehlungen
- Falls noch kein geeignetes Transformationswerkzeug existiert, müssen sie womöglich selbst eine entsprechende Transformation umsetzen oder durch einen Dienstleister umsetzen lassen. Folgende Schritte sind dazu sinnvoll:
- Prüfen Sie, ob die aus dem System ausgeleiteten Daten vollständig und den im System vorliegenden Daten entsprechen.
- Definieren Sie für jeden Datensatz und jedes Attribut Abbildungsvorschriften /Mapping-Regeln, wie diese vom ausgeleiteten Quellformat in das gewünschte Zielformat zu transformieren sind.
- Dokumentieren Sie diese Abbildungsvorschriften.
- Falls Sie bei der Abbildung feststellen, dass nicht alle im Zielprofil verpflichtend erforderlichen Informationen vorhanden sind, prüfen Sie die Erweiterbarkeit des Systems. Eventuell sind die erforderlichen Daten auch aus anderen Systemen beziehbar und können angereichert werden.
- Erstellen Sie eine automatisierbare Transformation (z. B. als Skript oder über ein dediziertes Transformationswerkzeug).
- Prüfen Sie die Ergebnisse der Transformation mittels Validatoren auf Korrektheit und prüfen Sie, ob im Transformationsprozess keine relevanten Informationen ungewollt verloren gehen (siehe hierzu auch Validatoren).
Wenn Sie selbst Transformationen vornehmen möchten, sind verschiedene Ansätze möglich, die im Folgenden beschrieben werden.
3.5.3.1.1 Einstiegsmaßnahmen
Einfache Aufbereitungen lassen sich mitunter bereits mit Kommandozeilen-Werkzeugen oder einfachen Skripten umsetzen.[35] Stellen Sie hierbei jedoch sicher, dass die zur Aufbereitung genutzten Schnittstellen stabil sind, d. h. über einen längeren Zeitraum hinweg in ihrem Aufbau beibehalten werden.
3.5.3.1.2 Fortgeschrittene Maßnahmen
Wenn für viele Datenarten Transformationen durchgeführt werden müssen oder ein größerer Personenkreis Transformation definieren soll, ist die Verwendung von speziell hierfür ausgelegten Werkzeugen sinnvoll und der erforderliche Aufwand macht sich schnell bezahlt. Sogenannte "ETL"-Werkzeuge (ETL steht für Extract, Transform, Load) erlauben - in der Regel über eine Benutzeroberfläche - die Konfiguration von Daten-Workflows, bei denen Daten aus ein oder mehreren Quellen abgerufen, dann transformiert, angereichert oder gefiltert und anschließend in ein Zielsystem geladen werden können.
[32] Vgl. Eisenrauch et al. (2025). Data Governance für multi- & intermodale Mobilität: Einordnungen, Praxisbeispiele und Handlungsempfehlungen. Bitkom e.V., URL: https://www.bitkom.org/sites/main/files/2025-01/bitkom-leitfaden-data-governance-fuer-multi-und-intermodale-mobilitaet.pdf (zuletzt abgerufen am 29.07.2026).
[33] Vgl. Freie und Hansestadt Hamburg, Landesbetrieb Geoinformation und Vermessung (o. J.). Urban Data Platform Hamburg, URL: https://www.urbandataplatform.hamburg/ (zuletzt abgerufen am 29.07.2026).
[34] Vgl. Boedecker, M., Fischer, M., Drüssler, K. (2024). Daten aus der Stadt für die Stadt – kommunale Datenplattformen in München, Leipzig und Hamburg im Rahmen des Projekts CUT - Connected Urban Twins. Freie und Hansestadt Hamburg Senatskanzlei – Amt für IT und Digitalisierung (Hrsg.) URL https://www.connectedurbantwins.de/app/uploads/2025/09/Projektbericht.pdf (zuletzt abgerufen am 29.07.2026).
[35] Vgl. Dierstein et al. (2023). Handlungsleitfaden für Kommunen zur Erfassung von Mobilitätsdaten und Integration in die Mobilitätsdatenplattform MobiData BW®. URL: https://www.neckarsulm.de/site/Neckarsulm-2022/get/params_E-1666713953_Dattachment/1337632/MobiWert-Handlungsleitfaden_A4_interaktiv-rz.pdf&ved=2ahUKEwj_1c-NwfeVAxVDW_EDHf5eCzAQFnoECCQQAQ&usg=AOvVaw203TSvQwJvPXpvKHLckdC3 (zuletzt abgerufen am 29.07.2026). Sie berichten von einem Datenexport aus einer Datenbank über CSV-Datei in Kombination mit einem JSON Skript.
Stehen keine Möglichkeiten zur Verfügung, die Qualität eines Datensatzes automatisiert zu überprüfen, erfordert dies stets eine manuelle Begutachtung vor Datenbereitstellung. Von außen erkennbar ist dies, wenn Bereitstellungen zwar grundsätzlich in einem festen Turnus, z.B. wöchentlich, erfolgen, jedoch nicht an Feiertagen.
Auch eine solche manuelle Erfordernis zur Begutachtung verursacht Kosten und reduziert für Datenkonsumenten den Mehrwert der Daten, da sie nicht zeitnah zur Verfügung gestellt werden.
Ursache hierfür ist in der Regel, dass Qualitätsprüfungen noch nicht so vollständig automatisiert wurden, dass in sie volles Vertrauen gesetzt wird.
3.5.4.1 Empfohlene Maßnahmen
- Etablieren Sie eine Prozesskette, die automatisierte Prüfungen beinhaltet und die Datenbereitstellung abbricht, falls irreparable Probleme festgestellt werden.
- Manche Probleme lassen sich automatisiert behandeln, z.B. durch Entfernung korrupter Einträge aus dem Datensatz (Hinweis: wenn sie solche Fehlerbehandlungen durchführen, benennen Sie diese in den Metadaten zu diesem Datensatz und stellen Sie, sofern keine nicht zur Veröffentlichung gedachten Informationen darin enthalten sind, das Protokoll dieser Bereinigung zur Verfügung).
- Erwägen Sie, einen Datensatz in unterschiedlichen Veredelungsstufen bereitzustellen: die Rohdaten, welche ggfs. noch Fehler aufweisen und konsolidierte/veredelte/bereinigte Daten, welche bestimmte Qualitätskriterien erfüllen, jedoch womöglich nicht ganz vollständig sind, falls unplausible Einträge entfernt wurden.
- Wenn irreparable Probleme festgestellt werden, untersuchen Sie im Nachgang deren Ursache, und versuchen Sie, deren Auftreten bereits an der Quelle zu verhindern.
3.5.4.1.1 Einstiegsmaßnahmen
Der erste Schritt zur Automatisierung sind häufig kleine Skripte, die uhrzeitgesteuert ablaufen. Validatoren können aus solchen Skripten aufgerufen werden, bevor in Abhängigkeit des Ergebnisses der Prozess abgebrochen wird oder die nächsten Schritte durchgeführt werden. Ebenso lassen sich optional "Bereinigungsprogramme" aufrufen, die häufige Datenprobleme anhand bestimmter Regeln bereinigen. Stellen Sie sicher, dass Sie (bzw. eine zum Eingreifen befähigte Person/Gruppe) über Erfolg bzw. Fehlschlagen informiert werden, z.B. durch eine E-Mail oder durch Nachrichten an einen Messenger-Channel.
Warnung: Entsprechende Kenntnisse/Fähigkeiten vorausgesetzt, ist dieser Ansatz in der Regel schnell umsetzbar. Risiken bestehen darin, dass solche Maßnahmen häufig unzureichend dokumentiert werden und das Wissen um sie nur bei einzelnen Personen verbleibt.
3.5.4.1.2 Fortgeschrittene Maßnahmen
Kommunen mit mehr Erfahrung und Ressourcen adressieren die Herausforderung der automatisierten Bereitstellung durch "Orchestrierungs"-Plattformen oder spezielle ETL-Werkzeuge. Hier lassen sich Datenextraktion, -transformation, -validierung und -veröffentlichung entweder programmatisch oder per Konfiguration definieren. Solche Werkzeuge umfassen häufig hilfreiche Funktionen, die das Monitoring und Steuerung der Prozesse erleichtern.
Server, über die Daten nach außen veröffentlicht werden, befinden sich aus Sicherheitsgründen normalerweise in speziell abgesicherten Netzbereichen (sogenannten "demilitarisierten Zonen", DMZ), oder werden von anderen Organisationen betrieben.
Bei der Veröffentlichung muss daher sichergestellt werden, dass Daten aus den internen Systemen zu externen System übermittelt werden können. Hierzu sollten Sie mit ihrer IT-Abteilung geeignete Übermittlungswege und hierfür erforderliche Freischaltungen und Sicherungsmaßnahmen abstimmen. Der BSI-Grundschutzbaustein NET.1.1 Netzarchitektur und -design gibt hier wichtige Empfehlungen und nennt weiterführende Dokumente zum Themenfeld Netze.
Bei der Übermittlung an die Mobilithek sollte Insbesondere erwogen werden, bei der Publikation die Möglichkeit einer aktiven Datenübermittlung per Anlieferungsmethode “PUSH” zu nutzen. Nähere Informationen hierzu finden Sie in der Technischen Schnittstellenbeschreibung, die sie über den Download-Bereich der Mobilithek herunterladen können.
3.6 Datenqualität
Datenqualität umfasst viele Aspekte und hängt immer vom angestrebten Einsatzzweck der Daten ab. Daten sind qualitativ hochwertig, wenn sie für ihren vorgesehenen Gebrauch im operativen Geschäft, bei Entscheidungen und bei der Planung geeignet sind. Neue Anwendungsfälle, in denen Daten genutzt werden, bringen oft eine neue Perspektive und neue Anforderungen an die Daten mit sich. Datenqualität spielt somit eine tragende Rolle in den Phasen 4 Technische Aufbereitung und Qualitätsmanagement und 6 Monitoring und kontinuierliche Verbesserung des Vorgehensmodells zum Teilen von Mobilitätsdaten in Kommunen.
Typische Qualitätsprobleme in der Praxis
- veraltete Daten
- unvollständige Angaben
- inkonsistente Formate
- fehlende Aktualisierung
- unklare Zuständigkeiten
In der Konsequenz ist es entscheidend, sich bei der Bewertung und Erreichung von Datenqualität ihrer späteren Nutzung bewusst zu sein.
Bei der Bewertung der Datenqualität werden Daten hinsichtlich 6 verschiedener Qualitätsparameter (sogenannter Dimensionen) bewertet, die im Folgenden beschrieben werden. Der Mobilithek-Blog listet relevante Guidelines und Definitionen von Qualitätsparametern auf.[36] Im Folgenden wird verschiedentlich der NQDM-Leitfaden zitiert, der detaillierte Qualitätshinweise enthält.[37]
3.6.1.1 Aktualität
Die EU Delegierten-Verordnungen geben bezüglich der Aktualisierung der Daten vor, dass diese “zuverlässig und wirksam” verwendet werden können, soweit bekannt und möglich auch im Voraus (siehe Artikel 8 EU DelVO 2022/670, bzw.Artikel 6 EU DelVO 2017/1926, zuletzt geändert durch EU DelVO 2024/490)
Dazu sollten die Daten in regelmäßigen Intervallen in Hinblick auf ihre Aktualität überprüft werden. Das Aktualisierungsintervall sollte auch in den Metadaten Erwähnung finden, damit Datennutzende die Aktualität der Daten einschätzen können.
Es ist darauf zu achten, dass nicht nur die Daten selbst aktuell sind, sondern auch die entsprechenden Metadaten. Beispielsweise ist es für Datennutzende schwierig, Fragen oder Feedback zu den Daten zu stellen bzw. zu geben, wenn die Kontaktangaben in den Metadaten veraltet sind.
Darüber hinaus empfiehlt es sich, die folgenden Aspekte zu beherzigen:
- Über eine automatisierte Überwachung sollte sichergestellt werden, dass Daten auch innerhalb dem in den Metadaten angegebenen Aktualisierungsintervall aktualisiert werden (siehe Monitoring).
- Datenpflege- und Datenverarbeitungsprozesse sollten so organisiert werden, dass Änderungen der durch die Daten beschriebenen Sachverhalte in einem angemessenen Zeitraum veröffentlicht werden können.
- Der neueste Datensatz sollte – trotz Zeitstempel oder Versionsnummer im Ressourcennamen – unter einer gleichbleibenden Adresse abrufbar bleiben, damit konsumierende Systeme automatisch auf Aktualisierung prüfen und Verarbeitungsprozesse starten können.
3.6.1.2 Konformität
Bei der Bereitstellung von Daten und Metadaten sollten jeweils relevante Standards berücksichtigt werden (z.B. Datumsangabe nach ISO 8601). Die syntaktische und semantische Formatierung von einzelnen Datenfelder wird auch durch die relevanten Datenstandards (Link) vorgegeben.
Auch sollte auf Erwartungskonformität geachtet werden. Damit ist gemeint, dass das bereitgestellte Material dem entspricht, was von den Nutzenden erwartet wird, beispielsweise bei der Benennung von Attributen und Vokabeln.[38]
Im Bereich von Mobilitätsdaten sind domänenspezifische Standards die in den EU-Verordnungen vorgebebenen Standards DATEX II, NeTEx/SIRI und INSPIRE (siehe Datenstandards), aber auch in andere, wie GTFS, GBFS, MDS, OCPI, u.v.m. In den Steckbriefen werden datenartspezifisch weitere gebräuchliche Standards erwähnt.
Um die Konformität sicherzustellen, kommen sogenannte Validatoren bzw. Prüfprogramme zum Einsatz, welche Daten auf Einhaltung der Standards prüfen (siehe Validatoren zu Leitfaden-Kapitel 3.6.4 Validatoren).
3.6.1.3 Konsistenz
Daten und Metadaten sollten widerspruchsfrei sein, sowohl in sich selbst als auch Datensatz-übergreifend.
Ein Datensatz ist dann beispielsweise in sich konsistent, wenn das Erstellungsdatum vor der letzten Änderung liegt (zeitliche Konsistenz).
Hinweis: Werden Informationen aus verschiedenen Quellen zusammengefügt, ist besonders genau auf die Konsistenz der Daten und Metadaten zu achten, beispielsweise in Hinblick auf die Lizenz.[39]
Darüber hinaus sollten gleiche Sachverhalte in gleicher, konsistenter Weise beschrieben werden. Gerade bei den komplexen Standards DATEX II und NeTEx lassen sich Sachverhalte häufig auf verschiedene Weise ausdrücken. Zwischen Daten Veröffentlichenden und Nutzenden sollten einheitliche Beschreibungen definiert werden. Solche Profile sind für einige Datenarten über die Mobilithek abrufbar. Für andere Datenarten sind sie noch abzustimmen.
Für einige Datenarten prüfen Validatoren nicht nur die o.g. Konformität, sondern anhand von Plausibilitätskriterien und Prüfregeln auch die Konsistenz.
3.6.1.4 Vollständigkeit
Ein Datensatz sollte vollständig sein: Attribute, die zwingend für die Weiternutzung des Datensatzes erforderlich sind, müssen demnach einen Wert enthalten.
Vollständige Metadaten erleichtern die Auffindbarkeit und erleichtern es Nutzenden, sich schon früh ein detailliertes Bild bezüglich des bereitgestellten Materials zu bilden.
Hinweis: Die Unvollständigkeit eines Datensatzes stellt kein Hinderungsgrund für die Veröffentlichung dar. Beispielsweise können Daten, die einen Personenbezug oder Betriebs- oder Geschäftsgeheimnisse enthalten, hiervon bereinigt und anschließend veröffentlicht werden. Grundsätzlich gilt: Lieber unvollständige Daten veröffentlichen als gar keine. Hierbei ist jedoch zu beachten, dass die Unvollständigkeit der Daten gekennzeichnet werden muss.[40]
Neben Attributen sollte er auch alle erwarteten physischen Entitäten beinhalten. So sollte ein Datensatz zum Thema Straßensperrungen tatsächlich auch alle in den Metadaten angegebenen Region und Straßenklasse vorhandenen/geplanten Straßensperrungen beinhalten. Sollfahrplandaten für eine Region sollten alle ÖV-Angebote umfassen.
Während sich die Vollständigkeit auf Attributebene zumindest teilweise anhand von Prüfroutinen feststellen lässt, bedarf die Prüfung auf Vollständigkeit in der Regel den Abgleich mit Referenzdaten. In den Steckbriefen weist dieser Leitfaden auf mögliche Referenzdaten für die jeweiligen Datenkategorien hin.
3.6.1.5 Fehlerfreiheit
Die Daten und Metadaten sollten korrekte Werte beinhalten und möglichst fehlerfrei sein.
Hinweis: Beinhalten die Daten kleinere Fehler, ist dies zunächst kein Hinderungsgrund für die Veröffentlichung. Jedoch sollte auf die entsprechenden Fehler in den Metadaten hingewiesen werden.[41]
Während sich die Prüfung auf zulässige Werte automatisiert durch Validatoren prüfen lässt, ist die Feststellung inhaltlicher Fehler in der Regel schwierig.
Hierbei helfen Abgleiche mit Referenzdaten, wie sie dieser Leitfaden in den Steckbriefen bei vielen Datenarten beschreibt, aber auch die Einrichtung von Rückmelde-Kanälen (siehe Feedback-Kanäle), über die eventuelle Fehler von Dritten gemeldet werden können.
3.6.1.6 Zugänglichkeit und Verfügbarkeit
Die Ressourcen sollten leicht zugänglich sein. Dazu gehören eine einfache Auffindbarkeit, langlebige Verlinkungen und Referenzen sowie verständliche Beschreibungen des angebotenen Materials.
Hinweis: Um sogenannte „Broken Links“ zu vermeiden – also Links, die auf ein nicht mehr erreichbares Ziel verweisen (oftmals erscheint die Fehlermeldung 404 page not found) – empfiehlt es sich, einmal gesetzte URIs nicht mehr zu verändern. Sollte dies unmöglich sein, hilft ein sogenannter »Redirect«, Anfragen zur neuen Adresse weiterzuleiten.[42]
Darüber hinaus sollten Ressourcen nach Möglichkeit mit so geringen Zugangshürden wie möglich abrufbar sein. Idealerweise können sie ohne vorherige Registrierung abgerufen werden. Bitte beachten Sie, dass die Mobilithek verschiedene Mechanismen und Einstellungen zur Offenheit und Kontrolle von Datenangeboten anbietet.
Praxisbeispiel:
Der Schweizer NAP- die Open Data-Plattform Mobilität Schweiz - stellt Ressourcen ohne Registrierung zum Abruf bereit. Um Datenabrufende im Bedarfsfall dennoch kontaktieren zu können, verlangt das Portal beim Abruf die Übermittlung einer Kontakt-E-Mail als zusätzlich zu übermittelnden HTTP-Header.
Auch die Verwendung veralteter Datenformate kann die Zugänglichkeit reduzieren, da womöglich aktuelle Werkzeuge nicht rückwärtskompatibel mit früheren Formaten sind. Dies ist insbesondere bei Binärformaten problematisch, wenn z.B. binär kodierte DATEX II Nachrichten ein früheres DATEX II-Schema nutzen, für das aktuell keine Schema-Dateien mehr publiziert werden und der Schemagenerator lokal installiert werden miss und dies nur unter Windows möglich ist. Nutzen Sie daher, wo immer möglich, aktuelle Versionen der Datenstandards.
[36] Vgl. Mobilithek (2025). Leitfäden zur Datenqualität, URL: https://mobilithek.info/blog/leitfaeden-zur-datenqualitaet (zuletzt abgerufen am 29.07.2026). Grundlegende Überlegungen zum Thema Datenqualität finden sich zudem im Tagungsband zu einem BASt-Kolloquium aus dem Jahr 2011: Lotz, C.; Luks, M. (2011). Qualität von on-trip Verkehrsinformationen im Straßenverkehr, Berichte der Bundesanstalt für Straßenwesen, Heft F82, Bergisch-Gladbach, 2011. URL: https://www.bast.de/DE/Publikationen/BerichteBASt/Berichte/unterreihe-f/2011-2010/f82.html (zuletzt abgerufen am 29.07.2026).
[37] Vgl. Bruns, L., Dittwald, B., & Meiners, F. (2019). Leitfaden für qualitativ hochwertige Daten und Metadaten (NQDM – Normentwurf für qualitativ hochwertige Daten und Metadaten). Fraunhofer-Institut für Offene Kommunikationssysteme FOKUS. Berlin. URL: https://www.fokus.fraunhofer.de/de/dps/news/leitfaden_nqdm_2019.html (zuletzt abgerufen am 29.07.2026)
[38] Vgl. ebd.
[39] Vgl. ebd.
[40] Vgl. Leerkamp, B.; Kuchhäuser, J.; Puslat, S. (2023). Evaluation der Prozesskette der SEVAS-Daten des Landesprojekts ”Effiziente und stadtverträgliche LKW-Navigation für NRW“, S. 90. Sie betonen die Bedeutung vollständiger Metadaten - und auch von Profilen, welche die notwendigen Metadaten spezifizieren.
[41] Vgl. Bruns, L., Dittwald, B., & Meiners, F. (2019). Leitfaden für qualitativ hochwertige Daten und Metadaten (NQDM – Normentwurf für qualitativ hochwertige Daten und Metadaten). Fraunhofer-Institut für Offene Kommunikationssysteme FOKUS. Berlin. URL: https://www.fokus.fraunhofer.de/de/dps/news/leitfaden_nqdm_2019.html (zuletzt abgerufen am 29.07.2026).
[42] Vgl. ebd.
Die Sicherstellung der Datenqualität hinsichtlich der zuvor dargelegten Qualitätsdimensionen liegt wesentlich in der Verantwortung von Datengebenden. Aufgrund der Erfahrungen und etablierten Gute-Praxis-Ansätzen der im NAPCORE-Projekt vertretenen Betreiber der europäischen Zugangspunkte für Mobilitätsdaten, sollten Datengebende die folgenden Empfehlungen berücksichtigen (siehe Quality Framework Application Guideline Kapitel 3):
- vor einer Veröffentlichung Guidelines oder Handlungsempfehlungen ("Best Practices") wie NAPCORE Quality Frameworks oder das TISA5-Sterne Rating konsultieren
- Relevante Informationen zu Daten/Diensten und zur Datenqualität (über Metadaten) publizieren.
- Datenqualität analysieren und validieren, bevor sie auf der Mobilithek bereitgestellt wird. Solche Untersuchungen sollten regelmäßig, gegebenenfalls auch automatisiert, wiederholt werden (siehe dazu auch Methoden zur Bewertung von Datenqualität).
- für dynamische oder veränderliche Daten sicherstellen, dass sie regelmäßig gemäß der geeigneten und empfohlenen Zeitintervalle aktualisiert werden. Wird der Aktualisierungszyklus als periodicity in den Metadaten angegeben, so lassen sich zumindest die technische Aktualisierung automatisiert überwachen (siehe Monitoring)
- Für dynamische oder veränderliche Daten sollten aktuelle oder geplante Qualitätseinschränkungen, z.B. aufgrund temporärer Wartung, den Datenkonsumierenden rechtzeitig übermittelt werden.
- Daten in den durch die Delegierten EU-Verordnungen vorgegebenen Formaten (insbesondere DATEX II, NeTEx, SIRI, INSPIRE) veröffentlichen
- Daten-Konsumenten informieren und auf Rückmeldung von Daten-Konsumenten reagieren können (Siehe Feedback-Kanäle)
- Daten nach den Anforderungen den EU delegierten Verordnungen nach FAIR-Kriterien publizieren. Außerdem sollen die Anforderungen an Vollständigkeit und Rechtzeitigkeit erfüllt werden
- Nationale Stellen bei der Durchführung von Konformitäts-Bewertungen unterstützen und gefundene Probleme zeitnah korrigieren.
3.6.3.1 Überprüfung der Datenqualität in verschiedenen Stufen des Datenbereitstellungsprozesses
Auch wenn Datenqualitätsprobleme häufig erst durch Datennutzende festgestellt werden, also nachdem die Daten bereits veröffentlicht sind, entstehen Sie in der Regel bereits schon weitaus früher, z.B. bei der Datenerhebung, ihrer Aufbereitung oder Bereitstellung.
Um Probleme möglichst frühzeitig zu erkennen und auszuräumen, sollten daher in jeder Stufe der Datenverarbeitung auf mögliche Fehler geprüft und diese möglichst an der Quelle beseitigt werden. Die Methoden zur Qualitätsbewertung unterscheiden sich dabei in der Regel je nach Stufe.
Der nachfolgende Ansatz zur Qualitätsbewertung in verschiedenen Stufen der Datenerhebungs- und Bereitstellungsprozesses – ist dem NAPCORE Quality Framework Application Guideline[43] entnommen:
Stufe 1: Während der Datenerhebung
- Software-Qualitätsprüfung (z.B. Formate)
- Stichproben-Prüfungen
- Nutzenden-Feedback
Stufe 2: Während der Datenverarbeitung
- Software-Qualitätsprüfung (z.B. auf Integrität, Konsistenz, Plausibilität, Verfügbarkeit, Vollständigkeit)
- Inhaltliche Prüfungen (logische Prüfung), Stichproben-Prüfungen, Verarbeitbarkeit der Daten, Überwachung von Log-Ausgaben
- Referenz-Auswertungen
Stufe 3: Während Datenlieferung und -bereitstellung
- Schema-Validierung, Verfügbarkeit/Zugänglichkeit, Plausibilitäts- und Vollständigkeitsprüfung
- Nutzungsstatistiken von Diensten
Dieses und weitere Beispiele sind dokumentiert im NAPCORE MMTIS Quality Framework.
3.6.3.2 Verschiedene Fehlertypen und den Umgang damit definieren
Während der Datenverarbeitung und bei Qualitätsprüfungen können unterschiedliche Fehlerarten auftreten. Manche sind kritisch, andere hinnehmbar oder behandelbar. Je nach Schwere sollte eine angepasste Fehlerbehandlung erfolgen. Dies kann einen Abbruch der Verarbeitung bedeuten, eine nachträgliche Datenkorrektur, das Entfernen inkonsistenter Daten aus einem Datensatz oder schlicht das Akzeptieren und Dokumentieren entsprechender Warnungen. (nach NAPCORE Quality Framework Application Guideline, Kapitel 4.2)
Häufig verwenden Organisationen für solche Qualitätsprüfungen und sich aus deren Ergebnissen ergebenden Vorgehensentscheidungen den Begriff "Quality-Gate". Dieser impliziert eine Schranke, welche sich beim Auftreten von Problemen schließt, so dass sich diese nicht im weiteren Verlauf der Prozesskette fortpflanzen.
Mitunter scheitern Organisationen jedoch daran, solche Quality-Gates "scharf" zu schalten, da die schiere Menge an Problemen nicht kurzfristig beseitigt werden kann und stattdessen lieber hingenommen wird.
In solchen Fällen sollte geprüft werden, ob Abbruchkriterien nicht sukzessive verschärft werden können, z.B. durch regelmäßig angepasste Schwellwerte, die zumindest bereits erreichte Qualitätslevel absichern.
Die Definition kritischer Fehlertypen und der automatisierten Prüfbarkeit ist auch zwingende Voraussetzung für eine Automatisierung von Datenbereitstellungsprozessen und sollte daher unbedingt angestrebt werden.
3.6.3.3 Definieren, was geprüft wird und dies dokumentieren
Wenn Qualitätsprüfungen vorgenommen werden, sollte diese dokumentiert werden. Dies umfasst nicht nur die reinen Prüfergebnisse, sondern auch Kontext- und Hintergrundinformationen. Insbesondere sollten die Prüfungen in den Metadaten eines Datensatzes beschrieben werden. Hierzu eignet sich das Metadaten-Feld "Quality Description" des mobilityDCAT-AP-Standards, der von NAPs und Mobilitätsdatenportalen genutzt wird (nach NAPCORE Quality Framework Application Guideline, Kapitel 4.3 und 4.4)
Prüfergebnisse sollte nach Möglichkeit ebenfalls in maschinenlesbarer Form veröffentlicht werden. Dies ermöglicht Datenkonsumierenden, selbst eine geeignete Reaktion auf Abweichungen festzulegen.
Darüber hinaus macht NAPCORE Quality Framework Application Guideline, Kapitel 4.3 und 4.4 einen Vorschlag für ein mit Datensätzen ausgeliefertes "Quality Statement". Wird eine solche Qualitätsaussage mit einem Datensatz ausgeliefert, sollte jedoch sichergestellt sein, dass seine Erstellung bzw. Aktualisierung automatisiert erfolgen kann, um nicht die Häufigkeit und Aktualität einer Datenveröffentlichung einzuschränken, weil z.B. erst eine manuelle Freigabe erfolgen muss.
3.6.3.4 Mögliche Methoden zur Qualitätsbewertung
Die Handreichung NAPCORE Quality Framework Application Guideline gibt in Kapitel 5 einen Überblick über übliche Methoden zur Qualitätsbewertung. Zu jeder der folgenden Methode sind dort in einer strukturierten Übersicht Methodenbeschreibung, Anwendungsbereiche, Voraussetzungen und Beispiele beschrieben:
- Gegenprüfung oder Referenzprüfung (Cross-Check or reference-check analysis)
- Logische und syntaktische Überprüfung (Logical and syntactic validation), siehe dazu auch Validatoren
- Visuelle Prüfung (Visual Check)
- Feedback von Datennutzenden bzw.-konsumierenden (Data user/consumer feedback) (siehe dazu auch Feedback-Kanäle)
- Gründliche Metadaten-Evaluierung (In-Depth Metadata Evaluation)
- Selbst-Evaluierung (Self evaluation)
- Kontextbezogene Nutzung einer zusätzlichen Datenquelle (Contextual use of an additional data source)
In den Datensteckbriefen werden datenart-spezifischen Beispiele für solche konkreten Bewertungsmethoden aufgeführt.
[43] Vgl. Lubrich, P.; Ariño-Montoya, D.; Founta, A.; Mylonas, C. (2025). Quality Framework Application Guideline. Report by Task 3.2: European NAPs Data Quality, NAPCORE Milestone M3.9, Version 1.0, 16. Mai 2025, URL: https://napcore.eu/quality/ (zuletzt abgerufen am 27.07.2026).
Um valide, also gültig zu sein, muss ein Datensatz, der in einem bestimmten Datenstandard veröffentlicht wird, die Vorgaben dieses Standards erfüllen. Die strukturelle Konformität zu diesen Standards lassen sich über sogenannte Schema-Validatoren prüfen. Darüber hinaus können domänenspezifische Validatoren, wie die unter Awesome NAPCORE empfohlenen, weitere Korrektheitsbedingungen und Plausibilitätsprüfungen durchführen.
3.6.4.1 Schema-Validatoren
Für die durch EU-Verordnungen vorgeschriebenen Datenstandards NeTEx/SIRI, DATEX II und die INSPIRE Datenspezifikationen existieren XML-Schemata bzw. für SIRI-Lite und DATEX II (seit DATEX II Version 3) auch JSON-Schemata. Sie legen fest, wie ein gültiger Datensatz aufgebaut ist und können zur Prüfung der strukturellen Konformität genutzt werden.
3.6.4.1.1 XML-Validatoren
Es existieren eine Reihe von Online-Validatoren und kommerzielle XML-Editoren, welche häufig sehr komfortable Unterstützung für die Validierung von XML-Dokumenten umfassen.
Eine allgemeine Einführung und gute Empfehlungen auch zur Validierung von XML-Dateien gibt der Normentwurf für qualitativ hochwertige Daten und Metadaten.
Für automatisierte Prüfungen z.B. im Rahmen einer Datenaufbereitungs-Pipeline sind Validierungs-Bibliotheken, die für unterschiedliche Programmiersprachen verfügbar sind, und entweder in Programme oder über Script-Aufrufe einbindbar sind, sinnvoll.
Beispielhafter XML-Validator xmllint
xmllint ist ein auf Linux-Systemen verfügbares, kommandozeilenbasiertes Werkzeug zur Formatierung und Validierung von XML-Daten. Mit ihm lässt sich manuell die Konformität eines XML-Datensatzes zu einem Schema prüfen:
$ xmllint --schema schema/DATEXII_3_Profile/DATEXII_3_D2Payload.xsd --noout sitationpublication.xml sitationpublication.xml validates3.6.4.1.2 JSON-Validatoren
Für SIRI und seit Version 3 auch für DATEX II ist als Alternative zu XML auch eine Veröffentlichung im JSON-Format möglich. Entsprechende JSON-Schemata ermöglichen eine Validierung auch dieser Publikationen. Auch wenn Sie eigene Datensätze im JSON-Format veröffentlichen, sollten Sie ein beschreibendes JSON-Schema für diese bereitstellen und die Publikation gegen dieses Schema validieren.
Eine allgemeine Einführung und gute Empfehlungen auch zur Validierung von JSON und den speziell für Geodaten gebräuchlichen GeoJSON-Format gibt der Normentwurf für qualitativ hochwertige Daten und Metadaten.
Hinweis: das DATEX II-JSON-Schema nutzt die JSON-Schema Version 2020-12, die noch nicht von allen Validatoren unterstützt wird.
Hinweis: Die Validierung von Datensätzen benötigt, je nach Validierungswerkzeug, mitunter mehrere Sekunden bis Minuten und ist daher für die Veröffentlichung von Echtzeitdaten als fester Baustein einer Verarbeitungspipeline womöglich inakzeptabel. Dennoch sollte in regelmäßigen Abständen, am besten automatisiert, die Veröffentlichung gegen das Schema validiert werden.
Beispielhafter JSON-Validator check-jsonschema
check-jsonschema ist ein in Python implementiertes kommandozeilenbasiertes Werkzeug zur Validierung von JSON-Daten. Mit ihm lässt sich manuell die Konformität eines JSON-Datensatzes zu einem Schema prüfen:
$ check-jsonschema --schemafile schema/DATEXII_3_D2Payload.json sitationpublication.json ok -- validation done3.6.4.1.3 CSV-Validatoren
Derzeit basiert kein in den EU-Verordnungen gefordertes Datenformat auf dem CSV-Standard. Dennoch kann es sinnvoll sein, Mobilitätsdaten als CSV-Dateien bereitzustellen, z.B. um sie einem Datenmittelnde zur Verfügung zu stellen, der sie entsprechend der in EU-Verordnungen geforderten Datenformate aufbereitet.
Zur Datenqualität von CSV-Daten gibt der Leitfaden Normentwurf für qualitativ hochwertige Daten und Metadaten im Unterkapitel CSV des Kapitels 7 "Datenformatspezifische Qualitätsmerkmale und Handlungsempfehlungen" ausführliche Informationen zu Aufbau und Struktur.
Mittels CSV-Validatoren wie z.B. cvslint oder dessen Online-Angebot csvlint.io des britischen Open Data Institutes lassen sich CSV-Dateien auf strukturelle Konformität prüfen.
CSV-Validatoren können auch fehlende Werte oder Werte mit falschem Typ feststellen, wenn zu dem Datensatz auch eine geeignete Schema-Beschreibung z.B. im JSON Table Schema oder CSV on the Web existiert.
3.6.4.2 Regelbasierte Validatoren
Über rein strukturelle Prüfungen hinaus, wie sie mit Schema-Validatoren möglich sind, ermöglichen regelbasierte Validatoren die Prüfung fachlicher Vorgaben.
3.6.4.2.1 XML-Validierung via Schematron
Schematron ist eine ISO-standardisierte, regelbasierte Sprache zur inhaltlichen Validierung von XML-Dokumenten. Schematron geht über rein strukturelle Prüfungen mittels XML-Schema hinaus.
Mit Schematron lassen sich Regeln formulieren wie z.B.
- Wenn Element A existiert, so muss auch Element B existieren
- Ein Datum X muss vor einem Datum Y liegen
- Wenn Feld U den Wert V hat, darf Feld W nicht Wert X haben
Für Schematron existieren verschiedene OpenSource- oder kommerzielle Programme, die XML-Daten mittels Schematron-Regeln auf Gültigkeit prüfen können
Beispielhafter Schematron-Validator pyschematron
pyschematron ist ein in Python implementierter, OpenSource-Schematron-Validator. Er kann als Kommandozeilen-Werkzeug genutzt oder als Bibliothek in eigene Anwendungen eingebaut werden. Mit ihm lässt sich z.B. eine NeTEx-Datei auf Einhaltung bestimmter Profil-Regeln prüfen. Im nachfolgenden Beispiel werden z.B. zwei verpflichtende Vorgaben des europäischen NeTEx-Profils EPIAP (CEN/TS 16614-6:2024) validiert:
Schematron-Datei epiap-schematron.xml mit beispielhaften Prüfregeln:
<schema xmlns="http://purl.oclc.org/dsdl/schematron" queryBinding="xslt3"><title>NeTEx EPIAP Schematron Validierung</title><!-- Namespaces des zu validierenden Dokuments müssen explizit deklariert werden --><ns prefix="netex" uri="http://www.netex.org.uk/netex"/><pattern id="stopplace-rules"><!-- Achtung: innerhalb eines patterns wird nur die erste auf ein Elementanwendbare rule ausgewertet. --><rule context="netex:StopPlace"><assert test="netex:AccessibilityAssessment">StopPlace muss AccessibilityAssessment haben (6.5 EPIAP mandatory minimal profile)</assert><assert test="netex:AccessibilityAssessment/netex:limitations/netex:AccessibilityLimitation">StopPlace AccessibilityAssessment muss AccessibilityLimitation haben (6.5 EPIAP mandatory minimal profile)</assert><!-- Weitere Regeln --></rule><!-- Weitere Regeln --></pattern><!-- Weitere Regeln --></schema>Diese kann dann wie folgt zur Prüfung angewendet werden:
$ pyschematron --svrl-out results.txt data/openstation_example.xml epiap-schematron.xmlok -- validation done3.6.4.2.2 Metadaten-Validierung via SHACL
Metadaten sollten, ebenso wie die durch sie beschriebenen Daten, korrekt und umfassend sein.
Gerade wenn eine Organisation selbst ein Portal zum Datenabruf betreibt, und nicht die Bereitstellungsfunktionen eines übergeordneten Datenportals z.B. des Bundeslandes oder der Mobilithek nutzt, sollten die Metadaten auch auf Korrektheit und Vollständigkeit geprüft werden.
Metadaten werden meist in den Auszeichnungssprachen Resource Descriptor Framework (RDF), turtle oder dem auf JSON beruhenden JSON-LD Format bereitgestellt, welches sich über in der Shapes Constraint Language (SHACL) formulierte Regeln validieren lässt.
Beispielhafte Metadaten-Validierung mit mobilityDCAT-AP SHACL Validation
Für den speziell für Mobilitätsdaten erweiterten Metadaten-Standard mobilityDCAT-AP kann hierzu der regelbasierte Validator mobilityDCAT-AP SHACL Validation:
% uv run scripts/validate.py --data meine_metadaten.ttl -vLoading SHACL shapes...✓ Loaded 2 SHACL file(s)✓ PASS meine_metadaten.ttl3.6.4.3 Domänen-spezifische Validatoren
Zusätzlich zu generischen Schema-Validatoren erlauben domänenspezfische Validatoren auch die Berücksichtigung fachlicher, auf die jeweilige Datenart bezogene Regeln und/oder Heuristiken. Für die im Rahmen der europäischen IVS-Richtlinie relevanten Datenformate führt das NAPCORE-Projekt die Liste Awesome NAPCORE Tools Catalog, die auch domänenspezifische Validatoren listet.
3.6.4.3.1 DATEX II-Validatoren
Spezielle Validatoren für DATEX II sind derzeit noch nicht verbreitet. Im Rahmen des NAPCORE-X-Projekts entsteht unter der Seite Awesome NAPCORE Tools Catalog eine Sammlung von Werkzeugen, auch für die Verarbeitung und Prüfung von DATEX II-Daten, über die voraussichtlich in den nächsten Monaten geeignete Werkzeuge zu finden sein werden.
In den Steckbriefen zu den Datenarten sind im jeweiligen Abschnitt Qualitätskriterien Aspekte genannt, die bei der Umsetzung eigener regelbasierter Validatoren als Anregung dienen können.
3.6.4.3.2 DATEX II-Profil-Validatoren
Zur Validierung von DATEX II-Profilen (als aus dem DATEX II-Schema abgeleitete bzw. erweiterte XML-Schemata) können mit dem DATEX II RAV Testcenter auf Gültigkeit geprüft werden. Derzeit sind ausschließlich DATEX II Profile für den Austausch statischer Daten zu sicherem LKW-Parken validierbar.
3.6.4.3.3 NeTEx-Validatoren
Spezielle Validatoren für NeTEx existieren derzeit vor allem für Profile anderer EU-Staaten.
Der NeTEx-Validator-Java der norwegischen ENTUR validiert NeTEx-Publikationen und prüft in der aktuellen Implementierung auf die Einhaltung der im Nordischen NeTEx Profil getroffenen Festlegungen. Er wird derzeit vor allem durch ENTUR selbst in der Validierungskomponente Antu in der Datenaufbereitung für ENTURs Auskunftssysteme genutzt.
Der kürzlich veröffentlichte NeTEx Validator Validator scheint ein KI-gestützte Re-Implementierung von ENTURs NeTEx-Validator-Java in der Programmiersprache Rust zu sein. Er weist derzeit noch eine Reihe von Fehlern auf und ist zur produktiven Nutzung noch nicht geeignet.
Das seinerzeit im Rahmen des DATA4PT-Projekts entwickelte greenlight-Validator scheint derzeit nicht weiterentwickelt zu werden.
Im Rahmen des NAPCORE-X-Projekts entsteht unter der Seite Awesome NAPCORE Tools Catalog eine Sammlung von Werkzeugen, auch für die Verarbeitung und Prüfung von NeTEx und SIR-Daten, über die voraussichtlich in den nächsten Monaten geeignete Werkzeuge zu finden sein werden. Die seinerzeit im Rahmen des data4pt-Projekts veröffentlichte Validatoren-Liste wird leider nicht mehr gepflegt.
In den Steckbriefen zu den Datenarten sind im jeweiligen Abschnitt Qualitätskriterien Aspekte genannt, die bei der Umsetzung eigener regelbasierter Validatoren als Anregung dienen können.
3.6.4.3.4 GTFS-Validatoren
Auch wenn das GTFS-Format nicht als geeigneter Datenstandard in der MMTIS-Verordnung vorgegeben ist, können GTFS-Validatoren sinnvoll sein. Häufig werden parallel zu NeTEx-Veröffentlichungen auch ihnen mehr oder weniger entsprechende GTFS-Veröffentlichungen angeboten. Gerade aufgrund der im Abschnitt NeTEx-Validatoren beschriebenen Mangel an NeTEx Validatoren lohnt für inhaltliche Prüfungen der Einsatz von GTFS-Validatoren.
GTFS-Validatoren prüfen in der Regel nicht nur strukturelle Aspekte wie Existenz der geforderten Dateien und Attribute dieser, sondern auch inhaltliche Konsistenz und Plausibilitätskriterien. Vielfach gehen diese Prüfungen über die heute in NeTEx-basierten Validierungswerkzeugen umgesetzten hinaus, so dass für inhaltliche Prüfungen auch GTFS-Validatoren sinnvoll sind.
Über rein strukturelle Prüfungen hinausgehende Plausibilitätstests, die in vielen Validatoren umgesetzt sind, sind beispielsweise:
- Aufeinanderfolgende Halte von Linienverkehren, bei denen Distanz und zeitlicher Abstand eine für das Verkehrsmittel unrealistische Geschwindigkeit erfordern
- Fußwege, deren Distanz in der angegebenen Dauer eine höhere Geschwindigkeit als realistische Gehgeschwindigkeit erfordern
- Mutmaßliche Duplikate
Eine Liste von GTFS-Validatoren wird durch die den GTFS-Standard pflegende Organisation MobilityData bereitgestellt.
3.6.4.3.5 SIRI-Validatoren
Spezielle Validatoren für den SIRI-Datenstandard für ÖPNV-Echtzeitdaten existieren derzeit vor allem für das für Norwegen definierte nordische Profil. ENTURs Validierungs-Bibliothek Anshar prüft neben Schema-Konformität auch verschiedene Profil-spezifische Regeln.
Darüber hinaus protokollieren in der Regel SIRI-Daten verarbeitende Systeme wie z.B. die OpenSource-Routenplaner OpenTripPlanner und MOTIS bei der Verarbeitung von SIRI-Daten auftretende Fehler.
3.7 Lizenzen
Für die Bereitstellung von Mobilitätsdaten ist die Wahl einer geeigneten Lizenz von zentraler Bedeutung. Sie legt fest, unter welchen Bedingungen Daten genutzt, weiterverarbeitet und verbreitet werden dürfen und schafft damit Rechtssicherheit für Datenbereitstellende und -nutzende gleichermaßen.
Im Bereich offener Daten haben sich verschiedene Lizenzmodelle etabliert. In Deutschland kommt insbesondere die Datenlizenz Deutschland zum Einsatz, während international häufig Creative-Commons-Lizenzen verwendet werden. Darüber hinaus existieren spezialisierte Lizenzmodelle wie die Open Database License (ODbL), die insbesondere für Datenbanken entwickelt wurde. Diese erlaubt grundsätzlich eine freie Nutzung, Veränderung und Weitergabe von Daten, enthält jedoch eine sogenannte Share-Alike-Klausel, nach der abgeleitete Datenbanken unter denselben Bedingungen weitergegeben werden müssen.
Eine besondere praktische Relevanz ergibt sich daraus bei der Nutzung von Daten aus OpenStreetMap (OSM), die unter der ODbL lizenziert sind. Werden solche Daten mit eigenen Datenbeständen kombiniert, kann dies dazu führen, dass auch daraus abgeleitete Datenbanken unter die ODbL fallen. Kommunen sollten daher frühzeitig prüfen, ob und in welchem Umfang Lizenzpflichten auf eigene Daten übergehen.[44]
Im Kern lassen sich für die Bereitstellung von Mobilitätsdaten folgende Lizenzansätze unterscheiden: Creative Commons (CC): Creative Commons ist eine US-amerikanische NGO, die eine Familie von Standard-Lizenzverträgen entwickelt und veröffentlicht hat, die international weit verbreitet ist. Für Open Data relevant sind folgende Lizenzen:
- CC0 (Zero): Die „freieste“ Lizenz ohne Bedingungen; sie wird z. B. von Open.NRW für maximale Nachnutzbarkeit empfohlen.
- CC BY 4.0 (Namensnennung): Nutzende müssen die Quelle nennen. Dies ist die offizielle Empfehlung für das Open-Data-Portal Schleswig-Holstein.[45]
- CC BY-SA (Share Alike): Verpflichtet zur Weitergabe unter gleichen Bedingungen, dies erschwert es Unternehmen, auf Basis der offenen Daten beispielsweise durch Kombination und Veredelung ein Geschäftsmodell aufzubauen.
- Datenlizenz Deutschland (dl-de), Version 2.0 (Zero/Namensnennung): Ein speziell für die deutsche Verwaltung entwickeltes Modell.
Auch wenn die Datenlizenz Deutschland speziell für die deutsche Verwaltung entwickelt wurde, ist vor dem Hintergrund der Intention des Rechtsrahmens im Bereich der Mobilitätsdaten, namentlich die europäische Integration dadurch voranzubringen, dass Reisendeninformation und andere Dienste grenzübergreifend möglich gemacht werden, bevorzugt die Verwendung von CC0 und hilfsweise von CC BY 4.0 zu empfehlen (siehe hierzu auch Rechtsgutachten zu CC-Lizenzen der Wikimedia Foundation). Die Durchführungsverordnung „zur Festlegung bestimmter hochwertiger Datensätze und der Modalitäten ihrer Veröffentlichung und Weiterverwendung“ vom 21.12.2022 nennt hierzu folgendes: „In den Leitlinien der Kommission für empfohlene Standardlizenzen, Datensätze und Gebühren für die Weiterverwendung von Dokumenten werden Creative-Commons-Lizenzen (CC-Lizenzen) als Beispiel für empfohlene öffentliche Standardlizenz. […] CC-Lizenzen werden von einer Organisation ohne Erwerbszweck entwickelt und sind weltweit zu einer führenden Lizenzierungslösung für Informationen, Forschungsergebnisse und kulturelles Material des öffentlichen Sektors geworden. Daher sollte in dieser Durchführungsverordnung auf die neueste Fassung des CC-Lizenzpakets, nämlich CC 4.0, verwiesen werden.“[46]
Typische Lizenzentscheidungen in der Praxis
- offene Lizenz (dl-de / CC0) als Standard
- Einschränkungen bei sensiblen Daten
- Klärung bei Kombination mit Drittquellen (z. B. OSM)
Werden Lizenzen mit Namensnennung genutzt, sollten zu lange Namensbezeichnungen vermieden werden und, insbesondere für statische Daten, sichergestellt werden, dass sie Bestandteil anderer Kartenwerke sein können und hierfür eine Nennung auf einer eigenen Unterseite, im Falle von OpenStreetMap zum Beispiel der Liste von Mitwirkenden, ausreichend ist. Dies kann z.B. über ein explizites Addendum zur Lizenz geschehen (siehe z.B. die Addendum-Vorschläge von OpenStreetMap).
[44] Vgl. Ministerium für Wirtschaft, Innovation, Digitalisierung und Energie des Landes Nordrhein-Westfalen (Hrsg., 2019). Datenlizenzen für Open Government Data. Rechtliches Kurzgutachten. Handreichung zu den Nutzungsrechteregelungen gebräuchlicher Open-Data-Lizenzen und Empfehlungen für ihren Einsatz, erstellt im Auftrag durch die PricewaterhouseCoopers Aktiengesellschaft Rechtsanwaltsgesellschaft, insbesondere S. 8-27, URL: https://open.nrw/system/files/media/document/file/opennrw_rechtl_gutachten_datenlizenzen_lowres_web.pdf (zuletzt abgerufen am 28.07.2026).
[45] Vgl. Land Schleswig-Holstein (2023). Open-Data-Leitfaden Schleswig-Holstein. URL: https://opendata.schleswig-holstein.de/leitfaden/leitfaden-opendata.pdf (zuletzt abgerufen am 28.07.2026)
[46] Vgl. Europäische Kommission (2023). Durchführungsverordnung (EU) 2023/138 der Kommission vom 21. Dezember 2022 zur Festlegung bestimmter hochwertiger Datensätze und der Modalitäten ihrer Veröffentlichung und Weiterverwendung, Amtsblatt der Europäischen Union, L 19 vom 20. Januar 2023, S. 43–75, URL: https://eur-lex.europa.eu/legal-content/DE/ALL/?uri=CELEX:32023R0138 (zuletzt abgerufen am 29.07.2026).
3.8 Prozess
Um Mobilitätsdaten zu teilen, sind verschiedene Schritte zur Vorbereitung und in der Durchführung notwendig. Diese sind in Kapitel Grünes Licht einholen erläutert, im Folgenden wird auf ausgewählte Aspekte etwas detaillierter eingegangen. Diese können alle als Aspekte der sog. Data Governance als Organisation eines verwaltungs- und fachbereichsübergreifend gesteuerten Datenflusses, der von der Erhebung über die Speicherung bis hin zur Verwendung in Anwendungsfällen und Prozessen reicht, verstanden werden:[47], [48], [49]
- Die organisatorische Verankerung des Themas Datenteilen in der Verwaltung, um sicherzustellen, dass es eine Stelle gibt, die sich für das Thema verantwortlich fühlt und es vorantreibt.
- Die Dateninventur als wichtiger Schritt, um sich einen Überblick über die an verschiedenen Stellen in einer Kommune bzw. kommunalen Unternehmen vorhandenen Daten zu verschaffen,
- Die verschiedenen technischen Möglichkeiten der Datenbereitstellung,
- Feedback-Kanäle als Rückkanal, der Hinweise auf Probleme mit der Datenqualität oder gewünschte (bzw. benötigte) zusätzliche Datenangebote geben kann, sowie
- Monitoring als weitgehend automatisierte Überwachung der Datenbereitstellung.
Für das Verständnis dieser Aspekte hilft es die im folgenden Kasten erläuterten typischen Rollen beim Umgang mit Mobilitätsdaten zu kennen.
Typische Rollen beim Umgang mit Mobilitätsdaten
Organisationale Rollen (Verwaltungspraxis)
- Fachabteilungen: erzeugen und pflegen die Daten (z. B. Baustellen, Verkehrsregelungen)
- Zentrale Koordination: bündelt Aktivitäten, definiert Standards und sorgt für Abstimmung
- IT / Datenmanagement: stellt Infrastruktur, Schnittstellen und Qualitätssicherung bereit
- Leitungsebene: setzt strategische Ziele und priorisiert Ressourcen
- Externe Partner: z. B. Verkehrsunternehmen oder Plattformbetreibende
Data-Governance-Rollen (Datenmanagement)
- Data Owner (fachlich verantwortliche Stelle): trägt die Gesamtverantwortung für einen Datensatz und entscheidet über dessen Nutzung und Bereitstellung
- Data Steward (operativ datenverantwortliche Stelle): sorgt für Qualität, Pflege, Dokumentation und Einhaltung von Standards im laufenden Betrieb
- Data Custodian (technisch verantwortliche Stelle): verantwortet die technische Speicherung, Verarbeitung und Bereitstellung der Daten
[47] Vgl. Bitkom e. V. (2025). Data Governance für multi- & intermodale Mobilität. Einordnungen, Praxisbeispiele und Handlungsempfehlungen, Berlin, URL: https://www.bitkom.org/sites/main/files/2025-01/bitkom-leitfaden-data-governance-fuer-multi-und-intermodale-mobilitaet.pdf (zuletzt abgerufen am 29.07.2026).
[48] Vgl. BBSR (2022). Die digitale Stadt gestalten. URL: https://doi.org/10.58007/3nzk-wh57 (zuletzt abgerufen am 29.07.2026).
[49] Vgl. National Academies of Sciences, Engineering, and Medicine (2024). Implementing Data Governance at Transportation Agencies: Volume 1: Implementation Guide. Washington, DC: The National Academies Press. URL: https://doi.org/10.17226/28837 (zuletzt abgerufen am 29.07.2026).
Wie in Phase 1 des Vorgehensmodells beschrieben, müssen die strategischen Ziele des Datenteilens für die Kommune geklärt werden. Dies alleine reicht aber noch nicht aus, um erfolgreich zu sein. Die praktische Durchführung der entsprechenden Projekte benötigt die Definition von Verantwortlichkeiten sowie die kontinuierliche Unterstützung durch die Leitungsebene
- Sicherstellen und Kommunizieren des Commitments: Das Teilen und ggf. Digitalisieren von Mobilitätsdaten muss von der Verwaltungsspitze als wichtig und chancenreich begriffen werden, um notwendige Ressourcen und Mandate für die Umsetzung zu sichern. Diese Unterstützung muss dauerhaft gesichert (z.B. durch regelmäßige Statusmeetings) und nach innen wie außen kommuniziert werden, so dass die Bedeutung sowohl innerhalb der Verwaltung als auch in der Bürgerschaft kontinuierlich verdeutlicht wird.
- Bestimmung der Rollen: In größeren Kommunen sollte ein Data-Governance-Manager oder ein Chief Digital Officer (CDO) benannt werden, der die zentrale Koordination übernimmt und als Schnittstelle zwischen Fachbereichen und IT fungiert. In kleineren Kommunen können diese Aufgaben ggf. bei Personen gebündelt werden, die in ähnlichen Bereichen bereits Aufgaben tragen, wie beispielsweise Datenschutzverantwortlichen, GIS-Beauftragten o.ä. Zudem sind für die verschiedenen Datenarten die o.g. Rollen Data Owner, Data Steward und Data Custodian zu definieren und dokumentieren.
- Vernetzung von Akteuren: Relevante Akteure innerhalb der Verwaltung (z.B. Stadtplanung, Tiefbauamt), in Eigenbetrieben (z.B. Stadtwerke/städtischer Verkehrsbetrieb) sowie externe Partner (Software-Dienstleistende, Mobilitätsanbietende) sollten möglichst frühzeitig eingebunden werden. Dies hat mehrere Gründe:
- Erstens kann durch die frühzeitige Einbindung unterschiedlicher Akteure innerhalb der Verwaltung eine Akzeptanz für die Maßnahmen, aber auch den damit verbundenen Kulturwandel geschaffen werden.
- Zweitens können Datensilos nur abteilungs- bzw. ämterübergreifend aufgebrochen und die in Phase 2 notwendige Dateninventur durchgeführt werden.
- Drittens können so Ressourcen und Expertise gebündelt werden, welche insbesondere in kleineren Kommunen häufig fehlen.
- Viertens sind rechtlich Expertise und die Einbindung der Datenschutzbeauftragten unbedingt notwendig, um sich abzusichern.
- Zudem kann durch eine frühzeitige Vernetzung zwischen Fachabteilungen, IT und Vergabestellen sichergestellt werden, dass neue Systeme nach dem Prinzip „Open by Design“ beschafft werden, also über offene Schnittstellen und maschinenlesbare Formate verfügen. Dies verhindert einen späteren „Vendor-Lock-in“ und stellt die Datenhoheit der Kommune sicher. Beispiele für Textbausteine, die in Vergabeverfahren genutzt werden können, finden sich in diesem Leitfaden im Abschnitt Bausteine für Ausschreibungen.
Die Durchführung einer systematischen Dateninventur (auch als Datenmonitoring oder Erfassung des Status quo bezeichnet) bildet die operative Grundlage für jedes datenbasierte Handeln in einer Kommune. Ihr Ziel ist es, eine umfassende Übersicht über vorhandene Datensätze, deren Speicherorte, Formate und die damit verbundenen Verantwortlichkeiten zu erhalten. Der Leitfaden bietet eine Arbeitshilfe zur Dateninventur an.
3.8.2.1 Methodisches Vorgehen (Datenscreening)
Zur Identifizierung relevanter Datensätze sollten Kommunen eine Verschränkung aus drei Screening-Perspektiven anwenden:[50]
- Selbst-Screening (Innensicht): Hierbei wird in der eigenen Verwaltung geprüft, welche Informationen bereits digital vorliegen oder bereits veröffentlicht werden (z. B. Statistiken, Berichte, Fachanwendungen). Ein besonderes Augenmerk liegt auf Dokumenten mit Tabellen, da deren zugrunde liegende Rohdaten oft wertvolle Potenziale für das Datenteilen bieten. Von MobiData BW beispielsweise wurde eine übersichtliche Checkliste publiziert, die hierbei unterstützen kann.[51]
- Fremd-Screening (Referenzsicht): Hier orientiert sich die Kommune an bereits veröffentlichten Datensätzen anderer Städte (z.B. auf der Mobilithek oder in Datenportalen wie www.govdata.de) oder nutzt Musterdatenkataloge (wie z.B. www.musterdatenkatalog.de), um gezielt nach vergleichbaren Beständen im eigenen Haus zu suchen. Ebenfalls sinnvoll ist der Abgleich mit den Veröffentlichungspflichten (vgl. Datenkompass), um das Ergebnis der Dateninventur zu vervollständigen. Aufschlussreich kann auch sein, sich über mögliche Sektorkopplungen Gedanken zu machen, wie also Mobilitätsdaten in Kombination mit Umwelt-, Wetter oder Gesundheitsdaten Wert für die Kommune und ihre Bürgerschaft schaffen können.[52]
- Stakeholder-Screening (Bedarfssicht): Durch die Analyse regelmäßiger Datenanfragen von Bürgern, Unternehmen oder der Wissenschaft sowie durch Umfragen und Veranstaltungen werden externe Bedarfe ermittelt, um die Inventur auf besonders nachgefragte Themen zu fokussieren.
In der praktischen Umsetzung kann dies durch eine Analyse von Dokumenten, hausinternen Interviews/Umfragen und Workshops mit den Fachämtern erfolgen.
3.8.2.2 Struktur und Inhalte eines internen Datenkatalogs
Das Ergebnis der Inventur ist ein interner Datenkatalog, der im Sinne einer Inventarliste alle identifizierten Datensätze bündelt. Ein solcher Katalog sollte mindestens folgende Informationen pro Datensatz enthalten:
- Grundmetadaten: Eindeutige Bezeichnung des Datensatzes, inhaltliche Beschreibung, Schlagworte und zeitlicher Bezug (Zeitraum der Datenerhebung).
- Technische Details: Dateiformat (z. B. CSV, JSON, GeoJSON), Speicherort (System/Datenbank) sowie Informationen über vorhandene Schnittstellen (APIs).
- Verantwortlichkeiten (Rollen): Eine klare Zuordnung der beteiligten Akteure ist essenziell. Hierbei sollten insb., die bereits genannten Data-Governance-Rollen benannt werden.
- Rechtliche Rahmenbedingungen: bestehende Nutzungsrechte, Lizenzen (z. B. CC0 oder Datenlizenz Deutschland) und mögliche Hinderungsgründe wie Personenbezug oder Geschäftsgeheimnisse müssen geprüft werden.
3.8.2.3 Hilfsmittel und Werkzeuge
Für eine effiziente Dateninventur im Bereich Mobilitätsdaten stehen verschiedene Hilfsmittel zur Verfügung:
- Musterdatenkatalog für Kommunen (musterdatenkatalog.de): Dieses Werkzeug bietet eine standardisierte Taxonomie und zeigt auf, welche Daten in Kommunen üblicherweise vorhanden sind. Es dient als Checkliste und Inspirationsquelle.
- Der Datenkompass im Rahmen dieses Leitfadens: dieser listet alle im Rechtsrahmen genannten Datenarten auf, benennt die jeweils geltenden Veröffentlichungspflichten und bietet Such- und Sortierfunktionen (Datenkompass).
- Strukturierte Analysetabellen: Zur Dokumentation eignet sich in der einfachsten Form eine Excel-Tabelle oder MS-Access-Datenbank. Der vorliegende Leitfaden bietet hierfür Vorlagen an LINK, die auf Basis bestehender Angebote entwickelt wurden (z. B. die Analysetabelle für Datenbestände des BBSR oder die Dateninventurtabelle von open bydata). Diese unterstützen dabei, Themenbereiche entlang des kommunalen Produktrahmens (z. B. Bau, Verkehr, Umwelt) systematisch abzuarbeiten.
- Software-Lösungen: Für die langfristige Pflege bieten sich Katalogsysteme wie CKAN oder DKAN an, die als Open-Source-Lösungen de facto Industriestandards für die Verwaltung von Metadatenportalen darstellen.[53]
Praxistipp:
Beginnen Sie „niederschwellig“ mit einer Auswahl an gut bekannten oder stark nachgefragten Datensätzen und berücksichtigen Sie dabei die nach den EU-Verordnungen festgelegten Fristen (siehe Datenkompass), anstatt eine vollständige Erfassung aller Behördendaten zu erzwingen. Eine kontinuierliche Aktualisierung ist wichtiger als eine einmalige, statische Vollerhebung.
[50] Vgl. Sautter, J., Lindner, M., Lödige, M., Dobrokhotova, E., Kirchner, J., Seick, J.-P., & Braun, S. (2024). Datenkompetenz in kommunalen Verwaltungen: Vorgehensmodell und Referenzrahmen für strategisches Handeln – ein Handlungsleitfaden für die kommunale Praxis. (BBSR-Online-Publikation 96/2024). Bundesinstitut für Bau-, Stadt- und Raumforschung. URL: https://doi.org/10.58007/s7fg-q691 (zuletzt abgerufen am 29.07.2026).
[51] Vgl. MobiData BW (2025). Checkliste Mobilitätsdaten vor Ort erschließen und bereitstellen (Stand 06/25). URL: https://mobidata-bw.de/uploads/page_images/2024-06-03-123412.404884240408MobilitatsdatenChecklisteWebseite.pdf (zuletzt abgerufen am 29.07.2026).
[52] Vgl. Atkins; World Road Association (PIARC) (2020). Road Related Data and How to Use It, Special Report 2020SP02EN, Paris: PIARC, URL: https://www.piarc.org/en/order-library/34599-en-Road%20Related%20Data%20and%20How%20to%20Use%20it (zuletzt abgerufen am 29.07.2026).
[53] Vgl. Krabina, B. (2020). Ein Leitfaden für offene Daten. (Hrsg. Bertelsmann Stiftung) URL: https://www.bertelsmann-stiftung.de/de/publikationen/publikation/did/ein-leitfaden-fuer-offene-daten (zuletzt abgerufen am 29.07.2026). Hier werden u.a. GovData, openNRW und die Portale von Rheinland-Pfalz, Aachen und Berlin als CKAN-Nutzer und Bonn, Düsseldorf und Köln als Nutzer von DKAN genannt.
Die Datenveröffentlichung können Sie auf verschiedenen Wegen vornehmen.
- Bereitstellung als gebrokertes Angebot über die Mobilithek über Anlieferungsmethode PUSH
- Bereitstellung als gebrokertes Angebot über die Mobilithek über Anlieferungsmethode PULL
- Manuelles Hochladen des Datensatzes zur Mobilithek und Bereitstellung durch diese
- Bereitstellung über Datenmittelnde
- Bereitstellung als nicht-gebrokertes Angebot, z.B. über einen selbst betriebenen Dienst (z.B. WFS oder OGC API-Dienst)
Seitens der Nationalen Stelle wird für unter das IVSG fallenden Datenarten die Bereitstellung als von der Mobilithek gebrokertes Angebot oder die Nutzung eines Datenmittelnden empfohlen.
3.8.3.1 Bereitstellung als gebrokertes Angebot über die Anlieferungsmethode PUSH
Mit der Wahl der Anlieferungsmethode “PUSH” können Sie Daten in selbstgewählten Aktualisierungsintervallen (z.B. minütlich oder täglich) an die Mobilithek übermitteln.
Dieser Weg hat den Vorteil, dass kein Web-Dienst zum Abruf der Daten eingerichtet werden muss.
Um die Daten per Push-Verfahrung übermitteln zu können, ist ein Mobilithek-Maschinenkonto erforderlich, dass Sie nach Anmeldung im Bereich “Meine Organisation” anlegen können. Weitere Informationen hierzu stellt die Mobilithek FAQ bereit.
3.8.3.2 Bereitstellung als gebrokertes Angebot über die Anlieferungsmethode PULL
Steht Ihrer Organisation ein eigener (Web-)Server zur Verfügung, über den Sie Daten veröffentlichen können, können Sie die Daten auch mittels Anlieferungsmethode “PULL” an die Mobilithek übermitteln.
Hierbei laden Sie die Datei auf den Server und machen diese über einen Web-Server (z.B. NGINX, Caddy, Apache httpd, MS IIS oder ähnlich) so zugänglich, dass die Daten regelmäßig von der Mobilithek abgerufen werden können (PULL-Anlieferung). Details hierzu beschreibt die Technische Schnittstellenbeschreibung der Mobilithek.
Diesen Weg der Bereitstellung können Sie ebenfalls nutzen, wenn sie die Daten nicht ausschließlich gebrokert, sondern auch zum direkten Download durch Dritte oder einen Datenmittelnden bereitstellen möchten.
Punkte, die Sie hierbei beachten sollten:
- Gerade große Datensätze sollten erst nach vollständiger Übertragung zum Abruf bereitgestellt werden. Dies wird häufig über einen Upload unter einem temporären Dateinamen und eine anschließende Umbenennung nach abgeschlossener Übertragung erreicht.
- Der Server sollte verschiedene Methoden unterstützen, mit denen die Mobilithek (oder auch andere abrufende Clients) prüfen können, ob der bereitgestellte Datensatz neuer als ein zuvor bereits heruntergeladener Datensatz ist. Hierzu sollte der Server z.B. die last-modified und/oder e-tag Header übermitteln und HTTP-HEAD-Anfragen unterstützen.
- In regelmäßigen Abständen aktualisierte Datensätze sollten unter einer stabilen URL, d. h. insbesondere ohne Datums-/Uhrzeit-Angabe bereitgestellt werden, so dass abrufende Systeme immer die gleiche URL zur Prüfung auf Aktualisierungen nutzen können.
- Die im vorigen Punkt empfohlene stabile URL kann auch eine direkte Weiterleitung auf den jeweils aktuellen Datensatz sein. So können Sie auch historische Versionen eines Datensatzes unter einer stabil bleibenden URL mit Zeitstempel veröffentlichen.
- Stellen Sie die Daten ohne Zwang zur Authentifizierung bereit.
- Wenn Sie bestimmte Abrufarten anhand von beim Abruf übermittelten Informationen (z.B. des http-Anfrageparameters “User-Agent”) ausschließen, teilen Sie dies explizit mit.
- Überwachen Sie regelmäßig Erreichbarkeit und Aktualität ihres veröffentlichten Datenangebots (siehe Monitoring)
Diese Empfehlungen vermeiden häufige Frustrationen bei Datennutzenden, wie sie z.B. von einigen OpenData-Aktiven als OpenData-AntiPatterns zusammengetragen wurden.
3.8.3.3 Hochladen des Datensatzes zur Mobilithek und Bereitstellung durch diese
Daten, die sich nur sehr selten und unregelmäßig ändern, können Sie auch manuell in die Mobilithek hochladen. Sie benötigen in diesem Fall keinen eigenen Server, die Daten durch die Mobilithek vermittelt (“gebrokert”) bereitgestellt werden. Die FAQ der Mobilithek erläutert das Vorgehen unter dem Punkt "FAQ allgemein/Datenangebote bereitstellen".
3.8.3.4 Bereitstellung über einen Datenmittelnden
Verschiedene Bundesländer oder andere Organisationen bieten Unterstützung bei der Veröffentlichung von Daten an. Neben der reinen Veröffentlichung übernehmen sie häufig zusätzliche Aufgaben wie Qualitätsprüfungen, Homogenisierung von Datenformaten, Aggregation und Duplikat-Bereinigung. In der Regel akzeptieren solche Datenmittelnde auch andere als die offiziellen Datenformate und nehmen Transformationen in die durch EU-Vorgaben geforderten Formate vor.
Die Veröffentlichung über solche Datenmittelnden ist durch die europäischen Verordnungen explizit zulässig. Die Verantwortung für die Veröffentlichung verbleibt jedoch unabhängig davon bei den Dateninhabenden.
In Deutschland übernimmt für den öffentlichen Personenverkehr der DELFI e.V. die Aufgaben des Datenmittelnden, für Baden-Württemberg für eine Reihe von Datenarten MobiData BW[54] und für Nordrhein-Westfalen MOBIDROM. Weitere Angebote öffentlicher und privater Anbietender werden in Zukunft entstehen. Je nach Datenart finden Sie in den Datensteckbriefe Hinweise auf überregionale und regionale Unterstützungsangebote und Angebote von Datenmittelnden.
Die Art und Weise der Datenübermittlung an Datenmittelnde variiert und muss individuell mit diesem abgestimmt werden.
3.8.3.5 Bereitstellung über einen selbst betriebenen Dienst (z.B. ein OpenData-Portal, einen OGC WFS- oder OGC API-Dienst)
Im Rahmen der offenen Bereitstellung von Daten als OpenData ebenso wie im Zuge der Umsetzung von Smart City-Projekten oder Geodatenportalen haben heute bereits viele Kommunen Systeme zur Veröffentlichung von Datensätzen im Einsatz. Dies können Datenkatalog-Systeme mit eigener Datenbereitstellung sein oder Geodatendienste wie OGC WebFeatureServices oder OGC-API Dienste.
Betreibt ihre Kommune bzw. eine Stelle ihrer Organisation bereits einen solchen Dienst, können Sie prüfen, ob hierüber nicht auch die Bereitstellung von Mobilitätsdaten, insbesondere als Anlieferung an die Mobilithek im PULL-Verfahren, erfolgen kann.
[54] V gl. NVBW – Nahverkehrsgesellschaft Baden-Württemberg mbH (2025). Factsheet Datenbereitstellungspflichten Stand 06/2025. URL: https://mobidata-bw.de/data/MobiData-BW-Factsheet-Datenbereitstellungspflichten.pdf (zuletzt abgerufen am 29.07.2026).
Nutzende haben häufig einen anderen Blick auf ihre Daten als sie selbst. Sie stellen vielleicht Qualitätsprobleme wie fehlende oder fehlerhafte Daten fest, oder haben Anregungen, welche Aspekte zusätzlich hilfreich sein könnten. Idealerweise richten Dateninhabende Kommunikationsmöglichkeiten ein, über die Datennutzende Rückmeldung zu Datensätzen geben können.
Wie Feedback zu Mobilitätsdaten eingeholt werden kann
- Rückmeldungen von Datennutzenden (z. B. Entwickler, Plattformbetreibende)
- Austausch mit internen Fachbereichen
- Nutzung von Kontaktmöglichkeiten auf Datenplattformen
- Auswertung von Nutzungsstatistiken (z. B. API-Zugriffe)
- strukturierte Rückmeldeprozesse für Fehler und Verbesserungsvorschläge
Diese Kommunikationskanäle können direkt (E-Mail, Kontaktformular) sein, oder öffentlich (Kommentarfunktion, Issuetracker).
3.8.4.1 Öffentliche Kommunikationskanäle
Öffentliche Kommunikation zu Daten hat den großen Vorteil, dass auch andere Datennutzende Fragen/Rückmeldungen anderer Datennutzenden sehen können und bei ihrer Datennutzung berücksichtigen können. Wir empfehlen öffentliche Kommunikationskanäle gegenüber den weiter unten beschriebenen direkten Kommunikationskanälen.
Existiert ein solcher Kommunikationskanal, sollte er auch über die Metadaten zum Datensatz publiziert werden. Hierzu bietet sich die Eigenschaft "discussionUrl" (siehe https://schema.org/discussionUrl) an.
3.8.4.1.1 Kommentierungsfunktion in Datenportalen
Manche Datenportale bieten die Möglichkeit, zu Datensätzen Kommentare zu hinterlassen. Zu bedenken ist hierbei jedoch, dass solche Kommentare nur für diejenigen sichtbar werden, die die Daten über dieses Portal abrufen. Häufig fehlen Portalen auch Funktionen wie ein Abonnieren auf die Kommunikation zu einem Datensatz, so Diskussionen nicht leicht verfolgt werden können.
3.8.4.1.2 Issue-Tracker/Fehlerverfolgungssysteme
In der Software-Entwicklung sind Issue-Tracking-System schon seit Jahren ein gebräuchliches Werkzeug, um Meldungen zu Fehlern oder auch Erweiterungswünschen entgegenzunehmen. Auch für Datensätze bietet sich dies an, um Rückmeldungen geordnet entgegenzunehmen und zu bearbeiten. Das IVS-Gesetz sieht nach §11 die Einrichtung und Betrieb eines solchen Systems durch die Nationale Stelle vor, über das
- Fehler, Ungenauigkeiten und Korrekturvorschläge erfasst werden können
- Die eingegebenen Informationen automatisiert an die Datenhinabenden und Datenmittelnden zur Prüfung weiterleitet
- Ergebnisse der Prüfung dokumentiert werden können.
Dateninhabende sind verpflichtet, sie betreffende Informationen zu prüfen und das Ergebnis der Prüfung über dieses System zu melden. Zutreffende Beanstandungen sind unverzüglich zu korrigieren.
3.8.4.2 Direkte Kommunikationskanäle
Die Mobilithek bietet über ihre Kontakt-Möglichkeiten die Übermittlung zu Datenverantwortlichen an. Alternativ können Sie in der Datensatzbeschreibung und/oder den Metadaten E-Mail-Adressen veröffentlichen, über die Rückmeldung zu den Daten gegeben werden kann.
Achten Sie in jedem Fall darauf, dass Sie bei der Veröffentlichung als auch bei der Hinterlegung bei Kontaktformularen stets Funktionspostfach-Adressen verwenden, so dass auch bei Abwesenheiten einer Person sichergestellt ist, dass Anfragen/Rückmeldungen Sie erreichen.
3.8.4.3 Organisatorische Prozesse im Zusammenhang mit Feedback-Kanälen
Die Einrichtung eigener bzw. Nutzung anderweitig bestehender Feedback-Kanäle ist alleine nicht ausreichend, es ist zudem notwendig, einen Prozess und Zuständigkeiten zu definieren, um das eingehende (bzw. auf einer Plattform gemeldete) Feedback inhaltlich zu bearbeiten, ggf. Maßnahmen zu konzipieren und einzuleiten oder Prioritäten für die Umsetzung von Maßnahmen zu vergeben. Hier sollte eine Person oder Stelle definiert werden, die für die Bearbeitung des Feedbacks zuständig ist und ggf. weitere Schritte einleitet. Zudem sollten Kriterien definiert werden, die eine Priorisierung erlauben (ist ein gemeldeter Fehler kritisch oder nicht? Oder handelt es sich eher um einen Verbesserungsvorschlag?) und eine Stellvertretung z.B. für Urlaube oder Krankheit benannt sein.
Analog zu Prozessen aus dem IT-Servicemanagement kann in den eher reaktiven Prozess der unmittelbaren Beseitigung des Fehlers und den eher strategischen Prozess der Ursachenanalyse und Konzeption von Verbesserungsmaßnahmen, damit ähnliche Fehler in Zukunft nicht mehr auftreten, unterschieden werden.
Der Begriff "Monitoring" umfasst viele Aspekte: ganz allgemein geht es um fortlaufende Überprüfung z.B. eines Prozesses oder Prozessergebnisses. Im technischen Umfeld wird hierunter oft die automatisierte technische Überwachung von Software-Systemen oder spezieller technischer Parameter verstanden.
3.8.5.1 Automatisierte Überwachung/Monitoring
Veröffentlicht eine Organisation Daten, kann es dabei immer mal wieder zu Problemen kommen. Vielleicht ist der die Daten veröffentlichende Server ausgefallen und daher nicht erreichbar. Oder das SSL-Zertifikat wurde nicht rechtzeitig erneuert und ist abgelaufen. Oder der Aktualisierungsprozess ist unbemerkt fehlgeschlagen und die Datenbereitstellung erfolgt nicht im vorgesehen Zeitintervall. Oder aufgrund eines Verarbeitungsproblems umfasst der Datensatz nicht mehr alle erwarteten Einträge oder enthält strukturelle Fehler...
Um solche Probleme zu vermeiden oder zumindest frühzeitig zu erkennen, sollte eine Organisation sowohl die Datenverarbeitungsprozesse überwachen als auch die veröffentlichten Publikationen.
Für über die Mobilithek veröffentlichte Daten bietet die Mobilithek eine Protokollierung von Ereignissen, das sogenannte Log. Es lässt sich hinsichtlich Zeitraum und anderer Kriterien filtern und kann manuell als CSV-Datei heruntergeladen werden. Hinweise zur Nutzung finden Sie in den Mobilithek FAQ unter “Grundlegende Fragen / Kann ich Log Ereignisse ansehen?” Empfohlene Maßnahmen:
- Überwachen Sie regelmäßig und automatisiert die Erreichbarkeit der Datensätze
- Überwachen Sie regelmäßig und automatisiert die Aktualität der veröffentlichten Datensätze
- Überprüfen Sie regelmäßig das Log der Mobilithek auf eventuelle Fehler.
- Führen Sie regelmäßig und automatisiert Qualitätsprüfungen der veröffentlichten Datensätze durch und überwachen Sie deren Ergebnisse
- Sorgen Sie dafür, dass bei festgestellten Problemen ein Kreis verantwortlicher Personen informiert wird
- Sorgen Sie dafür, dass bei festgestellten Problemen die zu ergreifenden Maßnahmen dokumentiert sind und durch die informierten Personen eingeleitet werden können
3.8.5.1.1 Einstiegsmaßnahmen
Für offen zugängliche Datensätze können Sie über sogenannte Uptime-Checker von außerhalb in automatisiert in regelmäßigen Abständen die Erreichbarkeit von Datensätzen prüfen. Womöglich betreibt die IT-Abteilung auch bereits Monitoring-Werkzeuge zur Überwachung von Software-Systemen und kann Sie mit diesen auch bei der Prüfung der Erreichbarkeit und Aktualität von Datensätzen und der Überwachung von Datenverarbeitungs-System und -Prozessen unterstützen.
3.8.5.1.2 Fortgeschrittene Maßnahmen
Idealerweise unterstützen bereits die eingesetzten Datenportale wesentliche Aufgaben. So können diese z.B. anhand von in den Metadaten angegebenen Veröffentlichungsintervallen feststellen, ob ein Datensatz bereits hätte aktualisiert werden sollen und somit veraltet ist. Oder, sofern die Metadaten Angaben zu verwendeten Datenformaten und -Profilen beinhalten, sporadisch eine automatisierte Validierung durchführen und bei Abweichungen Dateninhabende und gegebenenfalls auch Datenkonsumierende informieren.
Zusätzlich sollten Sie Datenverarbeitungsprozesse und -Systeme automatisiert überwachen und bei eventuellen Problemen die Personengruppe, welche das Problem untersuchen und beheben kann, informieren. Idealerweise unterstützen die eingesetzten Systeme bereits geeignete Schnittstellen zur Überwachung, z.B. im OpenTelemetry-Standard.
Darüber hinaus können Sie neben den Daten selbst auch zentrale Metriken eines Datensatzes publizieren und diese überwachen.
Für Datensätze lassen sich z.B. folgende Metriken überwachen:
- Datum bzw. Alter der Veröffentlichung
- Größe des Datensatzes
- Anzahl Einträge
- Anzahl Warnungen/Fehler aus Datensatz-Validierung usw.