Loop routes and headsigns in the Google Maps transit trip planner UI

[Aaron Antrim]

Google Transit team and Google Transit Partners:

Many transit services in small cities operate “loop”-shaped routes.
Trillium has found that the Google Maps UI does not accommodate loop
routes in an ideal way, particularly with regard to displaying
headsigns. This post describes the issue in further detail, as well
as the great number of services that are affected by this issue. This
post also makes suggestions for how to better accommodate various
styles of service and approaches to headsign information in Google
Maps. Feedback and responses from the Google Transit team and GTFS
publishers and consumers is very welcome.

In transit itineraries, Google Maps currently prefaces headsign
information with “towards” so customers see text such as “Line 6 Bus
towards Jantzen Beach.” (example: http://g.co/maps/d3hcd) In the pop-
up bubbles in the map view, Google Maps shows “Line 6 Bus Direction:
Jantzen Beach.” If no value is provided for trip_headsign, Google
Maps shows the name of the last stop as the destination for a trip.

This directional information works well for routes that travel
outbound and inbound to different terminuses. However, loop routes
start and end at the same station. Most often, one vehicle operates
continuously on loop routes.

Loop routes are a *very* common feature in small transit systems. The
majority of Trillium’s clients’ transit services include loop routes.
50 of our client transit services collectively operate approximately
195 loop routes.

Trillium has found that the Google Maps UI does not accommodate loop
routes well. One of the primary issues concerns the display of
headsigns. Most agencies that operate loop routes express objections
to the options currently available for showing their loop services.
“Red Route Bus towards Transit Center” doesn’t make sense, especially
if the customer is traveling away from the Transit Center.

To get around this issue, Trillium has prepared some GTFS in which a
trip_headsign of “[Loop]” indicates a loop service. This compromise
helps customers understand the idea that the loop route does provide
service in different travel directions, however it still yields an
awkward result.

This is an example result for Eureka Transit Service: http://g.co/maps/7hsz3

Oshkosh Transit System: http://g.co/maps/5jswe

San Benito County Express operates two opposite-direction loops (Green
and Blue Lines). We use headsigns of “Clockwise” and
“Counterclockwise” for these trips: http://g.co/maps/bh5cu

I can provide many additional examples if they would be useful.

I suggest that Google Maps should display headsign information in a
way that will better accommodate loop routes. Specifically, I ask
that headsign/travel direction information should be suppressed in
cases where trip_headsign is not provided. Alternatively, headsign
information could be suppressed if the stop_id for the first and last
stop time records is the same, but this may not cover every possible
case in which data publishers may prefer that trip_headsign
information is not displayed.

Additionally, there are many cases in which an earlier style Google
Maps used to show headsign information yielded better results.
Formerly, headsigns were shown after “Direction:” instead of after
“towards.” “Towards” does create a more natural phrase, but
“Direction” makes sense with a greater variety of possible
trip_headsign values, such as “Clockwise” (in the case of loop
routes), or “Northbound” or “Inbound” (for directional routes).
Therefore, I request that Google Maps consider returning to the
earlier display style.

Do any other feed publishers or consumers have feedback or responses
regarding this issue? I am also very interested in responses from the
Google Maps team.

Thanks for your consideration,
Aaron

--
Aaron Antrim
Trillium Solutions, Inc.
www.trilliumtransit.com
Portland, Oregon

Relevant threads:
“Best practices for loops” (http://groups.google.com/group/google-
transit-help-troubleshooting/browse_thread/thread/e09e9578fe4c43ea/
024e799fff97f90f?lnk=gst&q=loop#024e799fff97f90f)

Trip_id and block_id for loops (http://groups.google.com/group/google-
transit-help-troubleshooting/browse_thread/thread/f56dd192d0a20b54/
cb496ff9f1f22696?lnk=gst&q=loop#cb496ff9f1f22696)

[Tim Bender]

Inbound / outbound trips aren't significantly different than loop trips in Google Transit - you just have to break that loop out into individual trips between each destination sign change and then link them together using the "block_id" field in trips.txt.  

Consider an imaginary route (Route "L") that is a loop and always travels in the clockwise direction.  Buses on this route will have 3 major destinations (Downtown, Mall, & Airport - in that orider) and the vehicle will use these terms as headsigns to indicate travel direction to the rider.  

I'm guessing right now you consider each complete loop as a single trip, but you can only have one trip_headsign value for each trip (i.e. "Clockwise").  So to solve this problem, break each loop into 3 individual trips and then use the block_id value to block these trips together into a loop again (you're probably doing this already otherwise there'd be a part of the loop where the trip planner would force passengers to deboard and wait for the next vehicle to continue on the loop).  

So for the example route I gave above, instead of having a single trip that completes the entire route (Downtown to Mall to Airport back to Downtown) create 3 different trips like this: 

route_id,service_id,trip_id,trip_headsign,block_id

L,Weekday,L1,Mall,block1

L,Weekday,L2,Airport,block1

L,Weekday,L3,Downtown,block1

L,Weekday,L4,Mall,block1

etc...

-Tim

[Aaron Antrim]

Hi Tim,

Thanks for the comments! Everything that you say about the
capabilities of GTFS to describe headsigns is exactly right.

However, my concerns lie with these issues:

1.) Some transit services do not show destination-based headsigns on
vehicles, particularly for loop routes. I believe that GTFS, and trip
planning applications that use the data, should be able to describe
services as they exist. In short, we should not expect for transit
services to adapt other elements in their passenger information and
service descriptions to the requirements of GTFS and GTFS consuming-
software. It’s a “putting the cart before the horse” situation.

2.) Further, while I see how destination-based headsigns can be
assigned for loop routes, they do not make sense in many cases. They
may provide confusing information. Within the example that you
provide, how is the bus headsign indicated in other passenger
information? Do passengers infer it by looking at the timetable? Is
the direction information explicitly called out in the timetable? In
my perspective the information is unnecessary. Therefore, providing it
creates more opportunity for confusion.

3.) One-way loop routes and linear (inbound/outbound) routes are
different, and should be represented differently. Linear routes share
roughly the same route alignment for inbound and outbound trips. There
are two directions of travel. The one-way loop cannot be thought of as
having an inbound and outbound direction, because inbound travel
occurs on a separate route alignment than outbound travel. Further,
choosing the break point is somewhat arbitrary. With a linear route,
it’s where the bus turns around (the route terminus). Almost no one
has any reason to ride past the terminus and continue on the inbound
trip. With a one-way loop, there is no equivalent terminus. Passengers
might want to ride through any point.