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.

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.)

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.

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

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.