Proposal: New field in routes.txt to describe route geometry (loops)

[Aaron Antrim]

GTFS consumers & creators:

This is a proposal to add a way of describing route geometry types in GTFS, specifically to describe loop routes as such.

Many transit services in small cities operate "loop"-shaped routes.  Most often, one vehicle operates continuously on loop routes.  Travel direction (headsign) information is irrelevant for most of these routes.  Whereas travel direction or destination information expressed in the trip_headsign or stop_headsign field works well for routes that travel outbound and inbound to different terminuses, loop routes start and end at the same station.  

Some GTFS-consuming applications (I know of Google Maps -- are there others?) show travel direction or terminus information.  For loop routes, this is confusing to passengers.  If no value is provided for trip_headsign, Google Maps shows the name of the last stop as the destination for a trip.  This means the bus is always shown as heading "toward Transit Center" or something similar.  Here is an example for Cottonwood, Arizona (USA) in which the bus is always headed toward Garrison Park: http://g.co/maps/uhm5g

Previous discussion here: http://www.trilliumtransit.com/blog/2012/03/06/loop-routes-and-headsigns/

I have suggested that travel direction information should not be shown in cases where a trip_headsign value is not provided.  However, many feed publishers now depend on the default behavior.  Instead, I propose a new element of the Specification that would be used describes loop route geometry.  I offer two alternatives below.  I would like feedback to see which, if any, is preferred by GTFS consumers and creators.

Alternative A:

Add a new field, "loop," to routes.txt.  Values of 0, or undefined, means the route does not travel in a loop pattern.  1 means the route is a loop.

Alternative B: 

Add a new field, "route_geometry," to routes.txt.  This field could be used to describe route geometries besides loops. However, I am unsure if there are other geometries that would be useful to describe.  Does anyone have feedback?

0: undefined

1: bi-directional

2: multi-directional

3: loop

4: ??

The intended behavior for both Alternatives A and B is that destination/travel direction information will not be shown for loop routes in cases where a trip_headsign value is not provided.

There may be other advantages to describing loop route geometries than just display of destination/travel direction.  Consider, for example, block_id when used within a loop (http://www.trilliumtransit.com/blog/2009/04/15/google-transit-update-loop-routes-show-up-more-nicely/).  Or frequencies.txt and loop routes: https://groups.google.com/forum/#!topic/gtfs-changes/IXatiQb6X_0

-- 
Aaron Antrim
www.trilliumtransit.com
Portland, Oregon

[Bradley Tollison]

Perhaps instead of removing the headsign information, we could instead
add a note that states that the route is a loop and returns to it's
origin point?

On Wed, Apr 11, 2012 at 12:18 PM, Bradley Tollison <ieko...@gmail.com> wrote:
> I think this problem is inherent to loop routes, in that they in
> general are confusing. Headsign information is important because it
> helps patrons know what to look for as the bus approaches, often these
> small systems lack good signage to help wayfinding and so the only
> real decent piece of information is what is displayed on the headsign.

>> --
>> You received this message because you are subscribed to the Google Groups
>> "General Transit Feed Spec Changes" group.
>> To post to this group, send email to gtfs-c...@googlegroups.com.
>> To unsubscribe from this group, send email to
>> gtfs-changes...@googlegroups.com.
>> For more options, visit this group at
>> http://groups.google.com/group/gtfs-changes?hl=en.

[Bradley Tollison]

I think this problem is inherent to loop routes, in that they in
general are confusing. Headsign information is important because it
helps patrons know what to look for as the bus approaches, often these
small systems lack good signage to help wayfinding and so the only
real decent piece of information is what is displayed on the headsign.

On Wed, Apr 11, 2012 at 12:12 PM, Aaron Antrim
<aa...@trilliumtransit.com> wrote:

[David Healy]

One thing to point out is that the Headsign can be made meaningful on a circular or multi-directional loop by using the stop_headsign fields in stop_times.txt.

This allows the headsign of a trip to change as the trip progresses around the circle. From a GTFS consumer point of view, the consumer should always display the correct headsign for the stop at which the passenger boards the trip.
This way, the Headsign always makes sense as it will always refer to stop that is ahead of the current stop.

[Aaron Antrim]

Loop routes may not be an ideal route geometry from a traveler's perspective, because few people want to travel in circles.  However, one-way loops serve a purpose and they are common.  Resource-constrained agencies operate loop routes to maximize service coverage over an area.  The majority of Trillium’s clients’ transit services include loop routes.  50 of our client transit services collectively operate approximately 195 loop routes.

The intention of this proposal is to make trip planner itinerary results correspond to information shown on bus headsigns.  Often, loop routes are indicated only by a name, "Red Route", for example.  No destination information is provided.  Our goal is to provide information in the GTFS and through trip planners that matches how service is described in on vehicles and in other information as closely as possible.

As a temporary compromise, Trillium often has used values of "(Loop)" or "Clockwise"/"Counterclockwise" in the trip_headsign field.  This gives customers more information about the service but looks kludgy.  Examples below.

Eureka, CA: http://g.co/maps/9kn4t

Hollister, CA: http://g.co/maps/gnp8s

In short, destination information is not shown on the vehicle for most loop routes with which I am familiar.  I would not use stop_headsign to indicate the immediate next stop for customers.  However, Tim Sobota (Madison, WI) does provide us with an example of destination information being provided in the trip planner and on bus headsigns: http://www.trilliumtransit.com/blog/2012/03/06/loop-routes-and-headsigns/comment-page-1/#comment-6755

Does anyone have additional feedback or thoughts?  Are the proposal alternatives useful?  Logical?

--

You received this message because you are subscribed to the Google Groups "General Transit Feed Spec Changes" group.

To view this discussion on the web visit https://groups.google.com/d/msg/gtfs-changes/-/SeOIOM6TmK0J.

[Devin Braun]

stop_headsign is there specifically for the problem you're trying to solve.  It overrides the trip_headsign for that stop. 

 

So, for example, I'm on a Speedbus Lines bus going from California to Florida via New Mexico, Texas (two stops), and Louisiana.  Here's how I'd set up my files (simplified version and it's a flying bus based on the speed!).

 

__trips.txt__

trip_id,route_id,trip_headsign

Florida1,Florida_Line,Florida via New Mexico Texas & Louisiana

 

__stop_times.txt__

trip_id,stop_id,arrival_time,departure_time,stop_headsign

Florida1,California,08:00:00,08:00:00,

Florida1,New_Mexico,09:00:00,09:30:00,Florida via Texas and Louisiana

Florida1,Texas1,11:00:00,11:30:00,Florida via Louisiana

Florida1,Texas2,11:40:00,11:45:00,Florida via Louisiana

Florida1,Louisiana,12:00:00,12:30:00,Florida

Florida1,Florida,13:00:00,13:00:00,

 

The consuming application will show the proper headsign to the customer based on the stop they are boarding at, and I'm assuming the driver would change the headsign to match at each location. 

 

--Devin

[Aaron Antrim]

Right.  However, many loop routes do not show destination or intermediate point ("via") information on the bus headsign.  Instead, they just show the route name.  To/via information in the trip planner will not have any use for identifying the vehicle.  The trip planner results should match what appears on the vehicle headsign.

The example you provided is not a loop, but a directional trip.  I've extended your example to show some fundamental issues that arise with loops and to/via headsign information.

__trips.txt__
trip_id,route_id,trip_headsign,block_id
USLoop1,US_Route,"Oregon via Texas, Louisiana, Florida, and New York",USLoop

USLoop2,US_Route,"Oregon via Texas, Louisiana, Florida, and New York",USLoop

__stop_times.txt__

trip_id,stop_id,arrival_time,departure_time,stop_headsign
USLoop1,California,08:00:00,08:00:00,
USLoop1,New_Mexico,09:00:00,09:30:00,"Oregon via Texas, Louisiana, Florida, and New York"
USLoop1,Texas1,11:00:00,11:30:00,"Oregon via Louisiana, Florida, and New York"
USLoop1,Texas2,11:40:00,11:45:00,"Oregon via Louisiana, Florida, and New York"
USLoop1,Louisiana,12:00:00,12:30:00,Oregon via Florida and New York
USLoop1,Florida,13:00:00,13:00:00,Oregon via New York

USLoop1,New York,14:30:00,14:30:00,Oregon

USLoop1,Oregon,18:00:00,18:00:00,California

USLoop1,California,20:00:00,20:00:00,

USLoop2,California,20:00:00,20:00:00,

USLoop2,New_Mexico,21:00:00,21:00:00,"Oregon via Texas, Louisiana, Florida, and New York"

… [etc.]

If Sppedbus Lines has a frequent rider mileage program, passengers will accrue a lot of reward miles because of all the circuitous travel.  It may look a bit absurd on the national scale, but loop routes often necessitate indirect travel.  One-way local transit loops do often look like this.  Large urban systems typically do not have routes with this geometry, but small urban and rural systems do.

Also, note that I added a block_id field and a second trip, USLoop2.  This highlights another problem: What headsign should be shown at the Oregon stop when the vehicle is returning to California?  Note that some passengers may be continuing onto New Mexico, Texas, Louisiana, Florida, or New York.  I suppose the destination and via could be advanced each time.  But my point is that there is a reason why many loop routes do not show vehicle destination information, and why we may not want trip planning applications to show this either.  If so many destinations are served, it is not practical to list all of them.

--
You received this message because you are subscribed to the Google Groups "General Transit Feed Spec Changes" group.

To view this discussion on the web visit https://groups.google.com/d/msg/gtfs-changes/-/_sHdKM66Rz4J.

[Devin Braun]

I understand your proposal better now. You want to control the output of consuming applications for loop routes and force them to suppress the headsign, whether it's provided or not.

 

Maybe the solution can be more general to the specification.  Don't use "Loop Routes" as the example, because as was shown with stop_headsign, you can provide values that would make sense to passengers.  But sometimes, having a headsign doesn't make sense even for direct routes. For example, if planes or ferries are included in the feed, there isn't a headsign to show.  Also not all trains have headsigns if they travel in stations with electronic signs.  And you're right, if a provider writes their trips as huge loops, the final destination (the starting point) wouldn't make sense.

 

Maybe in routes.txt or trips.txt you can add a field, suppress_headsign, so that it wouldn't be used for those routes and/or trips.

 

Your route_geometry field could still be used to describe the type of route it is. This could still help developers visualize routes if they knew it was bidirectional, looping, etc.  But I wouldn't want to specify that we have a loop route and have the headsign suppressed because our headsigns are correct for loop routes.

 

Devin

[Aaron Antrim]

That is a good suggestion, Devin.

Following this suggestion, I propose to add a new field to trips.txt, no_dest_indicator.  This field will indiciate whether the destination is indicated on vehicle signs.  Trip planning applications could use this field to control if destination information is shown, both in cases where trip_headsign is provided and where no value is provided.

Possible values and meanings as follows.

no_dest_indicator is 0 or not defined: Vehicle destination indication is shown.

no_dest_indicator is 1: Vehicle destination indication is not shown.

If this looks good, we should create a separate thread to discuss this proposal, leaving this thread available for comments on the route_geometry proposal.

--

You received this message because you are subscribed to the Google Groups "General Transit Feed Spec Changes" group.

To view this discussion on the web visit https://groups.google.com/d/msg/gtfs-changes/-/paVYzWgSmQYJ.