They interview some key players who give a window into the evolving practice of opening transit data.  Check it out if you haven’t already.

Before this guide, printed schedule information and maps for each agency were available separately.  That made it more difficult for passengers to plan inter-agency trips.  It also meant that passengers weren’t always aware of all the services available.  Imagine, if you will, if you had to consult a different map or road atlas for roads maintained by each city, county, and the State DOT-maintained highways — in short, use a different information source according to the agency responsible for maintaining the roads you are driving on. Probably, if this was reality, driving would not be nearly as popular as it is today!  Or, imagine if you had to go to every individual airline’s website to search for available flights and their prices instead of using Travelocity.com or something similar.

The twenty-eight page guide includes timetables for five fixed-route transit services in the Humboldt Bay Area.  The overview map also shows connecting regional services, including the local transportation service in adjacent counties, and Greyhound and Amtrak service.  Multiple agenies’ services are shown in many of the detail maps that highlight particular cities.

In addition, the service guide responds to findings from the Humboldt County Coordinated Human Services Transportation — Public Transit Plan by showing flexible and on-demand human services transportation services in the same guide.  Below is an overview map.  It is accompanied by tables of transportation services that show eligibility requirements, service area and hours, accessibility features, contact, and other pertinent information for each service.

When finished, the multi-modal trip planner software will plan journeys by a combination of biking, walking, and transit in the areas where it has been implemented.  For regions that wish to implement the trip planner, they will need to use in-house resources or hire a firm to install, host, and manage the software.  Information on transit service, walking routes, and biking routes in the necessary formats will be one of the most important prerequisites for implementing the open-source multi-modal trip planner.

Check out the OpenTripPlanner site or join the developer discussion list to learn more and follow along with the effort.

• Redding Area Bus Authority (RABA) was a stakeholder in the Northeastern California Google Transit Feasibility Study.  Redding is a micro-urban city in Northern California on the inland Interstate 5 corridor.  Redding is a regional transportation hub, with neighboring transit services (Plumas, Modoc Sage Stage, and Trinity Transit) and intercity services (Greyhound, Amtrak) offering service.  [Example RABA trip]
• Trinity Transit was also a stakeholder in the Northeastern California Google Transit Feasibility Study. They are a rural system with some inter-city service.  [Example trip… note only works on Mondays and Tuesdays, you may have to adjust the date.]
• Siskiyou Transit and General Express (STAGE) was also a stakeholder in the Northeastern California Google Transit Feasibility Study. They are a rural, mainly inter-city transit service.
• Columbia Area Transit (CAT) operates intercity services between Hood River, The Dalles, and Portland, Oregon.  [Example trip.  Note the challenge to return Hood River to Portland service, which is only once per week.]
• Clemson Area Transit (CAT). The first agency in South Carolina to be live on Google Transit.
• Fairfield and Suisin Transit.  This agency connects with a lot of others (BART, Sacramento RT, Amtrak Capitol Corridor, Rio Vista Delta Breeze) that are live on Google Transit, which provides additional value for all.

As you can see, a busy season.  There are more to come soon.  Note that most of these agencies have chosen to make their data available at gtfs-data-exchange.com and the PublicFeeds page for developers to access it and build applications that help people use transportation services.

Via the Official Google Blog: “This week in search 12/11/2009.”

When public transportation information was added to WalkScore, FrontSeat realized they needed more open Google Transit feed data to make the feature useful in more markets.  CityGoRound makes it easier for people to find transportation applications for their area (see example of the localized search for Portland).  The website also highlights the need for open data to make these applications possible.  They recognizes and thank the agencies that provide open data (pulling this information from GTFS Data Exchange).

The project team were several hard-working transit and open data advocates: Brandon Martin-Anderson, Jehiah Czebotar, Dave Peck, Josh Livni, and Joe Hughes, who put this together in a few weeks.  The site is open source to facilitate its implementation in international markets.

Transit agencies with open data: Put a link to your localized City-Go-Round page on your agency website.  One of our clients is already planning to do this, and we’re planning to reach out to more clients to encourage them to refer their online customers to this useful resource.

You can also read about CityGoRound.com at the Headway Blog.  And there’s the Front Seat press release.

ISSUE: Queries for travel times more than 48 hours in advance of scheduled service return no results

Some inter-city routes within the project study area operate once or twice each week.  Currently, for these services to be returned in the trip planner, the end-user must query for a departure time and date near to the scheduled time of service.  If the query is for a desired travel time 48 hours or more in advance of the scheduled service, no results will be returned; to someone who doesn’t already know there is service on that corridor, it looks like there is no service available.

We suggested the Google Transit trip planner should search for and return services that are up to 7 days in the future of the desired travel time.

ISSUE: Maximum walking distance threshold prevents display of available transit service

When the origin or destination entered into the trip planner is farther than four miles from the nearest transit stop, no trip options are returned.  We contacted Google Transit Partner Support about the possibility of modifying walking distance thresholds in rural areas.

The recommendation developed with stakeholder input is for the travel to transit stop distance to be increased to 25 miles (that’s a pretty long distance; don’t know if it’s technically feasible). This travel distance to transit can be expected in areas where transit passengers travel over 100 miles to a regional airport in service areas with density of less than 5 persons per square mile, for example. In order to avoid trip planner results where travel-to-transit distance is greater than travel-by-transit distance, the travel-to-transit threshold should be increased for long-distance transit routes.

This issue presents a particular problem in instances where end users query for transit destinations and origins by the name of a city. In Google Maps, the discrete points that indicate the location of rural cities may be a significant distance from actual town centers and transit stop locations (see example below).

In rural areas, friends, family, and neighbors sometimes drive transit passengers to bus stops if walking distances are significant.  For some commuter rail services, Google has incorporated drive-to-transit directions. This feature may also be useful in rural areas.

Since Google Transit has most been often implemented in larger metropolitan regions, and has more users in those metropolitan regions, trip planner features are (naturally) often geared more towards metropolitan use cases.  One of the purposes of the Shasta County/NorCal Google Study was to catalog issues with the Google Transit trip planner in rural areas and with rural system features — using real data with Plumas, Shasta, Siskiyou, Trinity, and Tehama counties.

You can read the details of issues beginning on page 35 of the Feasibility Study.  For those who would prefer not to download the PDF, I thought I would share some some highlights on this blog.

Originally, my plan was to put the entire discussion of issues in one post.  When I started that project, I realized there was way too much text for one post, so I’m going to spread out discussion into a series of posts.  That will help focus comments and discussion around particular interests and issues.

I don’t want to seem like I’m picking on Google Maps and the transit team.  Sometimes people will zero in on problems and flaws with Google Maps and Transit, and I find myself defending the mapping application and approach behind it, which is to launch early and learn through testing with real users and data.  Building an application of the scale of Google Maps seems a bit like building an airplane in mid-flight (the analogy isn’t originally mine; I borrowed it from an EDS television advertisement) — there are millions of users, at least 40 languages, and lots of complicated data.  It’s hard to build a platform that serves every transit system and user equally well on a global scale.

I hope this feedback helps to improve Google Maps transit directions.  Mostly, I hope that by posting on this blog and inviting comments here and around the web, it will at least improve the overall quality of discussion and feedback for Google Maps improvements.

So, without further ado, the theme of the day is walking as part of Google Maps transit directions in rural areas.

ISSUE: Trip planner returns walking directions instead of available transit option for complete trip or segment

Some travel itineraries on loop routes may involve indirect travel paths and correspondingly long on-vehicle passenger travel times.  Travel times can be longer in rural systems because transit networks are designed for coverage (serving dispersed needs in the area) rather than productivity (building ridership by serving choice riders and commuters).  In cases where the trip planner calculates walking is a faster alternative to transit over all or part of a transit route, the trip planner does display options that minimize travel time, but may add unnecessary walking.

For an example, below: A more ideal display of a trip on TRAX Route 1 (Photoshop mockup, left) and TRAX Route 1 trip as it currently displays (right).

This software decision produces optimal travel itineraries for individuals that do not mind and are able to walk distances of, for example, 0.5 or more miles.  However, the result does not serve the needs of mobility-limited customers, customers with heavy bags, or people in rainy, cold, or wet places would want to avoid exposure to nasty weather.

This is a tricky issue because some passengers (like me) usually want the fastest possible itinerary even if it requires extra walking.  Others do not.  Some ideas that have been discussed with Google and on the various discussion groups with agencies, consultants, and Google are: (1.) including a checkbox to “minimize walking distance” in the Google Transit trip planner UI, or (2.) including a field to specify maximum walking distance.

This issue seems especially tricky.  When I use Google Maps, I see some cases where I wish it suggested less walking and others where it suggested more walking.  Here’s an example where Google Maps should suggest a little more walking and less transit.  It would make more sense to walk directly from the SF Muni F Line to the SF Ferry Building and board the ferry service to Sausalito.  But instead, Google Maps suggests a more round-about tour.  And in other cases, like above, Google Maps suggests walking a fair bit of walking when transit is available almost to the doorstep of the destination.  So I appreciate the challenge of building a system that gives intelligent itineraries when there may be a many factors and considerations at play.

What do you think is the best way to address walking as part of transit directions?

Open Street Map has enabled users to make near-instant edits to map data, wiki-style, for some time now.  Lately, Google is beginning to follow a similar approach (though edits are reviewed, and take effect later).  Previously, Google Maps used data from commercial map data provider TeleAtlas, and before that, NAVTEQ.   No more.

From the NY Times article:

People have been contributing information to digital maps for some time, building displays of crime statistics or apartment rentals. Now they are creating and editing the underlying maps of streets, highways, rivers and coastlines.

“It is a huge shift,” said Michael F. Goodchild, a professor of geography at the University of California, Santa Barbara. “This is putting mapping where it should be, which is the hands of local people who know an area well.”

…

Last month Google dropped Tele Atlas data from its United States maps, choosing to rely instead on government data and other sources, including updates from users.

“They have coverage in areas that the big mapping guys don’t have,” said Mike Dobson, a mapping industry consultant who once worked at Rand McNally. “It has the opportunity to cause a lot of disruption in these industries.”

Why is this important for transit?  Two reasons:

• Some agencies have complained of less-than-accurate in Google Maps for some regions.  Now, there are more effective avenues to address those concerns.
• Google Maps users can now readily add information about infrastructure and features for non-driving transportation modes such as walking and biking.  I think/hope this development will make Google Maps an increasingly multi-modal map and trip planning platform in the future.

The best way of presenting information at stop poles probably depends on system features and also on customer expectations.  In particular, at stops, or in systems where many routes share alignments, customers may want arrivals/departures ordered by time first as the primary variable.  But where route alignments are divergent this is not useful.  Customers would likely be better served with stop times separated out by route.

Jarret Walker (author of the excellent HumanTransit.org) kindly provided some photos of timetables posted at stops in Bern, Switzerland; Berlin, Germany; and Sydney, Australia.  Below…

First, a timetable in Sydney, Australia that lists all stop times in order, with columns for destination and route.

A more detailed view:

Next, some European examples.  This timetable for Metro Tram in Berlin organizes stop times (expressed as minutes after the hour) into rows for each hour of the day.  Note however, that the four columns with stop times show those times for the same line on different service days.

Next, here’s a similar arrangement as the Berlin example from Bern, Switzerland.  The full ensemble of information includes a system map:

And, a detailed view of the Bern, Switzerland timetable:

An adaptation borrowing on the Bern and Berlin approaches could be for each column to show stop times for a different line.  This would make it easy to for customers to look up a time if they are only interested in a specific line, while also making it fairly easy to look up times for the next available service at a particular time.  It would be necessary to have different grids for each service day.  This would be an approach like what Trillium implemented for UC Berkeley Bear Transit (see image after).

Web-view of times for UC Berkeley Bear Transit: (this is still somewhat experimental/beta; for some stations with lots of service the timetable overwhelms the display space of the popup box):

Even after reading some of the articles recommended in comments on the last post, I’m not entirely sure which are the best approaches for presenting information at stops.  Personally, I would probably prefer an adapted version of the Bern and Berlin examples as I proposed.  The Sydney example is simple but provides less structure than the others, limiting its functionality.  What do you think?

In conclusion to this discussion, one of the thoughts that arises for me is how necessary and useful it is to have good software to produce and maintain these stop-specific timetables and information.  Otherwise, this is an extremely labor-intensive process.  Aaron Priven, the designer of the AC Transit pole schedule I originally called out, described the system of Perl scripts and page-layout software that is used to produce the timetables in his comments on the blog.  He says he may get around to open sourcing the Perl scripts AC Transit uses as part of the process to get data from the HASTUS scheduling system and into Adobe InDesign.

Also, TriMet has open sourced TimeTable Publisher, the software they developed and use in house to create all of their printed and online timetables.  TimeTable Publisher is described further in this interview with TriMet’s Chief Technology Officer and IT Manager for GIS and Location-based Services.  The software can import information from a variety of sources, including the Google Transit Feed Specification (GTFS), eXtensible Markup Language (XML) formats, or directly from a SQL database.  Currently, the software does not include functions to create stop-specific timetables such as the ones described here.  With an interested client, we could put some developers on it and then contribute back to the source code so that these sorts of stop-specific timetables would be easier and less expensive for other agencies to implement in the future.  Is any agency out there interested?