QUALITY STRATEGIES IN SYSTEMS DESIGN

1. Strategies for Organization, Validation and Distribution of Transit Geographic Information Systems Data Jonathan WadeManager, Service Development SupportRegional Transpiration District, Denver, COGIS in Transit Conference, October 16-17, 2013, Washington, D.C.

2. QUALITY STRATEGIES IN SYSTEMS DESIGN • Base routes and schedules on real, quantitative data to constantly monitor to improve the customer experience • One database of record for each data element • Use best available database and consolidate data wherever logical • Fix errors at their source • Immediate feedback loops to fix errors • Frequent, automated processes to incorporate revisions and fixes in downstream systems • Constant and continuous incremental upgrades to data and systems

3. Base routes and schedules on real, quantitative data Requirements for persuasive presentations of data: The data is complete Stop data Ridership data The data is accurate Passes all validation processes Updated frequently The data is readily available Uses know where and how to access the data quickly

4. constantly monitor to improve the customer experience Bus stops defined Routing defined TriTapton-time performance analysis Other schedule data Time points Bus stops defined Ridecheck Plus ridership analysis and reporting TIES DB for error checking, production and data collection INIT CAD/AVL /APC data collection Trapeze scheduling Can we improve the customer experience?

5. improving the customer experience Scope of GIS and Schedule Data Changes • 3 Major run boards year (usually in August, January and May) • 30 to 50 revisions to each run board after voting • Minor changes: footnotes, running time changes • Major changes: rerouting, modifying operator run • 50-75 Special Services each year (scheduled in Trapeze) • Examples: Broncos Ride (football), Rockies Ride (baseball), etc. • About 1100 Special Service orders per year (scheduled in TIES)

6. Lines Points Schedules Polygons HIGH-LEVEL DATA FLOW Schedule Development Database (Trapeze) • Data entered by Service Planner/Schedules • Customer interfaces • Trip planners • Web schedules • Paper schedules • Operations Interfaces • CAD-AVL Systems • Operator pay • Ridership and schedule adherence systems Production Database(TIES – developed at RTD) Customer Interfaces Operations Interfaces

7. GPS Bus Stop Data FlowDatabases of Record for Stop data Trapeze FX Visual GPS Verification Append New GPS Data - Shape file Upload GPS Arc Catalog Method 2: GPS Field Data Collection Merge Shape file to Staging Table (Model Builder, Arc Toolbox, Arc Catalog) Processing1. Sequence on route2. Extract stops on patterns 3. Calculate distance 4. Calculate estimated stop times for each trip Trapeze, database of record for geographic coordinates and relationships of stops to routes Method 1: Stop Tool Data Entry Update SDE Bus Stops in Oracle Coordinates only Convert stop names from upper case Method 3: Edits Convert stop names to all upper case TIES Maximus (Asset Works) database of record for stop names and stop amenities No Coordinates

8. Bus and LRT Schedule Data & Bus Vehicle Assignments (Trapeze & TIES) Commuter Rail Schedules & Vehicle Assignments(Hastus and TIES) INFORMATION FLOW CONSOLIDATING RIDERSHIP DATA RTD Collection Staff InitAutomated Passenger Counting System 6ServiceMonitorsLaptops (ridechecks/pointchecks) 2 StationStartersDesktop (pointchecks) 42 LRT Cars (of ~ 178)APCs (ridechecks) 43 Street & LRTSupervisors Laptops (pointchecks) 56 CommuterRail (Future 2016)All with APCs (ridechecks) 302 Buses(of ~ 1000)APCs (ridechecks) Ridecheck Plus CAD/AVLSystem Schedule Adherence Data (INIT data 2013, ACS data pre-2013) LRT Factoring Survey ValidationTechnician APC Validation Automated Analysis and Reporting Ridership Analysis Maps Schedule Adherence Reports Ridership Analysis Reports Toad for AdHoc Reporting Google Earth Ridership Maps TriTapt and On-Time Performance

9. Points Lines Polygons Schedules Schedule Development Database (Trapeze) FIX ERRORS AT THEIR SOURCE • Validations conducted as data is created • On demand by scheduling staff • Currently 65 custom validations for route, pattern, trip, block, time point and run cut data • Adding a new validation rule at the rate of about one a month New Validation Needed? Data Valid? Production Database(TIES – developed at RTD) Customer Interfaces Operations Interfaces Errors?

10. Automated queries check schedule data via a web-based interface • Suite of validations complete in about a minute • On demand by Schedulers/Planners • Summarizes errors and provides drill-down for details Immediate FEEDBACK LOOPS To FIND AND FIX Errors

11. Frequent, automated processes to incorporate revisions and fixes Every few days to weekly update Less frequently, less automated Daily or more frequent update Stop data Every 3 hours Customer schedules on website Customer schedules on mobile website Electronic passenger information displays 2-3 times a week Dispatch electronic schedules Operator web site Weekly CAD-AVL data for operations External GIS System Map Internal Trip Planner Every other month Goal is weekly in 2014 External Trip Planner About Monthly Goal is weekly in 2014 GTFS About Monthly 3 week lag time a major hindrance

12. Benefits of Approach • Credibility, better decision making • All stakeholders within RTD are working with the same data • Reporting can consider a variety of data sources at one time • Minimizes frustration by eliminating errors before they get to downstream systems • The persons most likely to have created the error gets information needed to fix it quickly • Customers and operations benefit from accurate, timely schedule and GIS data