We use cookies and other similar technologies (Cookies) to enhance your experience and to provide you with relevant content and ads. By using our website, you are agreeing to the use of Cookies. You can change your settings at any time. Cookie Policy.

Google Transit Trip Planning Service An “Open Source” of Information

Originally published March 6, 2007

The recent TransITech Conference in New Orleans was wonderful. The city was alive with the pre-Mardi Gras atmosphere, and the conference attendees got a taste of New Orleans – post Katrina. The buzz at this year’s conference centered around the latest trends in transit IT-related solutions, including interactive voice response (IVR), passenger notification and trip planning applications. One solution that had the center stage was the Google Transit  trip planning service currently under development by Google Labs.

In my previous article regarding Google Transit, I praised the idea as being revolutionary for fixed route transportation, giving passengers all over the world the ability to plan a trip (in this case, here in the United States) from a single portal. Google Labs is offering this free service to all transit agencies that are willing to participate. To date, the transit agencies that have signed up for Google Transit are Pittsburgh, PA; Portland and Eugene, OR; Duluth, MN; Seattle, WA; Burbank and Orange County, CA; and Honolulu, HI.

The results? After speaking with representatives from several transit agencies, so far so good. Google Transit is being viewed as a “win-win” situation for both parties. Transit agencies may increase ridership and fare box revenue by participating, and Google can increase its advertising revenue and highlight Google applications and GIS platforms. Google has mapped out the data feed requirements for most transit properties that are using CAD (computer aided dispatch), AVL (advance vehicle locator) and other vehicle and dispatch platforms. Agencies should be able to map their transit data to conform to Google requirements. The data feed requirements consist of both required and optional fields.

The required data files for Google transit are:

  • agency.txt: This file contains information about the transit agency.

  • stops.txt: This file contains information about individual locations where vehicles pick up or drop off passengers.

  • routes.txt: This file contains information about a transit organization's routes. A route is a sequence of two or more stops.

  • trips.txt: This file contains information about scheduled service along a particular route. Trips consist of two or more stops that are made at regularly scheduled intervals.

  • stop_times.txt: This file lists the times that a vehicle arrives at and departs from individual stops for each trip along a route.

  • calendar.txt: This file defines service categories. Each category indicates the days that the service starts and ends, as well as the days the service is available.

The optional data files for Google Transit are:

  • calendar_dates.txt: This file lists exceptions for the service categories defined in the calendar.txt file.

  • fare_attributes.txt: This file defines fare information for a transit organization's routes.

  • fare_rules.txt: This file defines the rules for applying fare information for a transit organization's routes.

  • shapes.txt: This file defines the rules for drawing lines on a map to represent a transit organization's routes.

The final criteria for data preparation for Google Transit is that agencies will need to save all files as comma-delimited text, filed names should be in lower case and are case sensitive, and field values should not contain HTML tags, comments or escape sequences. Finally, files should be encoded in UTF-8 to support all Unicode characters. Agencies' data-feed files are required to use the following naming conventions:

  • agency.txt
  • stops.txt
  • routes.txt
  • trips.txt
  • stop_times.txt
  • calendar.txt
  • calendar_dates.txt
  • fare_rules.txt
  • fare_attributes.txt
  • shapes.txt

Note: Transit agencies will need to ZIP and name the ZIP file google_transit.zip. Then, they need to post the ZIP file in a directory named YYYYMMDD (example: 20070212), where YYYYMMDD is the earliest date of valid service included in any of the files.

Most of the TransITech 2007 attendees that I spoke with were very excited about Google Transit, but some were still cautious – and for good reason. Unlike larger properties such as Portland, Seattle and Pittsburgh, some transit agencies, especially smaller ones, do not have the IT resources necessary to prepare their transit data to conform to Google data feed requirements.

However, all attendees were encouraged by the discussion of using open source as a process to extract and format the data as well as being able to rely on others' best practices as a guide to participating. Almost all of the panelists speaking at the conference were envisioning that open source would be the future for transit data extraction, data management, best practices and creation of transit IT communities.

Open Source
So what is open source? Under the “Open Source Definition” in Wikipedia, licenses must meet the following ten conditions in order to be considered open source licenses:

  1. Free redistribution: The software can be freely given away or sold. (This was intended to expand sharing and use of the software on a legal basis.)

  2. Source code: The source code must either be included or freely obtainable. (Without source code, making changes or modifications can be impossible.)

  3. Derived works: redistribution of modifications must be allowed (to allow legal sharing and to permit new features or repairs).

  4. Integrity of the author's source code: licenses may require that modifications are redistributed only as patches.

  5. No discrimination against persons or groups: No one can be locked out.

  6. No discrimination against fields of endeavor: Commercial users cannot be excluded.

  7. Distribution of license: The rights attached to the program must apply to all to whom the program is redistributed without the need for execution of an additional license by those parties.

  8. License must not be specific to a product: The program cannot be licensed only as part of a larger distribution.

  9. License must not restrict other software: The license cannot insist that any other software it is distributed with must also be open source.

  10. License must be technology-neutral: No click-wrap licenses or other medium-specific ways of accepting the license must be required.

Open source is gaining massive momentum in the transit sector for several reasons. First, it enables agencies to develop transit-specific applications. Second, agencies can share these applications with other agencies without encroaching on license restrictions. Finally, there is a lower total cost of ownership (TCO). Most attendees left the conference with the notion that open source is free. I would agree that there is the potential for industry collaboration, and I like the idea of creating transit communities to share applications and best practices. Who can argue with a lower cost of ownership? But free? Don’t get me wrong – I think there is a place for open source, but I think it involves potential challenges.

I spoke with one attendee who is the IT manager at a mid-market transit agency. I asked him to share his thoughts on open source. He was all too willing to share with me all the great things his staff has done in the last year with open source. “We were able to develop an application that would extract data from two operational systems [source], compare the data and import the data into a SQL database [target].” So I asked him if he was able to calculate the cost versus benefit? He shared that he and his staff saved his agency approximately $100,000 in software and outsource consulting cost.

I inquired further and asked about the time investment and how many staff members were required to complete the project. He explained that it took six months for six full-time resources to develop the application from beta to production. Well, I said to myself, that’s not free – so I did a little math of my own. Each full-time resource, assuming that the team was comprised of DBAs and application programmers, would cost the agency $65,000 per year plus benefits. Dividing the total annual salary [$65,000 x 6 = $390,000] of the six full-time resources by 12 to get the cost per month [$32,500], and then multiplying by the number of months [6] it took to develop the application, I came up with an estimated cost of $195,000+/- . The point I’m making here is that the cost of development versus a buy was considerable, so agencies will need to make sure they don’t get carried away with open source – it is not really free.

The other consideration regarding open source for transit is its scalability. Will applications being developed have the industrial strength to scale as transit transactional data and historical data continue to grow?

Finally, will transit agencies be able to perform analysis and reporting? This year’s conference covered data movement and formatting, but there was very little discussion regarding business intelligence.

Open source definitely has its advantages, and I encourage transit agencies not to rebuild something they can purchase at a much lower cost. Also, keep in mind that the data is no good to anyone if it can’t be accessed. And, most importantly, don’t forget the end users.

My next article will focus on port authorities.

  • Keith BoyerKeith Boyer

    Keith is the Founder, Chief Operating Officer and Chief Marketing Officer of Data Management Group, a consulting firm that focuses on business intelligence and custom-designed Web-based systems. Keith is responsible for all internal operations, sales, marketing and strategic alliances.

    Editor's note: More transportation articles, resources, news and events are available in the BeyeNETWORK's Transportation Channel. Be sure to visit today!

Recent articles by Keith Boyer



Want to post a comment? Login or become a member today!

Be the first to comment!