Loop routes and headsigns in Google Maps transit trip planner user interface
One of Trillium’s roles for our clients is to advocate for our GTFS publishing clients. We provide feedback to applications and trip planning sites that use the GTFS, making recommendations for how information provided to customers could be improved. The latest example of this is feedback provided to Google regarding loop routes and headsigns in Google Maps. Here’s the correspondence.
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 destination information in a way that will better accommodate loop routes. Specifically, I ask that destination/travel direction information should be suppressed in cases where trip_headsign is not provided. Alternatively, destination 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.
[Update 7-March-2012: I changed the text in the above and below paragraphs, substituting destination information for headsign in many cases. Earlier, I had meant the GTFS’s trip_headsign values with the use of the word headsign, but the phrase “destination information” captures this better. As I understand it, “headsign” usually refers to the entire text that is shown on the vehicle readerboard (or destination indicator).]
Additionally, there are many cases in which an earlier style Google Maps used to show destination/trip_headsign information yielded better results. Formerly, destinations 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,
AaronRelevant 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)
The one thing I’m not clear on is…is there an ideal? That is, forget about the ‘compromise’ for a moment — what is it exactly that we would like to see in an ideal world, assuming we had all available information? We have computers as tools, so it’s possible we might be able to achieve the ‘ideal’, or the ‘seemingly difficult’, etc.
And, to have our ideal world/service/Gmaps, do we need to change/update the GTFS — more fields, etc.? I.e., do we need a ‘circular route’ indicator?
The ‘fallback rules’ are probably pretty easy to deal with, all things considered.
The inbound/outbound stuff always confuses me on the rare occasions when I encounter it. I ride the SF Muni (light rail/streetcar combo) on rare occasions. If I’m in the downtown core area — Embarcadero or Powell St stops — and I want to go ‘out’ to the Bayview, I actually need to take an ‘inbound’ train, whereas if i’m going ‘out’ to the Sunset district, I want to take an ‘outbound’ train. The inbound/outbound stuff can make sense, and probably often does, but the ‘straight line only’ people won out over common sense — cities are going to be multi/poly-centric (if we’re smart), so the inbound/outbound stuff will become even more ambiguous.
All that said, on a true loop route, it seems to me ‘clockwise’ and ‘counter-clockwise’ would make the most sense.
Or take from highway signage, ‘North’ or ‘West’ or ‘North/West’ or whatever.
Or, mention one or more destinations along the way, in order — Oakland 20 mi, Sacramento 75 mi, Tahoe 130 mi, etc.
Peter-
The goal is to make the information shown in the trip planner results match what is shown in timetables and on the vehicle destination sign. To that end, what I’ve requested — that destination information should not be shown in the trip planner for cases of a blank trip_headsign — would achieve this goal.
If a route only operates in one direction, then it is not useful to provide destination information.
I was thinking specifically of SF Muni when I mentioned Inbound/Outbound direction indications. I agree this approach does not agree with the way most people think about their travel, but it is how this agency and others communicate about service, so it needs to be accommodated.
Finally, it is not necessary to create a field to designated loop routes. However, there is a GTFS-changes proposal to make direction_id more explicit. If something like this is adopted, it would be useful for the adopted change to GTFS to take into account loop routes.
One of the most confusing parts of loop routes for passengers, especially if you have a bi-directional loop, is to tell the passenger what side of the street to stand on. For a one-way loop, this is probably not a problem because the stops are likely only on one side of the street. Having the correct headsign allows the passengers to determine what side of the street to wait on.
One way to solve this issue, and we have been doing this for a while, is to change the headsign halfway through the loop. Typically the bus will reach some middle point of the loop and begin heading back toward its starting point. We actually tell our bus drivers to change the headsign. This effectively gives us an outbound/inbound segment and allows passengers to ride the bus with the correct headsign. Google Maps shows this properly because we override the “trip_headsign” with “stop_headsign” where appropriate. This way, the headsign isn’t shown incorrectly for the trip once the bus has passed the middle point…either on the bus itself or on Google Maps (and any other app using our data, such as our realtime texting service).
Of course, because stop_headsign can be specified for every stop, you could always leave trip_headsign blank and only use stop_headsign. You can also change stop_headsign as much as you’d like during the trip.
You can use “Loop” as well, so passengers know the route is on a loop and that’s why so many destinations are in the headsign.
Devin
p.s. – This is also an issue for really long non-looping trips where there are many intermediate destinations and you don’t want to show the destinations that the vehicle has already passed.
Our current practice for loop routes is to designate the station from which the loop is served, appended with the name of the loop.
Our intent is to imply that the a given bus departing the station will hit the area of the specific loop name, but ultimately will return to the same spot. Our destination signage on the bus itself also remains constant for this concept.
http://g.co/maps/ymnc2
Bus destination sign:
21 NORTH TFR PT-LAKEVIEW
Trips depart/arrive North Transfer Point station, and loop through Lakeview neighborhood.
For loop routes that operate in two distinct directions (clockwise, counterclockwise), the loop name is a two-part construct of what is served earlier and what is served later.
50 WEST TFR PT: VIA RAYMOND: VIA SCHROEDER
Trips depart/arrive West Transfer Point station, and loop through Raymond area first, then Schroeder area.
Tim,
The one issue I see would be for someone who rides the loop route through the “top of the schedule”, if the loop routes are operated in a continuous work block, as most are. Do vehicles continue on the same route after they return to the transit center?
If this is the case, then we’re forced to think about destinations and travel directions differently than we do for linear routes, because the vehicle is constantly heading toward all destinations. The route is never finished; when the vehicle reaches the “start/end” point (often a transfer hub or transit center), it starts over again on its eternal loop. (ie: How does the provided information apply to someone who boards shortly before the Transit Center, and then continues to a point beyond the Transit Center along the route?)
Loop routes are an unfamiliar geometry for large urban systems. But they are commonly used in small urban and rural systems because they provide coverage (albeit at the expense of direct travel). Jarrett Walker, as usual, gives us a really nice discussion of loop routes: http://www.humantransit.org/2009/07/on-loops.html
I think the best practice on loop routes is to utilize the
stop_headsign field in stop_times.txt. I prepared a feed for a system
of 6 routes with two of the 6 routes having loops (one route is a
unidirectional loop, the other is a bidirectional loop).
My suggested approach is to take the halfway stop point location of
the entire loop and use that as the stop_headsign value for all stops
on the loop prior to the halfway point. Then I use the begin/end
location of the loop as the stop_headsign value for stop points
beginning at the halfway point or after it. This approach works for
either a unidirectional or bidirectional loop. Or you could just
simply divide the loop into two-halves and enter it as an outbound
trip on the first half of the loop and an inbound trip on the second
half of the loop.
See example showing a trip along an entire unidirectional loop trip as
two legs of the same entire trip_id (click on both hyperlinks and put
them side-by-side on your screen to see entire loop).
1. First half of the M5 loop (stop_headsign = North Brunswick) –
http://tinyurl.com/7e2qp7l
2. Second half of the M5 loop (stop_headsign = New Brunswick Rail
Station) – http://tinyurl.com/6pnx9gn
Thanks for sharing this example. I think this is a workable approach, but not without some issues (see below).
What is shown on the bus headsigns? I think what is shown in the trip planner should match that indicator.
The approach you use does have some limitations. Notice this trip to the New Bruswick Rail Station on the M5:
http://tinyurl.com/7znsrs3
The trip still shows a headsign of North Bruswick, even though the destination is the Rail Station. This is because the passenger boards on the first half of the trip. There is more discussion of this general issue here: https://groups.google.com/group/gtfs-changes/msg/4c6adfbaa5219c2d
Cheers,
Aaron
Headsigns are used primarily to indicate which direction a bus is traveling. Regardless of what it says (Inbound, Downtown, Clockwise) the purpose is to help a rider pick the correct bus to board to ensure he/she travels in the correct direction to the destination.
Linear (inbound/outbound) routes aren’t that different from loop routes (clockwise) in how they are represented in Google Transit. In fact, it’s probably easiest to think about linear routes as giant loops with a mid-point (half inbound, half outbound). But in Google Transit you show this as 2 individual trips with two different headsigns that correspond to what the vehicle’s headsign display is.
I’ve read through the comments here a number of times and still think the best solution is to break your loop into 2 or more segments and create trip_headsigns that make sense. Ideally your agency is already using more than one headsign for each loop to indicate to people which direction the bus is traveling. Maybe you make a policy decision to break it out into even more segments.
For example, say you have a loop that goes from Downtown to the Mall to the Airport, to the Stadium then back to the Mall (and your drivers sign up each segment as such). Instead of representing this as a single trip with a trip_headsign of “Loop” why not break it out into 4 trips and give each trip it’s own unique headsign (i.e. towards “Mall” or towards “Airport”) in the feed, then link these trips together via block_id. Another commenter suggested this approach above.
I know you’re concerned about limitations of this approach, but I think it works perfectly. If a passenger is traveling from the Mall to the Stadium the trip planner will tell him to get on the bus signed up as “Airport” but that’s all he needs to know to get on the right bus. If you’re trying to force the feed to display “Stadium” the passenger will likely be waiting around for a bus signed up as such and will never complete his trip.
Does this make sense or am I missing something?
Hi Tim,
Thanks for the comments! Everything that you say about the capabilities of GTFS to describe headsigns is exactly right.
However, my concerns are with these three 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, necessarily, 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.