Despite the GTFS specification defining how agencies should publish their transit data, every agency has different needs and structures, and therefore use and interpret the specification how it best suits them. Each post in this series discusses how a single agency structures their feed and highlights things to be aware of. It’s also worth noting that GTFS has changed over the years, and once an agency is setup using GTFS, they are typically reluctant to update their feed to reflect spec changes.

The feed from Adelaide Metro was the first that TransitTimes made use of, and therefore is treated is somewhat of a “baseline” feed.

This is also one of the most complete feeds we’ve encountered. That is, it’s required the least amount of massaging to get into a consistent format.

Trip Blocks

Initially, Adelaide Metro did not include block information in their feed, but they worked quickly to include this information. One of them problems with how they included this however, was that they re-used block IDs for unrelated blocks.

To overcome, we now check all trips in a block to ensure the “join” between each trip makes sense. That is, the final stop time of one trip and the first stop time of the next occur near each other (within a threshold of, say, X metres), and they must occur within Y minutes of each.

I’ll be posting on this blog in the future of further enhancements we’ve made to the block system to make searching much faster and simpler.

Time Points

Adelaide Metro include information about timed points in their stop_times.txt file, which is a really good addition, despite not being an official part of the specification.

When transit agencies release timetables, they don’t typically list every single stop in a trip, due to the sheer numbers. Instead, a selection of key stops are listed with times that drivers try to keep to.

This data is included in the feed using an extra column called timepoint. If the stop time represents a timed point on the timetable, the value is 1, otherwise the value is 0.

Note: TransitTimes does not currently make use of timed points but we hope to include this in an upcoming version

Overall Pros

• Adhere closely to GTFS specification
• Provide block and direction information
• Include time point information
• Provide accurate route colours
• Use calendar and calendar dates appropriately (many agencies provide excessive records and don’t use these files as intended)

Overall Cons

I can’t really fault this feed. The only thing I would like to see are a few stop naming inconsistencies and various spelling mistakes fixed.

Another addition that would be nice is to use the “parent station” functionality to differentiate between platforms at train stations so TransitTimes users know which platform to head to.