← Zurück zu allen Beiträgen
DATEX II Architektur EU

Wie wir DATEX II über 30 europäische National Access Points normalisieren

1. Mai 2026 · 11 Min. Lesezeit

Die EU-Richtlinie 2010/40/EU verpflichtet jeden Mitgliedstaat, einen National Access Point (NAP) zu betreiben, der Echtzeit-Verkehrs-, Sicherheits- und multimodale Reiseinformationen in DATEX II veröffentlicht. Auf dem Papier heißt das: ein Standard, 27 Veröffentlicher, eine Integration.

In der Praxis liefert jeder NAP ein anderes DATEX-II-Profil über einen anderen Transport hinter einer anderen Authentifizierung in einer anderen Aktualisierungsfrequenz. „DATEX-II-konform" ist ein Häkchen, das jeder Mitgliedstaat anders setzt.

Genau das haben wir beim Aufbau von NAPSPAN erlebt — einer einheitlichen API über EU 27 + UK + EFTA. Hier ist die Architektur, die uns 30 inkompatible DATEX-II-Feeds wie einen einzigen behandeln lässt.

Die Spezifikation und die Realität

DATEX II ist ein ausgereifter europäischer Standard, gepflegt von datex2.eu und koordiniert durch NAPCORE. Jede delegierte Verordnung verweist darauf als verbindliches Austauschformat:

Die Spezifikation ist also eindeutig. Die Umsetzung ist alles andere als das.

Worin sich die NAPs tatsächlich unterscheiden

„DATEX-II-konform" verbirgt mindestens fünf Achsen der Divergenz:

1. Profil

Jeder Mitgliedstaat veröffentlicht ein nationales Profil — eine eingeschränkte Teilmenge des DATEX-II-Modells. Das deutsche Profil (German Traffic Data Profile) definiert Vorfälle, Baustellen und Verkehrsfluss auf Autobahn und Bundesstraßen. Frankreichs transport.data.gouv.fr nutzt andere Unterelemente. Das niederländische NDW veröffentlicht eine engere Ereignistaxonomie. Der britische NAP TDT wickelt DATEX in TIH-spezifische Container. Im DATEX-II-Profilverzeichnis sind sie alle gelistet — gleiches Wurzelschema, in jedem Land eine andere Form.

2. Version

DATEX II v2.3 und v3.x sind beide aktiv im Einsatz. Manche NAPs liefern beide Versionen. Manche befinden sich mitten in der Migration. Die XML-Namespaces unterscheiden sich. Einige Elemente wurden zwischen den Versionen umbenannt.

3. Transport

DATEX II ist ein Payload-Format, kein Transport. Die NAPs liefern es über:

4. Authentifizierung

Die Matrix ist breit:

5. Frequenz und Frische

Manche Publikationen aktualisieren alle 30 Sekunden (Autobahn-Verkehrsfluss). Andere nur nächtlich (geplante Baustellen-Kalender). Manche sitzen hinter einem CDN, das mit Last-Modified-Headern die Frische schönrechnet. Adaptives Backoff zählt.

Der Format-Zoo

Das Ergebnis dieser fünf Achsen: Derselbe Vorfall — etwa ein Unfall auf der Autobahn — sieht aus jedem NAP völlig anders aus. Der eine liefert ihn als XML, der nächste als JSON-LD; der eine auf DATEX II v2.3, der andere auf v3.x; jeder verpackt die Nutzlast in seine eigene Hülle und erreicht uns über einen anderen Transport hinter einer anderen Authentifizierung. Gleiche Verordnung, gleicher Standard — keine zwei Feeds gleich.

Die Arbeit besteht also nicht darin, DATEX II einmal zu lesen. Sie besteht darin, 30 Dialekte davon zu lesen und in Einklang zu bringen.

Die Architektur

Die Lösung ist derselbe Ansatz wie auf der nordamerikanischen Seite: Jeder NAP wird von seinem eigenen, in sich geschlossenen Adapter behandelt, und alle erzeugen dieselbe normalisierte Ausgabe. Ob ein NAP als XML abgerufen, als JSON-LD gepollt oder aus einem länderspezifischen Container ausgepackt wird — der Adapter verbirgt jeden dieser Unterschiede. Er erhält eine Quellkonfiguration (welcher Feed, welche Zugangsdaten, welches Land, welche Profilversion) und gibt normalisierte Events und Features zurück.

Der Scheduler weiß und interessiert sich nicht dafür, welches DATEX-II-Profil, welche Version oder welcher Transport hinter jedem NAP steckt. Er fordert einen Adapter zum Abruf auf und erhält normalisierte Events und Features zurück — nichts anderes dringt durch.

Das normalisierte Modell

Alles landet in einem konsistenten Modell, unabhängig von der Herkunft:

Events — zeitlich begrenzte Vorfälle (Unfälle, Baustellen, Sperrungen, Wetter) mit Schweregrad, Standort, betroffenen Straßen, geplanter vs. tatsächlicher Zeit und Lebenszyklus-Status. Die quellspezifischen Felder, die jeder NAP mitführt, bleiben neben den normalisierten erhalten — nichts geht bei der Übersetzung verloren.

Features — alles andere: Kameras, VMS-Anzeigen, Wetterstationen, Parkplätze, Ladestationen, LKW-Routensegmente, Brücken-Durchfahrtshöhen. Sie teilen alle eine generische Form mit typspezifischem Detail, sodass ein neuer Point-of-Interest-Typ eine Konfigurationsänderung ist, keine Schemamigration.

Die schwierigen Teile

1. Profilfeld-Mapping

Jedes nationale Profil legt dieselbe kanonische Information — den Straßennamen, die Richtung, den Standort — an einer anderen Stelle ab, oft mehrere Ebenen tief verschachtelt und anders benannt. Jeder Adapter weiß, wo sein Profil jedes Feld ablegt, das uns interessiert. Wo ein Profil etwas schlicht nicht mitführt, bleibt das Feld leer — wir erfinden keine Daten.

2. Lebenszyklus-Tracking

Derselbe Vorfall wird immer wieder neu veröffentlicht, während er sich entwickelt, und jeder NAP signalisiert Updates anders — manche bei jeder kleinen Änderung, andere nur bei substantiellen. Wir verfolgen, wie sich jeder Datensatz im Laufe der Zeit ändert, sodass ein Update als dasselbe reifende Ereignis erkannt wird und nicht als ein neues. Diese Historie ist es, die grenzüberschreitende Analytics wie Räumzeit-Perzentile und Korridor-Zuverlässigkeit ermöglicht.

3. Koordinatenreferenzsysteme

Die meisten NAPs liefern WGS84 (EPSG:4326). Einige deutsche Landesfeeds nutzen ETRS89 / UTM-Zonen. Manche städtische Feeds verwenden das lokale Katasterystem. PostGIS übernimmt die Transformation, aber jeder Adapter muss wissen, was er empfängt.

4. Rate-Limiting im großen Maßstab

30 NAPs, jeder mit mehreren Ressourcentypen (Events, VMS, Parkplätze, Ladestationen, Wetter), jeder mit einer 30-Sekunden- bis 5-Minuten-Frequenz. Der Scheduler nutzt pro Server ein Semaphor mit konfigurierbarer Parallelität und Mindestabstand zwischen Anfragen. Circuit Breaker zurücksetzen bei wiederholten Fehlern. Adaptives Backoff erhöht die Frequenz, wenn ein NAP langsam ist oder Fehler liefert — sonst zieht ein einzelner langsamer NAP die Frische einer ganzen Region nach unten.

5. Ein Modell für jeden Feature-Typ

Das generische Feature-Modell zahlt sich jedes Mal aus, wenn eine neue Art von Daten online geht. Als die AFIR-Ladedaten auf der EU-Seite ankamen, fügten sie sich ohne strukturellen Umbau in dasselbe Modell wie Kameras und Parkplätze ein — einfach ein weiterer Feature-Typ neben den übrigen.

Die API

Nach der Normalisierungsarbeit ist die API geradlinig:

Aktive Vorfälle in Deutschland:

curl "https://api.napspan.com/api/v1/events?country=DE&type=incident&status=active" \
  -H "X-API-Key: your_key"
{
  "data": [
    {
      "id": "de_mobilithek_4711",
      "country": "DE",
      "type": "incident",
      "severity": "major",
      "title": "Verkehrsunfall A7 Richtung Hamburg",
      "affected_roads": ["A7"],
      "direction": "Hamburg",
      "lanes_affected": "2 of 3 lanes closed",
      "latitude": 53.5511,
      "longitude": 9.9937,
      "start_time": "2026-05-01T08:15:00Z",
      "estimated_end_time": "2026-05-01T12:00:00Z"
    }
  ],
  "total": 142,
  "limit": 100,
  "offset": 0,
  "has_more": true
}

Verkehrskameras in den Niederlanden als GeoJSON:

curl "https://api.napspan.com/api/v1/features/geojson?type=cameras&country=NL" \
  -H "X-API-Key: your_key"

Die Antwort lässt sich direkt in Leaflet, Mapbox oder ein anderes GeoJSON-kompatibles Werkzeug einsetzen.

Grenzüberschreitende Korridor-Abfrage (Berlin nach Amsterdam):

curl "https://api.napspan.com/api/v1/events/corridor?\
from_lat=52.52&from_lng=13.40&\
to_lat=52.37&to_lng=4.90&buffer_km=5" \
  -H "X-API-Key: your_key"

Ein Aufruf, zwei NAPs (Mobilithek + NDW), eine konsistente Antwortstruktur.

Was in den Daten steckt

Nach der Normalisierung enthält der Datensatz unter anderem:

Tech-Stack

Jetzt ausprobieren

Die API ist live mit einem kostenlosen Tarif (keine Kreditkarte):

Wenn Sie irgendetwas auf europäischen Mobilitätsdaten aufbauen — Logistik, Flottenrouting, Navigation, urbane Mobilitäts-Dashboards — würden wir gerne wissen, welche NAPs und welche DATEX-II-Profile für Sie als Erstes normalisiert werden sollten. Der schwierigste Teil ist nicht das Parsen, sondern zu wissen, welcher Mitgliedstaat welche Daten über welchen Transport hinter welcher Auth-Methode veröffentlicht. Nach 30 NAPs haben wir davon eine ziemlich gute Karte.

Bereit, NAPSPAN auszuprobieren?

14 Tage kostenlos. Keine Kreditkarte. EU 27 + UK + EFTA, normalisiert.

Kostenlosen API-Schlüssel sichern Karte erkunden