1 of 25

(static) GTFS 101

lunch & learn 1/11/22

by laurie

2 of 25

agenda

who

what

where

when

how

why

of static/schedule GTFS

3 of 25

(some caveats)

4 of 25

General�

Transit

​

Feed

​

Specification

5 of 25

why

static GTFS enables transit agencies to publish information about their network, schedule, and operations in a standard, structured format that can be consumed by software applications

GTFS

6 of 25

who

GTFS originally created by: Google with TriMet (Portland)

now…

agencies & vendors/contractors produce data

aggregators collect data (Transitfeeds, Transitland)

developers/apps consume feeds (Google Maps, Transit App, agency-specific) and build related tooling (Remix, Moovit, etc.; validators)

transit riders access information via apps & websites

stakeholders (ex. Google, MobilityData) maintain, update, and expand the spec (static change guidelines, General Bikeshare Feed Specification, GTFS-ride, etc.)

(we all work on Cal-ITP!)

7 of 25

what - file structure - demo

8 of 25

what - schema*

source: Remix Partridge

= required

= conditionally required

*this diagram does not include fares v2

9 of 25

what - spec

gtfs.org/reference/static

10 of 25

what - meaning

a description of the agency’s (fixed route) transit network and services:

  • what routes are there
  • where do they stop
  • how often do they run
  • where can you transfer between routes
  • what are the fares to ride
  • etc.

credit: Drew Dara-Abrams (@drewdaraabrams)

11 of 25

where / when

agencies host GTFS feeds on their websites (ideally/per CA Minimum Guidelines: at a stable URL that does not change)

feeds should be posted whenever there are significant/persistent service changes; “the GTFS dataset should cover at least the next 30 days of service” (x)

​

aggregators that pull feeds across many agencies (Transitfeeds, Transitland); they may pull updates at different cadences

​

in our data: calitp_url_number; calitp_extracted_at / calitp_deleted_at

12 of 25

where

Transitfeeds - SacRT

^ SacRT GTFS page

< SacRT GTFS clickthrough

13 of 25

how

produced by agencies or by contractors/vendors on behalf of agencies�

some are made “by hand” (Excel), others using dedicated software (Trillium GTFS Manager, AddTransit, etc.)

14 of 25

GTFS contains multitudes

gtfs is very flexible

  • can capture huge variety of services
  • multiple valid ways to specify the same idea
  • lots of optional information
  • ambiguous concepts: “route”, “agency”

15 of 25

GTFS challenges

  • variance in resourcing / quality
    • incentives for agencies�
  • not always intuitive
    • times wrap past midnight (24:30)
    • calendar / calendar_dates lack referential integrity
    • etc.�
  • intended scope is actually pretty limited
    • time-specific

16 of 25

example - Replica

https://replicahq.com/what-we-do/

17 of 25

Cal-ITP

  • aggregation �
  • analysis

Metabase views

18 of 25

Cal-ITP - aggregation & dims

Metabase views

19 of 25

Cal-ITP - aggregation / analysis

Metabase views

20 of 25

resources

  • spec documentation: gtfs.org (both realtime and static)�
  • MobilityData GTFS validator (static)�
  • Just a few packages & command-line tools:

21 of 25

questions?

22 of 25

appendix

23 of 25

what - file structure

static/schedule GTFS feeds (or “datasets”) are published as .zip files that contain a set of .txt files

24 of 25

what - example routes.txt & trips.txt files (SacRT)

^ routes.txt

trips.txt >

25 of 25

what - example stop_times.txt & stops.txt files (SacRT)

^ stop_times.txt

stops.txt >