By now, you should have read the General Transit Feed Specification. Here are a few additional tips for preparing an optimal data feed.
General Transit Feed Specification has both required and optional fields. We recommend that you provide as much optional information as possible to enable Google to utilize your feed to its full potential. With that said, Stop_desc in stops.txt and Route_desc in routes.txt are not integrated in Google Transit. Please use your discretion to fill out these fields.
Here are a few highly recommend fields:
agency_phone in agencies.txt: Google displays the phone number in trip planner to help riders to get additional information.
agency_id in agencies.txt,routes.txt and fare_attributes.txt: agency_id is required in both files if agency.txt contains more than one record (i.e. feed has data for more than one agency). Otherwise remove it from the feed. In other words, if number of rows in agency.txt is no more than 2 (header and one agency), do not include agency_id field in any file because there's only one agency in the dataset so there's no need for agency_id. If number of rows in agency.txt is greater than 2, agency_id field is required. The agency_id field AND non-empty string values must exist in agency.txt, routes.txt, and fare_attributes.txt because there are 2 or more agencies in the data set, and we need the agency_id to distinguish which routes and fares belong to which agencies.
route_color in routes.txt: Google displays the route color in each station's pop up bubble. If your route is displayed in the transit layer, the color may also be used in transit layer. Please provide a color consistent with your published maps. Route color should be specified as a six-character hexadecimal number in the order of RGB. The route_text_color and route_color should 'be set to contrasting colors, as they are used as the text and background color (respectively) for displaying route names. When left blank, route_text_color defaults to 000000 (black) and route_color defaults to FFFFFF (white). A common source of issues here is setting route_color to a dark color, while leaving route_text_color set to black. In this case, route_text_color should 'be set to a lighter color like FFFFFF to ensure a legible contrast between the two.
Route color shown at each station and in Transit Layer
stop_URL in stops.txt: Each station is painted on Google Maps, and its station name can be searched as a place name. When users click on the station icon, they see a pop-up bubble with upcoming schedules. If you provide a stop URL, it is displayed in the bubble and overrides the agency URL. For example, If you click on bart.gov it goes to BART's Montgomery station URL instead of BART.gov home page which is the agency_URL.
location_type and parent_station in stops.txt: use these fields in the following cases:
Transfers.txt: This file defines the rules for making connections at transfer points between routes. For example, if you had a bus connection that is guaranteed, unless you provide the transfers.txt, Google Transit won't guarantee this transfer. Here are some common cases where an agency should use transfers.txt:
calendar_dates.txt: Most agencies have special service schedules for holidays. Using calendar_dates.txt is a quick way to define such special services. It's very common for agencies to remove dates from a service and to add the same dates to a different service. For example, if 12-25 falls on a weekday, an agency may remove 12-25 from its weekday service but add it into the weekend service. In other words, records in the calendar_dates.txt often come in remove/add pairs.
shapes.txt: Google uses this file to draw service routes on Google Maps. It is also used to display your routes in the transit layer. If shapes.txt is not provided, Google draws a straight line between two stops, which is not visually appealing. If you choose to use shapes, there must be a shape point within 30 meters of any stop on a trip. If a shape passes the same stop more than once during a trip (i.e., if there is a loop) and no shape_dis_traveled numbers are given in stop_times.txt, then it is necessary that earlier shape points are closer to the stop than later shape points.
Route with shapes.txt
Route without shapes.txt
Shapes with lots of looping or inlining do not display well on Google Maps. For such cases, the use of shape_dist_traveled field in both the stop_times.txt and shapes.txt is required. The shape_dist_traveled field allows the agency to specify exactly how the stops in the stop_times.txt file fit into their respective shape. A common value to use for the shape_dist_traveled field is the distance from the beginning of the shape as traveled by the vehicle (think something like an odometer reading). Please note this differs from the straight line distance as the straight line distance is not how the vehicle actually travels through the street network.
frequencies.txt: If the agency has trips that run on a regular interval (i.e., every 5 minutes), it may be easier to model a single trip and use frequencies.txt to indicate how often that trip runs. To do this, create an entry for the trip in trips.txt and in stop_times.txt provide the relative timings for the stops on that trip. This should include the sequence of stops, the time between each stop, and the time that the vehicle waits at each stop. To have this trip then repeated on a regular frequency during a specific period, include a line in frequencies.txt that references the trip_id, the period for which the frequency applies, and the number of seconds between departures from the first stop.
When describing your stops and routes, you should keep it succinct and consistent with the name and description you use in your own materials and signage. The rule of thumb is that stop names should not contain words like "station" or "stop". Route names should not contain words like "line" or "route".
Route names and stop names should be included in the local language. As the GTFS uses UTF-8 encoding, there should be no problem providing names in the appropriate language.
A route_short_name should usually be a number or short identifier. The route_short_name should not be duplicated in the route_long_name, as they are generally shown next to each other.
Before Google launches your data feed to the public, Google recommends that you test your information thoroughly using a set of tools and the private preview we provide.
Before the data feed is submitted to Google, use the Feed Validator to ensure that the data is formatted correctly. Data should also be checked using the Schedule Viewer and the KML Writer to make sure that the data makes sense and accurately reflects your services.
Once your feed is accepted by Google, we will provide a private preview for you to test the routing. We recommend that you invite people most familiar with your service, such as customer support, to test it.
Google also recommends that you use the google_random_queries program to generate an HTML file with a list of Google Transit trip queries. You can find examples/google_random_queries.py (for Linux users) in the transitfeed source distribution and google_random_queries.exe (for Windows users) in random-queries-windows.zip on the googletransitdatafeed download page. Like feedvalidator, this program takes a GTFS source file path on the command line and generates an HTML output, by default google_random_queries.html. Load the HTML file in your browser and follow the instructions at the top of the file. You may want to open 5 to 10 queries in different browser tabs to save flipping back and forth between the HTML and maps.
Here is a list of things you should check on your Google Maps preview in addition to your normal test cases:
Google's trip planner attempts to show a few different options for each routing request but may not find identical results to other trip planners. Google's algorithm tries to find the fastest trip to the destination with a slight penalty applied to extra transfers and walking. If you find a request where you can find a much better option in your data, please report it to us.
When reporting issues to Google, please include the link to the trip by clicking on "link" on top right corner of Google Maps. Since we are not familiar with the local area, please include as much detailed information as possible.
If you have multiple people testing the preview, you may want to create a generic gmail account such as agency_name.gt@gmail.com for people to share. You may also want to create an online spreadsheet for people to collaborate on bug reporting. Please give Google write access to this document so we can provide our feedback.
As the data publisher, you have the best information about your own services, and so Google trusts you to provide up-to-date and accurate information.
We recommend that you provide a feed that is valid for at least 4 weeks after your initial launch.
You should also provide an update as soon as you know the schedule change, but no later than 2 weeks before the new schedule takes effect. For example, if you have a new schedule effective on February 20, 2009, you need to provide the new feed to Google no later than February 6, 2009. Google accepts new feeds every day. Feeds provided by Friday will be refreshed on Google Maps by the following Friday. When you provide a new feed, it must have service as of the posting date. For example, if your posting date is February 6, 2009, your feed should include service from February 6 (or earlier) to February 19, and new service data from February 20. This is because we completely replace the previous data with the new data set. If your feed only includes service from February 20, when we completely replace your previous data on Friday 2/13, you won't have service on Google Maps for February 13 to February 19. If you prefer to create a feed with only the new service date, and the existing feed on Google Maps ends on the new service date, you can use the Merge tool to merge the 2 feeds.
To automate the data update process, you can host your data on an HTTP or HTTPS server for Google to fetch regularly (see hosting instructions).