By Daniel Pulido and Diego Canales
What Is an RTPI?
Traditionally, the information sent to the public by an RTPI system has been generated by a computer-aided dispatch/automatic vehicle location (CAD/AVL) system. CAD/AVL itself is mainly intended for operators to manage vehicle trips and comes with hardware for producing vehicle location data.
In that configuration, an RTPI system makes arrival and departure predictions based on the data obtained from the CAD/AVL system. Those data include vehicle location as well as historical and schedule adherence information. The other components of the integrated system are the interfaces that present the RTPI to the public, either directly through smartphone apps, websites, and variable messages signs; or indirectly through an API (data feed) aimed at developers, who can then develop smartphone apps at no cost to the transit agency.
In the conventional setup, transit agencies buy the RTPI system from a CAD/AVL vendor in a bundle that includes all on-board and central hardware, network, software systems, and licenses. The product typically requires some in-house agency expertise and staff positions for IT maintenance.
Impacts of RTPI on Passengers
In terms of passenger effects, preliminary survey results indicate that providing access to real-time arrival information on transport systems decreases the perceived and actual wait times for riders and improves satisfaction.
Recent research suggests that real-time transit tools might also bring in new passengers. A 2012 study of the Chicago Transit Authority bus routes on which RTPI had been added found that the average daily ridership on those routes increased by 2%. Similarly, a 2015 study for New York City’s bus system also found that after three years, the increase in ridership attributable to the RTPI system totaled 2%, which translated into more than $5 million per year in additional fare revenue.
Innovations in RTPI Systems
Innovations by developers and other technologists have been creating better and cheaper ways to produce RTPI vehicle location data by using off-the-shelf GPS hardware or smartphones and tablets.
A key development on the software side has been the open source protocol. OneBusAway, for example, is an open source product that can disseminate AVL data to users through the web, public displays, smartphone apps, SMS service, and interactive voice-response.
Other startups, including Via Analytics and Transi-Time, have created stand-alone RTPI systems. Via Analytics has a prediction module that collects GPS data from tablets and uses an “anti-bunching” algorithm that better regulates the frequency of bus service. These systems are hosted in the cloud, eliminating the need to invest in servers and dedicated staff, and sold through a software-as-a-service (SAAS) business model.
Procuring It Right
The practice of buying AVL and RTPI systems together is gradually changing as transit agencies have started to see the potential benefit of acquiring the new RTPI technologies separately. However, AVL systems generally lack the interoperability and open protocols necessary to make separate procurement work.
This lack of interoperability and open protocols has blocked many transit agencies in the United States and Latin America from adding separately acquired RTPI software to their AVL systems. AVL hardware providers often impose proprietary constraints on the data produced by their systems. They allow access to the processed data only through the interfaces the vendor provides, thus restricting the use of others’ software and constraining sharing and re-use of the data. Under those circumstances, the data owned by the transit agency eventually decreases in value.
Thus, transit agencies should open their procurement processes to allow the entrance of new participants and technologies. However, doing so may not be enough to ensure full competition across technologies, and other measures should be considered.
For example, a transit agency cannot take full advantage of the latest technology that manipulates and disseminates RTPI data unless it has complete access to the databases managing the information. That means asking the AVL vendor to provide as many open-source components as possible (such as the PostgreSQL database system) or at least requiring an open architecture (meaning that the software is independent of the hardware).
The ideal when procuring new AVL systems is to require (1) open and fully documented architecture and interfaces, thus allowing interoperability; (2) open and standard data protocols as well as standardized and documented data feeds (APIs) from which to extract data; (3) permission to query and extract data from the database; and (4) authorization to reuse that data for other products.
For more information on this topic: