AB 1599: Seamless Interagency Stop Data - the California Transit Stop Registry
On June 23, the California Senate Transportation Committee is expected to hear and vote on a good bill to standardize bus stop data, making transit more convenient for riders and enabling smarter planning. AB1599 (Ahrens), sponsored by Seamless Bay Area allies Move LA, AARP, and StreetsforAll, would implement one of the recommendations of the State Transit Transformation Task Force to make transit more seamless across the state.
Transit agencies in California all produce transit data feeds (GTFS feeds). These feeds are used by navigation apps like Google Maps, Apple Maps, and the Transit app, and Caltrans sets statewide quality requirements to ensure data isn’t just available, but accurate and trustworthy.
A single bus stop can be served by many different agencies: riders changing buses in Napa County might be told by their trip planning app that they have to get off a bus at Calistoga Lincoln Bridge North and walk to Lincoln Ave. Bridge, even though those are actually the same stop and share the same bus shelter. Apps have no way of being sure that these stops, with different names and different GTFS stop IDs, are actually the same place.
What shows up as two different stops with different names and locations…
…is actually one stop with a shelter and signage.
On Mission St and 7th in San Francisco, buses from Muni, Golden Gate Transit, and SamTrans share a single pole. Despite this, all three agencies assign the stop a separate GTFS stop ID. Across the street for buses going the other way, SamTrans and Muni have separate stopping points, and Golden Gate Transit doesn’t stop at all. With five separate stop IDs describing stops in three different locations all sharing the same name, it’s difficult for software to reliably determine whether two agencies are serving the same stop. Apps and planners can only estimate which stops are likely equivalent based on names and location.
San Francisco’s Mission St & 7th has five stop IDs for three stopping locations.
How does AB 1599 address this?
Under AB 1599, transit stops would receive a unique stop ID, authoritative name, and authoritative location in the California Transit Stop Registry. If there’s a single bus stop on the ground, there will only be one digital bus stop in official datasets, GTFS feeds, and in transit apps.
Agencies can continue to call the same stop different names – an intercity bus agency might primarily call the stop by its city name, while a local agency might refer to it by its intersection. However, by making sure this stop has a single underlying stop ID and exact location, apps understand that it’s the same stop, and can correctly tell users to wait in the same place.
Datasets that riders rarely see directly, such as stop-level ridership data, transit amenity inventories, and other agency open data, will also be required to use the Transit Stop Registry's unique stop IDs, making it much easier to combine and analyze information that is currently fragmented. This can support route planning, service adjustments, accessibility improvements, and equity analysis.
Why not just encourage coordination?
California has over 200 transit agencies publishing separate GTFS feeds. A central registry of stop IDs both gives agencies a common source of truth and provides a reason to prioritize coordinating. Since the launch of the California Integrated Travel Project in 2019, the State has relied on a combination of guidance / assistance and requirements imposed on transit agencies to bring GTFS feeds, realtime service data, and modern fare payment infrastructure to agencies around California. By including coordinated stop IDs in the requirements for GTFS feeds, Caltrans can continue to improve the transit riding experience across the state.
What does AB 1599 leave unsolved?
Transit centers are a common place for multiple agencies from different jurisdictions to stop at the same location. However, buses from different agencies usually stop at different bus bays or platforms inside a transit center. The GTFS specification that defines how transit data feeds work includes a way to provide details on stops within a transit center: a “parent station” defines the transit center as a whole, while “children” stops represent each bus bay or platform inside the transit center.
Gilroy Transit Center is served by Caltrain, VTA, and routes to Monterey and San Benito counties. The Bay Area’s regional feed has a “parent station” for Gilroy Transit Center, and Caltrain and VTA’s stops are children of that station. Because GTFS feeds only define stops belonging to their own agency, Monterey-Salinas Transit and San Benito County Express cannot designate their stops as children of Gilroy Transit Center's parent station.
Several international examples of similar transit stop registries exist. Switzerland is in the process of migrating to a system called SID4PT, the Swiss Identification for Public Transport. SID4PT contains a version of a Transit Stop Registry, the Swiss Location Identification (SLOID). In SLOID, a StopPoint – a bus bay, a train platform, a ferry pier – defines the place at which a passenger actually boards. Like GTFS parent stations, associated stops – at a Transit Center, a train station, or simply just two stops on the street next to each other – are then grouped together into a StopPlace. Unlike GTFS, this hierarchy is maintained in the national registry and can span multiple operators.
Importantly, the national registry contains this hierarchical information, regardless of whether it is published in transit agency GTFS feeds. Because the hierarchy is maintained in the national registry, applications can understand how stops relate to one another even when those relationships are not present in individual operator feeds.
In addition to the current proposed name, location, amenities, and unique Stop ID, it is important that the Transit Stop Registry also include this authoritative information about transit center stop hierarchy.
What other information is useful in a transit registry?
In addition to stop information in SLOID, the Swiss system also records other information about transit systems:
SBOID - a registry of transit operators (ex: BART)
SLNID - a registry of transit routes (ex: BART Orange Line)
SJYID - a registry of transit vehicle trips (ex: the 9:03am BART Orange Line)
By giving each specific operator, line, and trip unique IDs, ambiguity is eliminated during data processing.
The Metropolitan Transportation Commission already does much of this work today. Through 511 SF Bay, they offer a “unified” Regional GTFS feed combining data from across 39 operators. Much of the work involved in building the “unified” feed would be obviated by a California Transit Stops Registry and a system designed to ensure names don’t overlap. Today, when assembling the Regional GTFS feed:
Stop IDs are modified to be unique where needed
Transit Centers are manually assembled where needed
Operators are assigned a standard prefix (ex: “AC” for AC Transit, “SF” for Muni)
Route_ids, trip_ids, and other data are modified to include that prefix (ex: “AC:7” for AC Transit Line 7, “SF:7” for Muni’s 7 Haight/Noriega)
Similar work across all transit agencies in the Regional GTFS feed
This results in two competing “authoritative” datasets with incompatible ID schemes: operator-provided GTFS feeds and MTC’s regional feed. When applications combine realtime data from one source and static data from another, identifiers no longer align.
Making route_ids, trip_ids, and related identifiers unique across agencies statewide would significantly simplify interagency trip analysis, data processing, and planning. Since the proposed changes already require agencies to modify their existing data pipelines, this is an opportunity to address this issue as well.
Given California’s decentralized transit governance, it is unreasonable to directly adopt the Swiss model. However, an Operator Registry with standardized prefixes should be established and required for use in GTFS and other open data, ensuring that agencies apply consistent prefixes to route_ids, trip_ids, and related identifiers in the same way that Transit Stop Registry stop_ids are mandated for stops. This would allow agencies to retain local control while enabling consistent interoperability across systems statewide.