PROPOSAL: Frequencies.txt for loop routes

[Aaron Antrim]

GTFS-changes group:

I work for several systems that operate loop routes.  Usually, these
involve the same vehicle traveling the route to start and end at the
same location.

I do not believe it is possible to specify that reoccurring trips
defined with frequencies.txt belong to one vehicle block.  In order to
avoid publishing a feed where the GT trip planner would tell a rider
to transfer to the same route at the top of a looping schedule, I
re-create trip for each looped run of the day and assign the same
block_id to them.

This isn't hard to do with my software, but it seems inefficient.
Here's a proposal to add a column to frequencies.txt,
"block_headway_secs."  This describes the interval, in seconds,
between when the same vehicle will serve a given stop.

Here's an example usage:
trip_id,start_time,end_time,exact_times,headway_secs,block_headway_secs
WEEKDAY1,06:00:00,21:00:00,1,1800,3600
WEEKEND1,08:00:00,19:00:00,1,3600,3600

WEEKDAY1 shows a scenario where buses run every half-hour, but the
loop takes one hour to complete. The same vehicle comes by every
hour. Therefore, each frequency-based trip would be assigned to an
alternating block.

WEEKEND1 shows a scenario where buses run every hour, and the loop
takes one hour to complete. The same vehicle comes by every hour.
headway_secs and block_headway_secs are equal. Most frequency-based
loops would be like this (in fact, of the clients I have worked for,
all of them have been), but I figure it is good to leave the door open
for variation.

This is a first stab. Thoughts?

Aaron

On Thu, May 3, 2007 at 2:32 PM, Fred Fang wrote:
>
> Hi Aaron,
>
> We currently do not support the notion of blocks in the frequencies.txt file.
> We are investigating how best to support this. In the interim, if you require blocks,
> please create separate trips and link them using the block id.
>
> Please visit the feed specification often to see how we intend to support blocks
> in the frequencies.txt file.
>
>
> Thanks!
>
> Fred
>
>
> On 5/2/07, Aaron Antrim <aa...@arcatacommunity.org> wrote:
>>
>> Hi,
>>
>> I am working to represent transit agency data with "loop" routes -
>> hourly routes where the same vehicle travels in a circle, visiting the
>> same location at the same number of minutes past the hour, every hour.
>>
>> This means the trip reoccurs every hour, but not with a new vehicle.
>>
>> Now with frequencies.txt it's possible to specify trip_id, start_time,
>> end_time, and headway_secs for reoccurring trips.
>>
>> There's also the block_id field in trips.txt: "Optional. The block_id
>> field identifies the block to which the trip belongs. A block consists
>> of two or more sequential trips made using the same vehicle, where a
>> passenger can transfer from one trip to the next just by staying in
>> the vehicle. The block_id is dataset unique." (http://code.google.com/
>> transit/spec/transit_feed_specification.htm)
>>
>> I want to specify a trip frequency, but what I read in the Google
>> Transit Feed Spec seems to suggest Google Transit will assume that a
>> new vehicle is being used for each reoccurring trip.  I'm not sure I
>> see a way of using the block_id feature to help, hear, either, as
>> there are no other trips for this one "loop trip" to be associated
>> with in a block.
>>
>> The only solution I can think of is to create many successive trips,
>> each with the same set of stop times spaced 1 hour apart and link them
>> together with one block id, but I hope there is an easier way to do
>> this that I am overlooking that will involve less redundancy.
>>
>> Thanks,
>> Aaron Antrim

[Tom Brown]

On Tue, Mar 10, 2009 at 11:25, Aaron Antrim <aa...@arcatacommunity.org> wrote:

GTFS-changes group:

I work for several systems that operate loop routes.  Usually, these
involve the same vehicle traveling the route to start and end at the
same location.

I do not believe it is possible to specify that reoccurring trips
defined with frequencies.txt belong to one vehicle block.  In order to
avoid publishing a feed where the GT trip planner would tell a rider
to transfer to the same route at the top of a looping schedule, I
re-create trip for each looped run of the day and assign the same
block_id to them.

This isn't hard to do with my software, but it seems inefficient.

I haven't looked at your data files but suspect we are talking about saving ~100kB-1MB. While this might be a large percentage it isn't much in absolute terms.

Everything we add to the spec makes it a little more complex to understand and parse. I think this change adds quite a bit of complexity (see questions at bottom) and provides at least these benefits:
1) lower disk and network usage
2) being able to represent looping routes as continuous *and* at a fixed frequency

Without your proposed change a looping route can be continuous using blockid (leaving the parser to work out the frequency using heuristics) xor provide easy to use frequency information.

Google's trip planner treats trips defined in frequencies+trips+stop_times with exact_times=1 almost identically to those that are strictly trips+stop_times. Do other consumers of GTFS handle frequency defined trips in more radical ways?

Here's a proposal to add a column to frequencies.txt,
"block_headway_secs."  This describes the interval, in seconds,
between when the same vehicle will serve a given stop.

Here's an example usage:
trip_id,start_time,end_time,exact_times,headway_secs,block_headway_secs
WEEKDAY1,06:00:00,21:00:00,1,1800,3600
WEEKEND1,08:00:00,19:00:00,1,3600,3600

WEEKDAY1 shows a scenario where buses run every half-hour, but the
loop takes one hour to complete.  The same vehicle comes by every
hour.  Therefore, each frequency-based trip would be assigned to an
alternating block.

WEEKEND1 shows a scenario where buses run every hour, and the loop
takes one hour to complete.  The same vehicle comes by every hour.
headway_secs and block_headway_secs are equal.  Most frequency-based
loops would be like this (in fact, of the clients I have worked for,
all of them have been), but I figure it is good to leave the door open
for variation.

Does it make sense to use block_headway_secs when exact_times != 1?
Should we require that block_headway_secs is >= end_time - start_time? (start_time and end_time meaning the first and last times for the trip in stop_times)
Should we require that headway_secs > block_headway_secs?
What about transitions between frequencies.txt lines with the same trip_id and different headway_secs?

In general I think exact_times=1 is very convenient for manually created feeds but has yet be demonstrated as very valuable to data consumers. If there are people manually creating looping frequency defined routes then your proposal with the constraint headway_secs == block_headway_secs would be very handy.

[Aaron Antrim]

My goal with this proposal is to reduce/streamline data complexity and maintenance as a feed publisher, and to find a clearer way of describing loop routes.  It is more a statement of need rather than a concrete spec change proposal.

Without your proposed change a looping route can be continuous using blockid (leaving the parser to work out the frequency using heuristics) xor provide easy to use frequency information.

Google's trip planner treats trips defined in frequencies+trips+stop_times with exact_times=1 almost identically to those that are strictly trips+stop_times. Do other consumers of GTFS handle frequency defined trips in more radical ways?

In all of the cases I have encountered, block_headway_secs would equal headway_secs.  It sounds as GTFS may already allow for what I am after in these cases.  Currently, if I were to submit a feed right now where:
- TRIP1 ran on frequency FREQ1
- was assigned to BLOCK1
- the duration of the trip (last departure_time for TRIP1 - first departure_time for TRIP1) < headway_secs
- first stop_id of TRIP1 = last stop_id of TRIP1
then would all these reoccuring trips be considered part of the same block in Google Transit (and they would see in-seat transfers?)

The reason I suggested adding block_headway_secs, was that I saw it as a way of describing possible cases I assume are out there but don't have examples for.  The proposal is more theoretical than practical in that regard.

Everything we add to the spec makes it a little more complex to understand and parse. I think this change adds quite a bit of complexity (see questions at bottom) and provides at least these benefits:
1) lower disk and network usage
2) being able to represent looping routes as continuous *and* at a fixed frequency

That second benefit, I think, gets at something which I may be important.

Here's an example of an itinerary on a loop route route in Arcata, CA:
http://tinyurl.com/btrkz9

In the GTFS for this agency, there are about 15 trips/day that are all assigned to a single block.  The result is that the trip planner shows two bus segments. Segment 1: Red Route to transit center.  Segment 2: stay-on-board (continues as Red Route) to destination.  The in-seat transfer counter-intuitively involves the vehicle continuing as the same route.

I'm submitting data for an agency with about 10 loop routes this week.  It would be great to work out something, either soon or down the line, that describes loop routes accurately and without introducing extra complexity.

exact_times=1 has been handy for me.  It makes data easy to maintain.

Anyone else have specific needs for/comments on describing loop routes in GTFS?  Please share!

[Aaron Antrim]

I wanted to follow up on this earlier proposal (actually more of a discussion item now).

Can I go ahead and start publishing feeds where loop trips have specified frequencies, and where they are assigned to a vehicle block in cases where the trip length equals the headway?  Or has this already been possible?

Do any other feed publishers have a need to represent loop routes in a way which will avoid the "continues as [same route name]" in-seat transfer issue?

Shall I work to modify the original proposal to resolve some of the issues and questions Tom brought up?

[Joe Hughes]

On Fri, Mar 20, 2009 at 3:53 PM, Aaron Antrim <aa...@arcatacommunity.org> wrote:
> Can I go ahead and start publishing feeds where loop trips have specified
> frequencies, and where they are assigned to a vehicle block in cases where
> the trip length equals the headway?  Or has this already been possible?

If you're talking about attaching a block_id to a single trip in
trips.txt and using that trip_id in frequencies.txt, this would appear
to violate the description of block_id in the spec:
"The block_id must be referenced by two or more trips in trips.txt."

Do the trips in question have scheduled times, or are they truly
frequency-based?

> Do any other feed publishers have a need to represent loop routes in a way
> which will avoid the "continues as [same route name]" in-seat transfer
> issue?

Is this an issue that you're seeing that's specific to Google Maps?
Sounds like an implementation quirk/issue that they could improve,
rather than a limitation of the spec semantics.

> Shall I work to modify the original proposal to resolve some of the issues
> and questions Tom brought up?

We should definitely try to find a solution for expressing this information.

Joe

[Aaron Antrim]

To recap, my purposes with this draft proposal are:
1. to represent loop routes in a way that could eliminate the awkward
"continues as [same route]" multi-leg presentation of loop routes
2. to make data publishing and maintenance easier

The first purpose (better display of loop routes in the trip planner)
is a much higher priority.

If the trip planner showed sections of two trips with the same
route_id and block_id as a continuous trip, then this display issue
would be solved.

For the sake of continuing discussion, responses to Tom's questions:

> Does it make sense to use block_headway_secs when exact_times != 1?

Yes, I think it would make sense to use block_headway_secs in cases
where exact_times is false. I have not encountered a schedule-less
loop route in my work, but I think it must exist somewhere.

For the sake of example, UC Berkeley Bear Transit is a service where a
frequency-based display (exact_times=0) could make sense because of
the short headways. The "P Line" (http://pt.berkeley.edu/print/175)
is a loop served by two buses. Headways are 12min. It takes 24min
for each bus to complete the loop.

> Should we require that block_headway_secs is >= end_time -
> start_time? (start_time and end_time meaning the first and last
> times for the trip in stop_times)

Yes.

> Should we require that headway_secs > block_headway_secs?

No, I think a requirement for headway_secs <= block_headway_secs would
make sense. (If vehicles are added to the same loop, this decreases
headway_secs, while block_headway_secs remains the same).

Or, headway_secs / block_headway_secs = # of vehicles or blocks

> What about transitions between frequencies.txt lines with the same
> trip_id and different headway_secs?

I think this could be handled with no changes to the current spec.
"The end_time field indicates the time at which service changes to a
different frequency (or ceases) at the first stop in the trip."
http://code.google.com/transit/spec/transit_feed_specification.html#frequencies_end_time_feed_data

In the case of the Bear Transit "P Line" example, the end_time would
be set at 19:10. So, "Bus 1" ends service at 19:10, and Bus 2 is in
the middle of its last trip at that time, which it completes through
the end of the trip.

> In general I think exact_times=1 is very convenient for manually
> created feeds but has yet be demonstrated as very valuable to data
> consumers. If there are people manually creating looping frequency
> defined routes then your proposal with the constraint headway_secs
> == block_headway_secs would be very handy.

This proposal may turn out to add too much complexity for data
consumers. Maybe this is actually shows a need for new features in
automated tools for publishing GTFS? If Google and other consumers
decide it's best not to implement this automation on their side, then
I'll plan a new feature in my GTFS publishing tool!

[Aaron Antrim]

I thought about this a little more.  It occurred to me that representing looping frequency-based trips is also a small display issue.

Example: Reoccurring trips on Flagstaff Mountain Line are represented with frequencies.txt and exact_times = 1.
Their feed is public: http://code.google.com/p/googletransitdatafeed/wiki/PublicFeeds
Example itinerary: http://tinyurl.com/df844q

I think one really nice touch in the Google Transit trip planner interface is the message "Service runs every 30 mins."

With the current spec, it is not possible to represent frequency-based loops in a way so that the trip planner will include this message.