Follow-up: Timetables for posting at stop poles (”Quick: When is the next bus scheduled to arrive?”)

Thanks to the readers and comment-makers, I received some enlightening feedback and new information after the post “Quick: When is the next bus scheduled to arrive?”

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?

What’s your transit score?

WalkScore.com, by FontSeat, is a site that automatically generates “walk scores” for inputted address locations.  These scores, numbers between 0 and 100, are intended to express the walkability of a location, as determined by the proximity of various services and destinations like grocery stores, restaurants, medical services, parks, and schools.  Some users of WalkScore include real estate agents and home sellers looking to market walkability, and home buyers who want to compare properties on the basis of walkability.

Some of the factors that walk scores fail to account for are available transit service and the quality of the streetscape and sidewalks.  Facility quality isn’t yet incorporated into walk scores, but FrontSeat is working to add available public transportation options as one of the variables that determine walk score.

Currently, transit proximity does not factor into the generated numerical score.  But, when a user searches for an address, transit stops (and the lines that serve them), along with nearby services and destinations, are displayed on a map, and listed in a sidebar.  Owing to the importance of transit for non-car mobility and the pedestrian lifestyle, transit stops are the first listed items in the sidebar.  Here’s a screenshot.

Transit stop locations and services are derived from publicly-available Google Transit feeds (see also GTFS Data Exchange).  The week after transit information was incorporated into WalkScore, many agencies made their GTFS data public.  Walk Score has a nice writeup on how they gather and use transit data.

The plans for incorporating a “transit score” into the walk score look promising.  UPDATE (11/28): As envisioned, generated transit scores will take into account the number of stops within a walkable radius of given location, the number of services at those stops, and also the usefulness of those services. One proposal is to determine transit score by the usefulness of the services accessible from the location, and how convenient it is to access these services (how far away the nearest stop is). Usefulness is calculated by talking the walk scores of the locations that the transit network allows passengers to reach from that stop.  This value is further refined by penalizing based on travel time (the presence of a line that provides direct, quick service to a services-rich downtown will produce a higher walkscore).

A neat example of the joyful surprises of making transit data openly available occurred for Trillium and one of our clients, Redding Area Bus Authority (RABA), in this process.  Right after RABA made their GTFS data public, the one of the project developers, Brandon Martin-Anderson, used RABA data to test concepts and generate some transit score heat maps for a mid-sized agency.  You can see the results on the WalkScore wiki.