-
Notifications
You must be signed in to change notification settings - Fork 41
LegEvent
home > Trip execution phase > LegEvent
The leg event is an operation on a leg:
PREPARE the TO can send a message telling the MP that he is preparing the booked leg [To be implemented by the MP] (see (7.2) in the process flow - trip execution). In the result the leg can contain the access information, like deeplinks, QR codes etc.
ASSIGN_ASSET can assign an asset to a leg. Can be to assign an asset in case there is still an asset type assigned [Optionally implementable by the MP]. See (4.7) in the process flow - trip execution
SET_IN_USE will activate the leg or resume the leg [TO and MP] (see (4.6) in process flow),
TIME_EXTEND will be used to request an extension in time; the end user wants to use the asset longer, the time field contains the new end time,
TIME_POSTPONE will be used to request a delay in the departure time, the end user wants to depart later, the time field contains the new departure time,
PAUSE will pause the leg [TO and MP] (see (4.6) in process flow),
START_FINISHING will start the end-of-leg [Optionally implementable by TO and MP],
FINISH will end this leg (see (4.6) in process flow) [TO and MP]
| field | required | description |
|---|---|---|
| time | * | Time of the event (local date), ISO 8601 |
| event | * | The 'event type', see above |
| comment | free text, should match Content-Language | |
| url | this field is only used to provide URI's containing proof for leaving the asset behind in an appropriate way, START_FINISHING or FINISH. | |
| asset | the asset related to the event. Is optional, only mandatory in case of ASSIGN_ASSET or when one of the process Identifiers starting with LEG_EVENT_LOCATION_REQUIRED_ is used. |
POST /legs/{id}/events
{ "time": "2021-04-14T15:54:58.324Z", "event": "PREPARE" }
This event could be used to indicate to the TO that the end-user is preparing to start the leg. The result can contain the needed information to open an asset.
Details
See Process Identifiers
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