edwinvandenbelt
commented
2 years ago Just a thought: start:
- GET /legs/{id}/available-assets to retrieve available docker/bike combinations (returned asset = locker)
- POST /legs/{id}/events - ASSIGN_ASSET with id to open up the locker; the returned asset is the bike inside
- POST /legs/{id}/events - SET_IN_USE to open up the bike
return:
-
POST /legs/{id}/events - START_FINISHING to return available empty locker OR
-
GET /legs/{id}/available-assets to retrieve available empty docker (returned asset = locker)
-
POST /legs/{id}/events - ASSIGN_ASSET with empty locker id to open up the locker
-
POST /legs/{id}/events - FINISH to close bike lock
Unhappy flows -> support module
Currently a TOMP booking leg is designed to typically address travel from A to B, where A is a source and B a destination. However, there are some modalities that do no map to this model in a straightforward manner.
For instance, when booking a parking space, it is arbitrary if we'd consider the parking location the source or the destination. Hence we should come up with some guidelines on how to specify a parking location.
Another example concerns docking stations or bike lockers where the pick-up locker does not necessarily have to be the same as the return locker. What are the assets in this case? Just the bike? Or also the docking stations? In this scenario I think that docking stations and lockers should be considered infrastructure (Station properties) rather than assets. However, if you actually rent a locker to park your bike in (compare parking your car in a parking space), it actually makes sense to regard the locker as an asset.
My main point here is that it may not be immediately obvious how to model these entities, depending on subtle details of the scenario. We should strive to standardize these to prevent that different parties are implementing it differently, because it can become very complex very quickly.
Urgency
Minor: currently solved in proprietary App.
Additional context
Some typical scenarios and context: 1A Booking a specific parking space in a location 1B Booking a parking space type in a location 2 Booking an ebike, that should be picked up from a specific locker. On returning the bike, the user should be directed to an available free locker (not necessarily the same as the pickup locker). In addition, the user should be informed if the bike is not properly connected to the charger, and ensure that the user closes the locker door. 3 Booking a locker to temporarily store and charge your own, or rented ebike. Customer should be charged for both locker rental time and charging time (which can be different).
Describe the solution you'd like
We have implemented the details of scenario 3 outside TOMP and within our proprietary App. I am not sure to what extent the details we implemented can or should be moved to TOMP, but they involve what we call 'pickup' and 'return' actions. These are actions that the user must perform when picking up and returning a bike respectively. And there should be a channel via which the user can be guided. For instance: Pickup:
Describe alternatives you've considered
Currently we handle everything that is not supported by TOMP, in the proprietary App.
Possible Implementation
Some hints: when a locker or docking station is actively used during a leg, it should be considered an asset (see scenario 3), if a locker or docking station merely serve as a pickup / dropoff point, it should probably be considered infrastructure or station properties.