Recently, I noticed that some of these issues were resolved.  Earlier, this trip was half walking directions.  Now, one of the results shows the option to take transit all the way to the destination.  See below.

Note, however, that we see the somewhat awkward display of an in-seat (stay on board) transfer to the same route, as the loop route continues through the top of it’s schedule here.  More on loop routes here.

At first, the data nerd in me liked this new feature. The new information presented is simple. It doesn’t take up much space in the interface. It is an interesting way to measure the journey.

But, as I’ve thought more, I’ve wondered what a passenger would do with this information. Comparing express vs. local services, for example, can be just as easily accomplished by looking at travel durations.

Any other ideas or comments?

The software aims to offer equivalent functionality to what Trillium already offers in the form of WebSchedule. However, TransitDataFeeder is different in several ways. Here’s more information about those differences, the project, and how this may potentially develop.

What is open source? What does that mean?
The “source code” of any software application is the DNA from which the working application is built. Open source means that this code is available, without cost, to anyone, for download, modification, and use. Stipulations for the use of the code, and modified versions of it, are spelled out in an open source license agreement. In the case of TransitDataFeeder, it is licensed under the Apache License 2.0.

Here’s what this means in plainer terms, specific to this project. Anyone can access the TransitDataFeeder source code. Using this code, it is possible to build and install the application. The application is written in Java, and needs JBoss and PostgreSQL installed. It requires some level of development experience, or at least understanding of software technologies, to execute this installation. More details on installation are in the project online discussion group.

New features are added, and bug fixes accomplished, by modifying the software code. These changes can be contributed back to the central source code repository for others to use and build upon.

Note that much of this activity will require the services of a professional developer to accomplish. This developer might be paid staff at a transit agency, or a consultant outside of the transit agency. Open source does not equal “cost-free.” To function well, the software requires support and maintenance. Open source software does, however, provide other benefits. It gives transit agencies more control over the software they use, enabling addition of features, bug fixes, and integration with other systems more readily. It helps transit agencies avoid vendor lock. Ultimately, open source software may potentially deliver improved value to transit agencies. For more on open source potential for transit agencies, read my interview with TriMet’s Chief Technology Officer and IT Manager for GIS and Location-based Services.

How did this project come about? What is its history?
The TransitDataFeeder (TDF) code and software is the end product of the Google Transit Data Tool for Small Agencies project, sponsored by the Transportation Research Board (TRB). Trillium designed the interface for the application and scoped its features. Software development was completed by our Portland-based neighbor SingleMind Consulting.

What’s happening now?
We’re wrapping up a pilot test. Several transit agencies participated in the proejct to use the TDF application to create GTFS. Trillium is currently helping them to use the produced GTFS to integrate data into Google Maps/Transit.

The software code is now available for those who wish to use it. The code is available at for download at the TDF project hub (Google Code). In addition, this site contains links to application documentation, project documents, and the open TransitDataFeeder discussion group.

Already, organizations are interested in, and beginning to use, the Transit Data Feeder code and application. One organization is goEuropa in Poland, which is also leveraging the OpenTripPlanner software for a regional online trip planner project.

As additional stakeholders and contributors engage in this ongoing open source software project, it is my hope that new features will be added. We actually went beyond the required scope in the delivered application features, but there are several features I hoped to include that could not be due to budget constraints. They are:

• Support for creating, maintaining, and exporting route alignments. If you’ve followed the Google Transit support groups, you’re aware of some of the issues and difficulties presented by supplying and maintaining the shapes.txt file, which describes route alignments. There are a few challenges: one route may include several travel patterns, each with a somewhat different travel path. For example, Trillium client Redwood Transit System’s Mainline route includes over 50 different travel patterns. Creating (and maintaining) the route alignment data for all those travel patterns using a brute force (manual) approach just isn’t feasible. It’s necessary to have easy-to-use tools to automate the process.
• Support for importing data. This feature, or set of features, would allow agencies to import a spreadsheet of stop locations, or even existing GTFS into the TransitDataFeeder.
• Bulk modification of data. Currently, it’s only possible to edit one record at a time. It would be useful to be able to select multiple records for bulk updates.
• Additional map-based data views. Currently, it’s only possible to view and edit one stop location at a time. In the future, I think it would be useful for the user to see and edit locations in a system-wide view.

Trillium plans to work with clients and partners to implement these features. We’ll keep you posted as new features are added.

How does my agency or organization (and our customers) and benefit and contribute?
Your agency can employ staff developers or consultants to install, use, and potentially improve on the TransitDataFeeder. If you are interested in the project, consider joining the TransitDataFeeder discussion group (Google Groups) to stay on top of the latest developments. If you would like to consider the TransitDataFeeder for your organization, contact Trillium to request a demo.

How does Trillium help transit agencies utilize and make the most of TransitDataFeeder?
Trillium plans to offer a hosted version of TransitDataFeeder. This means that we’ll turn on TransitDataFeeder for you on our server. There will be nothing for your agency to install. Trillium will handle updating the centrally-hosted software with new versions of the application to apply bug fixes and introduce new features. Part of this hosted service will be support services to help staff at client transit agencies use the software. If a transit agency client has specific needs or requirements the software needs to be modified to serve, Trillium is available for hire to design and develop the new feature.

Below, a screenshot of the TransitDataFeeder interface.

A Case for Open Data in Transit from Streetfilms on Vimeo.

Here’s from the filmmaker, Elizabeth Press:

Ever find yourself waiting for the next bus, not knowing when it will arrive? Think it would be great if you could check a subway countdown clock from the sidewalk? Or get arrival times on your phone? Giving transit riders better information can make ridng the bus or the train more convenient and appealing. And transit agencies are finding that the easiest and least expensive way to do it is by opening data about routes, schedules, and real-time locations to software developers, instead of guarding it like a proprietary secret.

I recently got the chance to dive into the topic of open data in transit with my colleagues at OpenPlans. We went up to Boston to see what transit riders got out of the transportation department’s decision to open up its data. We also talked to New York MTA Chair Jay Walder, City Council Member Gale Brewer, Zipcar co-founder Robin Chase, and Transportation Alternatives director Paul Steely White to paint a full picture of what it would mean if cities shared their transit and transportation data. The information is there, waiting to be put to use to help people plan transit trips, waste less gas driving, or make their streets safer.

If you look at almost any street map, a map designed for motorists or to give people a general sense of the shape of the city, you’ll see clear signals that the lines on the map are not all equal. A Google street map of this same area [referring to downtown Seattle], for example, uses simple line-weight and color to visually distinguish three classes of road: (a) freeways, (b) local arterials, and (c) other lesser streets. We all use this hierarchy to organize our understanding of the city, regardless of our means of travel.

If a street map for a city drew every road with the same kind of line and label, so that Interstate 5 looked no different from the smallest gravel cul-de-sac, we’d say it was a bad map. But it’s not wrong, the mapmaker would say! No, it’s not, but it’s misleading. If we can’t identify the major streets, we can’t see the basic shape of the city, and without that, we can’t really make use of the map’s information.

The process of learning any network — roads or transit or any kind of geography — begins with identifying a few features as major, and then understanding how the other features fit around those. If you’re looking a map of natural geography, you’ll notice the big rivers and mountains before you notice the small ones. If you’re looking at a highway map, you’ll understand the big highways first, and later, only as needed, you’ll study how lesser roads connect with those main highways. Transit customers and potential customers need the same ability to sort the mass of detail presented by a transit network.

So a transit map that makes all lines look equally important is like a road map that doesn’t show the difference between a freeway and a gravel road.

To show network frequency, Jarrett writes, many transit agencies have published frequent network maps. The examples he provides (TriMet’s frequent network map and L.A. Metro’s are some) are designed for print.

To my knowledge, there are not any maps designed specifically for the web that show frequency as a distinction of service. This seems somewhat surprising because, with source data becoming increasingly more available, it becomes possible to create a map application that shows services with greater service frequency, or which differentiates service frequency levels by colors or line thickness.

Let’s look at the most popular map application out there, Google Maps. In selected areas (mainly metropolitan areas where transit agencies provide data to Google), Google Maps offers a transit layer. The next screenshot shows where to find it.

Jarrett makes the point that internet trip planners mean that system maps are less important or necessary in many instances of trip planning.  However, the system map is still important for understanding a system and its role within the city and our lives.  Frequent and infrequent services are not distinguished in the Google Maps transit layer. Therefore it’s less easily possible to use this map to determine, for example, where to live or locate a business for access by frequent transit, or develop an understanding of how to use the system freely, without the aid of a trip planner.

Instead of distinguishing transit lines by frequency, Google Maps distinguishes lines by mode.  The screenshot above shows bus lines in blue, and light rail (update/correction: and street car) lines in a shade somewhere between maroon and lavender.  Presumably, the colors are set according to the route type specified in the GTFS data provided to Google.

Here’s an interesting choice: If we zoom farther out, we see only rail services.  In the screenshot below, we see Portland’s light rail lines in the lavender shade and the standard-gauge WES rail service in a pale green color.

The approach seems to work well enough with the current Portland example, but as more transit services are added to Google Maps/Transit, I foresee some limitations.  Here is one example: ODOT hired Trillium to publish GTFS for Oregon’s intercity bus network.  These bus routes span distances that are hundreds of miles.  Currently, if the services were shown in the transit layer (they are not), the services would only be shown when the user is zoomed fairly close in.  That’s not particularly useful; these intercity routes are the equivalent of highways in the road network.  Travelers want to see how they connect cities.

Therefore, I’d suggest that, instead of determining which services are shown at each zoom level by the vehicle type, Google Maps should determine this by the length of the route alignment.  If there was complete coverage (including Greyhound and Amtrak), this means that if the user is zoomed to the country level they would see the national bus and rail network.  Zooming in, she will see state and regional transit services.  Finally, zoomed into the city level, she will see local municipal routes.  And it is at this zoom level that it would be useful to have an indicator of the frequency of routes (either with line thickness or color) to better understand the local transit system.

Indeed, using information technology to facilitate ridesharing and transit usage appears to be a growing business that can make these low-carbon travel modes more convenient and attractive. “We’ve see an evolution in the technology,” said Aaron Antrim, president of Trillium Transit Solutions (Portland, Ore.), a three-per- son IT consulting firm that specializes in helping small- and medium-sized transit districts migrate their routes and schedules to Google Transit, the trip planner integrated in Google Maps that currently includes data for over 120 U.S. transit agencies.

“At first the iPhone could only plan driving trips, now it plans driving, transit and walking trips,” said Antrim. “Google Maps now includes biking directions, although that hasn’t shown up on the iPhone yet…. I think in the future mobile devices are going to become more and more powerful and useful for finding and comparing travel options, including transit, carpooling, walking, car-share, taxi, all the options, and compare them by cost and even greenhouse gas impact,” said Antrim. “Multimodal trip planning is going to be a killer app on mobile devices.”

Firms like Avego (Kinsale, Ireland) and Goose Networks (Seattle) are marketing web-enabled ride-matching and commute management programs. Avego sells a system that incentivizes drivers to pick up passengers along their route because passengers pay a per-mile fee to defray costs. Goose Networks sells software and services to organizations that want to measure and report the impact of their members commute activities.

There are many regional ridesharing and car/vanpooling websites and ser- vices such as San Luis Obispo County’s iRideshare.org, Rideshare.com which sells monthly vanpool commuting packages ($139 a month for a 50-mile roundtrip) in the Northeast and Zimride.com which is focused on college students.  And many people use Facebook or Twitter to find and share rides.

“There are many many different websites and companies out there, but few are really working because they’re not getting a critical mass of users,” said Antrim. “What successful companies like Goose Networks and Zimride have found is that they have to target a group of people with similar travel behavior, corporate campuses or educational institutions being the most common. They also need an external incentive or promotional program to sell the idea.” Antrim said the ridesharing business also needs a common data specification to allow potential users to find and compare their options from multiple services. “There are so many different sites and options that the user base is being divided up,” he said. “In fixed route transit, we have the General Transit Feed Specification for schedules, routes and fares. That doesn’t exist yet for carpooling.”

A post from February 2010 on Human Transit by Jarrett Walker, one of the smartest blogs on public transportation out there, asks if, and how, public transportation ridership data should be presented online.

A contact at TriMet asks Jarrett,

There is an internal TriMet web site, accessible to all TriMet employees, including drivers and mechanics, that has a wealth of information, such as budgets, ridership, etc. While all of this could potentially be misinterpreted, it seems to me that it should all be available to the public in a section of the public web site. I shouldn’t have to feel sneaky when I provide you with extracts from this material.

Here, here.  Open schedule and arrival information benefits customers because it enables the development of new applications to navigate and use the system.  Opening ridership information would offer its own benefits:

• Better informed public participation in the transit planning process (Jarrett also points out one of the potential hurdles here — where a public insists on network designs that prioritize productivity strongly over transportation equity and meeting needs)
• Helping taxpayers assess and understand the value they are receiving from their transit investment
• Providing the raw data to fuel software innovation in the same way that open schedule and arrival data has enabled applications like Google Transit, PDXBus, iBART, WalkScore, and so many more.  Here’s an example of a visualization of transit systems by size.  If more data was available, it might be possible to zoom into these agencies to see a breakdown by routes, modes, etc.

For more discussion, see Jarrett’s post “Email of the week: Should ridership data be online?”

Screenshot of iNap.

From EngineerScotty comes an idea for do-it-yourself automated stop announcements (ASA).  As a passenger, I find automated stop announcements quite helpful, as they are most often clearer, louder, and more consistently called than operator announcements.  Bus and train operators also appreciate ASA.  It is understandably difficult for them to pay attention to driving, traffic, and passengers and remember to call out regular announcements.

Even when there are automated announcements, I often use my iPhone to follow along a planned route to see where I need to pull the cord and get off the bus if I am unfamiliar with a city or transit route.  iNap is one application that develops this functionality.  It allows the user to set an alarm to be notified when their stop is near.

Since not every vehicle has ASA, EngineerScott ponders a hypothetical mobile application to call out the names of stops.  Drivers would plug their mobile device into the vehicle’s audio system.  I doubt there’s a sufficient market for this, however.  It would certainly present an interesting situation for agencies, with operators taking technology implementation into their own hands.

Read the full post, “Things that should be automated,” on the Dead Horse Times.

Transit trip planning in the rural areas of Northern California has become easier for many user groups as a result of the pilot implementation.  From Sue’s post:

“Trinity County has many recreational destinations,” a representative explained.  “Northern California visitors are now able to plan trips across this portion of California using multiple transit providers with ease.  This type of travel planning was once difficult, but is now simplified with Google Maps/Transit.”

Google Transit doesn’t just benefit the transit customer.  Social service agencies, caregivers, and those providing aid to someone can now Google transit information for their clients.  For the elderly who can no longer drive, Google transit information for bus stops and locations helps make it possible to  maintain a sense of independence.

The Northern California Google Transit Feasibility Study and Pilot Project was a finalist for the 2010 California Transportation Foundation Tranny Awards.

Here are some examples of the longer intercity itineraries that can now be planned on Google Transit:

LAX to Big Bear, California, across L.A. Metro, Metrolink, and Mountain Area Regional Transit Authority (MARTA). MARTA is a Trillium client.

Corning, CA to Sunsanville, CA via Tehama Rural Area Express (TRAX) and Susanville Indian Rancheria Public Transportation Program. Both are Trillium clients.

Clatsop County, OR to Salem, OR via Sunset Empire Transportation District, Tillamook County Transportation District (TCTD), TriMet, and South Metro Area Regional Transit (SMART). TCTD and SMART are Trillium clients.

Crescent City, CA to Cottonwood CA via Redwood Coast Transit (RCT), Redwood Transit System (RTS), Trinity Transit, and Redding Area Bus Authority (RABA). All agencies are Trillium clients.