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.
Northern California Google Transit Feasibility Study and Pilot project
Last month, the Shasta County Regional Transportation Planning Agency accepted Trillium’s Northern California Google Transit Feasibility Study.
The document is the culmination of a project begun in January 2009 to pilot rural Northern California transit agencies in Google Transit. Currently, Redding Area Bus Authority is live in Google Transit. Several neighboring agencies are in the Google Transit launch pipeline.
The project was funded by the Caltrans Division of Mass Transportation in response to a recommendation in the state’s March 2008 Rural Intercity Bus Study to explore Google Transit as a way of enhancing information dissemination for inter-city transportation services. The goal of this recommendation is to make connections between services easier for passengers to find and use.
The study was commissioned to:
- Investigate, and make progress towards overcoming, present limitations of Google Transit for rural areas and small agencies (see Chapter 3. “Trip planner pilot”)
- Inventory and describe ways in which transit agencies can put Google Transit feed data to other uses besides trip planning in Google Maps. (see Chapter 5. “Opportunities to leverage GTFS”)
- Inventory methods of publishing and maintaining Google Transit feed data for rural agencies. (See Chapter 4. “Google Transit feed publishing tools”)
- Make progress towards integrating traveler information, through Google Transit and Google Transit source data, into 2-1-1 human services and information referral programs. (See Chapter 6. “Implementation plan”)
Highlights of the findings are encapsulated in the Executive Summary. We hope and expect that this work helps broaden participation by rural and intercity California transportation in Google Transit.
Quick — when is the next bus scheduled to arrive?
Recently, I visited the San Francisco Bay Area. My friend Andrea, who lives in Berkeley, pointed out the inconvenience of transit timetables that separate all the scheduled departures by line. If there are multiple lines that travel to some of the same locations, the passenger just wants to look up ALL of the next opportunities to catch a bus, not just those for one particular line (to see an example of why you’d want to look up information this way, look at Lines 52L and 51 around the Downtown Berkeley BART in the AC Transit system map). Andrea says that in Germany, information posted at a stop lists all arrival/departure times in order, with the line shown in the next column.
Here's how AC Transit shows arrivals and departures on a stop pole.
I believe this is a Indian timetable that gives a bit of a taste. The colors indicate day of service here, but they could also indicate line.
Trillium experimented with a similar approach for Redwood Transit System online. However, RTS is not really a multi-line system.
Can anyone help me find examples of German timetables?
More details on the timetable in India here. See more on how Trillium implemented this format for timetable information for Redwood Transit System in the blog post “Avoid information overload with schedules for riders’ favorite stops”.
Notebook from World Intelligent Transportation Systems Congress
About two weeks ago, on September 22nd, I spoke at and attended the World ITS Congress in Stockholm, Sweden.
Usually, my audience and colleagues are managers, staff, and consultants for rural, small, and mid-sized transportation U.S. transit agencies. Speaking at, and attending an international conference of broad scope was a different experience for me.
I thought I’d share some highlight observations:
- With regards to transportation, I was far more inspired by the experience of using SL, Stockholm’s public transportation system, than I was by the congress itself. SL demonstrated what I didn’t even know was possible with public transportation. In what is actually the fairly small metro area of Stockholm (roughly 2 million residents, similar to Portland), SL provides service to 750,000 passengers daily (some making multiple trips). Public transit claims approximately 40% transport modeshare. All vehicles are quiet, clean, and fast. Routes operate with very high frequency.
The SL vision and mission statements show some of attitudes, priorities, and goals underpinning these achievements. The vision: “SL brings greater ease and convenience to day-to-day life and contributes to a more attractive Stockholm region.” SL’s mission includes providing attractive public transit. Attractive, as in, “this service attracts me to use it even though I have other options because it is fast, easy, and pleasant to use.” They see static and electronic signage, and online and printed customer information as playing a significant role in making public transportation attractive, though the agency is lagging behind U.S. counterparts in engaging partners to provide this customer information (more later). - Panelists in my session, “Using Social Networking Websites and Google: New Ways of Attracting Public Transport Riders,” almost all made open data the prominent theme in their presentations and discussion, and without any coordination among panelists beforehand. That’s a sign, I think, of the importance, and growing profile of this topic. The fellow from SL, Elias Arnestrand, who presented after me, gave a very candid and interesting snapshot of where SL is in their thinking and practice of sharing data, and, I think, provided a good window into the mind and approach of many European agencies. He said, essentially, that SL does see partner content providers as an opportunity to provide information to customers in new ways. However, SL has invested significantly in technology to deliver customer information and is reluctant to take steps which they see may compromise that legacy investment. In addition, SL takes providing reliable information very seriously, and so they’re concerned that giving up some of that control may compromise the SL brand and customer experience. However, the reality is that the demand for open data is mounting, and so refusing to take the steps down that path could open the agency to public relations debacles. Essentially, the agency has recognized they have no choice, so they are taking cautious steps towards engaging partners — probably just a few select partners at first, and potentially opening up further if that goes well.
I found the general caution I sensed in Europe around open data interesting in a few ways. It enhanced my appreciation of the Obama administration’s push for open data. I believe the Federal government’s policy is setting the correct tone and encouraging more forward-thinking policy and practice throughout the U.S. I also perceived that European agencies (of all types, not just transportation) are wary to private companies generating revenue off their public data. I tend more to agree with what I think and hope is a prevailing U.S. attitude, which is that this is perfectly legitimate for a private company to earn revenue from using public data, as long as they are providing some additional value from the data as well (and how can they earn revenue if they are not?). A vibrant market and competition in the online transportation information space will help the public more than a public agency making a couple bucks off the sale of data.
What I perceive is happening with European agencies here is somewhat akin to what sometimes happens developed nations as compared to developing nations in the adoption of new technology. Whereas in the U.S. we have billions of dollars invested in old copper-wire communications networks and outdated wireless networks, when a developing nation installs communications networks they are sometimes able to leapfrog the legacy technologies developed nations are saddled with and committed to. European transportation agencies have invested a lot in journey planners and customer information for transit. To embrace an approach with partner content providers probably feels as if they are compromising systems they’re already heavily invested in. Even though public transportation in the U.S. is very far behind Europe, I believe the approach many U.S. transit agencies are beginning to take in embracing third-party developers is more advanced and forward-thinking, and that we’ll see Europe follow along. - Somewhat disappointing was the World ITS Congress’s strong emphasis on technology for roads and cars, instead of seeing more multi-modal ITS for public transit, and even for bicycle and pedestrian way-finding and infrastructure planning, etc. I guess that’s a sign of the state of things, though. Even with Detroit going bankrupt, the auto-centric way of doing things still has, by far, the most power and largest pot of money.
Here’s the slidedeck from my presentation:
I love the grade-separated bike lanes inside of parked cars.
Modern transit facilities and old architecture co-exist quite nicely.
The lobby of SL's headquarters. It's a airy, beautiful building with a soaring atrium. Can you imagine a U.S. public transportation agency with HQ like this? SL says it's to attract the best talent.
Great transit contributes visibly to quality of life. In dense central districts, like here on Södermalm, streets are quiet and crowded with pedestrians.
The proximity-read transit passes made using transit a lot faster and easier.
People of every means take the bus. This one is very crowded!
Overnight transfers in Google Transit
I’m not sure, but I think that until recently Google Transit did not return trips with overnight, or very long, layovers. The introduction of overnight layovers will be very useful for planning trips on inter-city services.
Here’s an example of a trip with an overnight layover in the SF Bay Area.
Now, this trip caused some confusion on the Google Transit trip planner group. Without the red highlighting I added, it’s not obvious that one should stay overnight to wait for the morning Caltrain.
Airline itineraries frequently arrive and depart on different days. Here are some examples of how airline websites and travel aggregation sites have made it clearer when trips arrive and depart on different days.
Kayak.com:
United.com:
I like how Kayak spells out “This flight leaves Thursday and arrives on Friday,” but it is confusing that this messagedoes not appear with flight it concerns, flight 850 from Calgary to Heathrow. I guess this association is made by how arrival and departure times are also highlighted in the same red as the “Thursday/Friday” message.
I think it would be clearer for the Kayak message to read “This itinerary leaves on Thursday and arrives on Friday.” A similar message could be added in the Google Transit UI where it currently says “Showing Trip 1… Travel time: about 13 hours 20 minutes.” I also like United’s way of highlighting individual travel legs with next day arrivals “Arrives next day.” A message like this could be useful to highlight overnight trips. Or, including a date with arrival/depart times after travel times roll over to another day.
Tom Vanderbilt on how the iPhone and its ilk will change transportation
Tom Vanderbilt, author of Traffic: Why we drive the way we do just published iTransport, inventorying the most promising transportation apps for driving, parking, biking, transit and walking in Slate.
“Transportation is civilization,” Rudyard Kipling once wrote. Today we’re more inclined to express this equation with words like mobility and accessibility, but the spirit’s the same: The flow of people and goods (”traffic and all that it implies,” per Kipling) makes the world hum. But transit can feel uncivilized: We sit in congestion (wishing for the path less taken); we miss trains; we hunt for good places to park a car or a bike; we get lost.
Enter the iPhone. One of the device’s greatest areas of promise is as a transportation tool. Rival smartphones, of course, are equipped with GPS, Internet access, etc., but none corral quite so many of the features that delight transpo geeks (an accelerometer, a compass, etc.) into one device. And rival phones can only envy the iPhone’s flourishing app market, which includes some 65,000 options, many at least peripherally related to transportation (that is, if you include parallel parking games and the like).
SF Bay ferry services live on Google Transit
On Friday, the San Francisco ferry services went live on Google Transit. Now, travelers can plan inter-agency trips across BART, Muni, AC Transit and other services along with the five ferry services: Golden Gate Ferry, Baylink, Oakland/Alameda Ferry, Alameda Harbor Bay Ferry, and Blue & Gold Fleet at maps.google.com or an iPhone, iPod touch, or other mobile device like a Blackberry or Android-based phone.
Trillium publishes the GTFS for the ferry services with the support of Bay Crossings. We’re experimenting with ways of consolidating the management and dissemination of schedule information for customers. Currently, information from a centralized database, manipulated through Trillium’s WebSchedule is presented through the published GTFS for Google Transit, the SF Bay Ferries map at baycrossings.com, and the large flat panel display of scheduled ferry arrivals and departures at the San Francisco Bay Ferry Building Bay Crossings store location.
UC Berkeley Bear Transit schedules and multi-modal transportation map
This weekend, UC Berkeley launched new features on their Parking & Transportation website to help people use campus shuttles and bike and car parking infrastructure.
Trillium built these new features for Quiddities Dev, Inc., the firm that has produced UC Berkeley Parking & Transportations’s Drupal-powered website. Sidenote: I met the CEO of Quiddities at a TransitCamp Bay Area in 2008. Thanks, TransitCamp!
So, here’s some of what I think is worth sharing out of the new features.
1.) Trillium used the open-source TimeTable Publisher to create some very nice looking timetables in both vertical and horizontal layouts (for accessibility) from the Google Transit Feed Spec (GTFS) data for Bear Transit schedule and geographic information. Thanks, TriMet, for making TimeTable Publisher free and open source!
All the timetables are linked from the Shuttle Schedules page.
2.) Again, re-using a lot of the data used for GTFS production, we delivered a multi-modal online transportation map. The map shows all shuttle route alignments and stops for selected routes. If the user clicks a stop, it shows all the scheduled service at the parti
Open data roundup
Bits are flying in the open transit data discussion. Maybe I am biased, but it appears that a consensus is growing that free, readily-available, standards-based transit data is good for citizens, passengers and transit agencies.
Here’s a roundup of recent coverage. Sorry I haven’t been posting more; I’ve been very busy helping more agencies join Google Transit.
- I Bus, I Bike, iPhone: The Portland weekly newsrag, the Mercury, covers how TriMet’s pioneering in open data has made transit data available in more places on the web and in mobile devices.
- Who owns transit data? CNET compares the NY MTA, San Francisco MUNI, and Portland TriMet approaches to sharing schedule and arrival data.
- Does NextBus own MUNI real-time arrival times? Streetsblog San Francisco jumps into the very public discussion about/between Routesy, the NextBuses, Apple, and SF MUNI about who owns predicted bus arrivals.
- Muni App Makers, Rejoice: MTA, Apple Disputes Private Company’s Claims To Own Arrival Data: This story was well covered by the SF Appeal. It’s cool when geeky topics get this kind of coverage (ditto for the TriMet story in the Mercury).
- The Open Planning Project had a meetup on getting more open data (specifically for NYC) and put their notes online.
