Southern California Priority Corridor
Showcase Program Evaluation
Corridor- wide Rideshare Data Exchange
Project Evaluation Report
FINAL
November 1, 2004
Document No. 65A0030/ 0048
Task No. 5- 5
Prepared for
California Department of Transportation
Division of Research & Innovation, MS- 83
1227 O Street
Post Office Box 942873
Sacramento, California 94273- 0001
Prepared By
BOOZ ALLEN HAMILTON INC
1615 Murray Canyon Road, Suite 220
San Diego, California 92108
Rideshare Evaluation Report
i
CONTENTS
Disclaimer ............................................................................................................................... ...... 2
Abbreviations & Acronyms ......................................................................................................... 3
Executive Summary...................................................................................................................... 5
BACKGROUND..................................................................................................................... ...................................... 5
EVALUATION FINDINGS, CONCLUSIONS, AND RECOMMENDATIONS........................................................................... 6
1 Introduction ............................................................................................................................ 8
1.1 PURPOSE AND SCOPE OF THIS REPORT............................................................................................................ 8
1.2 EVALUATION DESIGN AND APPROACH........................................................................................................... 9
1.3 ORGANIZATION OF THIS REPORT .................................................................................................................. 11
1.4 PRIVACY CONSIDERATIONS................................................................................................................. ........ 11
1.5 CONSTRAINTS & ASSUMPTIONS ................................................................................................................... 12
1.6 PROJECT BACKGROUND ............................................................................................................................... 12
2 Project/ System Technical Description................................................................................ 15
3 System Performance Evaluation......................................................................................... 19
3.1 THE PROJECT/ SYSTEM DEVELOPMENT PROCESS AND TIMELINE.................................................................. 19
3.2 SYSTEM RELIABILITY, AVAILABILITY, COMPATIBILITY, AND SCALABILITY.................................................. 20
3.3 IMPACT OF SHOWCASE INTEGRATION ON PROJECT DEPLOYMENT AND SYSTEM PERFORMANCE.................. 21
4 Cost Evaluation .................................................................................................................... 23
4.1 CONSTRAINTS & ASSUMPTIONS ................................................................................................................... 23
4.2 PROJECT BUDGET & ESTIMATED DEVELOPMENT COSTS.............................................................................. 23
4.3 ESTIMATED OPERATIONS & MAINTENANCE COSTS ..................................................................................... 24
5 Institutional Impacts Evaluation ........................................................................................ 26
5.1 IMPACTS TO OPERATIONS AND MAINTENANCE PROCEDURES AND POLICIES................................................ 26
5.2 IMPACTS TO STAFFING/ SKILL LEVELS AND TRAINING.................................................................................. 26
5.3 IMPACTS TO THE COMPETITIVE ENVIRONMENT............................................................................................ 27
5.4 IMPACTS TO LOCAL PLANNING PROCESSES, POLICY DEVELOPMENT, AND THE MAINSTREAMING OF ITS ... 27
6 Traveler and Transportation Information Management Evaluation ............................. 28
6.1 EXTENT OF REGIONAL AND INTERREGIONAL TRANSPORTATION AND TRAVELER INFORMATION
INTEGRATION BETWEEN AGENCIES....................................................................................................................... .. 28
6.2 UTILIZATION OF REGIONAL AND INTERREGIONAL TRANSPORTATION AND TRAVELER INFORMATION BY
PUBLIC AGENCIES ............................................................................................................................... .................... 28
6.3 EXTENT TO WHICH COMPREHENSIVE AND SEAMLESS TRAVELER INFORMATION WAS DISSEMINATED TO – AND
USED BY – TRAVELERS ............................................................................................................................... ............. 29
7 Transportation System Impacts Evaluation...................................................................... 30
7.1 IMPACTS TO MODE SHIFTING AND INTERMODALISM.................................................................................... 30
7.2 IMPACTS TO TRAFFIC SAFETY AND ACCIDENT REDUCTION.......................................................................... 30
7.3 IMPACTS TO TRAFFIC CONGESTION.............................................................................................................. 30
Conclusions and Recommendations.......................................................................................... 31
Endnotes/ References................................................................................................................... 33
Rideshare Evaluation Report
2
Disclaimer
The contents of this report reflect the views of the author, who is responsible for the facts
and accuracy of the data presented herein. The contents do not necessarily reflect the
official views or policies of the State of California, Caltrans, or the U. S. Federal Highway
Administration. This report does not constitute a specification, standard, or regulation.
Rideshare Evaluation Report
3
Abbreviations & Acronyms
ATIS Advanced Traveler Information System
ATMS Advanced Transportation Management System
AVL Automatic Vehicle Location
Caltrans California Department of Transportation
CCTV Closed- Circuit Television Surveillance Camera
CM Configuration Management
CMP Configuration Management Plan
CMS Changeable Message Sign
COTS Commercial Off- the- Shelf
CTC California Transportation Commission
CVO Commercial Vehicle Operations
CW Corridor- wide
CWATIS Corridor- wide Advanced Traveler Information System Project
CWATMS Corridor- wide Advanced Transportation Management System Project
CWCVO Corridor- wide Commercial Vehicle Operations Project
CWSIP Corridor- wide Systems Integration Project
CWSPP Corridor- wide Strategic Planning Project
DOIT California Department of Information Technology
DRI Caltrans, Division of Research & Innovation ( formerly NTR)
EAP Evaluation Activity Plan
EP Evaluation Plan
FHWA Federal Highway Administration
FSR Feasibility Study Report
FTA Federal Transit Administration
FTE Full- Time Equivalent ( one full- time employee)
FTP File Transfer Protocol
GPRA Government Performance and Results Act
GUI Graphical User Interface
HAR Highway Advisory Radio
HP Hewlett- Packard
HQIT Headquarters - Information Technology ( division of Caltrans)
IDL Interface Definition Language
IMTMS Intermodal Transportation Management System
IPR Intellectual Property Rights
ISSC Information Systems Service Center ( division of Caltrans)
ISTEA Intermodal Surface Transportation Efficiency Act ( of 1991)
ITS Intelligent Transportation Systems ( formerly IVHS)
IVHS Intelligent Vehicle Highway Systems ( now ITS)
IWS Integrated Workstation
LAN Local Area Network
MOU Memorandum of Understanding
MPO Metropolitan Planning Organization
MTA Los Angeles County Metropolitan Transportation Authority
Rideshare Evaluation Report
4
MTBF Mean Time Between Failure
NDA Non- Disclosure Agreement
NET National Engineering Technology Corporation
NTCIP National Transportation Communications for ITS Protocol
NTR Caltrans, Division of New Technology & Research ( now DRI)
OCTA Orange County Transportation Authority
O& M Operations and Maintenance
OS Operating system ( such as Windows  , Unix, Linux, et. al.)
PC Personal Computer ( Windows  - based)
RCTC Riverside County Transportation Commission
RFP Request for Proposals
RTDIE Regional Transit Database Information Exchange
RTP Regional Transportation Plan
RTPA Regional Transportation Planning Agency
RWS Remote Workstation
SANBAG San Bernardino Association of Governments
SANDAG San Diego Association of Governments
SCAG Southern California Association of Governments
SCAQMD South Coast Air Quality Management District
SCPCSC Southern California Priority Corridor Steering Committee
SDT San Diego Transit
SIP Systems Integration Plan
TANN Travel Advisory News Network
TEA- 21 Transportation Equity Act for the 21st Century
TMC Transportation Management Center
TMS Transit Management System
USDOT United States Department of Transportation
VDS Vehicle Detector Station
VOS Volume/ Occupancy/ Speed
VCTC Ventura County Transportation Commission
WAN Wide Area Network
Rideshare Evaluation Report
5
Executive Summary
Background
As required by federal law, all Intelligent Transportation System ( ITS) projects that
receive federal funding must undergo an evaluation to help assess the costs and benefits
of ITS. This document is one of 23 reports produced as part of the Southern California
ITS Priority Corridor Showcase Program Evaluation to help planners and decision-makers
at the federal, state, and local levels make better- informed decisions regarding
future ITS deployments. This report presents the experiences, costs, and lessons learned
from Southern California’s Rideshare project.
In 1993, the U. S. Department of Transportation designated Southern California as one of
four Priority Corridors in which ITS could be of particular benefit. Southern California
suffers from extreme traffic congestion, limited room for expanding transportation
facilities, and above- average air pollution levels. The Southern California Priority
Corridor is one of the most populated, traveled, and visited regions in the country and
consists of four adjoining regions:
􀀗 Los Angeles/ Ventura
􀀗 Orange County
􀀗 San Diego County
􀀗 Inland Empire ( San Bernardino and Riverside Counties).
The ITS Showcase Program is one of several programs that have been implemented in
Southern California’s Priority Corridor to help aid mobility and mitigate traffic
congestion and its associated environmental impacts. The Showcase Program consists of
17 ITS projects that collectively form a Corridor- wide intermodal transportation
management and information network between Los Angeles, Orange County, San Diego,
and the Inland Empire. Each Showcase project deploys a piece of this Corridor- wide ITS
network, including regional Advanced Traveler Information Systems ( ATIS), regional
Advanced Transportation Management Systems ( ATMS), and regional and interregional
communications infrastructure. Eleven of the projects are regional in nature, while the
remaining six are Corridor- wide. Rideshare is one of the federally funded Corridor- wide
Showcase Projects in Southern California, as identified in the Southern California ITS
Priority Corridor Strategic Deployment Plan.
Corridor- wide Rideshare was designed to automate the interagency exchange of transit
route/ schedule and rideshare information, thereby extending coverage to one- third of the
geographic area and over 60% of the population of the state of California. After full
implementation, interested persons, organizations, companies and interaction
computer/ kiosks would be able to receive information on- line on rideshare and fixed
route bus, rail and maritime services operating within the Southern California Priority
Corridor.
Rideshare Evaluation Report
6
The central feature of this Corridor- wide service is the TranStar database, the SCAG
region’s central repository for transit and rideshare information. It is automatically
updated through the Regional Transit Database Information Exchange ( RTDIE) system,
which is currently owned and maintained by The Partnership. When SCAG initiated the
Corridor- wide Rideshare in September 2001, SCAG owned and maintained a RTDIE
database. Following the completion of Phase I in December 2002, SCAG discontinued
its regional Ridesharing program due to budget problems and subsequently devolved
responsibility of ridesharing services to the individual county commissions in the
Southern California region.
The transit itinerary planning service was subsequently sold to The Partnership ( also
known as the Traveler Advisory News Network or TANN), an advanced traveler
information services company offering turnkey solutions to public transportation
agencies for the distribution of traveler information to the public. This database is used to
provide an integrated multi- agency transit itinerary planning service called TranStar
directly to the public via telephone and the Internet.
The RTDIE system obtains transit route and schedule data from the Los Angeles County
Metropolitan Transportation Authority ( MTA), Orange County Transportation Authority
( OCTA) and other transit providers in the region. Under Stages II and III, RTDIE is
designed to exchange transit data with these agencies’ commercially developed transit
management systems ( TMS) by way of custom software that acts as an interpreter or
translator. This “ interpreter/ translator” software translates data between each system’s
legacy format and the RTDIE system’s format. Since each TMS is unique, slightly
different interpreter/ translator software is required for each system.
As initially conceived, the Rideshare project was divided into three stages. Stage I
developed an information exchange capability that enables the exchange of San Diego
transit data using TCP/ IP over the Internet. To date, this is the only stage to be
completed. The objective of Stage II was to migrate this capability so that the data
exchange occurs over the Showcase Network. Stage III would have designed, developed,
and implemented the Rideshare link to the Showcase Network, providing rideshare
information to inter- county commuters using the technology developed in Stages I and II.
It is worth noting that Stage I involved exchange of transit data only, not ridesharing data.
The purpose of this report is to evaluate Stage I, which involved linking San Diego transit
data to the RTDIE database.
Evaluation Findings, Conclusions, and Recommendations
The objective of Stage I of Corridorwide Rideshare was to demonstrate the ability to
upload San Diego area transit information to the RTDIE database and the TranStar
system. This report finds that the transit data files received from SANDAG were
successfully converted to the TranStar system database using TCP/ IP networking and
TCIP data exchange standards. The benefit of the project was the establishment of
Rideshare Evaluation Report
7
standard formats and procedures for the exchange of transit data and the linkage of
databases via the RTDIE server.
While Rideshare successfully converted transit data files from San Diego Transit and
SANDAG into the Inter- regional Rideshare Data Base and the merged database was
successfully loaded into TranStar, the information exchange capability accomplished
under Stage I did not, by itself, constitute compliance with Showcase standards and
protocols. Although Stage I represents an important first step in establishing data
conversion standards and formats in the exchange of transit data, the work plan under
Stage I did not include specifications defining the data interface requirement with the
Showcase Network. Those requirements were identified as part of Stages II and III,
which have not been undertaken.
From an institutional standpoint, there were several challenges that impacted the
completion of Stage I, and the transition to Stages II and III. The discontinuation of
SCAG’s Rideshare program had a chilling effect on the transition of the Corridor- wide
Rideshare project to Stages II and III. With the end of the Rideshare program, SCAG
sold TranStar to The Partnership, a traveler information services company that distributes
traveler information to the public through its web portal ( www. the- partnership. org). By
acquiring and maintaining TranStar, The Partnership has demonstrated a commitment to
consolidating and improving regional transit itinerary services in the Southern California
region. However, The Partnership has not been able to negotiate a cost sharing
agreement with SANDAG to continue updating transit information to the RTDIE
database. In addition, The Partnership has not been able to secure dedicated funding to
support ongoing system maintenance. As a result, the RTDIE database is not being
updated with San Diego area transit information.
Under Stage I, the data conversion process involved a single- step conversion of SDT
transit data files into the RTDIE system. Rideshare did not provide a data exchange link
for ridesharing ( i. e., carpool/ vanpool matching), which is anticipated as part of Stage II.
While the establishment of standardized formats for data exchange between multiple
legacy systems is important, it cannot be concluded that this project, by itself, supports
the Showcase Network.
The concept of automating inter- agency exchange of transit and rideshare data
throughout the Southern California Priority Corridor is a good one. However, the
implementation of a sustainable program has been impeded by the absence of a
memorandum arrangement between The Partnership and SANDAG that addresses cost
sharing, policies and procedures and other responsibilities. SANDAG has prioritized
ITS funding for regional integration efforts like the Intermodal Transportation
Management System ( IMTMS) that improve traveler information within the San Diego
region.
Rideshare Evaluation Report
8
1 Introduction
1.1 Purpose and Scope of this Report
As required by federal law1, all Intelligent Transportation System ( ITS) projects that receive
federal funding must undergo an evaluation to assess the costs and benefits of ITS. The
information provided in this report is intended to help planners and decision- makers at the
federal, state and local levels make better- informed decisions regarding future ITS deployments
based on the experiences of the Corridor- wide Rideshare project.
This document is one of 23 reports produced as part of the Southern California ITS Priority
Corridor Showcase Program Evaluation, and covers only the events and findings resulting from
the Rideshare evaluation. The complete set of findings from the Showcase Program Evaluation
are found in the following collection of documents:
Document Type/ Title Date Document Number
17 Individual Project Evaluation Reports
Corridor- wide ATIS Project Report 7/ 16/ 2003 65A0030/ 0033
Corridor- wide ATMS Project Report 10/ 28/ 2004 65A0030/ 0049
Corridor- wide CVO Project Report 9/ 27/ 2004 65A0030/ 0051
Corridor- wide Rideshare Project Report 11/ 1/ 2004 65A0030/ 0048
Corridor- wide Strategic Planning Project Report 10/ 29/ 2002 65A0030/ 0028
Fontana- Ontario ATMIS Project Report 10/ 15/ 2004 65A0030/ 0047
Modeshift Project Report 3/ 17/ 2003 65A0030/ 0029
IMTMC Project Report TBD 65A0030/ 0054
InterCAD Project Report 4/ 2/ 2003 65A0030/ 0030
Kernel Project Report 5/ 30/ 2003 65A0030/ 0031
LA ATIS Project Report 7/ 18/ 2003 65A0030/ 0038
Mission Valley ATMIS Project Report 10/ 13/ 2004 65A0030/ 0050
Modeshift Project Report ( draft) 9/ 7/ 2004 65A0030/ 0052
OCMDI Project Report 2/ 20/ 2004 65A0030/ 0040
Traffic Signal Integration Project Report 10/ 25/ 2004 65A0030/ 0055
Transit Mgt System Project Report ( draft) 10/ 19/ 2004 65A0030/ 0053
TravelTIP Project Report 6/ 3/ 2003 65A0030/ 0036
5 Cross- Cutting Evaluation Reports
System Performance Cross- Cutting Report TBD 65A0030/ 0056
Costs Cross- Cutting Report TBD 65A0030/ 0057
Institutional Issues Cross- Cutting Report TBD 65A0030/ 0058
Information Management Cross- Cutting Report TBD 65A0030/ 0059
Transportation System Impacts Cross- Cutting Report TBD 65A0030/ 0060
Final Summary Evaluation Report
Showcase Program Evaluation Summary Report TBD 65A0030/ 0061
“ TBD” indicates a future deliverable that is not yet available.
Rideshare Evaluation Report
9
1.2 Evaluation Design and Approach
The findings outlined in this report are based on over four years of direct observations at project
meetings, reviews of released project documents and agency memos, as well as formal and
informal interviews and discussions with project partners.
The evaluation is responsive to the needs and suggestions of the Priority Corridor’s Evaluation
Subcommittee, which reports to the Priority Corridor’s Steering Committee. As shown in
Exhibit 1, both committees are comprised of stakeholders from federal, state, and local levels.
Exhibit 1 – Management Structure and Organization of the Showcase Program
LA/ Ventura Orange Inland Empire San Diego
Technical
Advisory
Subcommittee
Evaluation
Subcommittee
Southern California
Priority Corridor Steering Committee
Evaluation Manager
( Caltrans DRI)
Regional ITS Strategic Planning Committees
Evaluation Team
Showcase Program
Director
( Caltrans DRI)
Agency
Project Managers
System
Developers/ Consultants
The Steering Committee’s member agencies include:
􀀗 California Highway Patrol ( CHP)
􀀗 Caltrans, Division of Traffic Operations ( headquarters)*
􀀗 Caltrans, District 7*
􀀗 Caltrans, District 8*
􀀗 Caltrans, District 11*
􀀗 Caltrans, District 12
􀀗 City of Irvine*
􀀗 City of Los Angeles Department of Transportation ( LADOT)
􀀗 City of San Diego
􀀗 Federal Highway Administration ( FHWA)*
􀀗 Federal Transit Administration ( FTA)
􀀗 Los Angeles County Metropolitan Transportation Authority ( LACMTA)
􀀗 Orange County Transportation Authority ( OCTA)
Rideshare Evaluation Report
10
􀀗 Riverside County Transportation Commission ( RCTC)
􀀗 San Bernardino Association of Governments ( SANBAG)
􀀗 San Diego Association of Governments ( SANDAG)
􀀗 South Coast Air Quality Management District ( SCAQMD)
􀀗 Southern California Association of Governments ( SCAG)
* Indicates an Evaluation Subcommittee member
The Showcase Program’s Evaluation Design is based on a set of evaluation Goals and supporting
Objectives and Measures that were developed by the Evaluation Team in partnership with
federal, state and local stakeholders, and documented in the “ Showcase Program Evaluation
Approach” in 1998. Each individual Showcase project is evaluated based on an applicable
subset of these Goals, Objectives, and Measures in order to help ensure that summary evaluation
results can be aggregated from across the multiple Showcase project evaluations. The Showcase
Program’s five evaluation Goals include:
􀀗 Evaluate System Performance
􀀗 Evaluate Costs
􀀗 Evaluate Institutional Issues and Impacts
􀀗 Evaluate the Use and Management of Transportation/ Traveler Information
􀀗 Explore Potential Impacts on Travel Behavior
As Rideshare evolved, project- specific refinements to the evaluation design were documented in
a high- level Evaluation Plan ( EP) and a detailed Evaluation Activity Plan ( EAP). In general, the
EP describes the project and/ or system under evaluation, and lays the foundation for further
evaluation activities by developing consensus among the Evaluation Subcommittee and project
partners as to which of Showcase’s evaluation Goals, Objectives, and Measures best apply to the
project.
As the project matured, and after the EP had been approved, an EAP was developed to plan,
schedule, and describe specific activities ( e. g., interviews, surveys) and step- by- step procedures
for conducting the evaluation. Data collection began after both plans had been reviewed and
approved by the Evaluation Subcommittee and the project’s partners.
Rideshare Evaluation Report
11
1.3 Organization of this Report
The Rideshare Evaluation Report provides a background description of the Southern California
Priority Corridor and the transportation challenges facing Los Angeles County. This is followed
by descriptions of the Showcase Program and the Rideshare project, including a detailed
technical description. The evaluation itself is subdivided and ordered into the five topic areas
described below:
System Performance  provides important benchmark information regarding system
availability, reliability, scalability and compatibility. The evaluation quantifies those items and
could be used to identify needed improvements and develop specifications for future systems.
Cost  provides important benchmark information regarding funding sources, software
licensing, development costs, costs to re- deploy elsewhere or expand the system, and operations
and maintenance ( O& M) costs. This report includes an estimate of how much it might cost to re-deploy
Rideshare elsewhere in the State, and also looks at the incremental costs for integrating
additional partner agencies and/ or traveler information kiosks into the existing system.
Institutional Impacts  provides important information regarding the administrative, procedural
and legal impacts resulting from the deployment of Rideshare. Such impacts typically include
changes in operator workloads, responsibilities and job turnover rates, as well as changes in and
limitations of agency- wide policies, procedures and guidelines.
Transportation & Traveler Information Management  typically provides important benchmark
information on system usage and user acceptance ( by both agency operators and the general
public). This report will provide quantitative and qualitative findings on these items and can be
used to identify user demand, needed improvements and potential areas of future growth.
Transportation System Impacts  provides analysis of Rideshare's potential impacts on transit
usage, traffic congestion, air quality, and traffic safety. This report will not quantify or describe
the impacts of the project to the overall transportation system, due to the fact that the TranStar
database no longer includes transit data from San Diego operators.
The report concludes with a summary, final remarks and recommendations for next steps.
Several appendices contain supporting documentation such as technical designs and copies of
evaluation data collection instruments ( blank questionnaires and a survey).
1.4 Privacy Considerations
Some of the information acquired in the interview and discussion process could be considered
sensitive and has been characterized in this report without attribution. The Evaluation Team has
taken precautions to safeguard responses and maintain confidentiality. Wherever possible,
interview responses have been aggregated during analysis such that individual responses have
Rideshare Evaluation Report
12
become part of a larger group response. The names of individuals and directly attributable
quotes have not been used in this document unless the person has expressly consented to its use.
1.5 Constraints & Assumptions
The Rideshare evaluation is subject to the following constraints and assumptions:
􀀗 The project’s consultant was not required to disclose actual project expenses, so the
project’s cost is based on the fixed- price budget stipulated in the Rideshare contract and
its amendments. The budget reflects the expenses and costs for services paid by the
client agency, but not necessarily the actual detailed costs for goods and services borne
by the contractor.
1.6 Project Background
1.6.1 The Southern California Priority Corridor
In 1993, the U. S. Department of Transportation designated Southern California as one of four
Priority Corridors in which Intelligent Transportation Systems ( ITS) could be of particular
benefit. Southern California suffers from extreme traffic congestion, limited room for expanding
transportation facilities, and above- average air pollution levels. The Southern California Priority
Corridor, illustrated in Exhibit 2, is one of the most populated, traveled, and visited regions in the
country.
Exhibit 2 – The Southern California Priority Corridor and Vicinity
Rideshare Evaluation Report
13
The Southern California Priority Corridor consists of four distinct regions that correspond with
the four Southern California Caltrans districts:
􀀗 Los Angeles/ Ventura Counties ( Caltrans District 7)
􀀗 Orange County ( Caltrans District 12)
􀀗 San Diego County ( Caltrans District 11)
􀀗 Inland Empire ( Caltrans District 8).
Roughly two- thirds of the state’s population – about 20 million people – resides in or around the
Southern California Priority Corridor.
Exhibit 3 – Population and Number of Registered Vehicles by County
County Population2
( as of 1/ 1/ 2003)
Registered Vehicles3*
( as of 12/ 31/ 2002)
Caltrans District
Los Angeles 10 million 6.7 million 7
Orange 3 million 2.2 million 12
San Diego 3 million 2.3 million 11
San Bernardino 1.8 million 1.3 million 8
Riverside 1.7 million 1.2 million 8
Ventura 0.8 million 0.7 million 7
Imperial 0.15 million 0.1 million 11
Total 20.5 million 14.5 million
* Includes autos, trucks, and motorcycles. Trailers not included.
1.6.2 The Southern California Priority Corridor’s ITS Showcase Program
The ITS Showcase Program is one of several programs that have been implemented in Southern
California’s Priority Corridor to help aid mobility and mitigate traffic congestion and its
associated environmental impacts.
The Southern California ITS Showcase Program consists of 17 individual ITS projects that
collectively form a Corridor- wide intermodal transportation management and information
network between Los Angeles, Orange County, San Diego, and the Inland Empire. Eleven of the
projects are regional in nature, while the remaining six are Corridor- wide in scope. Rideshare is
one of the six Corridor- wide projects.
The 17 Showcase projects are listed by region in Exhibit 4. Eight of the projects were fast-tracked
and designated " Early Start" projects because of their importance as base infrastructure
and their potential to act as role models for the rest of the Showcase Program.
Rideshare Evaluation Report
14
Exhibit 4 – The 17 Showcase Projects and their Status as of September 2004
Project RFP
Issued
Contractor
Selected
Contract
Executed
Project
Underway
Project
Complete
Corridor- wide
Scoping & High Level
Design ( Kernel)*
􀀹 􀀹 􀀹 􀀹 􀀹
Strategic Planning/ Systems
Integration
􀀹 􀀹 􀀹 􀀹 􀀹
CVO 􀀕
ATIS 􀀹 􀀹 􀀹 􀀹 􀀹
ATMS 􀀕
Rideshare 􀀹 􀀹 􀀹 􀀹 􀀹
Los Angeles Region
IMAJINE* 􀀹 􀀹 􀀹 􀀹 􀀹
Mode Shift* 􀀹 􀀹 􀀹 􀀹 􀀹
LA ATIS 􀀹 􀀹 􀀹 􀀹 􀀹
Inland Empire Region
Fontana- Ontario ATMIS 􀀹 􀀹 􀀹 􀀹 􀀹
Orange County Region
TravelTIP* 􀀹 􀀹 􀀹 􀀹 􀀹
OCMDI 􀀹 􀀹 􀀹 􀀹 􀀹
San Diego Region
InterCAD* 􀀹 􀀹 􀀹 􀀹 􀀹
Mission Valley ATMIS* 􀀹 􀀹 􀀹 􀀹 􀀹
IMTMS/ C ( ATMSi)* 􀀹 􀀹 􀀹 􀀹
Traffic Signal Integration
( RAMS)
􀀹 􀀹 􀀹 􀀹
Transit Management
System*
􀀹 􀀹 􀀹 􀀹
* Indicates an " Early Start" project.
􀀕 CWCVO and CWATMS do not yet have approved workplans.
Rideshare Evaluation Report
15
2 Project/ System Technical Description
Corridor- wide Rideshare is a Showcase- funded project designed to provide transit information to
the Showcase Network. To further the goal of regional integration of traveler information
services throughout the Southern California Priority Corridor, the San Diego Association of
Governments ( SANDAG) and San Diego Transit ( SDT) joined in partnership with the Southern
California Association of Governments ( SCAG) to create an Inter- Regional Rideshare Data Base
Link without changing individual legacy systems ( hardware, software or database structures).
Exhibit 5 provides a high- level schematic description of the interface between participating
transit agencies and the TranStar database.
Exhibit 5 – High- level RTDIE/ Rideshare System Schematic
Trapeze
Workstation
SCAG
Transtar
Workstation
Interpreter/
Translator
Transit & Rideshare
Data Broker
Interpreter/
Translator
Interpreter/
Paris Translator
Workstation
OCTA
Interpreter/
TMS Translator
Workstation
MTA
San Diego
Transit
LAN
Internet Connection
Internet Connection
Internet Connection
Web
Server
( Under Development)
( RTDIE prototype)
( Rideshare phase 1)
Project Design Concept
The Inter- Regional Rideshare Database Linkage was implemented in three stages:
􀂃 Stage I – The FHWA/ Caltrans Partnership was established to implement the Inter-
Regional Rideshare Database Linkage project, which develops a transit route function
that permits San Diego transit data to be imported in the SCAG area transit database
using TCP/ IP networking and TCIP data exchange standards.
􀂃 Stage II – After specifications on data interface requirements with the Showcase Kernels
are defined, the TranStar database will be linked to the Showcase network.
Rideshare Evaluation Report
16
􀂃 Stage III – After the transit data is linked, the next step involves the design, development
and implementation of the remaining Rideshare link to the Showcase network, providing
rideshare information to cross county commuters using the technology developed in
Stages I and II.
Stage I has been completed, but Stages II and III have not yet been undertaken. Because much of
the effort involved in defining the data interface requirements with Showcase occur in Stages II
and III, this report cannot provide a detailed evaluation of the Showcase compliance consistent
with National Standards. When SCAG was the lead agency for developing the Rideshare
project, it was anticipated that Stages II and III would be developed as funding became available.
The Partnership has expressed a desire to advance Rideshare to Stages II and III, but will do so
only if funding becomes available to support the long- term vision.
Under Stage I, seven San Diego area transit operators were asked to provide transit data to be
uploaded to the RTDIE database:
􀂾 North County Transit District ( NCTD)
􀂾 Metropolitan Transit System
􀂾 National City Transit
􀂾 San Diego Transit
􀂾 Chula Vista Transit
􀂾 San Diego Trolley
􀂾 San Diego Coaster
A point- of- contact at SANDAG was responsible for compiling the transit data from each of the
operators. Each operator was required to prepare six separate . txt files:
􀂃 Carrier: Code/ Name- Address- etc/ Holidays with or without service
􀂃 Routes: Route name or number
􀂃 Patterns: ( north/ south/ east/ west/ loop/ express)
􀂃 Run/ Trips: Stops served and days and times each one of these stops were served
􀂃 Stops: All the stops for all the run/ trips, patterns, routes and carriers
􀂃 Schedules: All times for runs/ trips, patterns, routes and carriers
Rideshare Evaluation Report
17
Exhibit 6 – Rideshare High- Level System Design
In te rnet
TRANSACT ION
( VALID ATION A ND
DAT A
BR OKER
SERVICE S
DATA
SERVER S IT E
INTERPRETE
T/ RAN SLATO
F ILE IN
COMMON
FORMA T
F ILE OU T
O
* W eb Server
Loc al
N etwork
AT IS
SAN D IEGO
OTHER
OPERATORS
Loc al
N etwork
TRANSTAR
SCAG
OTHER
OPERATORS
Loc al
N etwork
TRAPEZE
OCTA
OTHER
OPERATORS
T ION
The procedure used to link transit data from SANDAG and SDT into the RTDIE system
involved three basic elements:
􀂾 Submission of data files to RTDIE
􀂾 Processing of data files
􀂾 Retrieving data files from RTDIE
A fixed FTP directory structure was used to store data transferred between SCAG and the
RTDIE system. The two main FTP directories were TRANSIT and RTDIE. The TRANSIT
directory was used to store SDT data received by SCAG. The RTDIE directory was used to
store SDT data provided by RTDIE for retrieval by SCAG in formats that could then be imported
into TranStar.
Data files from external agencies were formatted according to the Participant Export/ Import File
Specification ( PFFS), Version 1.2 or later. SCAG then provided instructions for transmitting
files to the RTDIE File Transfer Protocol ( FTP) server.
The program used to process data files was RTDIE_ DAILY. exe. Agencies were instructed to
submit complete, correct, and internally consistent data files. The program then performed a
series of operations. It first checked the FTP directory structure for new, incoming data files.
The program then called the appropriate upload program to convert and loaded the new data
file( s) into RTDIE’s Oracle database. If the upload was successful, the incoming file was
Rideshare Evaluation Report
18
deleted from the FTP directory structure. The download program was then initiated by
RTDIE_ DAILY to convert and provide the new data for the other project participant.
All data files provided by RTDIE were then converted to a recognized format. Files provided
followed the format documented in the TranStar Batch Data Description. Once this was
executed, the file was loaded into TranStar. The file produced by RTDIE was then moved to the
TranStar area and processed by the conversion program to be recognized by TranStar. This
produced an Auto_ Update report, which listed each pattern in the route, showing any errors
encountered during the conversion process. This report was reviewed, and any errors found were
corrected prior to putting the problematic route in production.
The final step involved testing the transit data in TranStar by requesting itineraries from different
points in the area served by SDT. The test involved several discrete steps:
􀂃 Get at least 5 route schedules from SDT
􀂃 Select points in each of these routes
􀂃 Use these points to request itineraries from one point to another
􀂃 Use at least one morning, one afternoon and one evening trip for each of these routes
􀂃 Use at least a weekday trip, a Saturday trip and a Sunday trip for each of these routes.
􀂃 For each of these itineraries, verify carrier name, route number, headsign, original and
destination location and departure and arrival times.
Rideshare Evaluation Report
19
3 System Performance Evaluation
3.1 The Project/ System Development Process and Timeline
Rideshare’s development followed a traditional system development process, and took six
months longer than originally anticipated.
Rideshare is the culmination of over four years of design, software development, and
implementation efforts. The original Federal Work Plan was submitted in 1997 and
subsequently revised in April 2000 based on review comments by Caltrans and FHWA. Since
project initiation in 1998, several work items contained in the revised work plan were no longer
applicable. At the request of Caltrans and FHWA, the work plan was revised to reflect
milestones/ deliverables that are identified in the Revised Work Plan dated August 17, 2001.
Rideshare is primarily a software development and systems integration project, and it utilized the
traditional systems engineering approach as evidenced by the following project milestones and
deliverables:
􀀗 SCAG Work Plan ( revised) – August 2001
􀀗 Requirements Analysis – January 2002
􀀗 Systems Design Specification – May 2002
􀀗 Procedures & Operations – September 2002
􀀗 Implementation – December 2002
􀀗 Draft Report – March 2003
􀀗 Final Report – June 2003
The fixed- price Rideshare contract initially specified a seven- month period of performance, but
as evidenced by the dates on the above milestones, the amount of time required to plan, design
and reach consensus on the system extended significantly beyond the initial period of
performance. Project implementation began approximately fifteen months after SCAG’s
revision of the Inter- regional Rideshare Data Base Linkage Work Plan ( 8/ 17/ 01). After
completion of the System Design Specifications in May 2002, most of the subsequent delay
resulted from turnover in the project management team and internal delays associated with
reduced staffing resources within SCAG’s ITS group.
Rideshare Evaluation Report
20
Exhibit 7 – Corridor- wide Rideshare Project Timeline
1999 2000 2003
Mar- 03: Draft
Report
Jun- 03: Final
Report
1997: Initial workplan
sent to FHWA
Apr- 00: CW Rideshare
workplan revised
2001 2002
Aug- 01: CW Rideshare
workplan revised
May- 02: System
Design Specification
2004
Jan- 02: Requirements
Analysis
Sep- 02: Procedures &
Operations
The Corridor- wide Rideshare project team determined that the size and scope of the project did
not warrant a formal configuration management process.
The CW Rideshare project was considered relatively straightforward ( and the budget was
relatively small), so project overhead was kept to a minimum and the project did not develop a
formal configuration management plan or process. Although configuration management can be
critical for larger projects, the project team determined that the size and scope of CW Rideshare
did not warrant it.
3.2 System reliability, availability, compatibility, and scalability
3.2.1 System Reliability and Availability
Because Stage I of Rideshare has been suspended indefinitely, no assessment of system reliability
and availability could be performed.
After the completion of the Rideshare project, TranStar was sold to The Partnership, which opted
not to continue updating the Inter- regional Rideshare Data Base. Due to the absence of
dedicated funding to support Rideshare, SANDAG decided not to continue its role as coordinator
of transit data for the seven San Diego area local operators beyond the Stage I demonstration.
No memorandum of understanding between SANDAG and The Partnership regarding the
continuation of Corridor- wide Rideshare was established.
Rideshare Evaluation Report
21
3.2.2 Compatibility
There are no indications of any system incompatibilities.
Compatibility is the ability of two or more systems or components to perform their required
functions while sharing the same hardware or software environment. Under Stages II and III, the
RTDIE system is designed to exchange transit data with these agencies’ commercially developed
transit management systems ( TMS) by way of custom software that acts as an interpreter or
translator. This “ interpreter/ translator” software translates data between each system’s legacy
format and the RTDIE system’s format. Since each TMS is unique, slightly different
interpreter/ translator software is required for each system.
The RTDIE_ DAILY. exe program resulted in a successful uploading of San Diego transit data to
the RTDIE database. There have been minor anomalies associated with the data linkage process,
which had to be addressed manually. Depending on the size of the data file to be uploaded, the
amount of manual data “ massaging” required to meet formatting requirements can be significant.
3.2.3 Scalability
The TranStar system is sufficiently scalable to accommodate the integration of the RTDIE
database server.
Scalability describes the extent to which system usage can grow without sacrificing system
performance or requiring architectural or technology changes. In this report, system usage is
defined in terms of data ( object) throughput and is measured in units of megabytes per second
( MB/ sec). The factors that influence the system’s scalability include:
􀀗 Hardware capability
􀀗 Software design.
The use of a third- party service provider ( XO Communications) enables TranStar to lease
enough service to match its demand.
The Partnership leases server hardware, high- bandwidth Internet access and 24/ 7 operations and
maintenance support from XO Communications. At the moment, the current server hardware
and communications bandwidth is sufficient; however, should the load on this system increase,
more capability could be purchased.
3.3 Impact of Showcase Integration on Project Deployment and System Performance
Rideshare is one of 17 projects that make up the Showcase Program and Network. As such,
many interdependencies developed between the projects as plans were made for eventual
regional and Corridor- wide integration. This section describes how these interdependencies
impacted Rideshare and other Showcase projects.
Rideshare Evaluation Report
22
3.3.1 Impact of Rideshare on other Showcase Projects
Stage I of Rideshare is a database linkage project that uses TCP/ IP networking and TCIP data
exchange standards. Stages II and III of Rideshare would have provided “ cross- border” transit
data to the Showcase Network.
The main benefit of Rideshare would have been its provision of “ cross- border” transit data to the
Showcase Network through the development of the Inter- Regional Rideshare Data Base Linkage
system. A lesson to be learned by future ITS deployments is the risk associated with
implementing an inter- regional data exchange project in stages, based on the availability of
funding. While the project demonstrated that data exchange standards consistent with FHWA
National ITS Architecture could be established, the discontinuation of SCAG’s Rideshare
program created enough institutional uncertainty to derail any momentum associated with the
completion of Stage I of Rideshare.
3.3.2 Impact of other Showcase Projects on Rideshare
Delays with the Kernel Delayed the Development of Rideshare
The four regional Kernels comprise the centerpiece of the Showcase Architecture. The Kernels
authenticate ( that is, identify and approve) agency centers that wish to log on to the Showcase
Network, as well as provide additional common services such as location translation, “ yellow
pages,” publish & subscribe, and query. Regional systems that wish to exchange information
across the interregional Showcase Network must contain software to communicate and interface
with the Kernels. Those data interface requirements would have been developed under Stages II
and III.
Rideshare Evaluation Report
23
4 Cost Evaluation
The cost evaluation draws information from documented costs and personal interviews. Budget
information was taken directly from the project's contracts and amendments, while operations
and maintenance costs were obtained from discussions with agency personnel. Informal
interviews were conducted to verify information and fill in any " holes" that were discovered
during analysis.
4.1 Constraints & Assumptions
There are two primary considerations for the Cost Evaluation:
􀀗 Since Rideshare was funded through a firm fixed price contract, the project’s budget
information reflects the expenses and costs for services paid by the client agency, but not
necessarily the actual detailed costs for goods and services borne by the contractor.
􀀗 Operations and maintenance ( O& M) costs have been estimated based on available
information and certain assumptions indicated later in this section.
4.2 Project Budget & Estimated Development Costs
This section addresses the project’s contracted tasks and budget, as well as its role in supporting
the Showcase Program’s “ design once, deploy many times” philosophy.
4.2.1 Project Budget
Although the project took three times as long as anticipated, the increase in budget was minimal.
The South Coast Air Quality Management District ( SCAQMD) committed $ 425,000 of AB 2766
Discretionary Funds to be allocated within the South Coast Air Basin for the development of
RTDIE. Although this initial implementation of RTDIE covered much of Los Angeles County,
Orange County, San Bernardino, and Riverside, it did not include any transit data from San
Diego County.
The proposed cost to provide a comprehensive Inter- Regional Rideshare Data Base Linkage
system to include the San Diego data was estimated to be $ 210,000. Of this amount, $ 100,000
was provided by FHWA as part of the Showcase Program, with a 25% match committed by
SCAQMD out of the AB2766 funds for RTDIE. The project went forward with this budget of
$ 125,000 ($ 85,000 below the estimated cost).
Rideshare Evaluation Report
24
Exhibit 8 lists the project's six tasks and the budget associated with each one, as agreed to in the
initial contract and subsequent contract amendments. More detail regarding each task is
provided below. Since the project was negotiated as a fixed- price contract, the budgets shown in
Exhibit 8 indicate what was paid by SCAG, but might not accurately reflect the actual costs and
expenditures by the contractor.
Exhibit 8 – Rideshare Project Budget per Task4
Task/ Cost Item Final
Budget
Final
%
Task 0 – Project Management $ 19,700 15.8%
Task 1 – Requirements Analysis $ 32,500 26%
Task 2 – Detailed Design $ 32,400 25.9%
Task 3 – Procedures and Operations $ 5,200 4.1%
Task 4 – Implementation $ 21,800 17.4%
Task 5 – Stage II Analysis and Design 13,400 10.7%
Total $ 125,000 100.0%
4.2.2 Design Once, Deploy Many Times
Stage I of Rideshare does not support the “ design once, deploy many times” philosophy through
Showcase’s Kernel- Seed architecture, object- oriented technology, and standardized objects and
interfaces.
The “ design once, deploy many times” aspect of Showcase would have been supported under
Stages II and III of the Rideshare project, which were supposed to define the data interface
requirements with the Showcase Kernel Version 1.0. Since the completion of Stage I of
Rideshare, The Partnership has not integrated TranStar to the Showcase Network, which
continues to be available through a public access website supported by The Partnership.
4.3 Estimated Operations & Maintenance Costs
Currently, there are no incremental operations and maintenance costs associated with
Rideshare, because San Diego transit operators have chosen not to provide transit data to the
RTDIE system.
The Partnership continues to support the TranStar system, which costs approximately $ 500,000
in annual operating and maintenance costs. The Partnership investigated the incremental cost of
supporting the RTDIE FTP server, and estimated that the annual cost of formatting and
uploading San Diego Transit data to the RTDIE server would be approximately $ 275,000 per
year. Of this amount, ASP host services would cost approximately $ 75,000 annually, Call
Center services would cost roughly $ 25,000, route schedule maintenance services would cost
$ 150,000 and San Diego website development and maintenance would cost $ 25,000. In terms of
labor hours, ongoing data formatting and maintenance efforts would require approximately 2.5
FTEs divided roughly equally between The Partnership and San Diego transit operators.
Rideshare Evaluation Report
25
Because it does not have a dedicated funding source to support ongoing operations and
maintenance, The Partnership could not support continuation of Rideshare without ongoing
support from external partners. San Diego transit operators have not committed funding support
for ongoing operations and maintenance of the RTDIE server, leading to The Partnership’s
decision to suspend Rideshare indefinitely.
4.3.1 Maintenance
The Partnership covers system maintenance costs for TranStar, including both labor and
replacement hardware/ software. There are no additional maintenance costs associated with the
Rideshare project, which has been suspended indefinitely due to the absence of a funding
agreement between The Partnership and transit stakeholders.
Rideshare Evaluation Report
26
5 Institutional Impacts Evaluation
5.1 Impacts to Operations and Maintenance Procedures and Policies
A comprehensive evaluation of the impacts of Rideshare on operations and maintenance
procedures and policies should be performed after Stages II and III are implemented.
Due to transfer of ownership of the TranStar system from SCAG to The Partnership, and the fact
that Rideshare has not advanced to Stages II and III, there are no major adaptations to the
operations and maintenance procedures and policies for TranStar. Stage I of Rideshare
demonstrated that transit data from San Diego can be imported into the RTDIE database using
TCP/ IP networking and TCIP data exchange standards.
The Stage I work plan called for the establishment of on- going operational procedures
identifying responsibilities and requirements for maintaining and servicing the data delivery
function. Since the completion of Stage I, however, neither San Diego transit operators nor The
Partnership has allocated additional funding to update the San Diego transit data. As a result, San
Diego transit operators have suspended participation in the Rideshare program indefinitely,
pending the availability of dedicated funding to support future involvement.
5.2 Impacts to Staffing/ Skill Levels and Training
Rideshare has had no impact to staffing or skill levels required to maintain the TranStar system.
Because the procedure for updating transit information to Rideshare must be performed
manually, Rideshare would have required a part- time administrator to facilitate the data retrieval
process. With the sale of TranStar from SCAG to The Partnership, however, no additional
staffing resources were added to maintain and support the TranStar system, largely because The
Partnership did not have a funding agreement between participating transit agencies to provide
ongoing support for Stage I of Rideshare. As of the sale of TranStar to The Partnership, San
Diego area transit operators suspended its involvement in the Rideshare program, pending the
availability of dedicated funding to support ongoing participation.
One of the challenges Rideshare faced in ongoing operations is the fact that uploading to and
retrieving data from the RTDIE database was relatively labor- intensive, requiring substantial
effort to ensure that transit data received from scheduling was consistent with the data format
requirements. After receiving the data from local operators, SANDAG would have had to
review and validate all the transit data before uploading the data to the FTP server. If the upload
failed, SANDAG would have had to review the transit data again to identify problems with the
transit data. Another complication is due to the fact that San Diego area transit operators have
different schedule “ shake- ups,” the task of coordinating the receipt of updated transit schedule
would have been time- consuming.
Rideshare Evaluation Report
27
5.3 Impacts to the Competitive Environment
Because the Rideshare project was discontinued, TranStar does not provide transit trip itinerary
information for trips between the Los Angeles metropolitan area and San Diego.
To date, TranStar is the only on- line transit trip planner in Southern California available today.
The Partnership devotes a full- time system administrator to TranStar, which requires The
Partnership to update transit information from over twenty transit operators with different service
change and “ shakeup” intervals. Because the investment in designing the TranStar database is
considerable, it likely that TranStar will remain ‘ the only game in town’ for the immediate and
long- term future.
Expanding TranStar’s trip itinerary capabilities to include the San Diego region would provide a
unique benefit to Southern California Priority Corridor. The challenge is in automating the
digital interagency exchange of transit information at a cost that can be justified by the value it
provides to the traveling market.
5.4 Impacts to Local Planning Processes, Policy Development, and the
Mainstreaming of ITS
Since the completion of Stage I of the Corridor- wide Rideshare project, the institutional
foundation for the delivery of ridesharing services in the SCAG area has changed significantly.
The Stage I work plan called for the generation of an on- going operational agreement itemizing
and specifically defining the obligations of SCAG and San Diego Transit in assigning data
exchange responsibilities. Since the completion of Stage I of the Corridor- wide Rideshare
project, the institutional foundation for the delivery of ridesharing services in the SCAG area has
changed significantly.
With the elimination of SCAG’s Ridesharing program, the delivery of ridesharing service is now
the responsibility of each individual county commission within the SCAG area. Because of the
interregional nature of carpool matching and trip itinerary planning needs, the transfer of
ridesharing services to the county commissions has a negative impact on the availability and
quality of ridesharing information for those travelers who routinely commute between multiple
counties. The devolution of ridesharing services has the potential to hinder further ITS
development in the absence of a regional planning body like SCAG that can actively solicit
external funding for subsequent phases of the Rideshare work plan, and ensure that ITS
enhancements further the goal of regional ITS integration.
Rideshare Evaluation Report
28
6 Traveler and Transportation Information Management Evaluation
6.1 Extent of Regional and Interregional Transportation and Traveler Information
Integration Between Agencies
6.1.1 Rideshare System Impact on Data Flows
Prior to Rideshare, there was no coordinated interagency effort to import transit data from San
Diego into the SCAG transit database. Rideshare demonstrates that it is feasible to import
transit data files from transit agencies outside the SCAG region. However, it should be noted
that in the absence of creating a link to the Showcase network that automates inter- agency data
exchange, the process of importing updated transit data is manually performed and will remain
costly and time- consuming.
Under the SCAG work plan, it was envisioned that each transit agency ( SANDAG, MTA, OCTA
& SCAG) participating in the RTDIE would perform transit maintenance functions at their
facility. The Stage I function was designed to provide participating agencies with the ability to
import other transit carrier data. All carriers were held responsible for providing transit data to
SCAG. Each agency was also held responsible for retrieving translated data from other agencies
for input into their database.
Since the discontinuation of the Rideshare Services program at SCAG, The Partnership acquired
the TranStar trip itinerary planner and the RTDIE database and is responsible for monitoring the
performance of the hardware/ software and providing service, when necessary.
6.2 Utilization of Regional and Interregional Transportation and Traveler
Information by Public Agencies
TranStar is a valuable source of on- line traveler information, used regularly by end users and
public agencies for transit trip itinerary purposes.
TranStar currently receives transit data from all major transit carriers in Los Angeles, Ventura,
Orange and Riverside counties, including Metrolink and Amtrak. Because TranStar is the only
on- line transit trip itinerary system of its kind in Southern California, it has recently been
identified as a critical transit source database in the development of advanced multimodal travel
planning services. In Februrary 2004, Caltrans District 7 completed acceptance testing of the
Modeshift project, a trip itinerary planning system that enables the end user to obtain real- time
information about the time and cost of the same trip via automobile or transit.
Prior to the discontinuation of the SCAG’s Rideshare program, SCAG provided a link to the
TranStar webpage on its homepage. Because SCAG is established in the region as the
Metropolitan Planning Organization ( MPO), the SCAG website was an excellent platform for
making TranStar available to the public. With the sale of TranStar to The Partnership, SCAG
Rideshare Evaluation Report
29
eliminated the link to the TranStar homepage, although it can easily be located through several
Internet search engines. The Partnership maintains a public website for TranStar at
www. latranstar. tann. com, and provides a link to the TranStar page via its website at www. the-partnership.
org. Exhibit 9 shows the total number of users of the TranStar system between
January 2003 and May 2004. In the months of May, June, and July of 2003, The Partnership
performed routine maintenance and upgrades to the TranStar system.
Exhibit 9 – Monthly Usage of TranStar System
0
10,000
20,000
30,000
40,000
50,000
60,000
70,000
80,000
90,000
Jan- 03
Feb- 03
Mar- 03
Apr- 03
May- 03
Jun- 03
Jul- 03
Aug- 03
Sep- 03
Oct- 03
Nov- 03
Dec- 03
Jan- 04
Feb- 04
Mar- 04
Apr- 04
May- 04
Month
Hits
Because The Partnership is in the process of establishing its market niche in the Southern
California traveler information marketplace, new users not familiar with on- line traveler
information services have a harder time locating TranStar. Although MTA, OCTA, RCTC and
VCTC offer transit trip planning functions within their respective transit systems, these agencies
do not provide a direct link to the TranStar homepage.
6.3 Extent to which comprehensive and seamless traveler information was
disseminated to – and used by – travelers
Although the Evaluation had intended to conduct a user survey to evaluate the use of San Diego
transit information by TranStar users, there was not a sufficient amount of time to do so. Due to
the effort and cost involved with operation, San Diego discontinued providing data to TranStar
shortly after the Rideshare project was completed.
Rideshare Evaluation Report
30
7 Transportation System Impacts Evaluation
This purpose of this chapter is to describe the impacts of the Rideshare system on the
transportation network in Los Angeles County. Because Rideshare is among the first projects to
be developed in a multi- stage regional ITS integration effort, and the public does not yet have
Internet access to Rideshare, a detailed impacts analysis could not be performed at this time.
7.1 Impacts to Mode Shifting and Intermodalism
Because San Diego Transit has declined to continue exchanging transit data to the RTDIE
database, the Rideshare project has been suspended indefinitely. Because no San Diego transit
data has been uploaded to the TranStar database since the completion of Stage I of Rideshare, an
analysis of mode shifting and intermodalism cannot be performed. An analysis of the impacts of
mode shifting and intermodalism should be performed once Stages II and III have been
implemented and impacts associated with linking SCAG and San Diego region transit and
rideshare database for the entire Southern California Priority Corridor is established.
7.2 Impacts to Traffic Safety and Accident Reduction
At this time, an assessment of the impacts of Rideshare on traffic safety or accident reduction
cannot be performed, because Rideshare is currently not being updated and maintained. If and
when The Partnership and San Diego Transit agree to continue updating and maintaining
Rideshare, an analysis of the impacts of providing traffic advisory information on travel behavior
can be performed through a quantitative survey research.
7.3 Impacts to Traffic Congestion
At this time, an assessment of the impacts of Rideshare on traffic congestion cannot be
performed. Since the completion of Stage I, the RTDIE database has not included updated
transit route/ schedule data from San Diego Transit.
Rideshare Evaluation Report
31
Conclusions and Recommendations
The objective of Stage I of Corridor- wide Rideshare was to demonstrate the ability to
upload transit information to the RTDIE database and the TranStar system. This report
finds that the transit data files received from SANDAG were successfully converted to
the TranStar system database using TCP/ IP networking and TCIP data exchange
standards. The benefits of the project were the establishment of standard formats and
procedures for the exchange of transit data and the linkage of databases via the RTDIE
server.
While Rideshare successfully converted transit data files from San Diego Transit and
SANDAG into the Inter- regional Rideshare Data Base and the merged database was
successfully loaded into TranStar, the information exchange capability accomplished
under Stage I did not, by itself, constitute compliance with Showcase standards and
protocols. Although Stage I represents an important first step in establishing data
conversion standards and formats in the exchange of transit data, the work plan under
Stage I did not include specifications defining the data interface requirement with the
Showcase Network. Those requirements were identified as part of Stages II and III,
which have not been undertaken.
This report also presents several key findings:
􀂃 Stage I of Rideshare demonstrated the feasibility of linking transit data through
the RTDIE database without changing legacy systems. However, this evaluation
finds that recurring involvement in the data exchange process is costly because of
the labor- intensive resources requires to manually assemble “ post- shakeup”
transit schedule and route data and upload the data to the RTDIE server via the
TCIP/ IP network. In terms of labor hours, ongoing data formatting and
maintenance efforts would require approximately 2.5 FTEs divided roughly
equally between The Partnership and San Diego transit operators. As a result,
SANDAG and SDT have stopped preparing San Diego- based transit data for
import into the RTDIE database. Many of the data interface requirements defined
under Stages II and III would automate a large percentage of the data interface
procedures that currently must be performed manually.
􀂃 One of the biggest challenges facing the further development of a Southern
California Priority Corridor- wide Rideshare project is the transfer of ownership of
the TranStar database to The Partnership and the discontinuation of SCAG’s
involvement in regional ridesharing services. Since SCAG ended its ridesharing
program, several key ridesharing staff members transitioned to The Partnership.
However, there was no formal agreement between SCAG and The Partnership
regarding the funding and completion of Stages II and III of the Rideshare project.
While The Partnership has indicated that advancing Rideshare to Stages II and III
is an important agency priority, continuation of the Rideshare project is subject to
Rideshare Evaluation Report
32
external funding. There was no formal transfer or archiving of project
documentation. As a result, much of the momentum generated under Stage I has
been lost, with no clear strategy for securing additional external funding for
Stages II and III. Without more active support from SANDAG and SCAG, The
Partnership may not continue to identify Rideshare as a high ITS priority. It is
recommended that The Partnership, SCAG, and SANDAG develop a strategic
action plan that identifies modifications to the existing work plan, establishes a
timeline for Rideshare project completion, and describes funding responsibilities.
􀂃 In the twelve months following the completion of Stage I, The Partnership has
chosen not to include the San Diego transit route/ schedule data in the RTDIE
database. The main reason cited was lack of funding, both within The Partnership
and at SANDAG. It is recommended that The Partnership and SANDAG work
cooperatively to identify new sources of ITS funding in order to advance
Rideshare to the next stages of development.
􀂃 Stakeholder interviews indicate that there is lukewarm institutional support for
Rideshare, primarily because of the perception that the cost of manually importing
transit data from the San Diego region outweighs the benefits of improved travel
information. All three agencies are supporting subregional ITS projects that have
higher priority than Rideshare.
􀂃 Completion of Stage I of Rideshare is an important accomplishment, but it is not,
by itself, a Showcase- compliant project. The tasks outlined in the Work Plan for
Stages II and III describe the approach to defining data interface requirements
with the Showcase Network. It is recommended that a comprehensive evaluation
of Rideshare be performed after Stages II and III are completed.
􀂃 While San Diego cooperated in the development of Rideshare, it did not
undertake a reciprocal data exchange effort by importing SCAG- area transit data
into San Diego’s ridesharing data. SANDAG has prioritized ITS funding for
projects serving the San Diego subregional traveling market. These projects
include the IMTMS and the development of system interfaces and standards that
lead directly to the creation of an Integrated Workstation. At this time, Rideshare
has not been able to successfully compete with other ITS projects for local and
federal ITS funds.
􀂃 If the regional agencies ( e. g., MTA, OCTA, SANDAG) wish to encourage public
use of the TranStar system, they might consider providing Internet links from
their respective agency home pages to the TranStar site.
Rideshare Evaluation Report
33
Endnotes/ References
1 ISTEA requires that “ operational tests utilizing federal funds have a written evaluation
of the Intelligent Vehicle Highway Systems technologies investigated and the results of
the investigation.” Although Showcase is not officially an operational test, it deploys and
demonstrates ITS services, functions, and technologies under “ real world” conditions,
similar to an operational test.
2 California Statistical Abstract, Table B- 4. California Department of Finance,
Sacramento, CA. December 2003.
3 California Statistical Abstract, Table J- 4. California Department of Finance,
Sacramento, CA. December 2003.
4 The total project budget numbers are accurate and come from project files kept by
Tanna Manford, who took over management of the Rideshare project from Howard
Smith in Fall 2002.