Check for validation warnings

You get this warning when 2 trips that operate on the same day have frequency intervals that overlap with the same sequence of stops and times. This may mean you have duplicate trips in the feed or calendar entries that cause trips to start on the wrong day.

For example, you may create duplicate trips if you schedule a weekend service on a weekday that’s a holiday, but don’t disable the regular weekday service.

To fix this, verify that you correctly defined the service periods and exceptions.

You get this warning when you have a shape_dist_traveled value that doesn’t match the location of the stop along the shape. In some cases, the system can ignore the shape_dist_traveled value and match the stop to the shape. 

Review the problem instances and determine whether to completely remove the shape_dist_traveled values.

Try to represent a real-world stop with only one stop in the GTFS feed. In some schedule and routing systems, the same real-world stop is handled with different internal codes and defined in the feed multiple times.

Make sure the warnings aren’t because of bad stop locations or bad stop or station modeling. Stops with different names that are too close together can also indicate a problem.

The warning happens when 2 stops in the stops.txt file are too close to each other. This warning often implies that the stops are duplicates.

When 2 stops are very close, there’s a good chance they represent the same stop. Other warning triggers include:

• Stops with different names that are too close to one another
• Stops which are close but on different levels

Although this warning is common, it doesn’t automatically block the launch. The trip planner uses stop location to determine where to place a stop icon marker on the map. The marker represents the physical location where a passenger boards. Schedule and routing systems sometimes use different internal codes, defined multiple times in the GTFS feed, for the same stop.

To place a single map marker on one point, consolidate internal codes into a single stop location code for each unique geolocation. Ideally, a real-world stop should be represented by only 1 stop inside the GTFS feed. 

Review these warnings to make sure they’re not because of bad stop locations or incorrect stop modeling.

You get this warning when a stop in the stops.txt file is more than 100 meters but less than 1000 meters from its parent station, as linked through the parent_station column. The stop may not be part of the parent station complex.

• Ignore the warning if a subway entrance is far away from the center of its corresponding station.

Make sure you don’t have bad stop locations or bad stop or station modeling.

You may get this warning if you have an incorrect shape, wrong stop sequences, or wrong stop location.

Verify all stop locations are correct and that the shape matches the course of the corresponding trip.

Stops that aren't used by any trip in the feed aren’t processed further. Check that unused stop or station entries are intended and not caused by a problem in the feed.

A validation warning about unused stops or stations in a GTFS feed means there are entries in the stops.txt file that aren’t used by any entries in the stop_times.txt file. This means that no transit vehicles are scheduled to use that stop or station. 

It’s best for GTFS providers to leave stops or stations that aren’t served by any transit vehicles out of their feeds. A rider might be confused if one of these entries shows up on a map or in search results. 

When you resolve "Unused stop" or "Unused station" validation warnings, check whether:

• Transit vehicles should be scheduled to use that stop or station. There may be a problem with entries in the stop_times.txt file, such as the stop being incorrectly excluded from the trip or stop pattern of a route.
• The stop or station is no longer in service. If it isn’t in service, it may be best to remove it from the feed.

• You have corresponding entries in the stop_times.txt file. Usually, when you use the stop-station hierarchy in a GTFS feed, station entries (stops with a location_type of 1) don’t correspond to the file. If a station entry doesn’t have the correct location_type value, the feed validator considers it a regular stop and warns that it’s not used.

A block trip implies that passengers can remain on a vehicle to transfer from one route to the next. If the route_type changes, either the block or the route_type is incorrectly defined.

You must fix this problem.

The trip_headsign displays together with the route_short_name field. This prevents routing results like “1 towards 1 Central Terminal.”

The information between the headsign and name must be unique.

You get this warning when you have an incorrect stop_headsign. Correct stop_headsign for loop trips is the next stop. Trips must have at least one stop with the correct headsign.

For example, "Zoo" may be the headsign from the train hub to the zoo, however on the return trip this should become "Train hub" to indicate the new destination.

You get this warning when 2 trips operate on the same day with the same sequence of stops and arrival or departure times. This may mean you have duplicate trips in the feed or misconfigured calendar entries that cause trips to activate on the wrong day. Verify the correct definition of service periods and exceptions.

For example, you may create duplicate trips if you schedule a weekend service but don’t disable the regular weekday service.