-
Notifications
You must be signed in to change notification settings - Fork 40
PAXX
PAXX is a MaaS provider app and multimodal trip planner. The app will not just give advice but also let users book and can show access tokens where applicable. Among the travel modes we use in the planner will be various forms of shared mobility. In the trip planner we will include some option for staying somewhere for a while, which could be in the middle of a trip using shared mobility (e.g. go to an appointment for an hour and then go back).
In the planning phase we want to show the user many different options, both for the route they might take and for the brand/type of shared mobility they may use. For this we need the nearby vehicles available given the A->B trip and associated departure and arrival time (or A->? trip for floating bicycles). This could be immediate availability or for some time in the future, in which case we could use options like 1) paying more to reserve a vehicle at the specified time or 2) being able to give a likelihood of a vehicle being available at the given time.
For booking we don't have any further requirements on the TSP to know anything about the entire trip we're planning, only the starting location, destination point/ area/ station and the time at each - essentially just the leg in question. We also see bookings also as not for a specific vehicle but for any vehicle at the requested location that fulfils the user's requirements. We would like the process to be as smooth as possible, so the web hooks for availability updates and booking stages are important so shown trips are actually bookable. Booking should also be able to take place without a complex sign-up process, required deposit or long background checks for the selected TSP(s). In our view this should be solved with the universal MaaS user id's and shared fraud list, and not be something that happens on a per-booking basis.
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