STRATEGIES FOR ORGANIZATION,
VALIDATION AND DISTRIBUTION OF
TRANSIT GEOGRAPHIC INFORMATION SYSTEMS
DATA
Jonathan Wade
Manager, Service Development Support
Regional Transpiration District, Denver, CO
GIS in Transit Conference, October 16-17, 2013, Washington, D.C.
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
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
Bus stops
defined
Time
points
Trapeze
scheduling
CONSTANTLY MONITOR TO IMPROVE THE
CUSTOMER EXPERIENCE
Routing
defined
Bus stops
defined
TriTapt ontime
performance
analysis
Other
schedule
data
TIES DB for
error checking,
production
and data
collection
INIT
CAD/AVL
/APC
data
collection
Ridecheck
Plus
ridership
analysis
and
reporting
Can we
improve
the
customer
experience
?
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)
Points
HIGH-LEVEL DATA FLOW
•
•
•
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
Lines
Schedules
Schedule Development
Database (Trapeze)
Production Database
(TIES – developed at RTD)
Customer
Interfaces
Operations
Interfaces
Polygons
GPS BUS STOP DATA FLOW
DATABASES OF RECORD FOR STOP DATA
Method 2:
GPS Field
Data
Collection
Method 1:
Stop Tool
Data Entry
Method 3:
Edits
Upload
GPS Arc
Catalog
Append New
GPS Data Shape file
Visual GPS
Verification
Update
SDE Bus
Stops in
Oracle
Coordinates only
No Coordinates
Convert stop
names to all
upper case
Merge Shape file to
Staging Table (Model
Builder, Arc Toolbox,
Arc Catalog)
Trapeze, database
of record for
geographic
coordinates and
relationships of stops
to routes
Maximus (Asset
Works)
database of
record for stop
names and
stop amenities
Trapeze
FX
Processing
1. Sequence on route
2. Extract stops on patterns
3. Calculate distance
4. Calculate estimated stop
times for each trip
TIES
Convert
stop names
from upper
case
INFORMATION FLOW
CONSOLIDATING RIDERSHIP DATA
RTD Collection Staff
6 Service
Monitors
Laptops
(ridechecks/pointchecks)
43 Street & LRT
Supervisors
Laptops
(pointchecks)
(Trapeze & TIES)
(Hastus and TIES)
Init Automated Passenger Counting System
2 Station
Starters
Desktop
(pointchecks)
56 Commuter
Rail (Future 2016)
42 LRT Cars
302 Buses
(of ~ 1000)
APCs
(ridechecks)
All with APCs
(ridechecks)
(of ~ 178)
APCs
(ridechecks)
Ridecheck Plus
CAD/AVL
System
LRT Factoring
Survey Validation
APC Validation
Technician
Schedule
Adherence Data
(INIT data 2013,
ACS data pre-2013)
Toad for Ad Hoc
Reporting
Bus and LRT
Schedule Data & Bus
Vehicle Assignments
Commuter Rail
Schedules
& Vehicle
Assignments
Automated
Analysis and Reporting
Google Earth
Ridership Maps
TriTapt and
On-Time
Performance
Schedule
Adherence
Reports
Ridership
Analysis
Reports
Ridership
Analysis
Maps
Points
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
Lines
Schedules
Polygons
Schedule Development
Database (Trapeze)
New
Validation
Needed?
Data
Valid?
Production Database
(TIES – developed at RTD)
Operations
Interfaces
Customer
Interfaces
Errors?
IMMEDIATE FEEDBACK LOOPS
TO FIND AND FIX ERRORS
• 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 drilldown for details
FREQUENT, AUTOMATED PROCESSES TO
INCORPORATE REVISIONS AND FIXES
Daily or more
frequent update
• Stop data
• Every 3 hours
• Customer schedules on
website
• Customer schedules on
mobile website
• Electronic passenger
information displays
Every few days to
weekly update
Less frequently,
less automated
• 2-3 times a week
• Dispatch electronic
schedules
• Operator web site
• Internal Trip Planner
• Every other month
• Goal is weekly in 2014
• Weekly
• CAD-AVL data for
operations
• External GIS System
Map
• External Trip Planner
• About Monthly
• Goal is weekly in 2014
• GTFS
• About Monthly
• 3 week lag time a
major hindrance
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