Flexvervoer (BravoFlex e.d.) opnemen via gerichte NeTEx-flex-extract

[jipclaassens]

Aanleiding

Vraag van PBL (Jeroen, mail 14-7-2026): flexvervoer zoals BravoFlex is in het Nederlandse OV geïntegreerd in de NeTEx-standaard. Kunnen we daar iets mee, of is daarvoor een volledige overstap op NeTEx nodig?

Kern

Geen volledige NeTEx-migratie nodig (die is bij #71 bewust uitgesteld: NS levert nog IFF, NeTEx-tarieven onrijp). Flexvervoer zit in NeTEx als FlexibleLine/flexgebieden + BookingArrangement (boekingstermijn). Voorstel: NeTEx alleen als zij-input gebruiken voor een flex-extract, naast de bestaande GTFS-pipeline.

Aanpak

1. NeTEx-bestanden ophalen van NDOV-loket (data.ndovloket.nl/netex/):
   • cxx/NeTEx_CXX_SRE_*.xml.gz (~4 MB) — Hermes/Bravo Zuidoost-Brabant (BravoFlex-kern)
   • arr/NeTEx_ARR_NL_*.xml.gz (~12 MB) — Arriva NL (flex West-Brabant)
2. Inspecteren welke flex-elementen de NL-profielen daadwerkelijk vullen (FlexibleLine, gebiedsgeometrie, boekingsregels).
3. Extractie: flexgebieden + hubs → shapes/FSS voor GeoDMS.
4. Modellering: feeder-links binnen flexgebied naar hubs; reissnelheid = wegennet, wachttijd = parameter (af te leiden uit boekingstermijn).
5. Pilot: één concessie (Zuidoost-Brabant), effect op bereikbaarheidsindicatoren meten, daarna beslissen over bredere uitrol.

Open punten / keuzes

• Wachttijdpenalty is een methodische keuze voor PBL (bv. 15–30 min): het model is dienstregeling-gebaseerd, flex heeft geen dienstregeling.
• Dekking: niet elke flexdienst is open OV (WMO-/doelgroepenvervoer uitsluiten).
• Relatie met Uitzoeken of we GTFS kunnen vervangen door de bron NETEX #71 (NeTEx-bronarchitectuur): dit extract loopt daarop vooruit zonder de GTFS-pipeline te raken.

[jipclaassens]

Bevindingen verkenning (14-7-2026)

NeTEx-bestanden opgehaald van NDOV-loket (NeTEx_CXX_SRE_20260704 + NeTEx_ARR_NL_20260714, staan op E:/SourceData/NetworkModel_PBL/SD_next/Infrastructuur/NeTEx/) en doorzocht. Drie conclusies die de aanpak herkaderen:

1. Het NL-NeTEx-profiel gebruikt de NeTEx-flex-structuren niet.
Geen FlexibleLine, flexgebied-geometrie of BookingArrangement in de exports. Flex is gecodeerd als gewone <Line> met een BISON-marker: <TypeOfServiceRef ref="NL:BISON:TypeOfService:Flex" /> plus productcategorie (bv. FlexRRReis). Er valt dus geen gebiedsgeometrie uit NeTEx te extraheren — alleen een betrouwbare flex-classificatie per lijn (40 flex-lijnen in de Arriva-export).

2. Flexvervoer zit al in onze GTFS-feeds, met echte trips.
O.a. FlexiGo (Almere, 270 trips), FlexRRReis (Rijssen/Borne/Hengelo), U-flex (18 gebieden in feed 20260316; Vijfheerenlanden-West alleen al 3884 trips), Overal Flex, SyntusFlex, Texelhopper. Het model rekent flex dus nu al mee als gewone buslijn — zonder reserveringsdrempel (30-60 min vooraf boeken), dus de bereikbaarheid via deze lijnen wordt overschat.

3. Bravoflex specifiek bestaat niet meer in de actuele feeds.
BRAVO:ARR 820 Bravoflex zit in feeds 20231003 en 20241001, maar is verdwenen in 20251008 en 20260316. U-flex is in dezelfde periode juist sterk gegroeid.

Herkaderde aanpak

Geen NeTEx-migratie en geen gebieden-extractie nodig. Het werk wordt:

1. IsFlex-classificatie op routes (naam-heuristiek flex|texelhopper|opstapper|belbus op route-namen; NeTEx-marker als validatiebron).
2. Modelkeuze PBL: flex-legs (a) uitsluiten (conservatief), (b) wachttijd-/boekingspenalty geven (bv. 15-30 min op instap), of (c) laten zoals nu (optimistisch). Dit is de eigenlijke beslissing.
3. Implementatie in GeoDMS is daarna klein (classificatie + penalty/filter in de netwerkopbouw).

Eventueel later: per-jaar-analyse van flex-dekking (2023-2026 feeds) als PBL wil weten waar flex bereikbaarheid draagt.