Not all Real-time Passenger Information is created equal

There’s little question in the transit industry about the value of providing Real-time Passenger Information (RTPI) to passengers. RTPI has been found to increase ridership, reduce perception of wait time, and even make passengers feel safer. Today, the majority of transit agencies provide RTPI to passengers through apps, websites, displays, and other methods. This was not the case even a few years ago, and we, as an industry, should celebrate this tremendous milestone.

Today, we have a unique opportunity to bring passengers back to transit. Gas prices are at an all-time high, the economy is uncertain, and public transit has never been better positioned to entice passengers with the same technological advances that attracted them to Uber and Lyft. 

However, many transit technology vendors are still producing RTPI in proprietary feeds that only work with their apps and signs. These custom endpoints have limited scale and flexibility, which limits an agency's ability to truly keep passengers informed. The result is that the information is often inaccurate, does not yet take into account changes to service, and does not enable prediction information to be disseminated wherever passengers need it. We as an industry need to stop solving the same problems over and over again at every transit agency in the world, and start modularizing the technology so that transit agencies can focus on the things that make them unique, not what makes them similar to everyone else. 

Luckily for the industry, a data standard for RTPI has emerged that any passenger tool can be built on top of. This standard is called GTFS-realtime (GTFS-rt), it’s already used by thousands of transit agencies around the world to provide real-time predictions, vehicle locations, and service alerts in a standard, open format that can be used by any endpoint. GTFS-rt unlocks the ability for agencies to easily share RTPI with passengers wherever they want to consume it, leverage robust tools built for scale, and use the same data internally that their passengers see. For these reasons, every agency should be using GTFS-rt as their common data language. 

The benefits of GTFS-rt 

There are three key reasons why thousands of agencies are using GTFS-rt as the foundation for passenger information. 

1. GTFS-rt provides agencies with accurate, complete data to use everywhere. 

With GTFS-rt, transit agencies are able to buy or build GTFS-rt feeds and use it to power any passenger-facing tool. This means that passengers see the same data in signs at the bus stop, in the app of their choice, in a text, or anywhere else an agency wants to send it. This builds trust in information for passengers. It’s also easier for the agency, they can invest in one, accurate, rich set of data and use it for everything. As Cole McCarren, 

Real-Time Passenger Information Manager at MTA Maryland, describes, “Not only does the open data approach save agencies a whole lot of time because they don’t have to worry about keeping a dozen different databases up to date, but it gives the agency the advantages of a centralized approach to data and a decentralized approach to deployment.”

2. GTFS-rt enables agencies to use passenger information tools that have been made for the masses and validated at other agencies. 

With GTFS-rt, agencies can easily send RTPI to Google Maps, Transit, Apple Maps, and other apps which make getting information into the hands of passengers that much easier. Agencies and passengers benefit from tools that are built and tested for a wide audience. 

This is especially valuable at smaller agencies that might not have the funding or staffing to support their own apps. Daryl Weinberg, Transit Systems Architect at Capital Metro, describes, “I’m seeing a spread of GTFS-rt to small rural agencies that didn’t have it before. Everyone wants to get their data, get it out there, and share it. Small agencies don’t necessarily have their own trip planning app but hey there’s this thing called Google Maps and if you can give them the [GTFS-rt] data they will display it and now you’re informing your riders.” 

3. GTFS-rt enables agencies to use the same data internally that their passengers see. 

Another benefit of GTFS-rt is that technology vendors can build tools on top of this same, robust dataset that passengers use. Many agencies have different datasets for scheduling, operations, customer service, and passengers, which results in misalignment and miscommunication between departments and with passengers. By creating a common data language, based on GTFS-rt, agencies are able to have a single source of truth that feeds all internal departments as well as passenger-facing information.

With these benefits of GTFS-rt, agencies can set themselves up for success in today’s transit landscape. By using the same common data language to connect staff, passengers, and vehicles, agencies can provide a reliable service that builds trust with passengers. 

What does good GTFS-rt look like? 

GTFS-rt is an evolving standard that is gaining traction and guidelines across the industry. The California Department of Transportation (Caltrans) has adopted GTFS-rt guidelines for all California agencies. According to these guidelines, GTFS-rt should be complete and up-to-date. Complete means that there are valid real-time updates for all GTFS-rt fields - trip updates, vehicle positions, and service alerts. Up-to-date means that there is data and timestamps updated once every 20 seconds.

But GTFS-rt is only as good as the data that feeds it. Swiftly’s GTFS-rt Vehicle Positions fields are complete and accurate because Swiftly combines multiple vehicle position feeds, including from WiFi routers, in real time. This improves the resolution of vehicle tracking, the accuracy of real time passenger information, and increases overall system reliability. With multiple AVL feeds, Swiftly can support incoming AVL data as frequently as every 1 second, including updating timestamps and data for each trip and vehicle in service. In the event one of these data feeds goes down, the Swiftly platform will ensure that passengers and staff continue to get real time information by leveraging the additional AVL feeds. Swiftly publishes information for at least 99% of the vehicles in service at all times. 

Swiftly’s GTFS-rt Trip Updates fields are up to 50% more accurate than other vendors because Swiftly leverages large volumes of historical data paired with real-time observations and sophisticated self-learning algorithms to accurately predict future travel times. 

Swiftly is also able to provide a more accurate and complete trip updates feed by automatically providing assignment information and service adjustments. In cases where assignment data is missing, like if an operator fails to log in, the GTFS-rt will no longer update and apps will default to displaying the scheduled time. With automatic assignment, Swiftly is able to match an unassigned vehicle to a trip, resulting in updated vehicle locations and updated prediction times. Conversely, if a trip is canceled, Swiftly’s Service Adjustments is able to push out the cancellation to the GTFS-rt trip updates feed, so predictions are no longer showing for a stop for a bus that will never arrive. Without the trip cancellation, apps and other endpoints typically default to the schedule view resulting in passengers looking at a schedule time in an app for a bus that will never arrive – the notorious “ghost bus.”

Swiftly’s GTFS-rt Service Alerts are produced by tools operations teams already use so changes are easy to make. Communications teams have access to the same intuitive product so they can easily send alerts to passengers. 

GTFS-rt, and other data standards, could soon replace proprietary integrations

We believe in the future of data standards to give transit agencies technology that works well together to better serve their needs. GTFS-rt is one very important piece of the data standards future. It holds all of the critical information to power many onboard systems, like Headsigns and AVAS, that today rely on expensive, proprietary integrations. In fact, Swiftly recently launched a partnership with Way Sine to power AVAS with only a GTFS-rt feed. 

We’re currently building an integration with headsign vendors because headsigns can not yet be powered by GTFS-rt. We want to change that, and we’re not alone. Weinberg describes, “What we want to see moving forward and what we’re starting to do in our RFP packages is to require adhering to standards such as GTFS and GTFS-rt. So that everyone can be using the same source data in the same way. The only way we’re going to change that with our vendors in this industry is if the agencies require it. Require it in your RFPs and they will make the changes.” 

There has never been a better time than now to bring a reliable experience to passengers. Join thousands of transit agencies that are already unlocking industry-leading plug-and-play tools built on GTFS-rt. Interested in learning what your agency can do with GTFS-rt? Reach out.