Tag Archives: GTFS

Handling GTFS Blocks Part 1: Introduction

Posted on by

Transit agencies will almost always use each bus/train/tram continuously for an entire service day (or for some portion of it). Because a single trip on a single route may only take 30 minutes or an hour, each vehicle will perform potentially many trips in one day.

In some cases, the vehicle will just go back and forth on the same route. In other cases, once it reaches a certain point it will change its number. Sometimes passengers won’t know the route has changed; other times they will need to disembark and the vehicle may wait 20 or 30 minutes before starting its next trip.

In any case, transit agencies can represent the subsequent trips a single vehicle takes using the block_id field in GTFS. For instance, let’s look at the following screenshots from TransitTimes Adelaide.

This screenshot represents a single vehicle servicing two trips, each of a separate route. The first route (171) finishes at the shown stop, where its headsign number becomes 174.

It’s important as a developer to make use of this information if it is available, since patrons may be confused if your trip planner tells them to change buses if they don’t need to. Unfortunately, not all transit agencies provide this information (such as Transperth), but when the information is available to use we make use of it in TransitTimes!

While this is only an introduction to GTFS blocks, we’ll be posting various articles about good ways to make use of this field based on our experiences with TransitTimes. This will includes strategies for validating blocks, and how to optimize the data for quicker search.

Feed Challenges: Adelaide Metro

Posted on by

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.