Google Transit: Intercity trip planning issues in Oregon

Many more Oregon intercity transit services have launched on Google Transit recently. These services have launched as a result of Trillium’s work for the Oregon Department of Transportation.

Google Transit is beginning to include more intercity transit services.  You may have noticed the recent post about the addition of more Amtrak services.  The addition of Oregon intercity bus services is another opportunity to learn about intercity trip planning and provide feedback to the Google team and community.

As part of Trillium’s work for clients, we assess how the Google Transit trip planner responds to passenger queries.  Trillium documents issues and makes recommendations for how to improve trip planner responses.

Here is what we are learning from the Oregon project.

Google Maps undervalues shortened overall travel time and overvalues minimized walking distance for long-distance intercity trips. Previously, Trillium has suggested that walking distance be minimized in the Google Transit trip planner results. However, for intercity travel presents a different situations: for some trips, if a traveler walks a few additional miles or takes a taxi, they can access a more direct service that will save hours from overall travel time.

Google Transit was originally engineered for local transit systems on which travel itineraries are planned around specific arrival or departure times. This makes sense, given that when Google Transit began only local transit systems were included.  For longer distance intercity travel, especially involving services with less frequency, travel times may not need to be planned around as specific a time. Instead, the customer is likely to prefer the fastest/most efficient itinerary that arrives or departs on a particular day.  This approach is similar to how people often choose airline tickets online: Given a limited number of flights on a particular day, I choose the fastest itinerary.

Here is an example of a long intercity bus itinerary and a shorter alternative.   Immediately below is the long itinerary that was returned.

This itinerary is 9h 50min (full itinerary is at the bottom of the message): (from: Ste 250, 800 Northwest 6th Avenue, Portland, OR 97209-3715 (Portland Union Station) to: bend, or)

Here is a shorter alternative, 5h 1min. The last travel leg is on Valley Retriever Newport/Bend service.

from: Ste 250, 800 Northwest 6th Avenue, Portland, OR 97209-3715 (Portland Union Station) to:bend oregon bus station

The second query specifies a destination at the drop-off point for Valley Retriever (Bend Oregon Bus Station). If the same transit routes were used as in trip B, but bound for the destination of the early trip, the walking distance would be 1.9 miles. I speculate that the longer itinerary was generated to avoid this walking distance.

Previously, I have suggested that walking distance be minimized in the Google Transit trip planner results. However, this trip is a lengthy intercity itinerary. In this case a walking or drive/taxi distance of 1.9 miles is incidental, and shaves 3 hours off the trip.

I suggest that the significance of walking distance should take into account the overall length of an itinerary, and potential time savings. This means that for a longer itinerary, the walking distance penalty would factor less significantly.

Also, it is useful for the passenger to see both itinerary options (shorter overall travel time with longer walking distance, and longer overall travel time) in the results, which isn’t happening currently.

Aaron is the founding principal of Trillium Solutions, Inc. He brings experience that includes 12 years of web-development with 8 years in public transportation, with knowledge of fixed-route transportation, paratransit, rural transportation, and active transportation modes. Aaron is a recognized expert in developing data standards, web-application design, digital communications, and online marketing strategy. He originally developed Trillium’s GTFS Manager, and has played a key role in the development of the GTFS data specification since 2007.