Transitland Open Transit Feed Registry

One registry, four specifications, thousands of feeds. Transitland, operated by Interline Technologies, aggregates public transit data published as GTFS Static, GTFS Realtime, GBFS (bikeshare) and MDS (micromobility) into a single indexed catalogue in which every feed carries a permanent Onestop ID. Rail sits inside it rather than beside it: Amtrak and commuter rail operators are indexed alongside metro, bus, bikeshare and scooter services, browseable country by country.

Rows from the August 2026 research pass, shaped exactly as they land before normalization:

# feed record -- one row per registered feed
onestop_id   : f-9q9-bart              # format f-<geohash>-<name>
spec         : GTFS                    # GTFS | GTFS_RT | GBFS | MDS
name         : <operator or feed name>
languages    : en                      # BCP 47 tag
tags         : <atlas metadata key/values>

# the same record's real-time sibling
onestop_id   : f-9q9-bart
spec         : GTFS_RT                 # declared per feed, never assumed

# feed version -- one row per archived snapshot of a changed file
onestop_id        : f-9q9-caltrain
sha1              : <content hash>
fetched_at        : <fetch timestamp>
file_size         : <bytes>
service_window    : <earliest service date> .. <latest service date>
stats             : route_count, stop_count, trip_count

# operators join the picture
operator     : <agency name>           # related feeds grouped under one operator record

Three things fall straight out of those lines. First, identity that travels: an Onestop ID such as f-9q9-bart encodes geohash and name into one string, so feed, operator and stop records join across systems without fuzzy name matching. Second, history by construction - the Feed Archive stores every changed file as its own version, keyed by a SHA-1 content hash, so a schedule revision becomes a dated event you can diff instead of a silent overwrite. Third, shape before commitment - each version carries its service window (earliest and latest service dates) plus route, stop and trip counts, which is enough to size an operator's data before anything ships to you.

Ten load-bearing constructs appear on every feed record and form the verified dictionary below. The deeper dictionaries - route, trip, stop and departure-level attributes spread across the registry's twenty documented resource types, from agencies through operators to individual departures - ship under additional fields on request, confirmed with you before delivery rather than promised blind.

• Geography: worldwide, with country-level browse pages (United States, Canada, France and beyond). Rail-relevant operators ride in the same index as metro, bus, bikeshare and micromobility services, so a corridor question and a modal-market question resolve against one identifier scheme.
• Temporal: a live index of current feeds plus a versioned archive reaching back to each feed's registration - successive snapshots retained and deduplicated by content hash rather than overwritten.
• Granularity: feed-level records resolving downward to agency, route and stop entities, and to real-time departures per stop where the underlying specification carries them.

Set against Datadory's catalog of 1,744 datasets across 159 industries, this record scores 8/10 for quality on our verification pass - verified field definitions, a documented identifier scheme, and an archive design that keeps history instead of replacing it.

API, files, or your warehouse. Daily, weekly, or hourly.

You pick the channel and the cadence; the dictionary above travels unchanged through all three. Analysts building a service-supply panel tend toward a warehouse load joined to their own geography tables; consultancies benchmarking a client operator take file extracts cut to named agencies; product teams wiring arrival predictions take a scoped feed of the operators they serve. Name the operators, countries and specifications when you request the sample - the sample ships first either way, and changing cadence afterward is a settings conversation, not a re-integration project.

• Service-supply and network analytics - GTFS packages enumerate routes, stops, trips and calendars, so analysts model scheduled capacity per corridor instead of inferring it from timetables photographed into spreadsheets.
• Real-time products - feeds declaring GTFS Realtime ride alongside their static siblings under the same Onestop ID, which is the pairing vehicle-position and prediction features actually need.
• Multimodal market mapping - GBFS bikeshare and MDS micromobility live in the same registry, letting one team measure how rail, bus, bike and scooter coverage overlap city by city.
• Longitudinal network research - the hash-keyed version archive turns "the agency changed its schedule" into a dated, diffable sequence of events.
• Coverage intelligence - because the registry indexes who publishes machine-readable data and who does not, it doubles as a maturity census of transit data publication, country by country.
• Journalism and academia - stable Onestop IDs make citations reproducible years after a story or paper ships.

Developers and builders gain the most immediately: one identifier scheme and one record shape across thousands of feeds removes exactly the per-agency bespoke parsing that stalls transit integrations. Data scientists and analysts get longitudinal panels - the version archive means backtesting against the network as it actually was, not as it currently claims to have been. Market researchers and consultants hold a coverage census: which operators, in which countries, publish static schedules versus real-time streams. Journalists and academics cite records by Onestop ID, an identifier built to outlive redesigns.

It is the breadth layer: thousands of feeds across four specifications under one identifier scheme. The Mobility Database Global GTFS & GTFS-Realtime Feed Catalog is its nearest cousin and we break the trade-offs down in the SNCF portal vs Transitland head-to-head, where a single national operator's depth meets a global registry's reach. Depth plays belong to narrower records - TfL Open Data for one agency's whole surface, the National Transit Database ridership sets for US boarding counts. Teams usually pair one deep record with this one: registry for reach, specialist for resolution.

Four honest notes from our verification pass.

The count is "thousands," not a number. Neither the registry nor our August 2026 research pass surfaces an exact total of registered feeds. If a specific operator roster is your whole question, ask us for the list alongside the sample rather than planning around a figure nobody publishes.

It is not rail-only, and that is a feature. Bikeshare and micromobility ride in the same index as commuter rail. We filter to the operators and modes you name at delivery instead of handing over a firehose you paid to ignore.

Deep dictionaries ship under additional fields on request. The ten verified constructs above hold on every feed record; route-, trip-, stop- and departure-level layouts across the twenty documented resource types get confirmed with you before delivery rather than promised blind.

The declared spec wins. Every record states whether it publishes static, real-time, bikeshare or micromobility payloads, and the sample returns what each operator actually declares - not an assumption that a real-time stream exists everywhere.

Because "global transit feed coverage" is really four specifications, twenty resource types and thousands of independently maintained publisher quirks wearing one badge - and reconciling those is precisely the work nobody bills for. Datadory normalizes the registry to the shared dictionary above, keeps successive feed versions accumulating so schedule changes become observable history, and cuts samples to named operators, countries and specifications before any recurring delivery is configured. Browse the rest of the vertical on the rail transportation data hub or the best rail transportation datasets, then request the sample - it ships first either way.