1 / 23

Multimodal Trip Planning Application Mobility Provider Kickoff Meeting 12/13/2018

Multimodal Trip Planning Application Mobility Provider Kickoff Meeting 12/13/2018. TODAY’S AGENDA. Introductions Vision/Objectives  ​ Delivery Approach Open Source Operating System Schedule Mobility Provider Integration Why be Involved? Data Prioritization Staying Connected.

misaac
Télécharger la présentation

Multimodal Trip Planning Application Mobility Provider Kickoff Meeting 12/13/2018

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Multimodal Trip Planning ApplicationMobility Provider Kickoff Meeting12/13/2018

  2. TODAY’S AGENDA • Introductions • Vision/Objectives ​ • Delivery Approach • Open Source • Operating System • Schedule • Mobility Provider Integration • Why be Involved? • Data • Prioritization • Staying Connected

  3. MMTPA VISION • The future of transit is multimodal and on-demand • A shift away from personally-owned vehicles • A solution that uses both public and private entities • Integration with the Smart Columbus Operating System • One-stop shop to plan, book, and pay • As the regional public transit provider, COTA is the ultimate owner

  4. CITY OF COLUMBUS OBJECTIVES

  5. COTA OBJECTIVES

  6. PROJECT COMMUNICATIONS ​

  7. DELIVERY APPROACH​ • A foundation of open, free, and proven technologies. • A platform that is consistent with the Smart Columbus Operating System project. • A distributed ledger (“blockchain”) offers redundancy, transparency, shared governance, and long-term viability. • The assurance that user data is not available to anyone unless volunteered to release. • All user-facing apps use the same codebase, but can run on different devices (Android, iOS, kiosk, PC).

  8. OPERATING SYSTEM

  9. SCHEDULE

  10. SCHEDULE

  11. SCHEDULE • SPRINT 1: ROUTE PLANNING WEB APP – 12/11/2018 • SPRINT 2: RECORD TRIPS TO BLOCKCHAIN – 12/25/2018 • SPRINT 3: USER INTERFACE – 1/14/2019 • SPRINT 4: NATIVE MOBILE APPS – 1/28/2019 • SPRINT 5: COTA + 1 MOBILITY PROVIDER – 2/11/2019 • SPRINT 6: DATA COLLECTION – 2/25/2019 • SPRINT 7: FEATURES FROZEN – 2/28/2019 • Agile approach allows for user feedback and comments throughout the process.

  12. DELIVERY APPROACH​

  13. DELIVERY APPROACH​

  14. WHY SHOULD YOU BE INVOLVED? • Subsidies for traveler (Employer Pretax and National Transit Database (NTD) funding) • Increase in shared rides and linked trips to other modes • Understand travel patterns in the region • Allows mobility providers to identify gaps in transportation services • OS team will continuously analyze and update • Allows government agencies to: • Make policy decisions to meet the public’s travel needs • Understand shifts in transportation modes • Plan and invest in infrastructure improvements to meet the public’s travel needs • Access to funded Paratransit and NEMT trips • Connection to growing COTA ridership • Access to more riders (unbanked, low tech, mode shift from SOV) • Pay once across multiple modes • Promotion/marketing plan for MMTPA • Incentives and rewards will be used to promote use and services

  15. BUSINESS RULES • Encourage the use of accessible vehicles to make sure a reasonable number of accessible vehicles is maintained. • Maximize the riders per vehicle while still maintaining an acceptable added travel time (X) or deviation time for the travelers. • Encourage the use of transit as a leg of the trip if reasonable service is available from the origin to the destination. • Incorporate the traveler’s preference profile for tradeoffs between cost, trip time, walking distance and mode preferences. • Verify driver & vehicle qualifications to meet NTD requirements (Opt-in program with drivers)

  16. MMTPA DATA NEEDS FROM MOBILTIY PROVIDERS   • GTFS/GTFS-Real-time • Site: https://github.com/google/transit/tree/master/gtfs-realtime • Service Providers: Transit • GBFS (station) • Site: https://github.com/NABSA/gbfs/blob/master/gbfs.md • Service Providers: Car Share/Docked Bike Share • Modified GBFS (free_bike) • Site: https://github.com/NABSA/gbfs/blob/master/gbfs.md • Service Providers: Dockless Bike Share/Dockless Scoter Share • Modified TNC API • Site: See Modified TNC API • Service Providers: Ridesourcing (TNC)/Taxi/OnDemand paratransit/NEMT • Van Pool/Car Pool • Site: Waze Carpool API • Service Providers: Car pool, van pool, ride matching, etc. Future APIs • Parking • Site: Alliance for Parking Data Standards (APDS) https://www.allianceforparkingdatastandards.org/resources & ParkMobile/ParkColumbus App • Service Providers: Onstreeet Parking (IPS/Conduent), Garages, Lots

  17. TNC PROVIDERS DATA   • Provider_Locations allows check if the provider should be included in the selection process for a trip from/to a transit stop. In general, a 15 minute (configurable parameter) arrival time will be used to show available vehicles. • Service Provider, • Mode Type, • Driver ID (if applicable), • Vehicle ID, • Lat, • Long, • timestamp • Provider_Log table needs to be maintained in the OS to allow tracking of the activated trips for payment to the Ride Share Providers. It will contain: • trip unique key, • Timestamp (initiation, driver acceptance, arrival at origin, arrival at destination), • ETAs (initiation, driver acceptance, arrival at origin, arrival at destination), • origin, • destination, • provider ID, • driver ID, • driver rating • whether it was an accessible request, • was car seat requested, • customer ID, • transit tripID, • status (Completed, Cancelled by driver, Cancelled by Customer, Open)

  18. TNC PROVIDERS API   • Before pickup request • Provides qualified drivers in area to service trip • Confirmation request • Initiates trip request to selected driver • Allows drive response time • Logs trip to OS and payment to CPS • Vehicle update request • Updates vehicle location every 30 seconds from initiation to completion for traveler display and notifications • Customer rating request • Provides customer feedback and rating for driver and vehicle

  19. TNC PAYMENT AND SUPPORT    • Use business account to Provider API • All trip recorded to SmartColumbus business account when requested on API • Provide periodic reconciliation of services - Monthly, weekly, daily • Service Provider Web Portal • Dashboard for service provider monitoring • Reports available for all transactions and trips • Analytics showing predicted travel patterns and needs for all modes • Optional Access to CPS for your users • Can allow your app to provide payment on other modes of travel • PayPal like landing pages • Shared Traveler accounts in back office • Payment broker API checks funds availability

  20. CPS DATA NEEDS FROM MMTPA   • Landing Pages • CPS Login page (can save on phone, but not to OS) • Proof of payment page (QR Code, NFC, BLE, Bar Code, Activation Code) • Traveler account pages • Add payment methods • Add PII • Traveler parameters • Payment Broker • Data: request source, traveler account ID, service providerID, transaction amount, timestamp • IVR • Data: If telephone activation requested at HUBS or Web Portal then send: • tripID • Service providerID • travelerID • IVR Telephone #

  21. MOBILITY PROVIDER INTEGRATION 

  22. NEXT STEPS • Provide input on transportation capabilities by 12/21/18 • Support in developing agreements • Participate in Demonstrations • Bi-Weekly • Monthly (aligns with OS demonstrations) • Participate in Release Meetings • Milestone Dates

  23. Contact: Andy Wolpert adwolpert@Columbus.gov 614-230-1798 QUESTIONS?

More Related