real-time transit passenger information: a case study...
TRANSCRIPT
REAL-TIME TRANSIT PASSENGER INFORMATION: A CASE
STUDY IN STANDARDS DEVELOPMENT
A ThesisPresented to
The Academic Faculty
by
Landon Turner Reed
In Partial Fulfillmentof the Requirements for the Degree
of Master of Science in theSchool of Civil and Environmental Engineering and the
School of City and Regional Planning
Georgia Institute of TechnologyDecember 2013
Copyright © Landon Turner Reed 2013
REAL-TIME TRANSIT PASSENGER INFORMATION: A CASE
STUDY IN STANDARDS DEVELOPMENT
Approved by:
Dr. Kari E. Watkins, AdvisorSchool of Civil and Environmental EngineeringGeorgia Institute of Technology
Dr. Timothy WelchSchool of City and Regional PlanningGeorgia Institute of Technology
Dr. Hans KleinSchool of Public PolicyGeorgia Institute of Technology
Date Approved: November 18, 2013
ACKNOWLEDGEMENTS
First and foremost, I wish to thank Rachael Pastor, my fiance and motivational
speaker. The weekend coffee shop study sessions certainly helped bring this document
line by line to its completion. Your support has been unwavering even though a large
section of my brain has been taken over by grad school for the past two and half years. I
only hope that I can reciprocate such support when you decide to enter the life of post-
graduate projects.
I would also like to thank Kari Watkins, Hans Klein, and Tim Welch, the advisers
for this project. Dr. Watkins' support throughout my graduate studies has been
phenomenal. Our simultaneous arrival at Georgia Tech was serendipitous and gave the
chance to work on instructive and pragmatic projects, from this thesis to the most
engaging course projects I have had the opportunity to work on. Discussions with Dr.
Klein helped to inspire and refine many of the ideas presented in this research, especially
those in which I was the farthest from my comfort zone. The gracious support that Dr.
Welch provided as a new member to my thesis committee is much appreciated.
Graduate studies and the production of this thesis were influenced greatly by all
of the wonderful colleagues at Georgia Tech, both in SCaRP and Civil Engineering.
Thanks to all who contributed to the Urban Transportation Information Lab (UTIL) led
by Dr. Watkins, which provided a great environment to learn, share ideas, and gather
honest and helpful feedback. Thanks especially to James Wong and Aaron Gooze. These
two in particular fulfilled multi-faceted roles in my graduate studies. Friends, colleagues,
iii
office mates, intramural teammates, conference co-presenters, and, of course,
racquetballers.
This work could not have been completed without the support of the Georgia
Department of Transportation or the Georgia Transportation Institute/University
Transportation Center at Georgia Tech. Both of these organizations continue to provide
support to important and innovative projects in the field of transportation. I would also
like to acknowledge the interviewees who generously gave their time and expertise to
understanding the standards development processes analyzed in this thesis.
Another thank you to the open transit community for pushing the boundaries in
this area. One such member of this community, Dr. Sean Barbeau from the Center for
Urban Transportation Research at the University of South Florida, has been a wonderful
collaborator on this and other projects during my time here at Georgia Tech. He and
other members of this community work to promote open standards in the transit industry
by not only implementing and using these standards, but by leading research efforts to
better understand this complex ecosystem.
A final thank you goes to my whole family. All of your support and love
throughout my life have brought me to this achievement and will continue to push me
towards a happy and successful life. My formal (and informal) education was uniquely
shaped by each of you.
iv
TABLE OF CONTENTS
ACKNOWLEDGEMENTS iii
LIST OF TABLES vii
LIST OF FIGURES viii
LIST OF SYMBOLS AND ABBREVIATIONS ix
SUMMARY x
CHAPTER 1 INTRODUCTION 1
1.1 Contents 4
1.2 Scope 5
1.2.1 Real-time Passenger Information Transit Data Standards 5
1.2.2 Process-oriented Analysis 6
1.2.3 United States Focus 7
1.2.4 Open Standards 8
CHAPTER 2 BACKGROUND 9
2.1 Real-time Transit Information 9
2.2 The Need for ITS Data Standards 13
2.2.1 ITS Architecture / Standards: Final Rule 13
2.2.2 Open Data and Standardization 17
2.2.3 Pluralization of Stakeholders 18
2.2.4 Efficient Competition and Innovation 19
CHAPTER 3 LITERATURE REVIEW 21
3.1 Standards Development Theory 21
3.1.1 Economic Dimensions of Standards 22
iv
3.1.2 Standards Stakeholder Models 27
3.1.3 Public Policy and Standards Development 33
3.1.4 Technical Dimensions of Standards 37
3.1.5 Open Standards Development 38
CHAPTER 4 REAL-TIME TRANSIT STANDARDS DEVELOPMENT 47
4.1 Methodology 47
4.1.1 Justification for Case Study Methodology 48
4.1.2 Components of Case Studies 49
4.2 Case Studies 51
4.2.1 GTFS-realtime 51
4.2.2 TCIP 59
4.2.3 SIRI 68
4.3 Comparison of Standards and Standards Development Processes 73
4.3.1 Assessment of Openness 73
4.3.2 Implementations 75
CHAPTER 5 RECOMMENDATIONS 78
5.1 Moving Ahead for Innovation in the 21st century 78
5.2 Predictions for Continued Trends 79
5.3 Federal Policy Recommendations 81
CHAPTER 6 CONCLUSION 84
6.1 Key Findings 84
6.2 Future Work 85
APPENDIX A INTERVIEW QUESTIONS 88
v
APPENDIX B OPENNESS INDEX SCORING 91
REFERENCES 95
vi
LIST OF TABLES
Page
Table 1: Agency responses to question on underutilized AVL functions 11
Table 2: Comparison of key program interests for ITS in 2000 and 2013 14
Table 3: Importance of open standards requirements to different stakeholders 43
Table 4: Openness index scores for real-time transit passenger information standards 74
Table 5: Average adoption rate for (agencies per year) for real-time standards 77
vii
LIST OF FIGURES
Page
Figure 1: Growth of transit agencies with open data by passenger miles served 2
Figure 2: Diversity of technology and equipment vendors for AVL systems 13
Figure 3: Growth of open source lines of code from 1995 to 2006 45
Figure 4: Adoption of GTFS by U.S. transit agencies 52
Figure 5: Number of documented changes for GTFS vs. GTFS-realtime 57
Figure 6: Diagram of TCIP Model Architecture 62
Figure 7: Diagram of conceptual hierarchy for TCIP building blocks 63
Figure 8: Participants by sector in TCIP Passenger Information Tech. Working Group 64
Figure 9: Adoption of real-time data standards 76
Figure 10: Reasons given by transit agencies for not providing public arrival times 80
Figure 11: Issues agencies have with adoption of open standards for real-time data 86
viii
LIST OF SYMBOLS AND ABBREVIATIONS
ANSI American National Standards Institute
APC Automatic Passenger Counter
APTA American Public Transit Association
ATIS Advanced Traveller Information Systems
AVL Automatic Vehicle Location
CEN European Committee for Standardization
FCC Federal Communications Commission
FTA Federal Transit Administration
GPS Global Positioning System
GTFS General Transit Feed Specification
GTFS-realtime General Transit Feed Specification for Realtime
IETF Internet Engineering Task Force
ITE Institute for Transportation Engineers
ITS Intelligent Transportation Systems
TCIP Transit Communications Interface Profiles
TCRP Transit Cooperative Research Program
SDO Standards Developing Organizations
SSO Standards Setting Organization
SIRI Service Interface for Real-time Information
UAV Unmanned Autonomous Vehicle
V2V Vehicle-to-vehicle (ITS communications concept)
ix
SUMMARY
As the transportation sector fully integrates information technology, transit
agencies face decisions that expose them to new technologies, relationships and risks.
Accompanying a rise in transit-related web and mobile applications, a set of competing
real-time transit data standards from both public and private organizations have emerged.
The purpose of this research is to understand the standard-setting processes for these data
standards and the forces that move the transit industry towards the widespread adoption
of a data standard. This project will analyze through case studies and interviews with
members of standard-setting organizations the development of three real-time transit data
standards: (1) the development of the General Transit Feed Specification Realtime
(GTFS-realtime), (2) the Service Interface for Real Time Information (SIRI), and (3)
Transit Communications Interface Profiles (TCIP). The expected outcome of this
research is an assessment of federal policy on standards development as well as an
analysis of current and future trends in this sector—both technical and institutional. The
results will inform federal transit policy and future action in standards-setting and
intelligent transportation systems (ITS) requirements, identifying the potential catalysts
that will increase the effectiveness of federal- and agency-level programs.
x
CHAPTER 1
INTRODUCTION
Passenger information for public transit, particularly in the form of real-time
arrival predictions, has experienced a surge of growth in the past decade. While the first
passenger information systems existed even in the early 1990s (1), the increasing
diffusion of mobile smart devices has enabled new generations of applications that allow
users to access real-time information with increasing ease and reliability. The benefits of
providing this information, especially via mobile applications, are well documented. Such
benefits include significant reductions in perceived and actual wait times (2),
improvements in customer satisfaction (3), and increases in transit usage (4).
Smartphone market penetration, however, does not fully account for this growth
in real-time information delivery. The market success of the standard format for schedule
data known as the General Transit Feed Specification (GTFS), originally developed
through a partnership between Google and Portland's TriMet, has led to an unprecedented
adoption rate by transit agencies as shown by total unlinked passenger trips for agencies
with GTFS in Figure 1. These agencies have committed to producing and maintaining
their schedule data in standardized CSV tables to display their system on Google Transit's
trip planner and, increasingly, opening this data to other third-party application
developers.
1
While GTFS has emerged as a de facto industry standard1 for static schedule
information, there has yet to be a similar case for real-time passenger information, or the
current location of a transit vehicle and its consequent schedule deviance. Although the
menu of real-time data standards is almost identical in composition to the list of options
1 Some may call attention to the difference between the use of the word “standard” to describe what actually is a specification (for a good description of this difference, albeit in the printing and publishing industry, see http://www.npes.org/pdf/Standards-V-Specs.pdf). While this is a valid semantic concern, the difference between standard and specification lies on a continuum. Specifications that have been widely adopted and are openly maintained begin to move into the realm of standards. For this reason, the words may be interchanged throughout this document. This is not to detract from the respectable and painstaking work of accredited standards bodies, but rather just a side effect of the ever-changing landscape of adoptionand usage of standards and specifications.
2
Figure 1 Growth of transit agencies with open data by passenger miles served (79)
available for schedule data standards, a predominant alternative has not yet risen to the
top. This may be due in part to one or more of the following reasons: (1) the market for
real-time information is not mature enough to warrant widespread adoption, (2) the
available data standards do not not meet the technical needs of agencies, or (3) the effects
of lock-in and switching costs keep agencies fixed in contracts with vendors providing
proprietary solutions.
Nonetheless, the market for standards that do exist for real-time transit passenger
information in the United States is at a stage where the tipping point for adoption seems
likely to occur over the next decade. The open standards for delivering real-time
passenger information are (1) the General Transit Feed Specification for realtime (GTFS-
realtime), the real-time counterpart of GTFS; (2) Transit Communication Interface
Profiles (TCIP), the FTA and APTA's decades-old project that includes specifications for
all manner of technology systems in the transit industry; and (3) the Service Interface for
Real-time Information (SIRI), a passenger information standard developed by the
European Committee for Standardization (CEN), which has seen adoption in whole or
part by a few agencies in the US. There are a bevy of other standards for delivering real-
time information, but these are on the whole closed standards—generally controlled by
proprietary interests without open forums for comments or appeals. Examples of other
standards or specifications include the NextBus XML API, web services provided by
many different AVL or ITS vendors (Trapeze, Clever Devices, Orbital, etc.), the
3
OneBusAway API2, and many custom implementations (such as TriMet's web services
API).
There are likely a number of reasons that exist for why a real-time transit
passenger information standard has not yet reached a tipping point. This research aims to
understand the theory on standards development processes and organizations in an
attempt better understand standards development for real-time transit passenger
information and why widespread standardization has not occurred. It will examine other
cases of competing standards and how these processes were structured. Importantly, it
will reflect on standards theory and the role of policy in promoting successful standards.
1.1 Contents
This thesis is presented in six chapters. The present chapter introduces the
research goals, structure, and scope. The next chapter gives a background and context for
ITS architectures and standards for transportation, more generally, and transit,
specifically. It also describes the broader needs for standardization efforts as they pertain
to newer government, social, and technological initiatives.
The third chapter thoroughly reviews the theoretical literature that underpins
standards development from a variety of academic disciplines including economics,
sociology, and political science. This chapter also reviews historical cases of information
technology standards development as reference points for the analysis of the real-time
2 The OneBusAway API is not fully closed, but for the purposes of this research it is not considered here. The primary reason for its exclusion is that most of the discussion and work surrounding the API has been related to a particular implementation of the standard. As the project grows into other regions (New York City, Tampa, Atlanta, etc.) there may be cause to consider it under future research. Another reason for its exclusion here is that the author contributes directly to The OneBusAway Project and wishes to avoid conflicts of interest.
4
passenger information standards. Finally, the chapter fully introduces the data standards
and respective standards development processes under examination in this research.
Chapter four details the case study methodology the author employs for analyzing
the passenger information standards development. This chapter documents the case study
findings from each of the data collection efforts. These findings and the subsequent
analysis inform the concluding chapters in which the author presents recommendations
for each of the standards development processes and the larger ITS standardization effort.
Research needs and predictions on the future state of the practice are also elaborated on
in these final chapters.
1.2 Scope
The literature review and case studies that follow in chapters three and four
represent an analysis of standards development with a particular and well-defined scope.
The analysis will focus strictly on those standards development processes for real-time
passenger information in the United States.
1.2.1 Real-time Passenger Information Transit Data Standards
The scope of this work is limited in order to produce results that are relevant for a
particular subset of industry data standards and those organizations that develop those
standards. The standards under examination in this research are those that convey
passenger information in a real-time context. Such information includes data reported
about transit vehicles pertinent to the vehicle locations, schedule adherence/deviance,
service disruptions or changes, or even network congestion levels. These data may be
used to convey information about transit service that aids travelers in decision making
about their journeys.
5
It is worth noting that certain standards considered here, especially TCIP, contain
standards for an entirely other set of information exchanges for the transit industry.
GTFS-realtime, on the other hand, was designed and designated strictly for the
conveyance of real-time passenger information. As such, a strict “apples to apples”
review is not possible unless only the real-time passenger information components of
TCIP are considered. While the author recognizes that the real-time component of the
standard does not exist in isolation, for the sake of simplicity it will be compared strictly
in this real-time passenger information context.
Another important consideration is that TCIP and SIRI were both developed for
intra-agency interoperability, whereas GTFS-realtime was developed as a model for
external data consumption by third parties. Although on the surface these models exhibit
fundamental differences, the primary goal here is to consider how standards influence the
ability of transit passengers to consume real-time information. The passenger
information components of TCIP, SIRI, and GTFS-realtime all intend to serve this
purpose, whether the ultimate vehicle be an agency-operated website or variable message
signs, Google Transit, or any number of other web or mobile interfaces. Each of these
data standards have the capability to deliver this information; this research will consider
how the development of the data standard has hindered or helped to this end.
1.2.2 Process-oriented Analysis
This research effort seeks to understand the evolution, history, and future of the
standards development processes of the major real-time passenger information data
standards in the United States. By understanding these processes as well as the
economic, political, and technical dimensions of these standards, the purpose of this work
6
is to recommend a path forward for the industry in standards adoption and future
standards development work, especially as it pertains to real-time passenger information.
Rather than a substantive analysis of the content, format, and structure of the data
standards, this research effort seeks to understand the formal approaches taken by
standards development organizations (SDOs) and the approaches' resultant successes and
failures.
1.2.3 United States Focus
While advanced traveller information systems (ATIS) have been deployed for
both transit and traffic systems across the world, this research focuses strictly on the
United States context. Social and political organization varies country to country as do
the makeup of SDOs and their relationship with governmental entities. Because of the
complexity of such relationships in different contexts, this research will only consider
real-time passenger information standards that have been implemented and used in the
United States, particularly for those agencies that are members of the American Public
Transit Association (APTA).
SIRI, which was developed through CEN, represents the convergence of a few
European real-time information standards, most notably the UK's Real-Time Interest
Group (RTIG) and Germany's Verband Deutscher Verkehrsunternehmen (VDV). It also
draws on the basic conceptual framework put forth by France's TransModel, also a CEN
European Standard. While the SIRI data standard was developed through a European
SDO with solely European partners, a number of US agencies and real-time information
vendors have implemented the standard, bringing it into the pool of other US data
standards and into this analysis.
7
1.2.4 Open Standards
As mentioned above, this research will consider only open standards for real-time
transit passenger information. Any recommendations for policy or process are unlikely to
impact a closed standard. Therefore, in order to pursue productive work, closed and
proprietary specifications are wholly excluded from the case studies and consideration as
a possible filler for the real-time transit passenger information standards void. The
permanence of proprietary specifications relies on the perpetuity of the firm that holds
licensing, intellectual property rights, and general control of the standard. As such, a
realistic, long-term solution will not include closed or proprietary specifications. Chapter
three considers further the subtleties of open standards and will aid the reader in the
understanding of this concept.
8
CHAPTER 2
BACKGROUND
The purpose and utility of real-time transit information has changed over time.
Transit agencies originally installed systems that provided information on vehicle
location for operational reasons—to assist with crucial functions such as dispatching.
Today, these systems integrate with other technology subsystems such as automatic
passenger counters (APCs), influencing the way in which an agency assesses its
operations and even communicates with its customers, improving both the quality of
service and the customer experience. This section will explore both the technical and
historical basis of the technologies that provide this information and how some of these
changes have occurred.
2.1 Real-time Transit Information
Real-time transit information provides agencies, operators, and customers with
information about the current transit operations—whether it be a single transit vehicle, a
route, or an entire fleet.
Automatic vehicle location (AVL) refers to, primarily bus, technology systems
that determine the location of a transit vehicle or fleet of vehicles in operation.
According to TCRP Synthesis 73, an AVL system is defined as:
“the central software used by dispatchers for operations management that
periodically receives real-time updates on fleet vehicle locations. In most modern
AVL systems this involves an onboard computer with an integrated Global
Positioning System receiver and mobile data communications capability” (5).
9
One of the primary technologies for early AVL systems installed in the 1970s and 1980s
was the wayside signpost beacon system, which relies on a set of signposts installed at
key locations on the transit system (sometimes coinciding with features of service like
timepoints) and beacons that emit, usually, microwaves to indicate their presence when
they approach a signpost. This technology, still used for transit signal priority, is
increasingly being replaced by GPS-based systems, wherein each transit vehicle is
equipped with a GPS receiver and radio-based mobile communications system.
Transit agencies rely on real-time transit information for a host of operational
capabilities and improvements, beyond the information provided specifically for
passengers. Updates on the location and status of vehicles can be integrated with a menu
of other on- and off-board technology subsystems to provide functionalities such as
onboard next stop announcements, automatic data input for headsigns, advanced
communication with farebox systems to provide enhanced data on payments, stop-by-
stop boardings and alightings, schedule adherence for real-time predictions when linked
with schedule data (provided through a number of different interfaces), improved transit
signal priority (TSP) operation, and more (5). This abbreviated list provides a snapshot
of the usefulness of real-time information updates on the location and status of transit
vehicles in operation.
Though the menu of options for AVL systems is extensive, the reality of many
implementations is that few transit agencies utilize many or all of these capabilities. In a
survey conducted by Miller, et al., for TCRP Synthesis 73 (5), the researchers asked
transit agencies which aspects of the agency's bus AVL system are not fully utilized. The
responses for this question are shown in Table 1. While the highest percentage of
10
agencies had not fully utilized TSP (at 43.8%), the second highest response was Next
Arrival Predictions at 34.4% of transit agencies (5). Over a third of agencies either are
not providing or have not fully utilized arrival predictions for their transit systems. The
low utilization of TSP can partly be explained by the high capital costs of installing
wayside infrastructure and the coordination costs of working with other agencies to
calibrate and manage traffic signals. Yet the low utilization of Next Arrival Predictions is
not as easily explained by infrastructure costs.
Table 1 Agency responses to question on underutilized AVL functions (5)
Technology %
Transit Signal Priority 43.8
Next Arrival Predictions 34.4
Scheduling and Dispatch Software for Paratransit Operations 31.3
APCs 28.1
Next Stop Announcements 21.9
AVL Software for Fixed-Route Operations 18.8
Other 0.0
While arrival predictions can be delivered with costly wayside digital signage,
information delivery via websites, automated telephone systems, or mobile applications
offers a low-cost alternative to this infrastructure. One possible explanation for this high
response is that when the researchers administered the survey in 2008 these low-cost
technologies were less available. This theory can be discredited by survey responses
indicating that the earliest cases of agencies delivering next arrival predictions by signs or
websites were between 1998-2000 at rates of 9.4% and 3.1%, respectively. Indeed, these
low-cost methods were available, but this researcher posits that sufficient dominance of a
standard in the realm of real-time transit passenger information had not, and perhaps has
11
still not, matured enough to make these low-cost alternatives to wayside signage
economically viable. In the absence of reliable standards, market inefficiencies keep the
costs of Next Arrival Predictions too high.
Beyond the underlying technologies and uses, the number of vendors involved in
installing and developing these systems for agencies adds an entirely separate layer of
complexity. Figure 2 shows the various vendors involved in equipment supply or
technology integration mentioned in responses from 31 agencies to a 2008 survey
question conducted for TCRP Synthesis 73 (5). The wide distribution of responses (note:
these responses were not mutually exclusive, i.e., some agencies mentioned multiple
vendors/suppliers) suggest that there are a number of both large vendors with multiple
contracts across different agencies as well as many cases where smaller vendors may
create custom solutions for individual agencies or, at most, small market segments. There
are many technology providers for AVL systems and, based on recent evidence, few of
these vendors use anything besides proprietary, closed standards for disseminating real-
time passenger information within agencies or to third parties.
12
2.2 The Need for ITS Data Standards
2.2.1 ITS Architecture / Standards: Final Rule
Intelligent transportation systems (ITS) became a part of the federal agenda in the
early 1990s with the passing of the Intermodal Surface Transportation Efficiency Act
(ISTEA) of 1991. ITS represent the efforts to integrate information technology into
transportation infrastructure at any number of entry points, for example private vehicles
or public infrastructure like roadways. Table 2 shows the key activities of the ITS Joint
Program Office of the USDOT in 2000 (6) and in 2013 (7).
13
Figure 2 Diversity of technology and equipment vendors for AVL systems (5)
Digital RecorderGFI
GiroGreyhawk
HarrisHastus
INITLuminator
MotorolaOrbital
SiemensTrapeze
Twin VisionOther
0
5
10
15
20
25
AVL component vendors
Nu
mbe
r of
age
ncie
sw
ith v
endo
r
Table 2 Comparison of key program interests for ITS in 2000 and 2013 (6, 7)3
Date accessed January 16, 2000 September 3, 2013
Question What are the key elements of the ITS metropolitan approach?
What are the current key activities of the Federal ITS Program?
Answer (extract) Traffic signal control Vehicle to Vehicle (V2V) Communications for Safety
Freeway management Vehicle to Infrastructure (V2I) Communications for Safety
Transit management Real-Time Data Capture and Management
Incident management Dynamic Mobility Applications
Electronic toll collection Road Weather Management
Electronic fare payment Applications for the Environment
Railroad crossings Human Factors
Emergency response Mode-Specific Research
Regional multi-modal traveler information
Exploratory Research
-- Cross-Cutting Activities
A comparison of the major activities across the years indicates not necessarily a
distinct shift in priorities, but rather a shift in the way the organization addresses these
priorities towards more complex and interactive systems. However, the disappearance of
any explicit reference to “transit” may indicate a shift in priority to traffic and autos,
especially with the ever growing interest in vehicle-to-vehicle (V2V) communications
and unmanned autonomous vehicles (UAVs). Nevertheless, this may just as well be
explained by the contemporary emphasis on multimodal applications rather than treating
modes as discrete, unrelated subjects.
3 Key program interests for ITS Joint Program Office in 2000 were obtained through the Internet Archive Wayback Machine (https://archive.org/web/). 2013 interests were obtained directly from the ITS Joint Program Office Frequently Asked Questions web page.
14
In the Transportation Equity Act for the 21st Century, enacted in 1998, legislators
filed additional rules for ITS projects that were to be funded by the Highway Trust Fund.
These rules specified that any major ITS project must “...conform to the national
architecture, applicable standards or provisional standards...” (8). This provision extends
to any ITS projects funded out of the Mass Transit Account and, therefore, includes most
projects that may impact the regional coordination of local ITS operations. It should be
clarified that conformance to the “national architecture” in practice requires conformance
to a regional ITS architecture, which is based on the National ITS Architecture a much
more expansive system than any region is ever likely to implement (9).
In response to questions posed during the legislation’s comment period, the
Federal Transit Administration (FTA) modified the final policy to alleviate concerns
regarding “the premature use of required standards and interoperability tests...”
Specifically, the FTA relinquished agencies of the need to use any standard that is not yet
“mature” and has not been formally adopted by the USDOT. At the time of the
modification's writing, the only required standards were those related to commercial
vehicle operations (CVO) (10). According to a report published in 2010, no other ITS
standard has yet to be formally adopted by the USDOT, so it holds that agencies are not
formally required to utilize any standard. Nevertheless, the report notes that policy still
encourages the use of those standards developed by recognized standards development
organizations (SDOs), such as the American Public Transit Association (APTA) (11).
Branscomb and Keller (1996) offer an early summary of the challenges facing
ITS standardization and, perhaps, partial explanation for why no standard has been
15
formally adopted by the USDOT. In Converging Infrastructures: Intelligent
Transportation and the National Information Infrastructure, they write:
“ITS standardization issues are complex relative to those in the traditional
telecommunications environment because they span a broader array of
technologies and systems. At the same time, however, the environment for
standardization is relatively weak. Telecom standards evolved with a common
platform and a stable—indeed regulated—competitive environment; ITS will
consist of heterogeneous systems and a relatively independent set of players. In
addition, many of the technologies for which standards will be most needed are
nascent or immature at this time” (12).
Many of the same challenges exist nearly two decades later. Technologies and systems
remain diverse and complex. Most of the policy efforts tied to standardization have been
limited to light incentives, certainly not mandates. And, barring a few examples,
standards in the transit industry still seem nascent and/or immature, a fact which is
supported by the above mention of USDOT's hesitancy to formally adopt any ITS
standard.
Despite this apparent stagnancy, a couple of things have changed dramatically.
First, web and mobile platforms for personal information delivery have exploded, despite
the survey responses from TCRP Synthesis 73. The personal computer and, more
recently, the smartphone have enabled transit agencies—and anyone with an Internet
connection—to communicate efficiently with larger and larger audiences. A separate, yet
certainly related, occurrence is the emergence of the open data movement. The
democratization of information and datasets have created an ever-broadening market of
16
users and implementers who inject a distinct set of values, such as transparency,
openness, and sharing, into these standardization processes. In order for standards to
succeed in this new marketplace, the bodies that maintain these standards may need to
demonstrate a renewed commitment to these ideals—both that the standard is
developed/maintained and how new stakeholders might interact with the standard.
2.2.2 Open Data and Standardization
Executive Order (EO) 13642 issued by President Obama on May 9, 2013, has
broad-reaching impacts for open data and data standards in the United States (13).
Proponents of open data, discussed in more depth in Chapter 4, affirm that government
should provide its data freely and openly to private citizens and corporations in order to
spark innovation and assist government in performing its various functions. Using its oft-
cited poster children of weather data and the Global Positioning System (GPS), the EO
discusses the immense potential for entrepreneurial activity and economic growth when
public data are made freely available. Importantly, it asserts that "the default state of new
and modernized Government information resources shall be open and machine readable
[emphasis added]" (13). By providing government data in machine-readable formats by
default, the federal government is placing a new level of importance on the role of
standardization in the most basic operations of government. Standardization, if not a
prerequisite for the systematic provision of machine-readable data, is at the very least a
logical conclusion for the effort.
This EO and the policy it represents are important for the future of transit data
standards because it cements the pattern of growth and creation of niche data markets in
sectors such as transportation, health, or education. With this growth comes the continued
17
importance of data standards to convey this information in addition to the processes by
which such standards are developed. While standardization efforts in ITS are over a
decade old, the executive branch's relatively new open data policy allows an opportunity
to revisit these efforts and investigate how this “open paradigm” might impact preexisting
policy and methods. Certainly, most of the ITS standards have been developed to be
open standards; however, properly functioning in support of open data poses new
questions for these transit standards, particularly in how to handle an entirely new set of
stakeholders.
2.2.3 Pluralization of Stakeholders
Just as the release of Global Positioning System (GPS) spurred billions of dollars
in innovation and supported the spread of businesses around the globe, the opening of
historically closed or unavailable datasets is spawning a new set of interests and
stakeholders in transportation data from governments. According to a report released in
October 2013, open data has the potential to unlock billions, even trillions, of dollars in
economic value in the US. For the transportation sector alone there is around $720 to
$920 billion in latent value, suggesting that new stakeholders might be very important for
the overall economy (14). These new interests not only have a stake in if/when an agency
releases data, but also in how this data is provided once it is eventually delivered.
This new generation of stakeholders historically has had little influence on the
development of ITS standards. This of course is a natural consequence of arriving late to
the game, yet this is not to say that such parties have not been addressed. In a 2012
roundtable held by the White House Office of Science and Technology Policy (OSTP),
application developers and other transit industry stakeholders met to address challenges
18
facing the transit industry, namely “(1) a lack of consensus on standards for the exchange
of real-time transit data and (2) a lack of 'clinical trials' of cutting-edge technologies in
this area” (15). The direct outcomes of this meeting are not abundantly clear. In fact,
that the meeting even took place at all is difficult to ascertain because it is only published
on a few blogs. Nonetheless, the convening of such a meeting shows that the federal
government is aware of the issues in adoption of current standards and bringing transit
technology forward. As more and more agencies move towards an open data model, this
pluralization of stakeholders opens up opportunities for transformative change in the
public transit industry.
2.2.4 Efficient Competition and Innovation
The most fundamental motivation for pursuing transit ITS or any other set of data
standards is to enable efficient competition and innovation. The economic arguments for
standardization espouse the positive welfare benefits that widely adopted standards
generate and, conversely, the failure of technologies and innovations to which
incompatible standards can lead (16). Such positive benefits include network effects, the
avoidance of lock-in, reduction in switching costs, and enabling new market entrants, all
of which will be explored further in later chapters (17–19). Put simply, standards lead to
a more efficient arrangement of market forces and competition. While the success of
standards may not be in the interest of existing firms within the industry, it is certainly in
the interest of the general welfare of the public, who perceives such activity in the form
of cost reductions and improvements in services.
In considering the value of standards to transit ITS, it is helpful to consider the
genesis of GPS technology, Surely if the federal government had delegated the
19
management of GPS to local authorities, we would see the geographies of various
jurisdictions encoded differently to serve different needs. A state government may
choose to represent each point of latitude and longitude in reference to a coordinate
system that distorts the state's geography the least. Or a local municipality may choose to
represent every point in reference to the city center, a logical decision. Or an extremely
flat county might choose not to represent altitude in its local GPS at all.
In reality, we see different coordinate systems in use in nearly every jurisdiction
around the country that hosts geographic data. But if the federal government had
disjointed GPS—the foundational technology for pinpointing any user's precise location
at any given moment—in this hypothetical way, there would be little chance of the
technology having the lasting impact on the world that it has. This illustration is of
course flawed (the technology is for global positioning, not local positioning), yet in an
age where technologies can transform the world in mere months given the right
conditions and where data have been historically locked down so tightly, the example is
not altogether unbelievable.
In sum, the landscape of transit ITS standards may be in a period of change.
Thanks to a growing interest in the use of government data by a new set of stakeholders
and the formal recognition of these efforts by the President, there is now more than ever a
need to understand the impact that standards have on the transit industry. Understanding
the economic and policy impacts that standards have is a crucial first step to
understanding how individual standards develop and the environments in which they are
created.
20
CHAPTER 3
LITERATURE REVIEW
3.1 Standards Development Theory
Standards development processes, especially in the information technology sector
have received a great deal of attention in the past couple of decades. Indeed, it is the
success (or failure) of such processes that have led to the fruitful (or in some cases
painful) growth of industries that rely on networking and data exchange protocols, i.e.,
the Internet. Standards development theory draws from the fields of economics,
sociology, political science, business and information technology. This interdisciplinary
topic area thus has many different contributors bringing a wide range of expertise and
background case studies. Nevertheless, a review of such literature reveals common
threads and theoretical underpinnings.
In an attempt to cover all relevant aspects of standards development theory for
real-time transit passenger information standards, this section will consider:
• the economic drivers for standardization processes;
• the institutions that have historically steered standardization processes;
• policymaking surrounding standardization;
• the types of standards and the basic function each serves; and
• the definition of “open standards” development (as well as differentiation
between “open standards,” “open data,” and “open source”).
21
This literature review provides a set of objective criteria for understanding and analyzing
the real-time transit passenger information standards development. This analysis will
inform the economic viability of development strategies, the appropriateness of when and
where government has intervened with various policies, and the conditions of openness
for each of the standards. Previous work on transit interface standards has not taken this
extensive look at the theoretical literature surrounding standards development, yet in
order to move the industry forward on this issue, such a review is necessary.
3.1.1 Economic Dimensions of Standards
There are a number of economic motivations for standardization in an industry.
Each of these impart externalities onto transactions and product decisions, which spur the
economic viability of products and allow technological innovation to proceed at a strong
pace.
Network Effects
Some of the primary economic advantages offered by standardization are derived
from what are known as network effects. Katz and Shapiro (20)define network effects as
“the utility that a given user derives from the good [which] depends upon the number of
other users who are in the same 'network' as is he or she.” Economists have established a
number of types of network effects4 in the past few decades, all of which contribute to an
understanding of how these market externalities impact standards development and
implementation.
4Arun Sundararajan maintains a thorough listing of the various types of network effects on his personal website (http://oz.stern.nyu.edu/io/network.html) hosted at New York University from which many of the literature references were extracted.
22
For understanding how network effects might apply to real-time transit passenger
information, consider a transit agency in isolation. The agency may have an interest in
providing real-time information to customers. Developing a system to deliver this
information may take significant investment in labor and/or capital to build the system
from scratch. In the absence of standardization, adding additional agencies to this model
does not decrease individual agency investments to provide real-time information.
However, standardization drives down these costs because the costs (and benefits) of
development begin to be distributed across the network. The different ways in which
these effects disperse are described below.
Direct Network Effects
The most basic example of network effects and one of the most modeled in the
field are direct network effects. Direct network effects account for the direct increase in
value accounted for by an increase in usage. Such an effect is easily explained by
common communications networks, such as increases in Internet users or the number of
households with a telephone. As more individuals begin using a product, the value of
that product, or consumption benefit, for existing users and each additional user rises.
Both Katz and Shapiro (20) and Farrell and Saloner (19) discuss these basic effects in
their seminal works that were both published in 1985.
Indirect Network Effects
Indirect networks effects contribute to consumption externalities, or the how the
consumption of one good may depend on the market supply/availability of other
supporting or interoperable goods. Katz and Shapiro also refer to this phenomenon as the
hardware-software paradigm (20), which may be recognized today in the consumption
23
patterns of smartphones. Indeed, the availability and abundance of “apps” or native
applications—or even accessories like cases or peripherals—for a particular consumer
smartphone often heavily influences the purchasing decisions of consumers.
The applicability of this indirect network effect model may be limited for the
transit ITS industry because of the dominance of vertically integrated vendor solutions
for hardware and software. However, the model may be considered for instances where
passenger information standards have been adopted by a subset of transit agencies and
mobile application developers. In this circumstance, consumers have come to enjoy the
benefits of software variety and freedom of choice when a transit agency chooses a
standard that allows for an array of software providers to enter the market.
Two-sided Network Effects
Indirect network effects are sometimes referred to as one-directional cases of two-
sided network effects. Whereas indirect network effects refer to the scenario where a
variety of software packages may influence the consumption of a hardware package, two-
sided network effects include this scenario along with the reciprocal, where a variety of
hardware options for a given software will impart benefits on the consumption of the
software. Farrell and Klemperer list “credit cards, brokers, auctions, matchmakers,
conferences, journals, computer platforms, and newspapers” among key examples of
two-sided network effects (21).
Local Network Effects
Local network effects provide a strong theoretical understanding for standards
adoption and development in transit ITS. These effects describe the effects that a small
subset of a larger network has on consumption decisions. The federal requirement for
24
developing regional ITS architectures is a policy materialization of these effects. In other
words, ITS decisions made by a transit agency in a given metropolitan area will be
heavily influenced by the decisions of and existing infrastructure supported by agencies
within that same region. Again, this effect is supported by both the theoretical arguments
made by Sundararajan (18) and the policy mandates from USDOT (10).
Lock-in and Switching Costs
Besides the benefits attributed by network effects, the costs imparted on
consumers where standards do not exist in a market create an important motivation for
the introduction of standards. These costs, known as switching costs, may keep a
consumer locked in to a particular firm (or vendor) because the cost of switching firms is
too high or, put differently, “when consumers value forms of compatibility that require
otherwise separate purchases to be made from the same firm” (21).
When considering technology systems in the public transit sector, switching costs
may derive from the use of proprietary data formats and standards. Thus, switching from
one technology provider to a competitor would require high costs to translate or convert
data from one system to the new. Other examples of switching costs and lock-in “include
the transaction costs of closing an account with one bank and opening another with a
competitor, the learning cost incurred by switching to a new make of computer after
having learned to use one make, and the artificial switching costs created by frequent-
flyer programs that reward customers for repeated travel on a single airline” (17).
Approaches to Standards Coordination
The mechanisms by which a standard develops is an important determinant for
coordination, or reaching a harmonic agreement within the industry. Farrell and Saloner
25
Consider three approaches to coordination for interface or compatibility standards:
committee-based, market-based (or “bandwagon”), and hybrid coordination (22).
Committee-based Coordination
Committee-based coordination relies on the action of some formal body to
achieve standardization across the market participants, while market-based coordination
is defined by a set of competitive parties each working independently of one another (22).
There are many examples of committee coordination in standardization including any
standard setting organization that openly allows industry participants to meet and develop
a standard through a consensus-based process (e.g., ANSI, ISO, or CEN). The hybrid
approach relies on a combination of both market agents working together in a formal
committee approach, while simultaneously pursuing a market strategy for a standard.
Farrell and Saloner conclude that, while it may take a significantly longer time,
committee-based standard setting will more likely result in interface standards
coordination. Though the authors do note that as this process takes longer and longer the
marginal benefits (“payoffs”) for achieving standardization through committee begin to
diminish rapidly (22).
Market-based or Bandwagon Coordination
Farrell and Saloner suggest that standardization occurs in the market-based or
bandwagon coordination environment when there is a clear leader in the market (a “first
mover”) that pushes the market into standardization as a side effect of its leadership.
They mark key examples of this pattern as when Home Box Office (HBO) adopted
VideoCipher, a satellite signal scrambling system that once adopted by the entertainment
giant brought widespread coordination across the industry. Another example of this
26
bandwagon approach is with the pre-breakup telecommunications company Bell. When
Bell (the firm with the largest market share by far) made decisions on products or
standards, smaller companies such as GTE were forced to follow.
The Hybrid Approach
The hybrid approach to standards coordination describes when a firm decides to
participate actively in a committee approach while simultaneously pursuing a market-
based solution (22). This approach could be considered either hedging activity or, more
aggressively, covert deception used to make a move on the market with the committee's
ignorance. Keil suggests that the hybrid approach—combining market and committee
elements into a semi-open alliance of organizations—a model used in the standardization
of Bluetooth, is used increasingly by firms to achieve rapid dominance of new technology
markets (23).
3.1.2 Standards Stakeholder Models
As mentioned in Chapter 2, the role of stakeholders in the development of
standards is an important one, especially as this group changes with the government
implementation of open data policies. This section contains a few descriptions of
stakeholder models, or the types of stakeholders involved with standards development
and how their respective interests play out. The section provides a context for the
importance of organizations, history, and structures in standards development.
Creators, Users, and Implementers
Krechmer defines a model for stakeholders in open standards development that
relies on three categories: creators, implementers, and users (24). This is perhaps the
27
most basic hierarchical division of stakeholders, yet it helps to parse out interests in the
standardization process. While implementers and creators have the most stake in this
process, users have important interests as well that extend beyond the technical
components. West (25) presents a model with more subtleties, which provides a good
description of stakeholders for understanding market forces in this research.
Nevertheless, both models presented here prove valuable to understanding the interaction
and importance of stakeholder groups.
Creators (Standards Setting Organizations)
Standards setting organizations (SSOs) is a term that has been used to characterize
any organization involved in the development of standards, from governmental to non-
governmental bodies and from corporations to non-profit foundations. In a 2002 critique
on the evolving nature of SSOs, Cargill defines five types of SSOs:
• trade associations,
• Standards Developing Organizations (SDOs),
• consortia,
• alliances, and
• the Open Source software movement (26).
Cargill traces the history of SDOs, the definition typically applied for more
formally organized SSOs. He uncovers the acceleration of market demand for new
technology standards and simultaneous retardation of SDOs' ability to deliver standards
in a timely manner. This slowing pace of development originated with the growth of
“anticipatory standardization,” whereby shortened product cycles and rapid technology
28
change forced organizations to develop a standard far in advance of when it was needed
by the industry (26).
This change began to bring about an increasing number of consortia, or alliances
of companies with similar objectives, that retracted funding from SDOs, redirecting it
towards their own consortia activity. While these consortia on the whole did not
participate in anticipatory standardization, the model of standardization began to change
towards “existing practice.” In this model a company would submit a specification
already in practice to be reviewed for standardization by a consortium. The revised and
reworked specification would then be submitted to the industry as a standard, though as
Cargill accurately notes, “[t]he ultimate authorization, of course, was the take up of the
technology by the market (26).
The other crucial piece of this creator segment of the standardization hierarchy
comes from the influence of the Open Source Software (OSS) movement. This
movement, formally initiated in the late 1990s, consists of a large, semi-organized
network of individuals and organizations growing increasingly diverse, but with the
common goal of creating and improving bodies of universally accessible and
redistributable software (27).
Members of the OSS community often extend beyond the development of
software into the realm of standardization. While it may be on the other end of the
continuum from large SDOs, this largely voluntary community has made significant
contributions to the development of important open source software projects. The
decentralized nature of many of these projects shows important similarities to the
successful set of Internet open standards, which are developed in part by the Internet
29
Engineering Task Force (IETF) (28). The model of distributed networks of volunteer
technical experts has and will likely continue to have real impacts on how standards are
developed. The importance of this model is further discussed in section 3.1.5 Open
Standards Development.
Implementers
Implementers are those players in the standardization process that create new
products that directly employ the standard under development (24). This group,
therefore, has a uniquely strong interest in the outcome of a standardization process.
However, it is crucial to consider how these interests differ from standards creators (such
as an SDO) or the user of one of the implementer's products.
An implementer is concerned not with whether the standard is technically sound,
universally accessible, or meets some other idealistic notion of fairness, but rather that
the standard is accessible to her and meets the needs of her particular products and
market segments (24). This description is not to vilify implementers. Some
implementers may indeed have goals that the standard conform to firmly held values, but
if the standard does not meet an implementer's needs, it is not in her interest to support it.
It is useful here to discard the notion that firms in the marketplace enjoy competition—
firms would rather the playing game be tilted in their favor, but at the very least will
suffer a level playing field.
Users
Users of implementations of a standard have a stake in the standard's success.
Truly, when a standard reaches widespread adoption, its users gain benefits from network
effects, the freedom from lock-in, and stability in their investment. Krechmer writes that
30
the openness of a standard is increasingly important to end users. This is understandable
if we accept that openness implies:
when multiple implementations of the standard from different sources are
available, when the implementation functions in all locations needed, when the
implementation is supported over the user-planned service life, and when new
implementations desired by the user are backward compatible to previously
purchased implementations. (24)
The model for open standards has an increasingly visible impact on the standardization
process for creators, implementers, and users.
West's Model
West describes a stakeholder model in which there are five distinct groups with
interests in open standards development. These classes are: “(1) technology providers,
(2) incumbent vendors, (3) vendor challengers, (4) complement providers, and (5) users”
(25). The model has similarities to Krechmer's simplified model. Technology providers
develop the technology on which the standard is based. Oftentimes, this group also
accounts for the implementers in Krechmer's model.
Vendors consist of implementers who do not have control of the technology
development but do provide products that implement the standard. This group consists of
incumbents—those who lead the market and maintain a significant segment thereof—and
challengers—market leader competitors who wish to disrupt the control of the market.
This challenger group sometimes will create standards alliances or consortia to gain
control of the market or, perhaps more accurately, to level the playing field (25).
31
Complement providers are those who provide complementary products for a
given standard. These providers' interests are driven primarily by volumes—they desire
large market shares for their products with little regard for high profit margins. In other
words, they are interested in providing products that piggyback on the successful
implementations of a standard. Users, once again, make up the same group of
stakeholders as in Krechmer's model. This group ultimately cares about the
interoperability of the standard and the resultant benefits derived from achieving
interoperability.
We can apply West's stakeholder model to the public transit industry, particularly
as it pertains to real-time passenger information. Technology providers are those
companies that develop and, more often than not, also implement AVL technology. Many
of these same companies compose the group of incumbent vendors. Vendor challengers
are more difficult to pin down in this model, but Google and its decision to lead the
development of the GTFS-realtime open standard most accurately represents this model.
Google has been a disruptive force in the provision of transit data (and a number of other
sectors), most notably with the development of GTFS.
There are a number of other vendor challengers engaged in the GTFS-realtime
“consortium,” but the active members of this group mostly seem to be complement
providers. We can think of complement providers in this model as third-party application
developers, looking to provide real-time passenger information via apps that piggyback
off of information provided via AVL systems. They care not about developing a high-
cost, custom solution for a single agency, but rather reaching a large number of users—
what we will consider as agencies here.
32
The question of who the user is somewhat conflated because our public transit
agencies are direct users, but ultimately their customers are the beneficiaries. So here we
have two sets of users: direct (agencies) and indirect (transit riders). Considering this
basic model of stakeholders in the transit industry will be important for understanding
stakeholder relations and interests in the case studies in Chapter 4.
3.1.3 Public Policy and Standards Development
Government institutions have substantial influence over standards development
not only through the institutions through which they act but also through the public policy
they support. Greenstein and Stango note the importance of government decisions in
backing standards because of the power to mandate compliance with a given standard.
However, the incredible rarity of occasions in which these compliance decisions are
reversed is just as important for understanding the role of government in standards
development (29). The literature provides ample discussion of the benefits and costs of
government intervention as well as the conditions under which intervention is most
appropriate.
David and Greenstein, drawing on the work of Besen and Johnson on FCC
regulatory intervention, indicate the conditions under which different types of
intervention may be appropriate. Key among their recommendations are “government
should not mandate standards if these are likely soon to require revision… symptoms of
ineffective or premature actions should not be ignored—including negative industry
reactions and continuing attempts to break from mandated standards… [and] sparse
response to a [standardization] proposal may indicate premature action [by the
intervening agency]” (30, 31). While the latter two recommendations may be applied
33
retroactively to standardization proposals, the first applies to standardization processes
where government has yet to intervene.
While the authors recognize the numerous arguments for intervention to achieve
gains in efficiency, David and Greenstein note that there are issues that come with
government activity in standards development. These issues nearly all stem from the role
that stakeholders are able to play in the process. Typically, vested interests, or incumbent
vendors, are the most well represented and gain the most influence in a standards
development process. Consequently, old standards will be systematically protected while
new stakeholders will likely not be fully represented nor even identified in the process
(30).
Cabral considers ten different standards battles and the role that government
policy has played and can play in favoring or supporting a competing standard. He
considers two questions of import for policymakers: which standard to support and when
to intervene. For the first question, Cabral argues that a patient policymaker should
support the lagging standard, or the one that is likely to prove worthwhile over the long
term but has yet to fully mature or see market dominance. The policymaker in a hurry, on
the other hand, should back the current leading standard. As to when a policymaker
should intervene, the answer is binary again: the patient policymaker should delay any
action, the impatient should act now (32).
The definition of patience and impatience is, then, at the crux of this theory and
how policymakers should react to standards battles. Cabral suggests that this depends on
both the policy context, e.g., US vs. Europe vs. Japan, and the industry/technology in
question. For example, a government might favor the more centralized, impatient
34
approach of choosing a product early over allowing competitive forces to work through
markets (patient). When considering the technology in question, some product cycles are
relatively short, which would favor an impatient approach to avoid lagging.
Farrell and Shapiro consider the differences between these policy contexts in the
selection of high-definition television (HDTV) standards. Japan and Europe chose a
much more centralized approach, demonstrating characteristics of impatience. Each
chose a technology-firm combination very early on and supported it through the
development of the technology. On the other hand, the United States utilized the
resources of competing firms in the HDTV standard selection. Additionally, in the
United States terrestrial broadcasting interests carried significant political weight, so
displacing these providers by adopting a standard too early was out of the question for the
FCC. These differences materialized in a long delay in standard setting and technology
development in the United States, yet a side effect of this delay was an improvement in
the ultimate technology outcome.
In the United States, the FCC allowed for competitive systems to develop in
tandem until it chose a standard from a selection of proposals by 1993 (33). At this point,
tests were prepared to determine which HDTV proposal was deemed best. The results of
the February 1993 tests were, of course, inconclusive. In order to keep development
costs down and avoid further competition, companies and organizations involved formed
a Grand Alliance to cooperatively set the standard and build a working prototype.
Eventually this group submitted a proposal that is very close to what would be approved
by the FCC in 1996 (34).
35
This case shows a very patient policymaker in the FCC, which chose to allow
competing firms to generate multiple proposals. In turn, this led to these competitors
allying themselves in order to reduce duplication of efforts and bring HDTV to the
market more rapidly. So, the patient policymaker led to a better standard by creating
impatient market actors willing to collaborate. While this is just a single example, it
demonstrates some of the reactions policymakers have in different environments and lays
a foundation for understanding how policy context and technology influence patience.
De facto vs. de jure
An important distinction in the world of standards development is de facto vs. de
jure, or whether a standard is formally adopted/sponsored or not. The question of “who
is the formal adopter/sponsor?” poses difficulties in itself. Yet, typically de facto
standards achieve widespread dominance by the action of markets without the formal
requirement of a governing body, whereas de jure standards exist under the governance of
an accredited SDO.
The examples from FCC above primarily describe activities around quality or
safety standards enforced by the regulatory body. However, this regulatory activity is
less prevalent for ITS transit interface standards. Technically, there exists no de jure
standard for transit ITS products because the USDOT has not formally adopted any
standard, including the FTA/APTA TCIP. Nevertheless, the USDOT does support
standards development activity through accredited standards bodies such as APTA, ITE,
and ANSI. Fleming Waguespack (2005) IETF is an example of de facto standards-setting
body even though it is challenged by traditional standards and governmental bodies.
36
The most popular product will also be the de facto standard, and setting a standard
can offer a product a dominant market position. Thus de facto standard setting in
these cases is of enormous concern to firms in systems industries and will often
be central to their business strategies (35).
3.1.4 Technical Dimensions of Standards
Thus far, this review has covered “soft” or social dimensions of data standards.
These social components of economic and institutional analysis are critical to a complete
understanding of the motivations and interests in standards development. It will be
useful, however, to explore the technical dimensions of standards in order to refer to
phenomena by their proper names.
In the taxonomy of standards laid out by David, there are three classes of
standards: reference standards, which enable the accurate measurement and comparison
of different products (i.e., benchmarking); minimum quality or safety standards, such as
the expected lifetime or performance of an electronic component; and interface standards,
those standards which allow a sprocket developed by Sprockets, Inc. to communicate
with a widget manufactured by Widgets Corp. (36). Other researchers' taxonomies
include additional classes, such as variety reduction standards, which “limit a product to a
certain range of characteristics such as size and quality level” (for example, reducing the
number of types of screws) (37); however, this research will focus on the importance of
interface standards to the functioning of passenger information dissemination and the
market that supports such activity.
37
Interface and Compatibility Standards
Interface, or compatibility, standards describe the functional or physical
characteristics that are necessary for equipment or systems to exchange information
successfully. The standards contained in this research (SIRI, GTFS-realtime, and TCIP)
are all interface standards, defining the format, structure, and content of the real-time
information exchanged by onboard AVL systems to central servers to third party
consumers (either users or application providers). While the exact chain of
communication intended for each standard may differ, the basic function of compatibility
exists throughout.
Interface standards for IT, while relatively new to the public transit industry, have
been considered previously in academic literature. In 1998, Hickman reviewed the
current state of the practice for interface standards. His review included a survey of 300
software and hardware product vendors in the transit industry. The resultant response
rate of about 9% (only 27 fully usable responses) perhaps indicates a lack of interest in
the topic matter, a lack of knowledge, or a desire to remain silent on the subject. Whether
this response rate is indicative of a particular stance on the topic or simply the
consequence of happenstance, Hickman does note that his sample may be seriously
biased and should be “viewed with healthy skepticism” (38).
3.1.5 Open Standards Development
Standards development takes place in a variety of settings under different
institutional arrangements and technical requirements. However, all of the standards
considered in this paper have one thing in common: they all claim to be open standards.
An open standard is simply a standard that is “not under the control of a single vendor
38
and is easily available to those who need it to make products or services” (39). This is a
rudimentary definition because there are many facets of openness, which will be
considered below. This section will also explore related “open” movements and the
interaction between these trends and open standards development.
Components of Open Standards
There are, of course, a wide array of definitions for what makes an open standard.
Krechmer documents a few of these, which range from West's availability beyond the
standard sponsor to Perens' definition which draws from the open source software
movement. Perens emphasizes not just the development and availability of a standard,
but also the accepted practices and operating for a standard. His fundamental list of
principles and practices include:
1. availability,
2. maximize end-user choice,
3. no royalty,
4. no discrimination,
5. extension or subset, and
6. predatory practices (40).
Krechmer recognizes the importance of different stakeholder groups to open
standards: if a standard is only open for users and not creators, it is not truly open. For
creators, the development process must allow for open meetings, certain consensus
criteria, and formal procedures, such as balloting. Implementers have market needs upon
which an open standard must not impinge—namely, that the standard should not impose
burdensome costs, keep them from innovation, or put them otherwise in a negative
39
market position. Similarly, users consider a standard open when there are multiple
implementations to access—such as the availability of GTFS from multiple transit
agencies—and there is sufficient support for the standard. Krechmer's ultimate
definition, therefore, defines ten requirements that draw upon the expectations of
openness from each of these stakeholder groups:
1. Open meeting – requires that all stakeholders can participate in meetings;
different levels of barriers (economic, physical distance) can detract from an SDO
meeting this requirement.
2. Consensus – decisions on standard should be made by consensus, a term that has
a range of meanings; however, Krechmer views compliance with this requirement
to be binary.
3. Due process – requires that “consideration be given to the views and objections
of all participants” and that processes exist for participants to express such
perspectives.
4. Open world – suggests that any standard shall, in principle, be applicable to use
cases around the world. In other words, it should not be restricted by national or
political boundaries. However, because there are often regional or cultural issues
involved with standards, the requirement focuses on the geographic coverage in
which the standard operates.
5. Open Intellectual Property Rights (IPR) – refers to the license that governs the
use, redistribution, or commercialization of a standard for implementations.
Krechmer scales this requirement in five levels from 0 to 4 ranging from 0 –
commercial licensing to 4 – no copyright/patent protection.
40
6. Open change – is a somewhat redundant requirement in which Krechmer bundles
the first three requirements (open meeting, consensus, and due process).
Nevertheless, the requirement does indicate an important characteristic that relies
on the convergence of key principles and so may justify being addressed
separately.
7. Open documents – requires that documents for the standard development process
are made open. This includes “work-in-progress documents” (e.g., draft versions
of a standard, meeting discussions, technical reports, etc.) and “completed
standard documents.” Krechmer describes three states of open documents:
1. Work-in-progress documents are only available to committee members
(standards creators). Standards are for sale. (Current state of most formal
SSOs.)
2. Work-in-progress documents are only available to committee members
(standards creators). Standards are available for little or no cost. (Current
state of many consortia.)
3. Work-in-progress documents and standards are available for reasonable or
no cost. (Current state of IETF.) (24)
8. Open interface – prescribes that standards support both backward and forward
compatibility. This category could be broken down into connectivity, or how
devices in different spatial locations interact; extensibility, allowing modifications
to standards that do not break compatibility; and adaptability, allowing for
changes in communication system.
41
9. Open access – is a somewhat nebulous requirement that Krechmer seems to
attach more to safety standards than interface standards. Nevertheless, it could be
interpreted to indicate the degree of access users have to implementations of the
standard or the availability of conformance verification tools to verify
compliance.
10. On-going support – requires that a standard be supported during the four phases
of its lifetime (following creation): fixes, maintenance, availability, and
rescission.
According to Krechmer, these requirements fully satisfy the Perens definition of
open standards, including both principles—One World holds that a single standard ought
to perform a capability globally, for all cases—and practices—Open Meeting requires
that any and all may play an active role in standards development. Table 3 shows how
the ten requirements of Krechmer's definition apply to the three stakeholder groups. The
table indicates that three requirements—One World, Open IPR, and Open Change—
impact all three stakeholder groups. Users and implementers rely on nearly all of the
same requirements, except that implementers do not rely on on-going support.
42
Table 3 Importance of open standards requirements to different stakeholders (24)
RequirementsStakeholders
Creator Implementer User
1 Open Meeting X
2 Consensus X
3 Due Process X
4 One World X X X
5 Open IPR X X X
6 Open Change X X X
7 Open Documents X X
8 Open Interface X X
9 Open Access X X
10 On-going Support X
In addition to a robust definition of open standards, Krechmer provides an
analytical framework for assessing open standards development. Because the author uses
this framework for assessing passenger information standards in the chapter on case
studies, Krechmer's ten requirements, and their relevance for transit ITS standards, will
be further explored in Chapter 4.
Related “Open” Movements
In recent years, a number of technology-centric movements labeled with the
“open” qualifier have emerged. The author has cursorily reviewed open data with respect
to the White House's policy stance and its potential impact on standards development.
This brief section is to clarify this and other movements and their relevance for this
research.
43
Open Data
Perhaps the most recent open movement and the one most successful at capturing
the public eye has been the “open data” movement. Open data refers to the idea that
datasets, particularly those owned by the government, should be made openly available to
any private citizen or company that wishes to use them. In addition, the movement holds
that governmental agencies should provide such data in machine-readable, common data
formats so that they may be easily parsed by software developers, researchers, and any
other interested party. Open data holds a strong connection to the world of open
standards because the success of the movement relies on being able to build robust,
repeatable applications that function for both Agency X and Agency Y. In other worlds,
interface standards must be used by a large group of agencies in order for users to
experience the benefit of network effects.
Open Source
The open source software movement is a relatively new concept, but has already
had profound impacts on the software development industry. Open source refers to a
software development model that promotes free redistribution of software and software
components, makes source code (not just compiled code) openly available, and allows
derivative works (41). There are a variety of licenses under which open source software
is published (42), ranging from the very permissive (for example reuse for commercial
purposes) to more restrictive policies on how source code may be used.
The roots of the term “open source” grow very much out of the world of
standards. The term was coined in a Palo Alto, California, strategy session following the
decision to publicly release the Netscape Navigator source code (27). Netscape was
44
embroiled in longstanding “browser wars” with Internet Explorer. which it eventually
lost. The ultimate conclusion of these wars, however, would spark the open source
movement and the eventual destruction of IE's hegemony by open source browser
projects such as Mozilla Firefox and Chromium (the open source basis for Google
Chrome).
This movement has since grown astronomically, especially over the past decade.
Figure 3 Shows the exponential growth in the number of source lines of code contributed
to open source repositories tracked by Deshpande and Riehle over the period of January
1995 to December 2006. While this study is a few years old, the trend line is
unmistakable: the open source community is growing rapidly. According to the authors,
“the total amount of source code and the total number of projects double about every 14
months” (43).
45
Figure 3, Growth of open source lines of code from 1995 to 2006 (43)
While the open movements discussed here have distinct meanings, they do not
exist in isolation. It is likely that as open data and open standards proliferate, so too will
the number of open source projects and lines of code dedicated to using these data and
standards. This correlation is not a given, yet the interest in civic hacking (44) and
viewing government as a platform (28) suggest that these movements will work together
in concert and continue to exhibit this exponential growth pattern.
46
CHAPTER 4
REAL-TIME TRANSIT STANDARDS DEVELOPMENT
4.1 Methodology
The methodology presented here relies on the multiple case study to understand
the standards development processes utilized by each data standard. One of the principle
aims is to reach an understanding of how “open” each data standard is, or how well each
data standard complies to the definition of an open standard. According to Yin, a case
study is an empirical endeavor that investigates contemporary phenomena within the
context in which they occur. A case study provides a method to observe both the
phenomenon and the contextual details—which may be part of what the observer seeks to
understand (45).
The multiple case study methodology used here relies heavily on document
review and past surveys on agency attitudes and capabilities regarding the provision of
real-time information to understand characteristics of the standardization processes and
their impacts on agency adoption. Interviews were also conducted with members of the
SSOs from each of the standards development processes. The final source of information
is a collection of articles from a variety of peer-reviewed journals that contain data about
various implementations of (1) products deployed by different vendors, (2) standards
implemented in different use cases, and (3) opinions/perspectives on standardization and
ITS for transit.
47
4.1.1 Justification for Case Study Methodology
The case study as methodology offers research on systems, processes, and
institutions an important tool for understanding. Yin offers the following purposes for
choosing this methodology in research:
1. The research seeks to answer a “why” and/or “how” question,
2. The research focuses on contemporary events, and
3. The researchers lack “control over behavioral events” relevant to the research.
(45)
The research objectives in this thesis are to understand why and how each of the real-time
transit passenger information standards development processes function and to consider
how the standards environment could be improved for the better functioning of real-time
information provision. This is certainly a contemporary subject of review. While there
are some historical considerations, each of these standards is actively evolving over time
and each of the respective SSOs consider the future of the standards.
Finally, the researcher draws on insights from members of the SSOs and does not
attempt to nor could he control the behavioral events of these bodies. Any analysis of
standards development processes necessarily must draw on case study findings, lest the
research be focused on developing economic models or theoretical insights. This
research, on the contrary, seeks to understand specific real-world processes and
institutions and their respective arcs of development.
48
4.1.2 Components of Case Studies
Interviews
To gain insights into the history and evolution of the standards development
process, the researcher conducted interviews with either members of the SSO or persons
actively engaged in the standardization process for each data standard. The nature of
these interviews were primarily informational, seeking specific facts about the operations
and functioning of standards committees rather than opinions or speculations. The
interview questions are reproduced in Appendix A: Interview Questions. The major
categories for questions asked in the interviews are as follows:
• Interviewee's role in standard development
• History of standard development process
• Meetings, Consensus, and Formal Processes
• IPR, Global Availability
• Transparency, Interface, and Access
• Support for Implementers
Many of the question topics aimed to understand the openness of the respective standard
development process according to Krechmer's ten principles of open standards. Internal
Review Board approval was obtained for the interview questions and consent from
interview participants was obtained. Although these interviews were informational, in
order to protect the participants pursuant to human subjects policies, their names are
excluded from this thesis. Nonetheless, many parts of the interviews informed the case
study analysis.
49
Document Review
The researcher extensively reviewed documents on the standards and their
respective standardization processes. These documents include SSO and/or data
standards websites, documentation on current and/or past versions of the data standards,
and any publicly available meeting minutes or committee communications. Many of the
most important of these documents are referenced in the bibliography and are available
on the Internet. However, if at some point in the future, these are no longer available at
the URLs provided, please contact the researcher5 for a copy of the reference material
(given that the license governing the use and distribution of the content permits such
sharing).
Assessment of Openness
Openness is an important characteristic for standard setting that the researcher has
identified in the literature review. As mentioned above, many of the interview questions
were directed at understanding how well the standard satisfied Krechmer's ten principles
of open standards. A brief description of the most salient features of openness is provided
for each case study and a comparative review according to Krechmer's principles is
provided at the end of this chapter.
Review of Outcomes
Achieving standardization requires more than simply developing a standard. This
is only the first step in a process that, if successful, will lead to the widespread adoption
of the standard, the proliferation of network effects to both firms and users, and an
improvement in the functioning of the industry market. As such, it is important to review
5 This researcher may be contacted at [email protected].
50
the present outcomes in adoption of each of the standardization processes as indicators of
how successful each standardization process has been to date. This is, of course, an ever-
changing situation as implementation decisions are made and procurement documents
produced in agencies every day. However, there is value in ascertaining the current state
of affairs in order to both predict future trends and understand the process that led to the
present state.
4.2 Case Studies
4.2.1 GTFS-realtime
Background
History
GTFS-realtime is the real-time complementary standard to GTFS, the General
Transit Feed Specification, which contains static schedule information for a transit
agency or collection of agencies. The history of GTFS-realtime is tightly coupled with
that of GTFS. Portland's Tri-County Metropolitan Transportation District of Oregon,
more commonly known as TriMet, worked with Google to originally develop GTFS.
Bibiana McHugh is mentioned as having initiating conversations with Google, Yahoo,
and Mapquest in a desire to make transit trip planning information as readily accessible
as driving directions on popular mapping services (46). Chris Harrelson, a Google
employee, was already engaged in the integration of transit options to Google Maps. By
December 2005, TriMet's schedule information was available on Google Maps as Google
Transit (46).
51
A number of agencies followed TriMet's lead. Nearly a year later, Google
announced that the company had added five more cities to Google Transit (47). A change
proposal was later made in 2009, and shortly thereafter adopted, to rename the GTFS
standard (it was originally known as the Google Transit Feed Specification) to more
accurately capture its growing use in many other applications besides Google Maps (48).
Indeed, the standard has since grown to be adopted by nearly 700 agencies worldwide
(49).6 In the U.S., 272 transit agencies had adopted open data policies to provide their
GTFS feeds to the public as of March 2013 (50). Figure 4 shows this trajectory of
growth and when Google decided to tackle the issue of providing real-time transit
passenger information.
6 According to the website http://gtfs-data-exchange.com (accessed on November 7, 2013). This figure includes both official and unofficial feeds as well as some agencies that may have out-of-date feeds. Nevertheless, the scale of this figure is accurate.
52
Figure 4 Adoption of GTFS by U.S. transit agencies (82)
Once Google was in the business of providing scheduled transit information, the
provision of real-time information followed a natural progression. In the summer of
2011, Google launched Live Transit Updates for Google Transit for Boston, Portland, San
Diego, San Francisco, Madrid, and Turin (51). This service provides real-time updates
on transit vehicle arrival times as well as service modifications/alerts within the Google
Maps trip planning function.
The real-time arrival time updates for Live Transit Updates relies on a bulk-
delivery data standard known as GTFS-realtime, which Google developed with the help
of partner transit agencies listed above as well as a number of individuals involved in the
development of applications for transit. The specification, in secret development for
about a year before its release, was made open following its release. Thus, GTFS-
realtime brought to real-time passenger information what it had done to static information
only a few years ago: introduced a robust open standard for moving data from agency and
vendor coffers into the hands of third-party developers.
Scope
Google developed GTFS-realtime in order for the company to consume real-time
transit feeds in Google Transit. As such, the standard differs in two fundamental ways
from TCIP and SIRI, the other two standards considered in this research, which were
developed primarily for intra-agency interoperability and communication. First, whereas
TCIP and SIRI each allow for payloads of data at the transit vehicle level, GTFS-realtime
provides a data payload only for an entire fleet of vehicles, what is often referred to as a
“snapshot” of the transit system. While some agencies might have hundreds or even
thousands of active vehicles at any given moment, GTFS-realtime is able to efficiently
53
handle this data because it utilizes the lightweight Protocol Buffer data structure up to 10
times smaller and up to 100 times faster than XML serialized data (52).
This model differs from utilizing a transactional application programming
interface (API) such as the representational state transfer (REST) model that many
agencies choose to publish and SIRI has recently adopted as a transport architecture.
These transactional models allow for a more active conversation between interfaces. For
example, a client-based web application may make transactional requests to an API for
the next real-time arrivals for a specific stop (the next five buses to arrive at 5th St and
Main St).
The second fundamental way GTFS-realtime differs from the others is that it
operates on a strictly one-way communication model. That is, an agency publishes
GTFS-realtime for external bulk consumption. TCIP and SIRI offer more capabilities for
integrating real-time passenger information with operations. For example, TCIP was
developed with the architecture of an entire transit agency in mind. TCIP allows for
operational need to connect, for example, a bus' AVL system to other on-board
equipment. Similarly, SIRI allows buses to communicate with one another to, for
example, ensure that a timed transfer is made smoothly by informing Bus B to wait for
the passengers of Bus A if Bus A is running late.
Although these models may differ fundamentally, the primary concern of this
research is the delivery of real-time information on stop arrivals/departures, vehicle
locations, and service alerts. All three standards perform this function, whether they
function at the junction between bus and agency server, agency server and agency
web/sign interface, or agency server and third-party interfaces. The open data paradigm
54
has shifted many progressive agencies from keeping data within intra-agency networks to
sharing this data outside agency walls. Whether agencies commit to a fully open or semi-
open model, the need for an effective data standard for real-time passenger information
remains.
Technical Documentation
The documentation for GTFS-realtime (53) provides an overview of the standard,
description and examples of the feed types, and a complete reference of the specification.
The standard has categories for three types of real-time information:
• Trip updates – delays, cancellations, changed routes
• Service alerts – stop moved, unforeseen events affecting a station, route or the
entire network
• Vehicle positions – information about the vehicles including location and
congestion level. (53)
These categories provide for most, if not all, of the crucial information about transit
service that passengers might be interested in. Certainly there are more complex pieces
of real-time information that are left unaccounted for here, such as information about
connections/transfers between routes or detailed data structures about transit facilities.
The technical specifications for SIRI, discussed below, capture much more of this type of
information and allow for more transactional data exchange models. However, the bulk
exchange model for GTFS-realtime requires the specification to be somewhat more
minimal than it might otherwise be. This does, however, help the standard to maintain a
limited scope and agencies to achieve implementations more easily.
55
Development
Institutional Involvement
The primary institutions involved in the development of GTFS-realtime are
Google and the original six transit agencies who participated in the closed development
process. Since then, the specification has been adopted by a few more agencies (although
the precise number is difficult to come by). Google staff work actively to coordinate with
agencies on bringing them onto Google Maps and, by extension, onto the GTFS
specification.
Evolution
The history of institutional involvement for GTFS seems to have been instructive
for Google with its foray into real-time data. The company developed GTFS with the
benefit of transit industry expertise from a single agency. When the specification was
released publicly, there were initially a number of changes proposed and adopted almost
immediately. It is likely that Google revised its development strategy and institutional
involvement to include additional partners partly because of this experience. Another
possible explanation for this change in institutional involvement is that the company
wanted to expand its reach for bringing the standard around the globe by releasing Live
Updates for Google Transit with an international scope. Regardless of the reason, the
development of GTFS-realtime included a broader group of stakeholder institutions,
which has likely contributed to a decrease in post-release changes to the standard (see
Figure 5).
56
Another crucial piece of the evolution of GTFS-realtime is the growth in
“repeaters” that exist for the standard, or small applications that convert a different
specification to GTFS-realtime. Repeaters allow agencies that have real-time passenger
information in one format to gain the benefits of an open standard like GTFS-realtime.
Currently, the known repeaters for GTFS-realtime were developed for use in
OneBusAway, the open source suite of tools for delivering passenger information. The
repeaters include support for the NextBus, SIRI (Vehicle Monitoring and Situation
Exchange), and ACS Orbital OrbCad AVL (54). While this bandaid solution to
interoperability is not perfect (especially for a proprietary format that could change at a
moment's notice) and it may be impractical to consider for every possible proprietary
closed format, it does begin to expand the sphere of influence of GTFS-realtime and,
importantly, allows for easy integration with the SIRI open standard.
57
Figure 5 Number of documented changes for GTFS vs. GTFS-realtime (80, 81)
0 1 2 3 5 6 7 8 9 13 14 17 230
2
4
6
8
10
12
GTFS-realtime
GTFS
Months after initial release
Number ofdocumented
changes
Openness
GTFS-realtime is notable for the openness and transparency that governs it today.
Nevertheless, the standard was originally developed in the product development shroud
of Google secrecy for which the company is renowned (or notorious, depending on the
perspective). Original participants in the development of the specification signed non-
disclosure agreements in order to keep the details of the project closed. This is truly the
antithesis of openness; however, a participant of the process notes that in the realm of
standards development the barriers to initial development and publication are high. This
closed process allowed the participants to quickly develop the specification and deploy
implementations in the absence of painstaking and meticulous debates with a wide array
of stakeholders.
With the release of the standard in 2011, Google removed the barriers to
widespread participation. Open communication is maintained on a publicly-accessible
mailing list (https://groups.google.com/forum/#!forum/gtfs-realtime). Change proposals,
technical issues, and clarifications are all discussed on this forum by an active community
of agency staff, Google staff, and transit application developers/enthusiasts. The general
policy on changes to the standard is carried over from the policy governing GTFS. That
is, in order for a change to the standard to be considered it must see interest both from
application developers and transit agencies. The policy is intended to keep the standard
from becoming bloated with superfluous data and relevant for all stakeholders. As for
intellectual property rights, the specification is published under the permissive Creative
Commons Attribution 3.0 License (55) and all code samples are available under the
Apache 2.0 License (56).
58
Success
As mentioned previously, the static GTFS specification has been adopted by
hundreds of transit agencies around the United States and around the world. Because the
GTFS-realtime feed works in conjunction with GTFS, it stands to reason that many
agencies will invest in making their schedule information work seamlessly with their
real-time information. While this sounds simple on paper, in reality many agencies that
have AVL and scheduling systems will have different vendors providing each system.
Applications that deliver real-time information along with scheduled information (e.g., to
provide information on route geometries and stop locations along with real-time arrival
times) require the reconciliation of object identifiers in schedule and real-time systems.
In other words, trip identifiers or route identifiers in the schedule must match (or be
translated to match) those identifiers in AVL systems. Nevertheless, GTFS and GTFS-
realtime appear to be in a strong position to serve that role, especially thanks to the
support of real-time “repeaters” that translate the NextBus API specification, SIRI, and
others into GTFS-realtime (57).
4.2.2 TCIP
Background
History
The development of Transit Communication Interface Profiles (TCIP) was
initiated by the USDOT's Intelligent Transportation Systems Joint Program Office (ITS
JPO) in November 1996. Industry professionals came to the realization that in order for
transit technology systems to move forward in a progressive and constructive way,
59
standards needed to be an essential part of the conversation. The standard, funded by the
ITS JPO and originally developed by the Institute of Transportation Engineers (ITE),
switched ownership to APTA in 2001 primarily because of APTA's stronger expertise in
the transit industry (58). It was under APTA that the bulk of the standard was developed.
Scope
The primary goals of TCIP are to achieve intra- and inter-agency interoperability
and to decrease the negative effects of vendor lock-in. These goals are in direct
agreement with the federally-mandated concept of regional ITS architectures. However,
another one of its goals according to an APTA presentation from 2010 is to lead to
interoperability “between an agency and external Information Service Providers” (59).
This goal of interoperability with Information Service Providers suggests that the TCIP
standard might cater to the recent growth of application developers that have latched on
to the open data movement in order to provide information to transit customers. This is
indeed an important goal, but may be difficult for TCIP to fulfill simply because of the
sheer flexibility and customization that the standard allows7.
Technical Documentation
The documentation of each version of TCIP (including the current version) is
currently hosted on the APTA TCIP website in the form of zipped MS Word documents
(60). The standard itself is expansive, providing XML-formatted schema for nearly every
type of transit technology subsystem and business area imaginable including:
7 TCIP provides an expansive “menu” of options that can be specified for a given product/interface. For example, there may be 40 different fields (some of which may be required) for a certain message type. However, one vendor in compliance with TCIP may specify ten of these fields for its product, while anothervendor specifies ten different fields. Both may be TCIP-compliant, but the interoperability is not necessarily ensured. This is, of course, a concern with any flexible standard, but the breadth of TCIP makesit especially so.
60
• Scheduling,
• Passenger Information,
• Onboard Systems,
• Common Public Transport,
• Control Center,
• Fare Collection,
• Spatial Referencing, and
• Transit Signal Priority (TSP). (61)
Figure 6 shows a diagram of the expansive TCIP Model Architecture. The standard
provides building blocks from these schema out of which systems engineers can build
interfaces that are compatible with one another.
61
TCIP allows for the construction of system interfaces through a hierarchy of data
“elements” that compile into “frames” which compose “messages” that are passed
between interfaces in “dialogs” or data exchanges. Figure 7 shows a diagram of this
hierarchical organization. This extremely flexible system allows for an immeasurable
number of combinations and permutations for systems to communicate with one another.
In practice, there may be need for only a few sets of standard messages to send between,
for example, a CAD-AVL system and Web-based trip planner. The developers of TCIP
have accounted for this by making standard message sets available through TIRCE, or
TCIP Implementation Requirements and Capabilities Editor, an application that allows
users to build custom message sets and dialogs.
62
Figure 6 Diagram of TCIP Model Architecture (59)
Development
Institutional Involvement
While the TCIP standard development process began under ITE, the standard
underwent the bulk of its development and refinement while under the direction of
APTA. A series of technical working groups (TWGs) composed of a mix of transit
agency staff and vendor representatives developed the definitions and schema for TCIP.
A TWG existed for each major business area with an additional one for Tools (TWG 4),
for a total of 10 TWGs.
63
Figure 7 Diagram of conceptual hierarchy for TCIP building blocks (59)
An examination of the Passenger Information TWG (TWG 2), for which real-time
passenger information messages and elements are defined, shows the institutional
makeup of those involved in the standard development process. Figure 8 shows the
breakdown of institutional involvement in the Passenger Information TWG. The vendor
category is comprised of consultants to APTA, technical staff, and managerial staff. The
agency category is comprised of technical and managerial staff from transit agencies.
The TWG category is made up of APTA staff.
From this chart, it is clear that vendors make up the largest bucket of institutions
involved in the standard development process with 27 representatives; agencies make up
the second largest group with eight representatives; and TWG staff and academia are the
smallest groups with one and two members, respectively. Although, the number of
representatives listed on a contact sheet for the TWG is a primitive means to begin to
understand the interplay and influence on the standard development process, in the
64
Figure 8 Participants by sector in TCIP Passenger Information Technical Working Group (83)
absence of complete and organized minutes of past meetings, it offers a glimpse at how
institutions were represented in this process. According to Lehr, there are many scenarios
of strategic decision-making that occur within standardization committees. For example,
new market entrants and entrepreneurs are more vulnerable to delays and so stable,
incumbent firms may attempt to delay standardization outcomes (62). Nevertheless, this
process necessarily incorporated vendor input because these firms often know many of
the technical issues facing standardization firsthand.
Evolution
Most of the development work for TCIP was completed around 2006. The
standard moved from active development to a five-year review cycle at that time. A
comprehensive analysis on the changes made to TCIP is more difficult than for GTFS-
realtime or SIRI (see next section). The TCIP documentation is extremely lengthy, and
each version is contained within a series of word documents. This document structure
makes a comparison very cumbersome at best, impossible at worst. The versions are,
however, labeled according to software numbering conventions and number at a total of
fifteen versions (from version 1 to the current version 4.0). The most noteworthy change
for this research appears to have come in TCIP version 3.0.5.2, which was issued on
March 1, 2012 (63).
In version 3.0.5.2 of TCIP, a GTFS timetable importer was included in the
standard. While prior to this version TCIP has made reference to a number of other
industry-accepted standards, these other standards have all been maintained by accredited
SDOs. This is the first acknowledgement that, in some areas, de facto standards and
specifications have an important role to play. Indeed, before GTFS there were no de
65
facto standards adopted so widely to be worth including. However, it appears that when
hundreds of transit agencies (large and small) began to move towards a specification,
APTA took notice and decided to adopt the specification (albeit only as an importer) into
its transit standard family.
Openness
The standard development process for TCIP itself was open and transparent,
allowing any interested party to be involved in the development or comment on version.
APTA's standard development process is modeled after that of the American National
Standards Institute (ANSI), a well-established voluntary consensus standards
development organization whose membership comprises “more than 125,000 companies
and 3.5 million professionals” (64). When it comes to transparency, though, there are
some issues related to communication of information regarding the TCIP standard.
On the one hand, there is a wealth of information available on the standard's
website. Such information includes all previous versions of the standard, archived
meeting notes, free support tools for working with the standard, TWG member lists and
meeting attendee lists, a database of comments on the standard, and more. While the
number of archived documents is impressive, the organization of the material is
confusing. Just as the documentation for changes between versions is buried deep within
large MS Word documents, so is the information contained within these archives. The
content is searchable via a well-indexed search engine, but the organization of the
website is poor and nearly all content is in the form of sizable MS Word documents that
must be downloaded and parsed through.
66
Success
Measuring the success of TCIP by the number of implementations for real-time
passenger information would suggest that the standard has achieved less than it truly has.
There is no good indicator of how many agencies use TCIP to communicate real-time
passenger information either within an agency or to a third party. The only well-
documented instance of TCIP used for real-time passenger information is the pilot project
developed at LYNX (65), the Orlando-area system operated by the Central Florida
Regional Transportation Authority. This implementation of TCIP, however, will likely be
discontinued in the near future according to the interview conducted for TCIP. This is not
to say that the standard is not used in other business areas and for related purposes. There
have been a number of other pilot projects around the country, including at King County
Metro, Maryland MTA, and Chicago Transit Authority. In fact, New York City MTA
utilized modified parts of the standard for a recent project8 to deliver real-time
information to customers (66). Additionally, a recent TCRP synthesis on electronic
passenger information signage in transit reported that six other agencies in the U.S. (not
counting NYC MTA) utilized TCIP for real-time passenger information (67).
While there are a number of projects that draw on TCIP, the standard is far from
achieving its goals of providing intra- or inter-agency interoperability. While these goals
might have been achieved in a few cases around the country, TCIP has seen nowhere near
the adoption rate of GTFS. Based on the integral relationship between GTFS and GTFS-
realtime and other factors discussed in the GTFS case study, this author conjectures that
the same dominance will hold true in time for GTFS-realtime. While TCIP may continue
to play an important role in ensuring interoperability between subsystems beyond real-
8 The real-time information system is known as MTA BusTime (http://bustime.mta.info/).
67
time passenger information and in enabling the pursuit of custom solutions (such as with
NYC MTA), it is likely that it will be dwarfed by GTFS-realtime as it continues to grow
into new markets.
4.2.3 SIRI
Background
History
Developers of the first version of the Service Interface for Real-time Information
(SIRI) began working on the standard between 2004-2005 and the standard officially
emerged as a technical specification under CEN in October 2006 (68). The standard is a
result of the collaborative efforts from “equipment suppliers, transport authorities,
transport operators and transport consultants from eight European countries”
(69) including the Czech Republic, Germany, Denmark, France, Norway, Sweden, and
the United Kingdom. SIRI draws heavily from France's TransModel for its conceptual
framework, and the UK's Real-time Transport Interest Group (RTIG), Germany's Verband
Deutscher Verkehrsunternehmen (VDV), and the EU Trident project provided valuable
starting points for the development of the standard.
Scope
The development of SIRI brought together a number of national transit data
standardization programs in order to more effectively address standardization at a broader
scale. According to SIRI documents, the primary goals for developing the SIRI standard
were to give purchasers of real-time systems “a straightforward, watertight way of
procuring different components of a public transport information system from different
68
suppliers” and to provide suppliers of such systems “a Europe wide market, ensuring that
their systems can be used in every country without needing to implement different
interface standards in each region” (69).
Thus, the benefits were perceived to be directly attributable back to purchasers (or
transit agencies) and suppliers (ITS vendors). An added benefit was the opportunity to
update existing standards (whether at the national level or for proprietary systems) to
account for emerging technologies (69). So, whereas in the U.S., TCIP was the first
standardization attempt (outside of proprietary specifications), SIRI was a “next
generation” standard for a few nations that had already implemented national standards.
Technical Documentation
Technical documentation for SIRI is available in English on the SIRI website in
the form of a white paper (69) and, far more extensively, as a handbook (70). As with
TCIP, SIRI extends far beyond the provision of passenger real-time information (though
perhaps not quite so far as TCIP). Among its ten services shown below, or functional
data categories, those in bold italics are those which are typically considered under the
umbrella of real-time passenger information:
• Production Timetable (PT) – provides information on expected (or scheduled)
transit service for a day in the near future
• Estimated Timetable (ET) – provides information on real-time deviations for the
current day, or only those trips currently in operation
• Stop Timetable (ST) and Stop Monitoring (SM) – gives scheduled information
(ST) and real-time deviations (SM) at the stop level
69
• Vehicle Monitoring (VM) – sends real-time information on the location of a
transit vehicle
• Connection Timetable (CT) and Connection Monitoring (CM) – gives scheduled
information (CT) and real-time deviations (CM) to inform a departing vehicle on
the need to wait for an arriving vehicle at a stop or station serving multiple routes
• General Message (GM) – exchanges basic text messages between entities
• Facilities Management (FM) – provides information on the status of facilities,
such as elevators or escalators that are out of order
• Situation Exchange (SX) – exchanges structured messages between entities (68)
While the Estimated Timetable, Connection Monitoring, and Facilities Monitoring
services all provide real-time information that may be of value to the operations and even
some customer use cases, they are not necessarily within the scope of this research. Stop
Monitoring and Vehicle Monitoring, however, fall well within the definition of providing
schedule deviation/adherence and vehicle locations.
Development
Institutional Involvement
SIRI is the result of collaboration between a number of firms and governments
throughout the European Union. Working group meetings for the standard are attended
by representatives from each member country to CEN, although historically the most
participation and interest have come from Germany, France, the UK, and Scandinavian
countries. As mentioned above, a few national standards already existed from which
SIRI draws a great deal. Because these standards already existed, some interesting
70
accommodations were made in order to satisfy the interests vested in these preexisting
standards. For example, in order that previous implementations of the German VDV
standard might not be broken, two separate XSDs (XML schema definitions)—a nested
and flat version—were maintained for some time. This is a peculiar example of how
institutional and political values can outweigh the purely technical in standard
development.
Evolution
Like GTFS and GTFS-realtime, a well-organized set of versions and their
respective changes is maintained on the SIRI website (71, 72). A list of all changes made
since version 1.2 (April 7, 2007) is maintained there, along with—beginning with version
2.0—the country code of who initiated each change (e.g. Germany (DE), the United
Kingdom (UK), France (FR), etc.). The SIRI standard began as a CEN technical
specification, a “normative document… that would not gather enough as to allow
agreement on a European Standard... or for providing specifications in experimental
circumstances and/or evolving technologies” (73).
The most recent version of SIRI (2.0) was drafted into a proposal in order to
become the more robust and rigorous European Standard (EN), a cornerstone of the
concept of the Single European Market to facilitate effective trade both within and
beyond Europe (74). This continued work and development on SIRI signal its continued
importance in European markets and even in the US, where the NYC MTA heavily
incorporated the standard into its MTA BusTime project mentioned in the TCIP case
study above.
71
Openness
Much like TCIP, SIRI is developed within the confines of a formal, accredited
SDO, the European Committee for Standardisation. As such, the standard development
process is open and consensus-based, relying on a set of protocols that have been
established for the review, adoption, and maintenance of many standards under CEN.
Nevertheless, there are components of the SIRI standard that present barriers to open
participation and implementation of the standard. For one, meetings for the standards are
only open to participants of national committee members. Others may participate as
observers, but only on an invitational basis. Further, while the license restricting the use
of the standard only requires that copyright holders be acknowledged, formal standard
documentation must be purchased via the national member sites (e.g., via VDV's
website)9 and reproduction of any part of supporting standards produced by non-members
is prohibited without permission from these copyright holders. These barriers to
implementation and participation are minor, but remain impediments to becoming a fully
open standard.
Success
The continued and active development on SIRI points to its success as a standard,
especially in European markets. However, the standard would not be under consideration
had it not seen some interest and adoption in the U.S. market. NYC MTA is one of the
agencies that continues to push the evolution and development around SIRI, having
adopted it for MTA BusTime and pushing to add JSON (JavaScript Object Notation – a
9 Purchase of the SIRI specification was confirmed by an interview with a participant in the SIRI standardsdevelopment process. While there exist sites that host what appears to be the complete SIRI documentationfree of charge (http://www.siri.org.uk/), the researcher could not locate the national member sites where documentation or schema were available for purchase.
72
lightweight, web-ready alternative to XML) formatting and modern web service transport
methods to the standard (75). There are at least five other U.S. transit agencies reporting
usage of SIRI in a recent TCRP Synthesis on the use of electronic passenger information
signage in transit (67). Compared with the usage of either TCIP or GTFS-realtime this is
certainly a strong showing, especially given that this standard was imported from the
European Union.
4.3 Comparison of Standards and Standards Development Processes
4.3.1 Assessment of Openness
The framework used here to assess the openness of the real-time standards
considered in the case studies draws heavily from Krechmer's ten requirements of open
standards. While the categories were interpreted slightly differently than his original
descriptions to account for some of the idiosyncrasies of the requirements and to apply
them more directly to this case, the open standard requirements remain largely
unchanged.
The three case study standards (GTFS-realtime, TCIP, and SIRI) were each given
a scoring for the ten requirements. Table 4 shows the scoring of these categories broken
out. The scoring methodology was taken directly from Krechmer, with a few
modifications for this specific context. Appendix B: Openness Index Scoring describes
the breakdown of scoring for each requirement, the range for each category, and a
selection of notes that support the scoring decisions presented in Table 4.
The three open standards are considered alongside the NextBus API specification
solely to compare with a closed specification from the industry. While TCIP and SIRI
perform nearly identically in every category, GTFS-realtime earns higher marks in open
73
meetings, open IPR, open change (a direct representation of its stronger performance in
open meeting), and open documents. NextBus, on the other hand, being a closed
standard shows a low openness index, although it does earn a few marks in the open
world, open documents, and on-going support categories.
The results from the above table suggest that GTFS-realtime is a more open
standard than either TCIP or SIRI, which are both managed through accredited SDOs.
What explains this finding? Krechmer defines open standards as understood from the
lens of open source software. This is a very democratic and distributed perspective that
values not just consensus-based processes, but also the openness that is ascribed to fully
open meetings that are held and recorded for posterity online. It also depends on clear,
complete, and available documentation. It is in these areas where GTFS-realtime excels
most. Any discussion of the future of the standard is discussed online in an open forum.
The IPR licensing is clearly stated and defined on the GTFS-realtime documentation
(whereas with the others it is somewhat obscure). The documentation is fully available
online and presented in a coherent, concise way.
74
Table 4 Openness index scores for real-time transit passenger information standards
RequirementsStandards
SIRI TCIP NextBusOpen Meeting 0 0 1 0Consensus 1 1 1 0Due Process 1 1 1 0Open World 1 1 1 1Open IPR 2 3 4 0Open Change 0 0 1 0Open Documents 2 1 3 1Open Interface 1 1 1 0Open Access 1 1 1 0On-going Support 3 3 3 2
TOTAL 12 12 17 4
GTFS-rt
Certainly, there may come a time when Google decides to move away from
providing transit information (though this appears unlikely given its investment in the
product worldwide). Yet because GTFS-realtime is so well documented and the content
is clearly licensed, GTFS-realtime could easily spin off and continue to develop if the
adoption and interest were great enough. It is for these reasons that GTFS-realtime
scored higher on the openness index and perhaps why the standard may continue to
flourish.
4.3.2 Implementations
Each of the case studies examined the success of implementations for each of
three standards. According to data compiled from multiple sources, there appear to be
similar levels of adoption for the standards (67, 76). Figure 9 below shows data from the
2013 APTA Survey on real-time information provision, indicating that the closed
NextBus specification seems to hold the largest market share10. Even comparing with
data from TCRP which suggests that TCIP has seven U.S. implementers and that SIRI has
six, this observation holds true.
10 It is also worth noting that, although the survey indicates that 12 APTA member agencies have implemented NextBus, the NextBus website (https://www.nextbus.com/agencies/ accessed on August 2, 2013) reports that approximately 80 U.S. agencies have NextBus real-time systems (this includes APTA member agencies, some of which are duplicated in the list, as well as small university or circulator systems). This suggests remarkable rates of adoption for NextBus and is important to consider, yet this analysis will take into account only those agencies within the scope of this research, i.e. APTA member transit agencies.
75
An important caveat to the standards' levels of adoption is a look at how these
adoption levels have grown over time. This is, of course, a rough an imprecise measure
because there are a variety of complex and difficult-to-measure factors that influence
standard adoption (network effects, lock-in, etc.). Nonetheless, Figure 9 gives a picture
of how quickly these different standards have seen adoption since their inception. The
table shows the average number of agencies that have adopted each standard per year.
The year of inception is based upon the date that documentation was first made available.
For GTFS-realtime and SIRI, there is a strong confidence that the year of inception is
accurate. However, for NextBus and SIRI there may be instances where implementations
were in place before the year shown.
76
Figure 9 Adoption of real-time data standards (76)
The above table shows that, even though it is relatively new, GTFS-realtime has
the second highest number of agencies with implementations and the highest adoption
rate (average agencies per year). This finding holds true with reasonable expectations for
GTFS-realtime based on its integral relationship to GTFS, which hundreds of agencies
have adopted in a period of approximately 7 years (estimated adoption rate of
approximately 40 agencies per year). Assuming that Google continues to utilize GTFS-
realtime for its products and the standard review process remains open to full public
participation, it is likely that this adoption rate will continue to increase.
77
Table 5 Average adoption rate for (agencies per year) for real-time standards (67, 76)
Standard Year of inception Number of agencies Agencies per yearNextBus 2009 12 3.00TCIP 2006 7 1.00SIRI 2004 5 0.56
2011 8 4.00GTFS-rt
CHAPTER 5
RECOMMENDATIONS
5.1 Moving Ahead for Innovation in the 21st century
Effective real-time passenger information systems are crucial to satisfying
customers' expectations and demands. Transit riders are adopting smartphones and still
waiting for the bus. Budget-constrained agencies can deliver this information with
relatively little infrastructure by making use of often pre-existing AVL systems and
pursuing the open data policies already adopted by President Obama's administration.
There are certainly costs associated with this approach, especially if AVL data are
contained within a proprietary format. Nevertheless, the open standards that have
developed over the past couple of decades allow a path forward to break vendor lock-in
and reduce switching costs in the future.
While Moving Ahead for Progress in the 21st Century (MAP-21) addresses ITS in
general ways and allocates some funding for ITS (77), there are some opportunities to
address transportation technology and policy in the next-cycle authorization bill. MAP-
21 funding ends with FY 2014, so the next authorization bill will likely be introduced
sometime before the current fiscal year ends. The President's Executive Order (EO) on
open data for federal agencies offers an opportunity for the USDOT, specifically the FTA,
to couple ITS improvements at the local level with open data initiatives. The framework
to pursue these initiatives is in place—thanks to progressive agencies such as TriMet and
others—should Congress find that such a policy is in the nation's best interest. Open
78
data, besides being a force for government transparency and cost effectiveness, provides
sparks for innovation in both the public and private sectors.
One major criticism in this paper of TCIP is that documentation on the standards
development process and the standard itself is difficult to consume. As mentioned above,
understanding the changes between versions of the standard is difficult because there is
no list of versions and their respective changes over time. If this is difficult for the
researcher, it is almost certainly difficult for any organization interested in implementing
the standard. Therefore, another recommendation that follows the aim of transparency
from the open data EO is to substantially reorganize this content to improve not only how
the comprehensibility of the information therein, but also to simply improve the
transparency of the project generally.
5.2 Predictions for Continued Trends
Based on the historical success of GTFS and the indirect network effects that
bundle the static specification with its real-time component, there will likely be
widespread adoption of GTFS-realtime in the near future. The 2013 survey on real-time
arrival information by APTA (76) and TCRP Synthesis 104 on electronic signage by
Schweiger (67) mentioned above both capture a great deal of valuable information about
the current market for real-time information.
One point drawn from the market analysis provided by the APTA survey is that
there is immense demand by agencies to share real-time passenger information with their
customers. Currently only 37% of agencies are providing real-time information via an
API or web or mobile application. For agencies without AVL systems, the vast majority
of them (92%) are interested in installing AVL on their vehicles. Even of those agencies
79
that have AVL systems already, 47% currently do not provide customer-facing real-time
arrival times.
The benefits of public-facing (especially mobile) information systems have been
well established (see Chapter 1), so it is likely that the agencies with AVL but without
public-facing systems will soon move forward with a public-facing solution. In fact,
Figure 10 shows the reasons agencies are not providing arrival times to the public. While
8% of these agencies have projects in progress and a handful of others have
organizational or technical restrictions, over 20% simply are constrained by technical
ability or funding constraints. As open standards diffuse into the market, economic
theory dictates that the cost of implementation will decrease, making feasible solutions a
realistic option for more and more agencies.
By cross-referencing data sources that capture the usage of real-time transit
passenger information standards, it appears that SIRI, GTFS-realtime, and TCIP all have
a similar number of implementations in the U.S. However, the adoption rate for GTFS-
realtime far outpaces that of either SIRI or TCIP (and even beyond that of NextBus, a
80
Figure 10 Reasons given by transit agencies for not providing public arrival times (76)
popular proprietary solution). Anecdotal evidence from open source repository hosting
applications such as GitHub (https://github.com) suggest that software development is
most active around GTFS-realtime. While this should not serve as concrete evidence of
adoption or even transit agency interest, it does bring up the question of how open
movements (open standards, open data, and open source) overlap and reinforce one
another and how this might apply to the case of real-time transit passenger information.
5.3 Federal Policy Recommendations
To date, there has been little visible response from the federal government to the
development of alternative de facto standards for passenger information such as GTFS
and GTFS-realtime. True, GTFS was incorporated into TCIP in version 3.0.5.2 of the
standard that was issued on March 1, 2012. However, it is unclear how effective the
inclusion of this GTFS timetable importer has been for the proliferation of TCIP and,
consequently, how effective such action would be for including translators or importers
between GTFS-realtime and TCIP or SIRI and TCIP. It seems that the federal
government could take one of a few alternative paths of engagement to respond to the
likely proliferation of GTFS-realtime or the possible proliferation of SIRI in the United
States. The paths listed here are as follows:
1. Achieve Interoperability – work to develop translators or importers for de facto
standards to keep TCIP relevant (as with static GTFS). In 2012, APTA released a
new version of TCIP that included the functionality to import static GTFS
“timetables” into TCIP-formatted messages. This could be an approach for
keeping TCIP interoperable with real-time passenger information provided by
agencies with GTFS-realtime, SIRI, or any other open standard.
81
This path is not recommended by this researcher because the cost of
the approach is shouldered by the public sector rather than developers or vendors
that otherwise might be incentivized to shoulder the development work
themselves.
2. Provide Guidance to or Incent Vendors/Agencies – shift focus to providing
guidance on the development of open systems and use of open standards where
real-time passenger information is concerned. Incenting vendors or agencies to
provide open standards is listed as one of the FTA strategies to study in a 2011
FTA report prepared by the Volpe Center (11). The status of this program is
currently unknown. However, the approach listed in this document promoted
incentivizing only the adoption of TCIP. A more flexible approach would be to
incentivize the adoption of any one of a set of open standards (perhaps any one of
the three standards studied in this research). Such an action would (a) encourage
a flexibility of approaches that would all be open, (b) allow market forces to
shape an efficient outcome, and (c) possibly spur the market of vendors or civic
hackers to further develop translator/repeater to convert from one standard to the
next.
This path is recommended because it draws a balance between cost
effectiveness and ensuring the promulgation and (possibly) eventual
interoperability of all open standards concerned. In this approach, there may be
costs involved with incentives provided (whether they be financial or not), but
these costs are likely to be less than Approach 1 and have the added benefit of
engaging all stakeholders actively. Additionally, this path provides opportunities
82
for the TCIP standard to be adopted for other functional areas within transit
agencies. If GTFS-realtime in fact becomes a de facto standard for real-time
passenger information (just as GTFS has already become), agencies may find
greater benefit in TCIP if the standard is compatible with GTFS-realtime.
3. Follow Existing Path (Do Nothing) – do not respond to the high adoption of
real-time passenger information standards; let the market manage the adoption of
standards and rely on regional ITS architectures to guide this process. This path
is not recommended because it ignores the clear response of agencies to adopt
open standards, whether TCIP or not. This policy response does not work to effect
change or assist agencies or vendors that are interested in supporting open
standards and, in turn, promoting the goals of regional ITS architectures to intra-
and inter-agency interoperability as well as interoperability with emerging
technologies and systems.
83
CHAPTER 6
CONCLUSION
This research has addressed the history and background of federal ITS policy and
the role of real-time transit passenger information. A comprehensive literature review of
standard setting theory has helped to frame the multiple case study approach to
understanding and reviewing the standard development processes for and institutional
influences on GTFS-realtime, TCIP, and SIRI—the major open standards used in the U.S.
for the delivery of real-time transit passenger information. Among the impacts analyzed
here are the effect that the standard development processes have had on the adoption and
diffusion of the standards, or the “success” of each standard. Federal policy
recommendations on the role of government in this area of growing importance are
provided here as well.
6.1 Key Findings
A crucial finding of this research is that standards that open themselves to
participatory and democratic processes (characterized by clear documentation, open
communication—e.g. via mailing list—and rough consensus) may begin to play a larger
role in technology and society. This has been demonstrated by Krechmer and others (24,
25) with the influential role that IETF has played in building standards for the Internet—a
process which is not without criticism or issues of its own (78)—one of the most
important technology systems for today's economy and society.
These case studies also suggest that early, on-the-ground implementations of
standards are critical to achieving adoption. Much like IETF, GTFS-realtime began as an
invitation-only group in order to get rough installations of the standard implemented and
84
working before opening the standard to the general public. This model is unable to
account for the complex and comprehensive standards that may result from committee,
but perhaps the committee approach is not always the most effective way to see
standardization occur in an industry—unless broad consensus is met on implementation
of the standard as with HDTV in the U.S. (see Public Policy and Standards
Development).
As a strategy to achieve interoperability in this important area of transit ITS, the
researcher recommends an incentive strategy for the federal government to promulgate
open standards for real-time transit passenger information. By incenting vendors and
agencies to adopt any open standard (not just TCIP), the FTA would (a) encourage a
flexibility of approaches that would all be open, (b) allow market forces to shape an
efficient outcome, and (c) possibly spur the market of vendors or civic hackers to further
develop translator/repeater to convert from one standard to the next. Such an approach
would be cost-effective, engage the broadening base of stakeholders, and embrace the
language supporting open and machine-readable government information in President
Obama's Executive Order 13642.
6.2 Future Work
Future work should include a comprehensive and systematic survey of transit
operators, vendors, and the emerging group of contributors to transit web and mobile
information systems. In addition to confirming the exact interfaces and standards
implemented (in past surveys, responses sometimes indicate contradictory or confusing
results), the survey should quantify perceptions and attitudes about open and proprietary
standards. Commendably, APTA has begun to do this with their 2013 survey (see Figure
85
11), yet a cross-sectional look at not just agencies, but also vendors and other
contributors, will help to clarify a complete vision of the state of standards development
and adoption for real-time transit passenger information.
This proposed survey could tap the members of mailing lists maintained on
Google Groups dedicated to the discussion of these specific standards (such groups
currently exist for GTFS-realtime and SIRI) and the development of transit applications
generally. It would be instructive, too, to revisit the vendor perspectives on open
standards explored by Hickman in 1998 (38). While this research considered only APTA
member transit agencies, expanding the scope to all transit operators in the region
(including small circulators and university systems) would help to clarify the overall
picture of perspectives on open standards.
Another future research area that may already be underway at FTA is to
understand what kind of incentive structure would best spur agencies and vendors to
86
Figure 11 Issues agencies have with adoption of open standards for real-time data (76)
adopt open standards. Currently the research scope for agency and vendor incentives at
FTA only allows for TCIP; however, it is crucial that other open standards for real-time
transit passenger information be recognized as an integral pieces to a larger puzzle. The
comprehensive survey work described above would help to clarify the type of incentives
needed to move the industry toward open standards.
While such research would be valuable to understanding motives and market
forces currently in play, the next few years of standardization may obviate the need for
such research. As open standards spread in the United States and the demand for real-
time transit passenger information grows stronger, the industry may reach the tipping
point of de facto standardization, enabling an efficient and effective marketplace for both
purchasers and suppliers of real-time systems. The adoption of a standard by an industry
and even a single agency is a complex phenomenon, full of many difficult to measure
externalities. However, the open standards marketplace and the standards themselves can
be made more efficient and effective through greater transparency and the further
democratization of the standards development process.
87
APPENDIX A
INTERVIEW QUESTIONS
Interview Questions
Interviewee's role in standard development• Were you involved in the initial development of the standard?◦ If so, what was your role in the past?◦ What is your role now?
• What are the number of hours you commit to the standard per month or week?◦ How would you define the nature of this work?▪ Support▪ Development▪ Stakeholder Coordination▪ Other
◦ How has this commitment level changed over time?• Do you work closely with others on the standard?
History of standard development process• When did the standard development process begin?◦ Did the standards development process begin with a different organization?◦ If so, how did the transition between organizations occur?
• Have changes been made to the standard itself over time?◦ If so, how frequent have these changes occurred?◦ Could these changes be categorized as major (structural or purpose) or minor
(technical details)? Do you have any examples?◦ What are some changes currently under consideration for the standard?
• How have the different groups of stakeholders for the standard changed over time?◦ Who are the existing stakeholders?◦ Would you characterize each of these stakeholder groups as active, moderately
active, or inactive?• How do you anticipate the standards development process to change in the future?◦ Do you expect changes to the goals or purpose of the standard?◦ Do you expect changes to the organization charged with developing the
standard or governance of the standard?◦ Do you expect major substantive changes to the standard itself?
Meetings, Consensus, and Formal Processes
88
• Are meetings held to discuss the standard development?◦ What is the forum for these meetings (in other words, are they held
electronically, over email, in person)?◦ What is the frequency of these meetings?◦ Are these meetings open to the public?◦ How and to whom are these meetings publicized?
• Is consensus a requirement for decision making?◦ How is consensus defined in this context (somewhere between 51% and
99%)?◦ If consensus is not reached what happens to the issue at hand?
• What are the formal procedures that must be followed when considering change proposals, comments, or change adoptions?◦ May anyone make their views known?◦ What must occur for a change to be adopted formally into the standard?▪ Are there balloting procedures?▪ Who can participate in the balloting?
IPR, Global Availability• Under what license is the standard provided?◦ Are there restrictions on the use of the standard?◦ Do these restrictions infringe upon reasonable and non-discriminatory
(RAND) terms?• Could the standard be implemented anywhere in the world?◦ Are there technical restrictions on its use in another country (such as language
or character encodings)?◦ Is the standard dependent on other standards that are only available on a local,
regional, or national basis?
Transparency, Interface, and Access• Are discussions pertinent to standard made in a public forum, where anyone may
participate?• Are work-in-progress documents (technical proposals, meeting minutes/reports,
or proposed changes) made openly available and published publicly?◦ If not, to whom are these documents available?
• Is documentation on the final standard available publicly?• Is there a method by which interested parties can be alerted to news related to the
standard?• Are different versions of the standard developed to be forward and backward
compatible?◦ What is required of implementers in order to make an implementation of the
standard function with a different version?• Are implementers of the standard able to verify conformance with the standard?
89
◦ Are users able to verify conformance?◦ What tools are available for validating an implementation?
• Are there multiple implementations of the standard available that users can access?
Support for Implementers• Is support for the standard on-going and available for any user or implementer?◦ If not, what are the restrictions on support for the standard?
• Are the phases in the lifetime of the standard for which support is not provided? ◦ The five phases of a standard's lifetime can be defined as: (1) creation, (2)
fixes, (3) maintenance, (4) availability, and (5) rescission.
90
APPENDIX B
OPENNESS INDEX SCORING
91
Requirements RangeSIRI
Score Notes
Open Meeting (0-1) 0Consensus (0-1) 1 Proposals are approved on a consensus basis.Due Process (0-1) 1 Due process is followed per CEN policies.
Open World (0-1) 1
Open IPR (0-4) 2Open Change (0-1) 0 The first five requirements are not met.
Open Documents (0-3) 2
Open Interface (0-1) 1
Open Access (0-1) 1
On-going Support (0-3) 3TOTAL 12
Meetings are primarily only open to member countries, though there may be occasional exceptions to invite contributors on an ad hoc basis.
There are implementations in a number of European countries as well as in the United States.According to the SIRI website, the schema is copyright of the member companies and organizations. The schema may be used as long as these bodies are acknowledged. However, the schema may not be reproduced without permission of the identified copyright holders.
Documentation for the current standard (and past versions) is freely available. The documentation is well organized and easy to consume. However, according to the interview, the official documentation must be purchased from national member sites. This could not be confirmed after through research and so may need future investigation.The specification aims to meet forward and backward compatibility principles.The SIRI website makes available a number of examples to verify compliance against as well as a number of implementations around the world.According to interviews, SIRI has an active community that contributes to ongoing support of the standard. The strong interests of CEN member countries in the standard suggests that it will see lifetime support.
92
Requirements RangeTCIP
Score Notes
Open Meeting (0-1) 0
Consensus (0-1) 1Due Process (0-1) 1 Due process policies are documented on the TCIP website.Open World (0-1) 1 There are implementations in the US and Canada.
Open IPR (0-4) 3Open Change (0-1) 0 The first five requirements are not met.
Open Documents (0-3) 1
Open Interface (0-1) 1
Open Access (0-1) 1
On-going Support (0-3) 3TOTAL 12
While meeting participation is available to all parties and there are some meeting minutes available online, implementers have no way to easily consume all of these documents nor is there a clear path to becoming involved in meetings on the standard.Proposals are approved on a consensus basis, which is documented on the TCIP website.
According to interviews, use and redistribution of the standard is permitted. However, the licensing is not clearly indicated on the website for the standard or in any documentation.
Documentation for the current standard (and past versions) is freely available. However, the documents are poorly organized and difficult to consume. The availability of meeting minutes is patchy. Understanding the changes made to each subsequent version is cumbersome.The standard aims to meet forward and backward compatibility principles.Accessing and verifying the validity of other implementations is made easy with free tools to process and develop message sets.APTA engages in a regular maintenance plan to review and revise TCIP on a periodic basis.
93
Requirements RangeGTFS-rt
Score Notes
Open Meeting (0-1) 1Consensus (0-1) 1 Proposals are approved on a consensus basis.
Due Process (0-1) 1
Open World (0-1) 1
Open IPR (0-4) 4Open Change (0-1) 1 The first five requirements are met.
Open Documents (0-3) 3
Open Interface (0-1) 1
Open Access (0-1) 1
On-going Support (0-3) 3TOTAL 17
Meetings are open to any and all contributors and are accessible via a mailing list on a Google Group.
Change proposals and comments are vetted in a transparent forum on the mailing list. In order for proposals to move forward, they must have support by both a developer and implementer.The specification was released with implementations in the US, Canada, Spain, and Italy.The license for the specification is clearly published. Use of the standard is permissive and parameters on its use and redistribution are clearly outlined.
The documentation for the specification is clear and concise. There is clear documentation on how to use the specification. “Meeting minutes” and discussions are fully preserved on the mailing listThe specification aims to meet forward and backward compatibility principles. Extensions made to the standard will not break the existing standard.Accessing and verifying the validity of other implementations is made easy with open source tools to process implementations.Because the standard is available with an express and permissive license and because the standard is not housed within a formal SDO, the maintenance of the specification could proceed even if Google decided to abandon the standard.
94
Requirements RangeNextBus
Score NotesOpen Meeting (0-1) 0 There is no open meeting to discuss the NextBus specification.
Consensus (0-1) 0Due Process (0-1) 0 There is no formal process for filing comments on the specification.Open World (0-1) 1 The specification has implementations in the US and Canada.
Open IPR (0-4) 0Open Change (0-1) 0 The first five requirements are not met.
Open Documents (0-3) 1
Open Interface (0-1) 0
Open Access (0-1) 0
On-going Support (0-3) 2TOTAL 4
While NextBus clients may be able to influence the specification to some degree, the ultimate decision belongs to NextBus.
The specification is distributed with the NextBus copyright and may not be used except by NextBus Inc.
Documentation for the current specification is freely available. However, future changes and documents on committee meetings or change proposals are not available.The specification does not meet requirements for open interface including backward and forward compatibility principally because documentation on changes and schema downloads are not fully available.Outside of NextBus Inc.'s website there is no way to access implementations.Support for the standard appears to be available during most phases of the specification's lifetime.
REFERENCES
1. Gildea, D., and M. Sheikh. Applications of Technology in Providing Transit
Information. Transp. Res. Rec., Vol. 1521, No. 1, 1996, pp. 71–76. Available at:
http://trb.metapress.com/content/755n164721hqt866/.
2. Watkins, K. E., B. Ferris, A. Borning, G. S. Rutherford, and D. Layton. Where Is My
Bus? Impact of mobile real-time information on the perceived and actual wait time
of transit riders. Transp. Res. Part A Policy Pract., Vol. 45, No. 8, 2011, pp. 839–
848. Available at: http://linkinghub.elsevier.com/retrieve/pii/S0965856411001030
[Accessed August 9, 2013].
3. Ferris, B. OneBusAway: Improving the Usability of Public Transit. 2011, Available at:
http://dub.washington.edu/pubs/277 [Accessed August 2, 2013].
4. Tang, L., and P. Thakuriah. Ridership effects of real-time bus information system: A
case study in the City of Chicago. Transp. Res. Part C Emerg. …, 2012, Available
at: http://www.sciencedirect.com/science/article/pii/S0968090X12000022
[Accessed November 16, 2013].
5. Miller, D. L. et al. TCRP Synthesis 73 AVL Systems for Bus Transit : Update.
Transportation Research Board, 2008.
6. ITS FAQs. U.S. Dep. Transp. via Internet Arch., 2000, .
95
7. ITS Joint Program Office FAQs. U.S. Dep. Transp., 2013, Available at:
http://www.its.dot.gov/faqs.htm [Accessed September 3, 2013].
8. United States Congress. Transportation Equity Act for the 21st Century. Public Law,
1998, Available at: http://scholar.google.com/scholar?
hl=en&btnG=Search&q=intitle:Transportation+Equity+Act+for+the+21st+Centur
y#2 [Accessed September 5, 2013].
9. The National ITS Architecture 7.0. Iteris, 2013, Available at:
http://www.iteris.com/itsarch/ [Accessed September 4, 2013].
10. USDOT. Intelligent Transportation System Architecture and Standards; Final Rule.
Fed. Regist., Vol. 66, No. 5, 2001, pp. 1445–1459.
11. Burger, C. et al. FTA Transit Intelligent Transportation System Architecture
Consistency Review – 2010 Update. 2011.
12. Branscomb, L. M., and J. Keller. Converging Infrastructures: Intelligent
Transportation and the National Information Infrastructure. The MIT Press, 1996.
13. Obama, B. MAKING OPEN AND MACHINE READABLE THE NEW DEFAULT
FOR GOVERNMENT INFORMATION. 2013, pp. 1–3. Available at:
http://www.gpo.gov/fdsys/pkg/FR-2013-05-14/pdf/2013-11533.pdf.
14. Manyika, J. et al. Open data : Unlocking innovation and performance with liquid
information. 2013.
96
15. Moving America on Transit. Locat. Inf. Syst. Lab. USF, 2012, Available at:
http://www.locationaware.usf.edu/ongoing-research/projects/moving-america-on-
transit/ [Accessed September 4, 2013].
16. Gandal, N. Compatibility, Standardization, & Network Effects: Some Policy
Implications. Oxford Rev. Econ. Policy, No. January, 2002, pp. 1–22. Available at:
http://oxrep.oxfordjournals.org/content/18/1/80.short [Accessed August 29, 2013].
17. Beggs, A., and P. Klemperer. Multi-period competition with switching costs. Econom.
J. Econom. Soc., 1992, Available at: http://www.jstor.org/stable/10.2307/2951587
[Accessed August 28, 2013].
18. Sundararajan, A. Local network effects and complex network structure. BE J. Theor.
Econ., No. September, 2007, Available at:
http://www.degruyter.com/view/j/bejte.2007.7.1/bejte.2007.7.1.1319/bejte.2007.7.
1.1319.xml [Accessed September 5, 2013].
19. Farrell, J., and G. Saloner. Standardization, compatibility, and innovation. Rand J.
Econ., Vol. 16, No. 1, 1985, pp. 70–83. Available at:
http://www.jstor.org/stable/10.2307/2555589 [Accessed August 2, 2013].
20. Katz, M., and C. Shapiro. Network externalities, competition, and compatibility. Am.
Econ. Rev., Vol. 75, No. 3, 1985, pp. 424–440. Available at:
http://www.jstor.org/stable/10.2307/1814809 [Accessed August 27, 2013].
97
21. Farrell, J., and P. Klemperer. Coordination and Lock-in: Competition with Switching
Costs and Network Effects. Handb. Ind. Organ., 2007, Available at:
http://www.sciencedirect.com/science/article/pii/S1573448X06030317 [Accessed
August 16, 2013].
22. Farrell, J., and G. Saloner. Coordination through committees and Markets. Rand J.
Econ., 1988, Available at: http://www.jstor.org/stable/10.2307/2555702 [Accessed
August 28, 2013].
23. Keil, T. De-facto standardization through alliances—lessons from Bluetooth.
Telecomm. Policy, Vol. 26, No. 3-4, 2002, pp. 205–213. Available at:
http://linkinghub.elsevier.com/retrieve/pii/S0308596102000101.
24. Krechmer, K. Open standards requirements. J. IT Stand. Stand. Res., Vol. 50, No. 6,
2006, pp. 1–34. Available at: http://www.igi-global.com/article/open-standards-
requirements/2573 [Accessed August 16, 2013].
25. West, J. Standards and public policy,, eds Greenstein S, Stango V. 1st Ed. 2007.
Available at: http://books.google.com/books?
hl=en&lr=&id=3hMKHwUmaZ8C&oi=fnd&pg=PA87&dq=The+Economic+Reali
ties+of+Open+Standards+:+Black+,
+White+and+Many+Shades+of+Gray&ots=rw-
lwgfRNy&sig=2RRILw75h2owJzr4XNVbBfE6G70 [Accessed September 6,
2013].
98
26. Cargill, C. Intellectual Property Rights and Standards Setting Organizations: An
Overview of Failed Evolution Submitted to the Department of Justice and the
Federal Trade Commission. 2002. Available at:
http://xml.coverpages.org/CargillPatents020418.pdf [Accessed August 28, 2013].
27. History of the OSI. Open Source Initiat., 2012, .
28. O’Reilly, T. Open Government: Collaboration, Transparency, and Participation in
Practice,, eds Lathrop D, Ruma LFebruary 2. 2010.
29. Greenstein, S., and V. Stango. Standards and public policy,, eds Greenstein S, Stango
V 2007. Available at: http://books.google.com/books?
hl=en&lr=&id=3hMKHwUmaZ8C&oi=fnd&pg=PR8&dq=standards+and+public
+policy&ots=rw-kz9kWED&sig=DXcNfKOXX3tUtarfuMveWhp7_2A [Accessed
August 28, 2013].
30. David, P., and S. Greenstein. The Economics of Compatibility Standards: An
Introduction to Recent Research. Econ. Innov. new …, Vol. 1, 1990, pp. 3–41.
Available at: http://www.tandfonline.com/doi/abs/10.1080/10438599000000002
[Accessed August 29, 2013].
31. Besen, S., and L. Johnson. Compatibility standards, competition, and innovation in
the broadcasting industry. RAND Corporation, Santa Monica, CA, 1986. Available
at: http://www.rand.org/pubs/reports/R3453 [Accessed September 18, 2013].
99
32. Cabral, L., and T. Kretschmer. Standards and public policy,, eds Greenstein S, Stango
V 2007. Available at: http://books.google.com/books?
hl=en&lr=&id=3hMKHwUmaZ8C&oi=fnd&pg=PA329&dq=Standards+Battles+a
nd+Public+Policy&ots=rw-kz9kXFy&sig=b8GXROBKH5XtvrCQYjsWBBvgbkc
[Accessed August 28, 2013].
33. Farrell, J., C. Shapiro, R. Nelson, and R. Noll. Standard setting in high-definition
television. Brookings Pap. Econ. …, No. Ses 8821529, 1992, Available at:
http://www.jstor.org/stable/10.2307/2534762 [Accessed October 2, 2013].
34. Alvarez, S., J. Chen, D. Lecumberri, and C. Yang. HDTV: The Engineering History.
1999, Available at: http://web.mit.edu/6.933/www/HDTV.pdf [Accessed October
2, 2013].
35. Bresnahan, T. F., and P.-L. Yin. Standards and Public Policy,, eds Greenstein S,
Stango V 2007.
36. David, P. A. Some new standards for the economics of standardization in the
information age. Econ. policy Technol. Perform., 1987, pp. 206–239.
37. Tassey, G. Standardization in technology-based markets. Res. Policy, Vol. 1, No. 4-5,
2000, pp. 587–602. Available at:
http://linkinghub.elsevier.com/retrieve/pii/S0048733399000918 [Accessed August
28, 2013].
100
38. Hickman, M., S. Tabibnia, and T. Day. Evaluating Interface Standards for the Public
Transit Industry. Transp. Res. Rec. J. Transp. Res. Board, Vol. 1618, No. 1, 1998,
pp. 172–179. Available at:
http://trb.metapress.com/index/N810P3N140M7601P.pdf [Accessed August 23,
2013].
39. Cargill, C., and S. Bolin. Standards and public policy,, eds Greenstein S, Stango V
2007.
40. Perens, B. Open Standards Principles and Practice. Available at:
http://perens.com/OpenStandards/Definition.html [Accessed September 10, 2013].
41. The Open Source Definition (Annotated). Open Source Initiat., 2013, .
42. Open Source Licenses. Open Source Initiat., 2013, Available at:
http://opensource.org/licenses [Accessed November 7, 2013].
43. Deshpande, A., and D. Riehle. The total growth of open source. Open Source Dev.
Communities Qual., No. December 2006, 2008, pp. 197–209. Available at:
http://link.springer.com/chapter/10.1007/978-0-387-09684-1_16 [Accessed
September 10, 2013].
44. Baraniuk, C. The civic hackers reshaping your government. New Sci., Vol. 218, No.
2923, 2013, pp. 36–39. Available at:
http://www.sciencedirect.com/science/article/pii/S0262407913616255 [Accessed
November 8, 2013].
101
45. Yin, R. Case study research: Design and methods. 2009. Available at:
http://books.google.com/books?
hl=en&lr=&id=FzawIAdilHkC&oi=fnd&pg=PR1&dq=case+study+research+desi
gn+and+methods&ots=lX5O7bkSZt&sig=tB5IynYMjylAmXCswte6fjfBaH4
[Accessed October 2, 2013].
46. Rojas, F. Transit Transparency: Effective Disclosure through Open Data. 2012.
Available at:
http://www.transparencypolicy.net/assets/FINAL_UTC_TransitTransparency_8 28
2012.pdf [Accessed July 10, 2013].
47. Harrelson, C. Happy trails with Google Transit. Google Off. Blog, 2006, Available at:
http://googleblog.blogspot.com/2006/09/happy-trails-with-google-transit.html
[Accessed September 4, 2013].
48. Hughes, J. proposal: remove “Google” from the name of GTFS. Google Groups,
2009, Available at: https://groups.google.com/d/msg/gtfs-
changes/ob_7MIOvOxU/zEScjv6VLBMJ [Accessed September 19, 2013].
49. Czebotar, J. GTFS Data Exchange. 2011, Available at: http://www.gtfs-data-
exchange.com/ [Accessed December 9, 2011].
50. City-Go-Round. List of Public Agencies on City-Go-Round. 2011, Available at:
http://www.citygoround.org/agencies/ [Accessed October 27, 2011].
102
51. Gontmakher, S. Know when your bus is late with live transit updates in Google Maps.
Google Off. Blog, 2011, Available at:
http://googleblog.blogspot.com/2011/06/know-when-your-bus-is-late-with-
live.html [Accessed October 2, 2013].
52. Protocol Buffers Developer Guide: Overview. Google Dev., 2012, .
53. GTFS-realtime Documentation. Google Dev., 2012, Available at:
https://developers.google.com/transit/gtfs-realtime/ [Accessed September 20,
2013].
54. Ferris, B., and S. Barbeau. Real Time Data Configuration Guide. GitHub, 2013, .
55. Creative Commons Attribution 3.0 License. Creat. Commons, 2013, .
56. Apache 2.0 License. Apache Softw. Found., 2013, .
57. Ferris, B. GTFS Realtime Resources: Tools and Libraries. 2013, Available at:
https://github.com/OneBusAway/onebusaway/wiki/GTFS-Realtime-
Resources#tools-and-libraries [Accessed November 7, 2013].
58. ITE. Institute of Transportation Engineers Response to Comments. 2001.
59. APTA TCIP Standard.No. September, 2010, .
60. APTA TCIP: Documents. Am. Public Transit Assoc., 2013, Available at:
http://www.aptatcip.com/Documents.htm [Accessed November 7, 2013].
103
61. Transit Communications Interface Profiles (TCIP) Standard Development Program.
Am. Public Transit Assoc., 2013, .
62. Lehr, W. Standardization: Understanding the process. JASIS, No. September, 1992,
pp. 1–16. Available at:
http://msl1.mit.edu/classes/5cmi2/2005/lect_03/__Standardisation__Understanding
_the_Process____Lehr__W.__1992_.pdf [Accessed August 2, 2013].
63. APTA TCIP version 3.0.5.2. Am. Public Transit Assoc., 2012, .
64. Membership Overview. ANSI, 2013, Available at:
http://www.ansi.org/membership/overview/overview.aspx [Accessed November 7,
2013].
65. Ayers, R. G., J. E. Ayers, T. W. Schirmer, and A. E. Systems. Transit Communications
Interface Profiles ( TCIP ) Traveler Information Pilot.No. September, 2011, .
66. OneBusAway-NYC Wiki: Interface Design. GitHub, 2013, .
67. Schweiger, C. TCRP Synthesis 104 Use of Electronic Passenger Information Signage
in Transit. 2013, .
68. Teil-titel, E. E. H. T. Public transport — Service interface for real-time information
relating to public transport operations — Part 1 : Context and framework
Contents.Vol. 1, 2013, pp. 1–93.
104
69. SIRI (Service Interface for Real-time Information) Management Overview - White
Paper. 2005. Available at:
http://www.kizoom.com/standards/siri/schema/1.0/doc/Siri White paper08.zip.
70. Knowles, N. SIRI Handbook & Functional Service Diagrams: Version 0.13 Draft.
London, 2008. Available at:
http://www.kizoom.com/standards/siri/schema/1.3/doc/Handbook/Handbookv15.p
df.
71. SIRI Schema and Documentation Downloads. SIRI, 2013, .
72. SIRI History. SIRI, 2013, .
73. Technical Specifications. Eur. Comm. Stand., 2013, .
74. European Standards. Eur. Comm. Stand., 2013, .
75. Introduction to SIRI. New York City MTA, 2013, .
76. Grisby, D. APTA Surveys Transit Agencies on Providing Information and Real‐Time
Arrivals to Customers. Am. Public Transit Assoc., No. September, 2013, pp. 1–13.
Available at:
http://www.apta.com/resources/reportsandpublications/Documents/APTA-Real-
Time-Data-Survey.pdf [Accessed November 7, 2013].
77. MAP-21 - Moving Ahead for Progress in the 21st Century: Summary. Fed. Highw.
Adm., 2012, Available at: http://www.fhwa.dot.gov/map21/summaryinfo.cfm.
105
78. Libicki, M. C., J. Schneider, D. R. Frelinger, and A. Slomovic. Scaffolding the New
Web. 2000, Available at:
http://www.rand.org/pubs/monograph_reports/MR1215.html [Accessed August 13,
2013].
79. Wong, J. Leveraging the General Transit Feed Specification (GTFS) for Efficient
Transit Analysis. Transp. Res. Board 92nd Annu. Meet., 2013, pp. 10013. Available
at: http://trid.trb.org/view.aspx?id=1240798 [Accessed September 4, 2013].
80. Changes to GTFS. Google Dev., 2013, Available at:
https://developers.google.com/transit/gtfs/changes [Accessed November 7, 2013].
81. Changes to GTFS-realtime. Google Dev., 2013, Available at:
https://developers.google.com/transit/gtfs-realtime/changes [Accessed November
7, 2013].
82. Wong, J. Leveraging the General Transit Feed Specification for Efficient Transit
Analysis. Transp. Res. Rec. J. Transp. Res. Board, No. 2338, 2013, Available at:
http://trid.trb.org/view/1240798 [Accessed November 8, 2013].
83. TCIP Technical Working Group 2: Passenger Information. Am. Public Transit Assoc.,
2005, .
106