-
Notifications
You must be signed in to change notification settings - Fork 41
Asset based
Asset based planning will need an identifier to distinguish the asset you're looking at (or at least should be nearby). This identifier can be found in several ways, using Bluetooth or another identifying method. It will be very likely that you can directly send a planning request with booking intent; you don't have to plan a trip. By using the booking-intent=true the TO will generate offer(s) for the asset directly.
For a description of the endpoint itself, see Planning based#request.
Whenever you want to require the MP to do planning and booking in one go, you should add 'ATOMIC_PLANNING_AND_BOOKING'. It will force the MP to request a planning with booking intent and directly book the returned asset, without user interaction.
For Bluetooth we need to do a bluetooth swipe before we can plan/book the asset, adding all found bluetooth devices in the planning request:
POST https://exampleTO.com/plannings/?booking-intent=true
{
...
"useAssets": [ "2058f89b-9aec-4515-9ee1-f453fccd71fe", "61d4a23a-248d-497f-ab7b-9b36dfec2568", ... ],
...
}
The TO can look into his known bluetooth operated assets and respond with a planning option for each matching asset. To request the MP to add Bluetooth IDs in the request, you should add 'ASSET_BASED' and 'BLUETOOTH_SCAN' in your process indentifiers (GET /operator/meta) more....
It is also possible to request assets for a specific station. Adding 'SPECIFIC_LOCATION_BASED' to the process identifiers will force the MP to add at least a stationId in the 'from' field (or a stopReference in case of a public transport operator):
{
"from": {
...
"stationId": "string",
...
}
}
Other identifying methods, like QR code, NFC, Barcode or manual entry of an identifier, work simular. Instead of sending the Bluetooth IDs, the QR code, NFC ID, barcode number or manual entered ID should be sent in the 'useAssets' array. Of course the appropriate process identifier should be added in the meta endpoint (GET /operator/meta) more....
Introduction
- Roadmap
- Semantic versioning
- Use cases
- Changes per version
- Contribution
- Participants
Workflow
- Operator information
- Planning phase
- Booking phase
- Trip execution phase - start
- Trip execution phase - on route
- Trip execution phase - end
- Support
- Payment
Points of attention
- Modalities
- Specifying locations
- GDPR
Eco system
- Relations
Introduction
Scope of the TOMP-API
Versioning and releases
Process Flows
- Authentication
- Operator Information
- Privacy and Registration
- Planning Module
- Booking Module
- Trip Execution Module
- Payment Module
- Support Module
Meta-Information
Reference implementations
To-dos and risks
Technical Specifications
A1 List of terms and definitions
A2 Passenger characteristics dictionary
A3 APIs available on the transportation ecosystem
A4 Overview of the User stories
A5 Authors, Architects, collaborators and stakeholders involved
A6 Adoption and Implementation of the TOMP-API