Use of ITS Data in Transit Planning and Management at Metro Transit (Minneapolis / Saint Paul) John Levin Director of Strategic Initiatives

Use of ITS Data in Transit Planning and Management at Metro Transit (Minneapolis / Saint Paul) John Levin Director of Strategic Initiatives

2 Metro Transit at a Glance 15 th largest in U.S. 7 counties, 90 cities 121 bus routes 2 light rail lines 1 commuter rail line 900 buses, 86 LRVs 3,150 employees 300,000 daily rides We at Metro Transit deliver environmentally sustainable transportation choices that link people, jobs and community conveniently, consistently and safely.

Metro Transit ITS Technology TransitMaster AVL/APC AVL on 100% of buses and commuter rail trains APCs on 75% of buses and 70% of LRVs Internal and external bus announcements Internally developed real-time information system EMTRAC transit signal priority GFI fareboxes Cubic smartcard fare collection Ubisense internal bus garage locator systems On-board vehicle area network (VAN) in deployment on bus fleet

The Opportunities in Use of ITS Data There is an immense amount of data available about our operations Vehicle locations, including adherence to schedule (AVL) Boarding and alightings by stop (APC) Transit signal priority requests and responses (TSP) And much more. There are powerful tools available Data storage and processing Visualization and interactive reporting tools Delivery of reports and tools to front line employees Statistical methods for deeper analysis of trends and patterns

The Challenges in Use of ITS Data Getting quality data Linking data to scheduled / actual service Adjusting to ever changing scheudles Integrating data sources Leveraging tools for reports and visualizations Making decisions based on the data

Data Quality Hardware systems are generally reliable. Problems are usually easy to detect and correct Keeping up with geocoding of ever changing schedules Inconsistencies between the schedule and what actually happened Bad GPS reception Also, limits on what data is available Polling rate only every minute Do not have door open/door close events, traffic information, etc.

Data Matching Connecting observations back to the scheduled service is critical to many analyses Many commercial systems do a poor job with this task Evolution in approach Old method: Throw away questionable data Current method: Rematch data: by location, by trip Better way: Match data across data sets Significant investment in staff time to address issues Data has improved; Terminals continue to be a problem

Data Integration Connecting data at logical level (trip and stop) Data Mart updated by nightly ETL from multiple sources Fact / Dimension (Star schema) data structure Designed for ease and speed of reporting Avoid hits on source data systems for routine reporting Allows for value added data sources and semantic layers Aggregate data depending on lowest level of desired granularity (e.g. APC data for stop, trip, route)

Data Mart Structure

Value added: Bad Days How to track the context of the observations: Weather, construction delays and detours, special events, holidays, school breaks Used in two ways Exclude non-representative days to get normal condition Compare non-representative days to normal days Evolution Old way: Mental notes. Try to remember which days to exclude Current way: Database table by route, date and reason code Better way: More detail on specific impacts by trip, time and location

Value Added: Semantic Layers Link observation to related information What else happened on this trip? (early, late, ridership, etc.) What happened earlier or later on this trip? What happened on an earlier or later trip at same location? Apply agency metrics to the data What is an overload? What is a late or early bus? Where are there gaps/bunching of service? What are the logical segments of a route? Implemented at either ETL or data universe layer Transparent to the user of data Easy to edit code to recalculate fields without rewriting reports

Using the Data: What happened? High level summaries, KPIs Diagnostic reports: where are there problems? Drill down reports: slice and dice the data Visualizations

Using the Data: Why it happened? What caused the results that were observed? (Ridership, On-time performance, etc.) Operator behavior? Operator variation? Schedule factors: running time, recovery time External factors: ridership, traffic, detours, weather, obstructions, signals, etc. What can we do with this information Operator coaching and training Schedule adjustments Transit advantages, removing obstructions Service control strategies

Delivering Data to the Users: Current Tools Reporting tools delivered with systems TransitMaster Playback Fare data reporting Excel based tools Dialog window to specify data query, generate ODBC queries Pivot tables to aggregate / summarize data Mix of on-the-fly and pre-generated reports Crystal reports

Delivering Data to Users: In Development Interactive Web Tools Web-based reporting environment Input controls / filters create interactive tools More robust visualizations Combining reports/tools into dashboards Statistical Modeling / Predictive Analytics Ridership forecasting On-Time Performance modeling Real Time Tools Diagnostic reports Decision support tools GIS mapping of on-time performance, incidents, etc.

The bottom line Quality, Safety and Efficiency of service Providing data that guides decision making Schedule planners Route planners Operators and operations supervisors Street supervisors Control center dispatchers Developing the skills and processes to use ITS data effectively

Use of ITS Data in Transit Planning and Management at Metro Transit (Minneapolis / Saint Paul) John Levin Director of Strategic Initiatives john.levin@metrotransit.org 612-349-7789