Gepubliceerd

Belangrijke standaarden in Publieke Mobiliteit

GTFS, OSDM, MDS, CDS/M, OTP, OJP, TOMP-API en het Beckn-protocol beantwoorden elk een andere vraag. Samen beschrijven zij de standaarden die een open mobiliteitssysteem nodig heeft.

In voorbereiding

Concept — vóór livegang uit te werken.

Interoperabiliteit ontstaat niet vanzelf. Zij is het resultaat van open afspraken over hoe systemen dienstregelingen, voertuigen, beschikbaarheid, boekingen en betalingen integreren. Drie families van standaarden doen daarvan vandaag het meeste werk in Publieke Mobiliteit.

GTFS, OSDM, MDS, CDS/M, OTP, OJP.

GTFS (General Transit Feed Specification) beschrijft het geplande openbaar vervoer — lijnen, haltes en dienstregelingen — in een vorm die elke applicatie kan lezen. Het is de reden dat een reisplanner het ov-netwerk van een heel land kan dekken zonder met elke vervoerder afzonderlijk te onderhandelen.

OSDM (Open Sales and Distribution Model) is geen directe vervanging voor andere mobiliteitsstandaarden, maar fungeert als een complementaire uitbreiding die specifiek de verkoop, prijsstelling en ticketing afhandelt. Binnen het Europese transportlandschap vult OSDM de lacunes op die andere standaarden achterlaten. Waar bestaande protocollen zich sterk richten op dienstregelingen, netwerktopologie of voertuiginfrastructuur, beheert OSDM de daadwerkelijke financiële transactie. Het model is officieel gestandaardiseerd door de Internationale Spoorwegunie (UIC) als IRS 90918-10. Het is echter niet beperkt tot spoorwegmaatschappijen.

MDS (Mobility Data Specification) is specifiek ontworpen voor het beheer van de openbare ruimte. Waar standaarden zoals OSDM zich richten op ticketing en verkoop, richt MDS zich volledig op de regulering van voertuigen op straat. Het wordt beheerd door de Open Mobility Foundation (OMF). De standaard werkt voornamelijk via drie belangrijke API-componenten:

Aanbieder: Aanbieders van gedeelde mobiliteit (zoals Lime, Bird of Tier) sturen historische en realtime gegevens naar de stad (bijv. voertuiglocaties, afgelegde ritten).

Agentschap: De stad vraagt ​​specifieke live gegevens of telemetrie op bij de aanbieders.

Beleid: De stad verstuurt digitale regelgeving in een machineleesbaar formaat naar de vervoersbedrijven (bijv. maximumsnelheidslimieten, actieve geofenced parkeerverbodzones).

CDS-M staat voor City Data Standard - Mobility (ook wel City Data Specification for Mobility genoemd). Het is geen op zichzelf staand dataformaat, maar een gestandaardiseerd raamwerk en proceshandleiding die is ontworpen om gemeenten en vervoersbedrijven te helpen bij het veilig, legaal en ethisch uitwisselen van gedeelde mobiliteitsgegevens. Terwijl technische API’s zoals MDS (Mobility Data Specification) of GBFS definiëren hoe gegevens worden geformatteerd, definieert CDS-M hoe gegevens moeten worden beheerd, verwerkt en overeengekomen tussen bedrijven en overheid (B2G). Het is oorspronkelijk ontwikkeld in Nederland door het Ministerie van Infrastructuur en Waterbeheer in samenwerking met grote Nederlandse steden (waaronder Amsterdam, Rotterdam en Utrecht) om knelpunten in het delen van gegevens op te lossen.

OTP staat voor OpenTripPlanner. Het is een toonaangevend, open-source softwareplatform dat wordt gebruikt om reisplanners te bouwen. Het neemt ruwe OV-gegevens (zoals dienstregelingen en kaarten) en verwerkt deze om de beste routes voor gebruikers te vinden. OTP fungeert als het wiskundige ‘brein’ achter de routeplanning. Als een gebruiker van punt A naar punt B wil reizen, berekent OTP de snelste combinatie van lopen, fietsen, autorijden en openbaar vervoer. Het maakt gebruik van open standaard dataformaten zoals GTFS (voor dienstregelingen van het openbaar vervoer) en OpenStreetMap (OSM) (voor de geometrie van wegen en voetpaden). Grote vervoersautoriteiten en -bedrijven wereldwijd (zoals Entur in Noorwegen, TriMet in Portland en diverse regionale apps in Europa) gebruiken OTP als de backend-engine voor hun consumentenapps.

OJP staat voor Open Journey Planner. Het is een officiële Europese API-standaard (geformaliseerd onder CEN/TS 17118) die is ontwikkeld om verschillende, onafhankelijke reisplanningssystemen met elkaar te laten communiceren. OJP is een open brokerageprotocol gebaseerd op een XML-verzoek/antwoordstructuur. In plaats van elke regio te dwingen al hun gegevens in één enorme, centrale database te verzamelen, stelt OJP een app in staat om realtime routeberekeningen van meerdere regionale systemen tegelijkertijd op te vragen en deze samen te voegen tot één doorlopende grensoverschrijdende route. OJP behoort tot het Europese referentiekader Transmodel. Het werkt samen met verwante standaarden zoals NeTEx (voor dienstregelingen) en SIRI (voor realtime voertuiglocaties). De ITS-richtlijn MMTIS van de Europese Commissie verplicht OJP om naadloze, grensoverschrijdende multimodale reisplanning in heel Europa mogelijk te maken.

TOMP-API, ontwikkeld door de werkgroep Transport Operator / Mobility Provider, standaardiseert de transactie tussen een mobiliteitsaanbieder en de dienst die zijn ritten doorverkoopt: wat beschikbaar is, hoe er wordt geboekt, en hoe de rit wordt gerapporteerd en afgerekend.

Het Beckn-protocol gaat een stap verder. In plaats van één koppelvlak te standaardiseren, beschrijft het hoe een gedecentraliseerd netwerk van aanbieders en consumentenapplicaties elkaar kan vinden en rechtstreeks transacties kan doen, zonder een centraal platform ertussen. FINOMAD bevordert de toepassing, het gebruik, de training en de doorontwikkeling ervan voor mobiliteitsdoelstellingen.

Elk beantwoordt een andere vraag. Samen gelezen beschrijven zij de standaarden die een open mobiliteitssysteem nodig heeft.

  • standards
  • beckn
  • explainer
  • Waarom de verschuiving van MaaS naar MaaF?

    Mobility as a Feature beschrijft mobiliteit die is ingebed in diensten die mensen al gebruiken. Wat drijft die verschuiving, en wat betekent zij voor open infrastructuur?

  • Wat is het verschil tussen MaaS en Publieke Mobiliteit?

    Beide termen beschrijven het samenbrengen van vervoerswijzen tot één reis. Ze verschillen in accent — en dat verschil verklaart waarom FINOMAD er in de communicatie één van verkiest.

  • Wat is MaaS?

    Mobility as a Service uitgelegd: waar de term vandaan komt, wat de sector ermee bedoelt en waarom de statuten van FINOMAD hem noemen.

Alle artikelen