Verkenning: rekenen met GTFS-RT (gerealiseerde reistijden / betrouwbaarheid)

[jipclaassens]

Aanleiding

Vraag van PBL (Jeroen, mail 14-7-2026): valt er ook te rekenen met GTFS-RT, dus de OV real-time-/GPS-locatiedata?

Wat is GTFS-RT

GTFS-Realtime: live protobuf-stream (elke ~30 sec) naast de statische GTFS-dienstregeling, met drie berichttypen: TripUpdates (vertragingen/uitval per rit), VehiclePositions (GPS per voertuig), ServiceAlerts (verstoringen). NL-bron: OVapi/NDOV.

Twee rekensmaken

1. Gerealiseerde bereikbaarheid: TripUpdates-archief → dienstregeling per dag corrigeren naar wat er echt reed → bestaande model per dag draaien. Methodisch het mooist (verdeling van bereikbaarheid over dagen, slechte-dag-analyse), maar rekenzwaar: één netwerkbouw per dag.
2. Betrouwbaarheidsopslag: vertragingsverdeling per lijn/segment schatten en als opslag op de reistijd zetten (bv. 80e-percentiel i.p.v. dienstregeltijd). Eén run, veel goedkoper; minder detail.

Datakwestie (bepalend)

• GTFS-RT is een vluchtige stream; er is geen officieel archief. Rekenen vereist historie.
• Trein: realisaties zijn al goed gearchiveerd (NDOV-realisatiedata, o.a. via rijdendetreinen.nl) → pilot kan direct.
• Bus/tram/metro: zelf archiveren (GTFS-RT of KV6 pollen, orde GB's per maand). Terugvullen kan niet — als PBL dit serieus wil, archivering nú starten, uitwerking kan later.

Voorstel

1. Onderzoeksvraag scherpstellen met PBL: betrouwbaarheid van bereikbaarheid? Equity van vertragingen? Slechte-dag-bereikbaarheid?
2. BTM-archivering alvast aanzetten (goedkoop, no-regret).
3. Pilot met trein (archief bestaat): gerealiseerde vs. geplande bereikbaarheid voor een testperiode.
4. Op basis van pilot kiezen tussen smaak 1 en 2 voor landelijke toepassing.