Jarvus Innovations

At conferences over the past few years, I have been excited to hear GTFS referenced across dozens of presentations, posters, and meetings. GTFS is ever-further entrenched in the collective consciousness and its usefulness is widely appreciated. As a fan and user of GTFS, I am glad to see its role as a transit data success story cemented.

However, there is one context where I am concerned that GTFS is perhaps too firmly entrenched: As other transit data standards like TIDES and TODS see increasing adoption, I have seen a tendency to over-index on certain specifics of GTFS and put other standards in a GTFS-shaped box.

If we don’t want new standards to become victims of GTFS’s success, we can’t overfit on the GTFS trajectory. We need to reflect carefully and learn the right lessons from GTFS.

What is GTFS?

GTFS is a data standard for sharing schedule and realtime data with riders. On the most basic level, GTFS refers simply to the set of rules that describe that standard: the file and field definitions that outline the data format. This is probably what most people mean when they talk about GTFS.

However, there are several additional characteristics of GTFS that people may implicitly have in mind in data standards conversations. Awareness of these aspects varies, but it includes elements like:

• The documentation of the specification
• The tooling related to and supported by the specification
• The governance of the specification
• The community associated with the specification
• The history of the specification

The beauty of a mature data standard is that it has just this sort of ecosystem around it; it’s not just a list of files and fields lying inert on a page, it’s a constellation of people and processes.

It is exactly this maturity and this constellation that presents risk, though, when trying to generalize from GTFS to other data standards. We need to truly understand about how this ecosystem came into being if we want to replicate it, and we need to distinguish between details specific to GTFS and generalizable goals.

This means we need to look one level of abstraction beyond “what GTFS did”. For example: GTFS schedule is composed of (pseudo-)CSV text files compressed into a zipfile. This clearly does not mean that all successful future transit data standards need to adopt this file and delivery format. Instead, the lesson should be that a data standard’s file or storage format should be selected based on a combination of user and technical requirements that is appropriate for the intended use cases.

Below are two additional examples of the type of abstraction we need to perform.

The rider experience and precision of purpose

The foremost purpose of GTFS is to share rider-facing information so that people can plan and take trips on public transit. This purpose helped drive adoption of GTFS because the link between trip planning, rider experience, and ridership is intuitive: if an agency wants people to ride their services, the potential riders need to be able to plan their trips, especially as online routing and realtime traffic tools for driving have become ubiquitous. Increasing ridership is a clear value proposition for GTFS.

The risk for future standards is that they are held to the same standard regarding direct impact on rider experience. Precisely because the niche of rider-facing information is already filled by GTFS, the link between other data standards and the rider experience (and, thus, ridership) will necessarily be less direct.

Other standards need to fill other purposes within agencies and the industry at large. The ultimate purpose of any standard might be rider experience, in the sense that the ultimate purpose of a transit agency (and thus all its activities) is to provide a rider a positive travel experience. But standards like TIDES and TODS are concerned with operational information that is not directly rider-facing, and their adoption will not affect riders as immediately as GTFS does.

We in the transit data community need to make business cases for other standards that are precise to their specific purposes. We can and should link standards to rider experience where appropriate, but we also need to be transparent when that relationship is indirect and avoid over-promising on second-order effects. We should not claim that other standards will deliver on ridership or rider experience exactly how GTFS does, because that sets new standards up to fail and undermines the rider-facing focus that has helped make GTFS successful.

The lesson from GTFS is not that standards must be directly rider-facing to have an important use or worthwhile impact. Instead, the lesson is that standards need to fulfill a clear and useful purpose for agencies and the broader transit industry, whatever that purpose is. Proponents should be prepared to speak to exactly what a standard can do and how it will help solve problems the industry cares about, even if those problems are not as immediately intuitive or high-profile as rider-facing trip planning.

The elephant in the room: Google and theories of adoption

The “G” in GTFS used to stand for Google. It is undeniable that the rise of GTFS was inextricably linked with its use in Google Maps. To this day, Google plays a vital role in contributing to and supporting GTFS.

However, Google is not the be-all end-all of GTFS. GTFS is used by a host of transit technology vendors, consultants, agency staff, researchers, developers, and planners because it serves useful purposes for all of them. Alignment and cooperation between diverse parties (including Google) has reinforced the value of the standard and led to positive outcomes for the industry.

The risk here is concluding that a data standard requires ownership by or explicit alignment with a single powerful actor or product to be successful. Instead, we should focus on how we can achieve a compelling alignment of incentives between different actors to drive the outcomes that we want. One legacy of GTFS is that it has helped coalesce and formalize a transit data community; now we can leverage that community to identify and build future standards, and find new ways to resource the development and stewardship of those standards.

Focus on the meta-attributes

The above examples are based on specific issues I’ve heard in conversations about emerging standards, but I assume that this dynamic will repeat as standards like TIDES and TODS get more and more attention in their respective areas.

As these conversations continue, we must try to focus on meta-attributes: what was it about the GTFS approach that made it successful? How can we replicate successful mechanics in new contexts? The Mobility Data Interoperability Principles offer one set of abstractions and broader principles along these lines.

Hopefully, as additional standards mature, we will begin to have a larger canon of success stories, enabling a more comparative approach. Until then, we must do our best to be thoughtful about the GTFS example and what to take from it.