Main Page

From GoogleTransitDataFeed

The GoogleTransitDataFeed Open Source Software project is an effort to develop and gather open source tools which generate transit data in the Google Transit data feed format from existing transit industry data formats. Our goal is to offer tools for transportation providers which enable them to participate in Google Transit. The following elements need to come into play before Google Transit can integrate transit system data from a transportation provider:

• The transportation provider agrees to the terms and conditions of Google Transit. Start here to initiate the process.
• Transit network and schedule data are "fed" to Google Transit. In a first step, a Google Transit data feed file set must be generated. In a second step, the file set must be "posted to the web", which means it needs to be hosted on a web server for upload to the Google Transit website.

Contents 1 How it works 2 Challenges 3 Feedback and contact 4 Where it's going

How it works

The first tool available from GoogleTransitDataFeed is a transformation from the TransXChange standard format to the Google Transit data feed format. The following steps are necessary:

• Download a transformation tool from the Google Code page for GoogleTransitDataFeed. The download and use of the programs is free - they are released under the Open Source Software license Apache License 2.0. There are currently two tools: The Transxchange2GoogleTransit transformation, and the Google feed validator and schedule viewer.
• Install and run the program for your input file(s). Windows and Linux are supported. This generates a Google Transit data feed file set. Details about installation of the program are described on the Download page. Instructions on the use of the programs are located on the user manual page.
• Upload the file set to a web server. The file sets can be hosted on any web server which is publicly accessible
• Establish your relationship with Google Transit
• Provide the web address (URL) of the data feed files on the webserver to Google Transit.

Challenges

While participation in Google Transit and licensing a GoogleTransitDataFeed tool from this web site are free of charge, it is likely a transportation provider will encounter a number of challenges which need resolution before a transit system can be integrated in Google Transit. This means effort on the part of the transportation provider. For the most part, these challenges exist in the quality of the transit system data. If a transit system database is already feeding data into a sophisticated downstream system like a Computer Aided Dispatch / Automatic Vehicle Location (CAD/AVL) system, it is likely that the level of data quality is already high enough to feed Google Transit without much additional effort. On the other hand, if the quality level is relatively low, a considerable effort might be required to acquire and maintain data needed for Google Transit. Possible challenges:

• Basic data acquisition. Google Transit requires either stop coordinates or geocoded addresses associated with stop locations. It might be necessary to hit the streets and acquire GPS coordinates, stop names, and establish procedures to maintain the acquired stop inventory to keep it current when service changes impact the transit network
• Data consistency and completeness. Route patterns and trips must be consistent, i.e. timepoints on trips running over route patterns must match timepoints of the route patterns. Missing stop names, route patterns and so on must be complete.
• Proprietary data formats. Proprietary data formats must be open to the extent that a transformation from these formats to a standard data format or directly to the Google Transit data format can be implemented. Refer to a discussion of transit data formats for additional information.

Note that this effort on the part of transportation providers can be beneficial beyond feeding data to Google Transit. It will also be helpful in supporting the installation and good performance of downstream systems like CAD/AVL, Automatic Passenger Counting (APC), Traffic Signal Priority (TSP) or wayside passenger information.

Feedback and contact

Feedback is welcome in the discussion section of each page. Contact Google Transit Data Feed:

Where it's going

• Server-side transformation. The v1.3 release of Transxchange2GoogleTransit provided the Transxchange2GoogleTransit transformation as a web application. Since v1.3, user authentication against a Mediawiki user database has been added. It is a mid term goal to host the web application on the web, and make the TransXChange transformation available to users without the requirement for tool installation on a user computer.
• Add transit data formats. TransXChange is the first data format featured by GoogleTransitDataFeed. There are more transit data standards, and a number of scheduling system specific (i.e. vendor specific) data formats. Some transportation providers maintain an organizational database which holds relevent transit data, e.g. GIS-based network data combined with scheduling system-based schedule data
• After talking to Google Labs and leading stakeholders in the transit industry, we identified the need for FOSS tools which will not only provide transformation tools, but also tools for data entry and maintenance which export the relevant transit data following the Google Transit Feed Specification. We hope to develop such tools to enable transportation providers to participate in Google Transit, while benefiting from FOSS and open industry standards to help improve transportation providers' capabilities in managing their transit data. The goal is to provide a tool which scaleable from a single computer installation to a hosted solution, based on a application server architecture with Apache Tomcat servlet container and AJAX.