1 / 18

Review of Fare Collection Concept of Operations and High Level Data Requirements

Review of Fare Collection Concept of Operations and High Level Data Requirements. FC RSTWG Webinar May 19, 2010 2:30 – 4 pm Prepared by: Paula Okunieff, Con SysTec. Regional Fare Calculator (Appendix B-1) Marketing Study related to Fare Elasticity (Appendix B-2)

wilson
Télécharger la présentation

Review of Fare Collection Concept of Operations and High Level Data Requirements

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. Review of Fare Collection Concept of Operations and High Level Data Requirements FC RSTWG Webinar May 19, 2010 2:30 – 4 pm Prepared by: Paula Okunieff, ConSysTec

  2. Regional Fare Calculator (Appendix B-1) • Marketing Study related to Fare Elasticity (Appendix B-2) • Operational Scenario #1: Service Improvements for Low Income/Welfare Populations • Operational Scenario #2: Ridership Improvement Study Use Cases / Scenarios

  3. Trip Plan (API) Data Inputs Processes Data Outputs Fare Calculator Rider Characteristics / Usage General Cost Fare Cost API (for Trip Plan) Transfer Rules Promotion / Restrictions Fare Calculator System Description Interagency Transfer Rules Customer

  4. [N-1] Need for a Trip Planning API. • [N-2] Need for Customer Characteristics and Usage to describe Rider Characteristics and Preferences. • [N-3] Need for information from Providers / Carriers on fares, fare promotions and restrictions. • [N-4] Need for information from Providers / Carriers on transfer rules. • [N-5] Need for information from two or more Providers / Carriers on their agreements for transfer between services. • [N-6] Need for fare cost interface Fare Collection: Needs

  5. [N-1] Data Needs • Origin (first stop – locationID and related agencyID) • Scheduled start time / date • Destination (last stop – locationID and related agencyID) • Scheduled completion time / date • Number of legs • Parking (enter and leave) -- optional • For each Leg • Provider • Mode • Route, route direction • Trip information: tripID, service type, day type • Starting trip time and location • Ending trip time and location • Distance between starting and ending location Need for Trip Planning API w/Info Trip Planning API will trigger the request for estimated Fare Cost for a specific trip. The information in the API should include the following:

  6. [N-2] Data Needs • Number of people traveling • For each person • Age (if a child – under 13 yrs old, then the child’s height) • Eligibility [disabled, student, senior, regular] • Preference for fare product • Other criteria (e.g., return trip ticket, frequent traveler, etc.) Need for Customer Information and Usage Info Fare information should include information on rider characteristics and usage such as: Rider class Number of riders Preference for fare products Other characteristics

  7. [N-3] Data Needs • From N-1 Data • Carrier • Mode • Origin, destination or both • Route, route direction • Trip information • Departure date / time • Day type • From N-2 Data • Fare product type and use • Number of travelers • Rider class • If available from N-2 data • Frequency of travel • Payment option • Product purchase time / location Need for Fares, Fare Promotions and Restrictions The fare promotions / restrictions should be tagged to one or more of the following parameters… Note: fare structure may be flat, zone, distance and/or time based

  8. [N-4] Data Needs • Mode to mode • Route direction of previous and next trips [order of trip legs] • Arrival (or departure) time of previous trip and departure time of next trip • Additional information (derived from fare media): • Shared or bundled fare product(s) for trips (trip plan) Need for Transfer Rules (for each Provider) Each Provider / Carrier should provide information on Transfer Rules. Information derived from the Trip Plan API [N-1] include…

  9. [N-5] Data Needs • Carrier to carrier • Rider class definition • Mode to mode • Route, route direction (of previous and next trip legs) • Arrival (or departure) time of previous trip and departure time of next trip • Additional information (derived from fare media): • Shared or bundled fare product(s) for trips (trip plan) Need for Transfer Rules between Providers Provide information on Transfer Rules between Carriers. Information derived from the Trip Plan API [N-1] include…

  10. [N-6] Data Needs • Trip Plan (from N-1) • Total base cost • Additional information (derived from fare media): • Shared or bundled fare product(s) for trips (trip plan) Need for Fare Cost API Interface that provides information on Fare Cost

  11. Describe Data Requirements • Define Data Concepts, entities and attributes • Describe relationship model (ERD) Moving towards Requirements

  12. Fare Data Model A CUSTOMER generates a PASSENGER TRIP PLAN (PTP). The PTP is composed of one or more LEGs from the CUSTOMER’s ORIGIN to DESTINATION. Each LEG (start and end points; start and end times) is associated with a segment of an AGENCY’s TRIP. (The TRIP is also associated with a MODE-specific TRANSIT VEHICLE, trip type, and other service features.) The FARE may be based on the GEOGRAPHIC UNITs traversed (e.g., DISTANCE traveled, or number of ZONES passed through) for each LEG (ORIGIN to DESTINATION), and the TIME PERIOD (time, date, and duration) when the LEG is to occur. When the PTP has more than one LEG, the total FARE may be the sum of FAREs for each LEG, or the CUSTOMER may transfer (be granted ACCESS RIGHTs) from one TRIP to another with a DEFAULT FARE or composite FARE based on the implementation of BUSINESS RULEs including DISCOUNTs and USAGE FACTORs. The CUSTOMER may purchase one or more FARE PRODUCTs that allow the CUSTOMER a variety of ACCESS RIGHTS to travel and transfer over different GEOGRAHPIC UNITs (Distance/Zones), TIME PERIODs (day type, length of days, time interval during a day*, date*, month*), and between AGENCYs, SERVICE TYPEs (i.e., express vs. local) and MODEs, sometimes governed by the ORDER OF TRAVEL. A BUSINESS RULE may be applied to the FARE COST based on the FARE PRODUCT used, or different USAGE FACTORS such as round trip fares, restricted geographic region, FARE TRANSACTION LOCATION, or the CHARGING METHOD applied to purchase the FARE. Additionally, a DISCOUNT may be applied based on number of people traveling (group and family “tickets”), rider class type, or marketing campaign. * Associated with a “named” period of time, e.g., 7am-10am, 1-1-2010, September

  13. Fare Cost… is the intersection of Passenger Trip Plan (N-1), Fare Structure (N-3) and Access Rights (Business Rules) (N-2 to N-5) and how it applies to the Customer(s) (N-2)

  14. Fare Structure [N-3] Each trip has a “default fare” based on an Agency’s Fare Structure for different classes of riders.

  15. Trip Plan [N-1] Description

  16. Access rights are one or more business rules Access Rights / Business Rules [N-2, N-3, N-4, N-5]

  17. One or more customers may be associated with the PTP or the FARE Customer Description

  18. Augment model to map to needs • Refine language in ConOps to better express data concepts in Data Requirements • Publish Systems Engineering Documents (due late June) • Final Concept of Operations • Draft Data Requirements for Fare Collection Next Steps

More Related