MobilityData is a non-profit organization that develops and maintains mobility standards such as GFBS and GTFS. It recently started the GOFS project, which will result in GTFS-GOFS. The first part of GOFS will be released this year, and the TOMP-WG has been able to give advice and input for this first release. Instead of creating another standard, we agreed together to get aligned. The TOMP-API moved a bit towards the GOFS needs, making them generic and the initial GOFS proposal moved a bit towards the TOMP-API. Altogether a great example of how alignment further enhances interoperability!
What is the impact?
There are two major changes on the TOMP-API, but they are both non-breaking: a functional split of the ‘plannings endpoint’ and a simplification of the booking for single legs.
Functional split of plannings endpoint
We added 2 endpoints: ‘inquiry’ and ‘offer’. Both are in the planning module and will replace the endpoint plannings in one of the upcoming versions (it is marked as deprecated).
Inquiry is actually the plannings endpoint with the query parameter ‘booking-intent’=false. It is supposed to return a set of (in case of GOFS containing one or none) options. These options are not yet offers, but just informational requests. This endpoint can be called very often and shouldn’t delay the process of creating offers and booking them.
That’s also a reason why it is handy to split those 2 functionalities.
Offer, on the other hand, is a request to reserve an asset (although not final). This endpoint is the ‘bridge’ between the planning and the real booking and will replace the plannings endpoint with ‘booking-intent’=true.
Simplification of booking option (single leg)
The other extension is actually a simplification. In the previous setup, it was mandatory to return an array of legs in each booking option. For most implementors, this is a bit awkward: they always return only one leg, containing one asset (or asset type). In version 1.3.0 it will be possible to return booking options, without the legs. But
in that case, you have at least to return the start and end time in the booking AND supply the ‘mainAssetType’. That should be the asset type that was returned in the leg.
This example will clarify, this is in version 1.2.2
{ "validUntil": "2021-11-30T10:04:14.059Z",
"options": [
{ "id": "unique-booking-id",
"from": { ... },
"to": { ... },
"legs": [
{
"id": "unique-leg-id (in case of single leg, recommended to use the booking-id)",
"from": { ... },
"to": { ... },
"departureTime": "2021-11-30T10:04:14.059Z",
"arrivalTime": "2021-11-30T10:04:14.059Z",
"assetType": { "id": "simple car", "assetClass": "CAR" }
}
],
"pricing": {
"estimated": true, "class": "FAIR", "parts": [ { "amount": 3.96, "currencyCode": "EUR", "type": "FIXED" } ]
}
}
]
}And this in version 1.3.0:
{ "validUntil": "2021-11-30T10:04:14.059Z",
"options": [
{ "id": "unique-booking-id",
"from": { ... },
"to": { ... },
"departureTime": "2021-11-30T10:04:14.059Z",
"arrivalTime": "2021-11-30T10:04:14.059Z",
"mainAssetType": { "id": "simple car" }
"pricing": {
"estimated": true, "class": "FAIR", "parts": [ { "amount": 3.96, "currencyCode": "EUR" } ]
}
}
]
}
With those 2 adjustments, we can align with GTFS-GOFS, where GOFS will use the file-based structure to disseminate information (MaaS level 1), but we both (GOFS and TOMP-API) use the inquiry endpoint to get accurate options for a specific trip (in GOFS terms ‘accurate pricing’). Of course, it is free for TOMP implementors to return more data than GOFS demands. That would mean, that upgrading older versions of the TOMP-API for On-Demand Operators, implies you’ve already started with implementing GTFS-GOFS.
As TOMP-WG we could have a look together to make a generic translator around the current ‘Operator Information’ module, to produce the GOFS files.