search

TOMP-WG / TOMP-API

Transport Operator to Mobility-as-a-Service Provider-API development for Mobility as a Service
Apache License 2.0
96 stars 41 forks source link

TSP definitions and MSP models #46

Closed ro5k0 closed 4 years ago

ro5k0 commented 5 years ago

Based on the discussions at the meeting today I feel it would be good for us to list a definition of what type of service, with limitations and options, that different TSPs provide.

My feeling is that currently a lot of the work has been geared towards traditional public service providers, and schemas, which don't necessary consider new forms of shared mobility.

I believe this will give us a clearer understanding when having future discussions about what variables we need to consider when creating endpoints as a TSP for consumption by various MSP models.

It would be good if we can complete this process for known TSPs who may not be at the table.

It would also be good to complete this for MSPs with different business model types (e.g. no-trip planning single point, single asset pick-up and return) so we have a full picture of who we need to encompass when creating data beyond existing platforms.

ro5k0 commented 5 years ago

Cargoroo

Description Cargoroo is a back-to-one TO that provides cargo bikes for immediate hire. Due to the type of vehicle we offer, we have defined the back-to-one model as being the most appropriate for our business model and use cases.

Station Type & Info All our stations are virtual in nature and may be represented as geoshape (a circle or a polygon). Currently only one asset is assigned to a single station for use.

Stations can and may be moved. This may be at the request of the City or location manager that the station is located. It could also be in order to maximise fleet usage internally. There is no set duration or time that this will occur.

There are currently no posts or visual identifiers defining a station except for the bike being in position. This may change in future.

Asset Type & Info All our assets are cargo bikes. They have a standard configuration with a hot swappable battery. Additional configurations to this bike that we currently have is if the cargo bike has Maxi-Cosi (child car seat) adaptors available for use in the bike.

A user can currently filter our assets based on: Availability; Distance from a users current location; SOC on the batter; If the bike has the car seat adaptors.

Shared Mobility Model We operate a back-to-one model which means a user must pick up and return a hired asset to the same location.

This means our concept of end location will always be the same as the start location. We do not have a defined end time (see below).

Bookings We do not currently allow advanced bookings within our system. This means we do not have an end time relating to a trip. A user must immediately reserve a bike to enable it to be held for usage. They are then free to use the bike within a 24 hour period for a duration up to 24 hours (to comply with our T&Cs).

When a user reserves a bike they get a 20 minute window in which to be positioned next to the bike and to have opened the lock. Before the lock is opened and during the 20 minute window the booking is in the state of CLAIMED.

Once the lock is opened the booking is REDEEMED.

If the lock is closed outside of the station geofence that the bike belongs to the booking/trip is in a REDEEMED state.

If the bike is within the station geofence to which it belongs and the lock is closed then the booking is ENDED and cost calculations for the booking are carried out.

If a user fails to open the bike during the reservation period then the booking goes in to the state of EXPIRED.

Trips A trip occurs when a user is in the state of REDEEMED within a booking. The trip has six key states:

Limitations

efel85 commented 5 years ago

Decided on 24/7: everyone should fill in this template above for their own company/business model.

Feel free to add missing information. The end goal is to create a spreadsheet that includes an overview of the different models.

pimmeh commented 5 years ago

InTraffic

Description InTraffic has a two propositions. The first one is multimodal trip planner that is offered via an API to MaaS providers. With parameters such as starting location and destination, along with preferences, a multimodal trip is provided. Modalities consist out of the ones that are connected to our trip planner. The second proposition is the trip follower, also offered via an API to MaaS providers. When an end user books a complete and multimodal journey, that journey is saved in our trip follower that will monitor the trip. When there is, for instance, a disturbance, the trip follower communicates back to the user what that is and might include an alternative journey.

TURNN

Description TURNN is the MaaS provider app of the ICT Group (of which InTraffic is also apart). TURNN uses the multimodal trip planner from InTraffic. End users can book transport on demand, receive tickets for their journey, travel with public transport, etcetera.

paxx-dev commented 5 years ago

PAXX

Description 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).

Requirements w.r.t. shared mobility 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.

edwinvandenbelt commented 5 years ago

DAT.Mobility

Description DAT.Mobility is an organisation delivering advise and products about mobility and IT. We are in this community to learn about this environment and we will actively contribute to it. Therefore we will cooperate with Kyyti and GoOV to add a contribution to the MaaS environment in the Netherlands (and even abroad). In the past we were actively involved in the OpenTripPlanner (plannerstack) and we've developed a lot of custom trip planners, monitoring software and we're very familiar with integrating (mobility) applications.

GoOV

Description GoOV wil bereiken dat mensen die moeite hebben met zelfstandig reizen, zo veilig en zelfstandig mogelijk kunnen reizen, met behulp van hedendaagse technologie en tegen lagere maatschappelijke kosten dan de huidige vervoersoplossingen.

Kyyti

Description Kyyti is a Finnish MaaS provider, willing to operate on the Dutch market as extension to their Scandinavian operating field. They are also active in Austria.

tubublobz commented 5 years ago

CITYWAY

Description Cityway is a France-based MaaS-operator that helps Transport Authorities to implement mobility data warehouses and then build local MaaS apps on top of it. Our historical technological strength is our transit trip planner, multi-modal and predictive. We are working on aggregating mobility offers in given areas and create a mobility account that simplifies mobility for the traveler. Here we created a generic Partner API in order to industrialize the integration of new Transport Operators.

Mobility Account / Partner API The mobility account is one of our newest product (live in Mulhouse & beta-phase in Saint-Etienne - France).

It gives access to a lot of Transport Operators : • Unlocking a shared-car or a shared bike, • Lifting the gate at a parking lot • Using public transportation tickets

The traveler then pays one bill for all usages at the end of the month. He can monitor his consumptions during the month and soon he’ll be able to buy “mobility packages”. In order to gather all those services in one app, we have to integrate the web services of all partners/transport operators.

For this we created a Partner API that helps us standardize communications with partners/transport operators.

We are here to take good ideas and share already implemented one in our projects.

efel85 commented 4 years ago

contribution from GVB (municipal transport operator in Amsterdam):

GVB

Description GVB is the public transport operator in Amsterdam. Daily almost 900.000 travellers use our services. GVB operates metros, trams, busses and ferries. All these modalities use predefined time-tables and travel along predefined routes from station to station.

Station Type & Info Stations vary from large metro stations aimed at large volumes of travellers to simple stops for busses. All stops are clearly identified. Using PT planners the nearest stop can easily be found. This information is publicly available as open data.

Asset Type & Info GVB operates trams, busses, metro’s and ferries. Realtime information about their current position is publicly available as open data.

Shared Mobility Model GVB operates a many-to-many? model, offering journeys from almost any place in Amsterdam to any place in Amsterdam.

Bookings At this moment GVB offers various methods to pay for a trip. • OV chipcard • With preloaded cash • With subscriptions for Amsterdam or part of Amsterdam for a fixed amount of time • Disposable OV chipcard • For a fixed amount of time (1hr, 1 day upto 7 days) • Voucher • To pay for disposable OV chipcards in advance

Currently GVB is changing its system so we can accept 2D barcodes to travel. This will be in production Q3 2020, first on metro. In 2022 GVB will start to accept EMVc (contactless bankcards) to pay directly for trips. Ferries are free for walking or cycling passengers.

Trips Trips are either defined as a journey from a metro-station to another metro-station or a journey in one vehicle from a stop to another stop.

Limitations We do not allow a user to book in advance for a specific trip, and do not offer a seat guarantee.

edwinvandenbelt commented 4 years ago

Added everyone in the Wiki. Please close