Item 3.4 discussion re: planning and booking logic

[ro5k0]

Please find the notes from our meeting today for item 3.4 in the previous meeting notes. We look forward to discussing them in more detail tomorrow

ATT: Roberto, Gerke, Ross

Assumptions

• A TSP may have one or many of the following:
  • A free floating model (e.g. Felyx, Car2Go)
  • A back to one model (e.g. Cargoroo, Greenwheels)
  • A back to many model (e.g. Urbee)
  • A transit model (e.g. trains, trams, buses)
• A TSP may have a timetable for travel
• A TSP may have an availability status (what that is depends on TSP e.g. Asset, seat, route [train, tram, bus])
• A TSP may or may not allow a booking in advance

Discussion points

• A TSP only needs to know the following (free-asset-status as a POST request):
  • Start location (can be calculated by MaaS provider as a fixed station based on static information)
    • Radius from location
  • End location (can be calculated by MaaS provider as a fixed station based on static information)
    • Radius from location
  • Start date/time
  • End date/time
  • Meta information relating to asset type requirements
    • Disability
    • Can share
    • Fuel type
    • Etc
• Station information needs a type as it may not be a conventional station
  • Could be a virtual station or an area of operation or a physical stop
  • Needs to have a GeoShape rather than lat/long as it may be a polygon, a point, or a point with radius (circle)
• On free-asset-status need to:
  • Clean up description and remove the additional dictionary at the top of the array
  • A timestamp to show when the system defined the asset as being available
    • Timestamp should have a timeout to show how long the TSP can guarantee the information will be valid for (could be 0 for infinity or number of seconds from timestamp)
      • This allows a MaaS provider to favour items that have more certainty
      • This allows a MaaS provider to know which order to make a hold on a booking
  • Duration of hold allowed while booking before a reservation starts
    • This takes the belief that you can hold an item in order to start a booking process without financial repercussions on systems that charge for a reservation on a booking
  • ClaimID to make the booking with in order to save having to re-request all the data just to make a booking
    • This is based on the assumption that planning to a TSP is just a query about if a booking can be made (see below)
• Booking may be planning because as a TSP we have no concept of planning. We just return data about what assets are available. The MSP is the one who handles the planning based on the information the TSP returns. Therefore the same API call could be made with a different status (e.g. QUERY, NEW, START, END, CANCEL)

Discussion for meeting on 10/07/19

• Need to define a what a trip is between the different TSPs
  • What and who handles a leg? Is it a MSP or a TSP?
• Look at defining endpoints to make them more defined against an object type
  • Specific methods and actions should then be defined against those endpoints to allow for additional actions to be added easily

[efel85]

I've created this sequence diagram based on our discussions of the past two working groups. Let's discuss tomorrow if this covers what was decided.