Test a static feed in a private preview

Once you’ve uploaded a valid General Transit Feed Specification (GTFS) feed in the Transit Data Sharing Portal, you can activate a private preview to test feed scheduling and routing in a staging environment before releasing it to the public.

Share testing access

We recommend you invite people who are familiar with your transit service to test your preview data, such as customer support representatives.

Preview your GTFS data in Google Maps

1. Sign in to the Google Account associated with your Transit Data Sharing Portal account. (Create a new Google account.)
2. Visit Google Maps.
3. Test various queries in your area (e.g., station locations, schedules, and route shapes.)

If you have multiple people testing the preview, you may want to either create a generic Gmail account (such as <agency_name.gt>@gmail.com) for individuals to share, or associate a Google Account with your group's internal email alias.

Test your feeds

After you've accessed the private preview staging environment, you can query the feed data directly via the Google Transit "Get Directions" user interface.

Each "Get Directions" query will generate a few trip options labeled “Google Confidential” in red next to the results. These options use only your feed data.

You might see options that don't have the "Google Confidential" label attached: these options come from active data in other feeds. 

Every time you update your feed you’ll have to wait a few days for your preview data to refresh. Therefore, it's important that you fix as many problems as possible. 

In addition to your normal test cases, you should also check your private preview to ensure that:

• Route shapes for the trips match well with the roads on Google Maps

• The total time of the trips makes sense (for example, the bus doesn’t move too fast or too slowly)

• Both weekend and weekday trips are tested, using the Leave now drop down

• Transfers occur at appropriate places

Test different routing options

Google's trip planner is designed to show several different options for each routing request. However, it may not generate identical results to other trip planners. Google's algorithm tries to find the fastest trip to the destination, applying a slight penalty for extra transfers and walking.

If you find a request where your data shows a much better option than Google’s trip planner does, please report it to your Transit Partners support team. When reporting issues to Google, please include the link to the trip by clicking on the  button at the top left corner of Google Maps, and selecting "share or embed map." Since we aren’t familiar with the local area, please include as much detailed information as possible.

Note that routing data that is already live and available to the public is displayed as the first alternative, even if one of your routes in the preview is more suitable.

Test trips with transfers

As you test your feed preview, check that the transfers between trips make sense. Try some queries that will need transfers at the main transfer points in your network and see if the results are logical.

Keep the following points in mind when testing for transfers.

• Our routing algorithm considers transfer opportunities at the same stop and transfer opportunities that require walking from one stop to another.

• In both cases, our algorithm estimates a minimum transfer time (including a safety buffer) between arrival and departure, and accounts for any required walking. You may need to adjust our estimates for your particular data.

Also verify transfer times in major transfer stations where several lines meet or end, looking specifically at the difference between arrival and departure times. If you notice that our estimated minimum transfer time is too low (this is rare) or too high, you can fix this by providing a transfers.txt file (as explained in the GTFS spec) that describes transfer opportunities in your network.

Test your feed with random queries

Another way to test your feed is by using the random queries found in your GTFS validation report. The validation report Queries tab includes randomly generated Google Maps directions queries between pairs of stops in your feed. Use these queries to test and verify transit routing results for your feed, augmenting your own testing.

Quality assurance review

Once you have addressed any problematic warnings and are satisfied with the preview version of your GTFS feed, please contact your Google team so that we can perform a quality assurance review of your feed. We’ll report any potential issues that we find within your feed, and work together with you to resolve these issues.

Google requires a final launch review and approval before any GTFS feed launch.

Best practices for testing your private preview

Check your routes in preview on Google Maps

After you’ve verified the random queries, you can manually plan trips on Maps using the stops’ geo coordinates.

Generate a random trip

You can generate a sample trip that contains your data on the Queries tab on the validation report.

Plan a trip

Make sure you're signed in to the Transit Data Sharing Portal with your Google Account before manually testing.

To manually test a trip, follow these steps:

1. Open Maps.
2. Click Directions .
3. Click Transit .
4. Use the lat / long values of the stops to plan a trip. Keep the following in mind:
   • Station and stop names aren’t available for preview
   • Connections to existing bus / train / ferry services from other transit agencies aren't available
5. Test queries using the Leave now and Depart at options.

After a trip is planned

Routing results for the trip appear on a light pink background. This data is confidential and isn’t displayed to end users.

After the trip is planned, check the following details:

• Route short name / Route long name
• Stop time and date
• Stop name
• Travel duration
• Shapes (if provided)
• Agency name
• Agency url
• Agency phone number (if provided)  
• Fare information (if provided)
• Fare url

Make sure all the entities match the data provided on your website, and will be recognizable to end users.

The routing results are a visual representation of the fields displayed to end users.

Check your GTFS feed

Preliminary tests

• Service period: Make sure the service period is more than 28 days and less than 3 years.
• Coverage: Provide complete coverage. In case you’re providing limited coverage, notify us with a valid explanation in the checklist form.
• Validation warnings: Check and resolve the validation warnings on the Error tab in the most recently generated validation report

Detailed tests (GTFS files)

• Agency.txt: Agency information provided is correct and matches the agency’s website
  • Agency phone number and fare URLs are recommended to enhance user experience
• Calendar.txt: All the services with active days of the week included
• Calendar_dates.txt: 
  • Exception dates match the service period defined in calendar.txt
  • All the dates on which services are running differently (reduced / added) from the usual dates (like festival / gazetted holidays) are included
  • If your services run without service exceptions, ignore the "Feed has no calendar date exceptions" warning
• Routes.txt: 
  • Route names and color match agency’s website and are recognizable to end users

  • When both route_short_name and route_long_name are provided, end users will find route_short_name

  • Routes aren't split by direction
  • Route_urls are route-specific or not provided at all
• Trips.txt: 
  • Trip_headsigns provided indicate the correct direction of the trip and are recognizable to end users
  • Trip_headsigns don’t duplicate route names
  • Trip_headsigns are only defined for linear routes
  • Trip_short_names are only defined for route_type: heavy rail
  • Trip short name values are only defined for heavy rails or long-distance trains
• Stops.txt: 
  • Stop names look reasonable and match agency’s website
  • Stop names don’t include stop_codes (except Brazil)
  • Stop names can use abbreviations but need to be consistent
  • Stop locations are accurate (on correct side of the road, near the footpath)
  • Stop_codes, if provided, are available on the agency’s website and end users must be familiar with them
  • Stop urls are stop-specific
• Shapes.txt (optional but highly encouraged): 
  • Shapes accurately follow the roads / rails 
  • Shapes are provided for all trips and referenced by trips.txt file
  • Fix any validation warnings related to shapes.txt file
• Stop_times.txt: 
  • Stop times defined in feed should be available on the website and recognizable to the end users

  • Check pick up, drop off type, if defined

    pickup_type and pickup_type 2 (Must phone agency) and 3 (Must coordinate with driver) aren't supported.
  • For loop routes, stop_headsign must be defined at each stop
• Feed_info.txt: 
  • Feed Language defined in this file or in agency.txt
  • Compare start and end date with calendar files
• Validation warnings
  • No Stop Too Far From Shape warnings
  • No Stops Match Shape in Wrong Order warnings
  • No Too Many Consecutive Stop Times With Same Time warnings
  • No Overlapping Stop Times For Trips in Same Block warnings
  • No Feed Service Date Gap warnings
  • Stops in Wrong Timezone warnings
  • Route Color Contrast Warning warnings
  • Min Transfer Time is Missing warnings
  • Stop Headsign Duplicate Stop Name warnings
  • Point of Location Too Close To Origin (0,0) warnings

Submit your pre-launch checklist

After you’ve tested your feed according to the guidelines above and are satisfied with the routing results on Maps, you can go ahead and complete the pre-launch checklist form. Then, your submitted feed will undergo a quality analysis check.