Transit Information at Lyft
Our riders expect a reliable arrival estimate as well as a smooth drop-off experience. We’ve exclusively been a ridesharing service for several years, so we’re accustomed to being our own dispatch service. Now, with transit, we have to shift to understanding someone else’s operations and service. Unlike ridesharing, bikes, or scooters, we rely on transit agencies to supply us with information on when and where vehicles are.
GTFS: The Data That Gets You There
Most agencies publish their transit data in the General Transit Feed Specification (GTFS) and GTFS Real-Time formats. Agencies publish this data directly to Google Maps, and most also make it available for the public on their websites.
Research shows that transit users tend to overestimate how long they’ve been waiting for transit. We also see that the availability of real time information significantly reduces this perceived wait time. This makes the widespread adoption of the transit data standards, including GTFS in the U.S., an enormous accomplishment.
Agencies and app developers alike use GTFS to build trip planning tools. Its widespread adoption has also allowed cartographers, data scientists, and others do all kinds of fascinating things with GTFS data.
GTFS is so popular that it inspired a similar standard for bikeshare: the General Bike Feed Specification (GBFS). We’re excited to be working with the North American Bike Share Association to support this standard, as we continue to think about how standards can best serve riders.
How We Use GTFS
We use GTFS to show nearby departures and suggest transit itineraries within the Lyft app.
Lyft is using public feeds for most of our transit data needs. We made an exception for New York City, where we’ve chosen to rely on Moovit, a transit data provider instead. NYC’s data is more complex, and we appreciate Moovit’s help in ramping us up quickly and reliably in this important market.
Making Transit Data Better
Lyft has an in-house transit data curation team dedicated to reviewing the transit data we ingest from agencies. Our goal is to show riders the information they need to make their journey with confidence. Every day we spot and correct issues like:
- A route name abbreviated to something that one of our visually-impaired users couldn’t understand through a screen reader.
- A bus stop on the wrong side of the street or in the middle of an intersection.
- A bus incorrectly displaying the same headsign for both directions.
Headsigns are particularly tricky, and our own CEO, Logan Green, reported one of these bugs while testing data in Oakland. He noticed that the 51B, which goes between Rockridge BART and the Berkeley Marina, was describing trips in both directions as being “towards Rockridge BART.” We figured out that the agency was incorrectly labeling these Marina-bound headsigns, so we informed AC Transit’s support team, who corrected the issue in their next data release.
We correct the issues that we find for our own data pipeline, but we also report issues to agencies. We were the first to alert one agency that their real time feed wasn’t accounting for the switch to daylight savings time. And we were quick to report to another agency that their replacement shuttles weren’t yet included in their static feed.
We appreciate the opportunities we’ve had so far to understand transit agencies’ intentions and challenges with GTFS. We look forward with working with more agencies as we continue expanding the transit offerings in our app.
