-
Notifications
You must be signed in to change notification settings - Fork 41
Trip execution phase start
home > Trip execution phase > Start
The trip execution phase can be started in several ways:
- The end-user opens the first asset, the required access information has been delivered by the TO in the Prepare event or in the Commit of the booking phase
- The TO is starting the leg (e.g. rides the taxi to the end-user)
- The MP will start searching for a physical asset near the end-user
The end-user is near the booked asset, requests to open the asset (online). The app signals the MP, and the MP calls the TO:
POST https://exampleTO.com/legs/746ac-48792bb-746dac3/events/
{
"operation": "SET_IN_USE",
"asset": {
"assetId": "bike1",
"place": {
"coordinates": {
"lng": 6.169639,
"lat": 52.253279
}
}
}
}
The bike should be opened now by the TO. In case there is not yet assigned a specific bike to the booking, it should be assigned now.
The app has to send the information to open the bike (e.g. using Bluetooth). The app has to inform the MP that the asset is in use, only after the bike is opened.
POST https://exampleTO.com/leg/746ac-48792bb-746dac3/events
{
"operation": "SET_IN_USE",
"asset": {
"assetId": "bike1",
"place": {
"coordinates": {
"lng": 6.169639,
"lat": 52.253279
}
}
}
}
The TO can have assets that have to be prepared before they can be used by the end-user. For instance a taxi operator or a bike parked in a carousel. Let's say we're a taxi operator. We've scheduled the leg and our taxi driver is leaving the garage.
We have to inform the MP (and thereby also the end-user):
POST https://exampleMP.com/legs/746ac-48792bb-746dac3/events
{
"operation": "PREPARE",
"asset": {
"assetId": "taxi3428",
"place": {
"coordinates": {
"lng": 6.169639,
"lat": 52.253279
}
}
}
}
After starting the leg with the end-user on board, we have to send
POST https://exampleMP.com/legs/746ac-48792bb-746dac3/events/
{
"operation": "SET_IN_USE",
"asset": {
"assetId": "taxi3428",
"place": {
"coordinates": {
"lng": 6.169639,
"lat": 52.253279
}
}
}
}
The last scenario is that an upfront booked asset type has to be searched for. The MP will search for an available asset nearby the end-user, let's say about 15 minutes before start time.
GET https://exampleTO.com/746ac-48792bb-746dac3/available-assets
This one will give all available assets nearby. The MP (or end-user) can select one, the asset can be assigned to the leg:
POST https://exampleTO.com/legs/746ac-48792bb-746dac3/events
{
"operation": "ASSIGN_ASSET",
"asset": {
"assetId": "bike18",
"place": {
"coordinates": {
"lng": 6.169639,
"lat": 52.253279
}
}
}
}
After this, scenario 1 can be followed.
The LegEvent object reflects an operation on the leg, like requesting access information, opening a lock / informing about an opened lock, pausing, closing a lock / informing about a closed lock, assigning assets, extend the leg, or postponing the leg.
Leg
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