We are investing a significant amount of time towards better understanding how Streamdata.io can be put to use in the transit industry, and part of this work involves documenting the existing standards in use across the sector. When it comes to the standards for sharing data between transit providers, and the software developers building on top of their data, the General Data Transit Feed (GTFS) is the dominant standard. It is known as GTFS static, or static transit, setting itself apart from the GTFS real time specification, which we’ll talk about in a future post.
The GTFS standard defines a common format for public transportation schedules and associated geographic information, providing a common way for public transit agencies publish their transit data and developers write applications that consume that data in an interoperable way. GTFS is simply a ZIP file of CSV files, providing a static snapshot of any single transit agency. Each zipped up file can contain up to thirteen individual files:
– agency.txt – One or more transit agencies that provide the data in this feed.
– stops.txt – Individual locations where vehicles pick up or drop off passengers.
– routes.txt – Transit routes. A route is a group of trips that are displayed to riders as a single service.
– trips.txt – Trips for each route. A trip is a sequence of two or more stops that occurs at specific time.
– stop_times.txt – Times that a vehicle arrives at and departs from individual stops for each trip.
– calendar.txt – Dates for service IDs using a weekly schedule. Specify when service starts and ends, as well as days of the week where service is available.
– calendar_dates.txt – Exceptions for the service IDs defined in the calendar.txt file. If – calendar.txt includes ALL dates of service, this file may be specified instead of calendar.txt.
– fare_attributes.txt – Fare information for a transit organization’s routes.
– fare_rules.txt – Rules for applying fare information for a transit organization’s routes.
– shapes.txt – Rules for drawing lines on a map to represent a transit organization’s routes.
– frequencies.txt – Headway (time between trips) for routes with variable frequency of service.
– transfers.txt – Rules for making connections at transfer points between routes.
– feed_info.txt – Additional information about the feed itself, including publisher, version, and expiration information.
You can find more detail in the GTFS reference over at Google, who is the steward of the data specification, and uses the feeds as part of their Google Maps, and other transit related solutions. If you are looking for a source of GTFS feeds, we recommend the Transit Feed API, which provides programmatic access to one of the more complete sources of transit feeds around the globe. Many leading transit providers publish a GTFS feed for their operations, with smaller group of them publishing GTFS real time feeds, which we’ll cover in a second post, talking about the separate streaming opportunities with these larger transit providers.
GTFS is a static feed, which means it doesn’t change very often, and just provides a static snapshot of transit operations. It doesn’t provide real time information on vehicles, just the schedules, and other relevant details. This makes proxying GTFS feeds with Streamdata.io not a very valuable thing, as things do not change much that much. You need that next layer of activity regarding what transit vehicles are doing, which is present only in GTFS real time feeds, and user activity which is only available at the application or client layer. Even with this reality, GTFS static feeds provide an excellent base for transit applications, and something we want to understand further, and help our users put to use in their own systems, and applications.
Follow us on social