Important standards in Public Mobility

Interoperability is not a property that appears on its own. It is the result of agreeing, in public, on how systems describe timetables, vehicles, availability, bookings and payments to one another. Three families of standards do most of that work in Public Mobility today.

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

GTFS (General Transit Feed Specification) describes scheduled public transport — routes, stops and timetables — in a form any application can read. It is the reason a journey planner can cover an entire country’s transit network without negotiating with every operator individually.

OSDM (Open Sales and Distribution Model) is not a direct replacement for other mobility standards, but acts as a complementary extension that specifically handles sales, pricing, and ticketing. Within the European transport landscape, OSDM fills the gaps left by other standards. While existing protocols focus heavily on timetables, network topology, or vehicle infrastructure, OSDM manages the actual financial transaction. The model is officially standardized by the International Union of Railways (UIC) as IRS 90918-10. It is however, not limited to rail operators.

MDS (Mobility Data Specification) is specifically designed for public space management. While standards like OSDM focus on ticketing and sales, MDS focuses entirely on regulating vehicles on the street. It is managed by the Open Mobility Foundation (OMF). The standard operates primarily through three main API components:

Provider: Shared mobility operators (like Lime, Bird, or Tier) send historical and real-time data to the city (e.g., vehicle locations, trips taken).

Agency: The city requests specific live data or telemetry from the operators.

Policy: The city transmits digital regulations in a machine-readable format to the operators (e.g., maximum speed limits, active geofenced no-parking zones).

CDS-M stands for City Data Standard - Mobility (also referred to as City Data Specification for Mobility). It is not a standalone data format, but a standardized framework and process manual designed to help municipalities and transport operators exchange shared mobility data securely, legally, and ethically. While technical APIs like MDS (Mobility Data Specification) or GBFS define how data is formatted, CDS-M defines how data should be governed, handled, and agreed upon between Business and Government (B2G). It was originally developed in the Netherlands by the Ministry of Infrastructure and Water Management alongside major Dutch cities (including Amsterdam, Rotterdam, and Utrecht) to solve data sharing bottlenecks.

OTP stands for OpenTripPlanner. It is an industry-leading, open-source software platform used to build trip planners. It takes raw transit data (like schedules and maps) and processes it to find the best routes for users. OTP acts as the mathematical routing “brain”. If a user wants to travel from point A to point B, OTP calculates the fastest combination of walking, bicycling, driving, and public transit. It relies on open-standard data formats like GTFS (for transit schedules) and OpenStreetMap (OSM) (for road and walkway geometry). Major transport authorities and companies worldwide (such as Entur in Norway, TriMet in Portland, and various regional apps in Europe) use OTP as the backend engine for their consumer apps.

OJP stands for Open Journey Planner. It is an official European API standard (formalized under CEN/TS 17118) developed to allow different, independent journey planning systems to talk to each other. OJP is an open brokerage protocol based on an XML request/response structure. Instead of forcing every region to pool all their data into one massive, central database, OJP allows an app to request real-time route calculations from multiple regional systems simultaneously and stitch them into one continuous cross-border itinerary. OJP belongs to the Transmodel European reference framework. It works alongside sister standards like NeTEx (for schedules) and SIRI (for real-time vehicle locations). The European Commission’s ITS Directive MMTIS regulation mandates OJP to facilitate seamless, cross-border multimodal travel planning across Europe.

TOMP-API, developed by the Transport Operator / Mobility Provider working group, standardises the transaction between a mobility operator and the service that resells its trips: what is available, how it is booked, how the trip is reported and settled.

The Beckn protocol goes a step further. Rather than standardising one interface, it describes how a decentralised network of providers and consumer-facing applications can discover one another and transact directly, without a platform sitting in the middle. FINOMAD promotes its application, use, training and further development for mobility purposes.

Each answers a different question. Read together, they describe the standards that an open mobility system needs.