Proposed change to SFMTA GTFS data file

Skip to first unread message


Jan 11, 2019, 8:04:24 PM1/11/19
to Transit Developers
The San Francisco Municipal Transit Agency posts our GTFS data at with terms of use at and as a text file within the GTFS zip.

Currently, the file stop_times.txt does not include the optional field timepoint.

We are proposing that the SFMTA Muni data be modified such that it will include the timepoint field. All stop_times.txt rows will contain a value for timepoint such that: 

1 means it is a timepoint (exact times)

0 means it is not a timepoint (estimated times).

We may implement this as early as February 2019.

Developers who consume this file are welcome to ignore the field, since it is optional, but obviously we don’t want anyone’s program failing.

Are there any developer concerns about this?

Hope this helps.

Charles “Chas” Belov

Uses pronouns: he, him, his, himself


Communications and Marketing

Michael Smith

Jan 14, 2019, 12:11:06 AM1/14/19

Thank you for reaching out to the transit data/GTFS community. Always useful to have a dialog on such issues.

Adding timepoint information can be very helpful. But there is currently an issue with the timepoint definition in GTFS. It can mean two very different things to transit agencies and to users. There can be 1) "operational timepoints"; and 2) what we sometimes call "schedule adherence timepoints". They are very different from each other. An "operational timepoint" is where a driver is to not depart a particular stop until the scheduled departure time. This is the type of timepoint that Google refers to in their documentation on the timepoint column for the stop_times.txt file:

Scheduled stops where the vehicle strictly adheres to the specified arrival and departure times are timepoints. For example, if a transit vehicle arrives at a stop before the scheduled departure time, it will hold until the departure time.   

If a stop is configured to be a timepoint then real-time information systems are to take this into account when generating downstream predictions. It also affects trip plans. 

A "schedule adherence timepoints" on the other hand indicates which stops are to be used for schedule adherence reports. Currently SFMTA does have specific stops that are considered to be "schedule adherence timepoints". But such stops are not supposed to affect the real-time information generated.

My experience with SFMTA is that the drivers do not adhere to "operational timepoints" even though I have been told years ago that they are supposed to. This is actually a very good thing from a passenger's point of view. It means that the transit vehicles operate as quickly as possible and don't pause in a frustrating way in the middle of the route to "catch up with the schedule". If you have ridden Trimet buses you have probably experienced these kinds of slow downs. Transit is slow enough as it is. We don't want to slow it down anymore with timepoints.

But if timepoints are defined in the GTFS, typical clients will treat them as "operational timepoints" and real-time information would be less accurate since that is not the way SFMTA drivers have been behaving. Vehicles would arrive at subsequent stops before the predicted time and passengers would miss their bus, a very poor user experience! 

At Swiftly we can configure an agency such that timepoints defined in the GTFS will not match the GTFS specification and instead be treated as "schedule adherence timepoints". Therefore we are fine with such a change. But other clients will certainly have trouble if stops are defined as "operational timepoints" in the GTFS yet the drivers do not actual behave accordingly.

Therefore I first recommend that the SFMTA clarify whether drivers actually wait at timepoints until the scheduled departure time. If they do not, then it would be best to define the stops in question in a non-GTFS standard way, such as "schedule_adherence_stop" or "otp_stop", instead of as a GTFS "timepoint".


You received this message because you are subscribed to the Google Groups "Transit Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to
For more options, visit
Reply all
Reply to author
0 new messages