frequencies.txt general concepts + pull-ins and pull-outs effect on file

Skip to first unread message


Apr 29, 2021, 3:28:03 PM4/29/21
to Transit Developers
The SFMTA is looking at implementing frequencies.txt for those routes which are operating on a headway-based rather than a schedule-based schedule. I'm finding the inclusion of trip_id, as opposed to route_id and day of service, as a required field to be confusing.

Suppose the following:

6am to 8am : off-peak
8am to 10am: on-peak
10am to 6pm: off-peak
6pm to 8pm: on-peak
8pm to 12am: off-peak

Suppose trips 121 through 129 fall within the 8am to 10am time frame and are headway-based. Am I understanding the spec correctly that we would need those trips to each have a record in frequencies.txt, for a total of 9 records, each with a value of 0 for exact_times, and that each of those 9 records would also contain the exact same value for start_time (8am), end_time (10am) and headway_secs (900)?

If that's not correct, then how would I populate the various fields?

Where we are running into complications is that there are occasional extra trips during this period which only cover the beginning or end of the route because the trip enters or leaves the route midway (also known as pull-ins and pull-outs, which are in service for trolley buses in our agency during the time they are on the route). These trips might only be 2 minutes apart from the frequency-based trips. They are potentially just as inexact, because they started out as or will be becoming frequency based trips. However, it would be confusing for us to display most of the time that the frequency is 15 minutes, then suddenly display that the frequency is 2 minutes for a couple minutes, then 13 minutes, then go back to 15 minutes. We want to show the frequency the whole time.

Do we leave these trips out of frequencies.txt? Do we include them and still (if my understanding of frequencies.txt is correct) use a value of 0 for exact_times, and the exact same value for start_time (8am), end_time (10am) and headway_secs (900)? This would essentially make these bonus service that doesn't show up in the frequency display (which makes sense; there's no particular reason for a customer to specifically wait for them). I just want to make sure that's the correct approach.


Apr 29, 2021, 3:29:48 PM4/29/21
to Transit Developers
*We want to show the same frequency (15 minutes) the whole time.

Michael Smith

Apr 29, 2021, 7:12:56 PM4/29/21
I really see frequency based configurations as not being adequate for large transit agencies. You describe some of the problems like pullins and pullouts. But a key issue is that the frequency based configuration precludes the real-time passenger information (RTPI) system from providing useful information in many situations. It makes it far too difficult for the RTPI to predict when buses are supposed to start their trips, meaning that predictions near the beginning of routes have to either be hidden from the public or simply considered to be quite inaccurate. And the frequency configuration doesn't allow the specification of when a bus is going to be taken out of service so it will wrongly continue to be predicted for. 

The kind of configuration I have seen work is using a schedule based config for the GTFS and then using service adjustments  for when adjustments are made to maintain headway. Specifically, would use service adjustments for adding trips, cancelling trips, or for changing the departure time for trips.


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
To view this discussion on the web visit
Reply all
Reply to author
0 new messages