-
Notifications
You must be signed in to change notification settings - Fork 41
Planning phase
The planning phase is quite simple with respect to the API: the Transport Operators (TOs) can be asked what assets they have available. This can be done using a request with fields like: from location to location, timestamp to start, timestamp to end, the number of travelers, and their (dis)abilities.
The planning endpoint has 2 flavors: one for quick searches (booking-intent=false) and one for creating offers (booking-intent=true). The first one is optional, but the TO should take into account that this flavor can be used a lot. Therefore it is not needed to be very accurate; the booking-intent=true should be accurate.
From version 1.3.0 these two flavors are split into 2 separate endpoints: /planning/inquiry and /planning/offer (see #402).
Within the planning phase we distinguish 3 'scenarios':
- Asset based: without long term reservation, book and open asset to use (e.g. using Bluetooth)
- Planning based: long term reservation, assign physical asset later on
- Map based: using a map to depict all the available assets to book one
There are also a few specific requirements you can possibly have to deal with:
- Requiring specific data (like addresses, licenses, phone numbers) for booking
- Return area
- Postponed commit
To integrate access methods (like deeplink, QR codes, etc.), look at this page.
From version 1.3.0 it is also possible to enlist things you bring along (like luggage or a bike) and ancillaries you need. Look here.
- Planning request: this request requires the information needed for planning. How the content should be filled, is described here and partially mandatory, dependent on the processIdentifiers.
- Planning result: the results are bookable objects, each containing a (sequence of) legs. If you're implementing and return max of 1 leg per booking, use the same ID for the booking as for the leg, for convenience reasons.
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