OSDM - CDSM-WG/CDS-M GitHub Wiki
OSDM consists out of 2 parts: an offline and an online part.
Offline: Within the offline sales model the participating companies agreed to allow sales based on the provided fare data. The receiving company is responsible to apply the rules defined within the fare data. In case the implementation does not cover some features it is not allowed to sell fares that use these features.
Online: Specifications for the OSDM API standard. The OSDM specification supports two modes of operation: Distributor Mode and Allocator Mode. The API works the same in both mode, except that in allocator mode the API also returns fare information. The OSDM specification combines the allocator and distributor modes into one aligned API interface.
The aims of the Open Sales and Distribution Model (OSDM) are twofold:
- to substantially simplify and improve the booking process for customers of public transport trips and,
- to lower complexity and distribution costs for distributors and carriers.
OSDM strengthens rail and public transport as a convenient and ecological means of transportation by simplifying distribution. Finally, it lays a solid fundament which can be extended to the distribution of other means of transportation.
The OSDM Online API and specification essentially consists of two parts: Offline Model and Online API. The Online API works in two modes: Distributor Mode and Allocator Mode. The Allocator Mode differs from the Distributor Mode only in that additionally to Admissions (aka. tickets), Reservations, Integrated reservations, or Ancillaries also Fares (priced segments) are offered and can be booked.
Reference
Data concepts
OSDM covers a lot of concepts. First we'll address the offline part.
Offline
| Concept | Remark |
|---|---|
| delivery | |
| calendar | |
| Service | levels, classes |
| Fare | prices |
| constraints | Regional, service, carrier, passenger, ... (a real big portion about constraints) |
| after sales | conditions |
| cards | |
| locations | connection points, stations, zones |
Online
| Concept | Remark |
|---|---|
| places | |
| trips | |
| offers | |
| bookings | |
| fares | |
| reservations | |
| passengers | |
| purchaser | |
| fulfillments | |
| refunds | |
| exchanges | |
| complaints | |
| products | |
| coach layouts | |
| reduction cards |
Modifications
None.
MDS Details
Configurable fields
The fields in the JSON are described here, but only those that need explanation. The values in the building block, are fixed, unless they are between square brackets ([]).
| name | required | value | description |
|---|---|---|---|
| version | * | [version] | The allowed version(s), comma separated. Replace this value by f.x. "1.2,2.0,2.1" |
| url | * | [url] | The URL where this file (or endpoint) can be found, f.x. "https://example.transporter.com/gbfs/system_regions.json" |
| refreshRate | [refresh rate] | The refresh frequency. Specified in 8601 Duration (see https://en.wikipedia.org/wiki/ISO_8601#Durations). f.x. "PT5M" for 5 minutes. |
Dimensions
| name | value | argumentation |
|---|---|---|
| privacy | A | for all endpoints containing data without the combination location/timestamp |
| B | for all endpoints containing data with location/timestamp | |
| implementationEffort | D | When it is implemented as separate files, it is the simplest implementation, an A. This limits also the possibility to authenticate, and the available assets files more or less require an API endpoint solution. Therefore it is marked as a D. |
| reusability | E | This is a domain-specific interface, with very limited possibilities to use outside the scope of city-mobility provider |
| interoperability | A | This is a worldwide standard (A). |
| domain | A | Applied in the domain city-transport operator, it is absolutely an A |