How it happens:

When using blocks to describe linked trips by a vehicle, when one trip begins before the last one ends, an overlap occurs. Overlaps do not occur when the last stop time of one trip is the exact same as the first stop time of the next trip.

How to fix it:

Usually, an overlapping block indicates an error in the schedule - a bus cannot be in two places at once! - but it may also indicate that the schedule is not being faithful to the operations. When using blocks, trips must be exact if there are tight connections made between trips, or there is interlining between routes. Review the scheduled trips for accuracy, and if correct, confirm that the designated vehicle is expected to service both trips. If both are true, either the operational details must be adjusted, or the schedule must be corrected.

How it happens:

Different validation tools will have different benchmarks for what is determined to be an unreasonable speed between stops. Usually this is north of 75 mph, but may be lower in some cases.

This may also happen if there are multiple stops with identical stop times, since a bus cannot travel distance in 0 seconds.

How to fix it:

Review the schedule against the distance traveled - if a bus is traveling along a highway, it is not out of the question it may go 60 mph, but if it's traveling along a neighborhood road, it likely is not going that fast.

GTFS allows for fractions of minutes, so using seconds to denote time difference between multiple nearby stops may reduce the likelihood this warning crops up between stops with similar stop times.

In some cases, on-demand stops will create additional distance that is not usually covered by the bus in that amount of time. This warning can be ignored if that is the case, though riders will be impacted if the on-demand stop extends their trip significantly from what the schedule said.

If the stop times are 'aspirational' - meant to encourage riders but not feasible to achieve - consider the impact this has on riders when they arrive later than expected for reasons other than bad traffic. Too fast travel warnings help highlight areas in the schedule where the math and reality likely do not line up.

How it happens:

When stop times get out of order in a trip, it triggers a time travel error. Usually this happens when a stop time is mis-entered, but may also be an issue with a faulty schedule.

How to fix it:

Double check the stop times and their sequence to make sure they only get larger as the trip progresses. Depending on how the GTFS was made, the stop sequence may need to be updated to accurately reflect the order of stops in the trip.

If a trip travels across a timezone boundary, all stop times, regardless of stop location, should be in the same timezone as the agency (as described in agency.txt)

How it happens:

All trips must have their last stop have a stop time, even if the stop is on demand or does not have a scheduled stop time in public facing materials.

How to fix it:

Ensure the last stop of every trip has a stop time, even if it is an estimate or not publicly listed.

If the last stop is not a publicly accessible location, such as a bus barn, exclude those from the trip. Deadheads should not be in the GTFS unless they are explicitly there for use in a CAD/AVL system, and the stops are indicated with pickup and drop off restrictions as not available.

If the last stop is not serviced because the trip is actually a shortened version of previous trips (such as the last trip of the night not finishing the usual run), remove those stops from the trip. Stops should only be included in a trip when they are serviced, and if they are not serviced, they should be removed from the trip.

How it happens:

Depending on the validation software, stops that are between 3 and 6 meters may be considered 'too close' and should be combined into a single stop.

Note: If multiple stops are used at the same location to facilitate CAD/AVL predictions (such as one stop being for arrivals, and another for departures), this can usually be ignored.

How to fix it:

Make sure your stops are unique and not duplicative. Stops can be shared between routes, and with coordination, between agencies. When stops are in pairs, such as an inbound stop and an outbound stop across the street from each other, ensure they are in good locations for the rider, not the bus.

If stops are clustered at a transit center or depot, make sure to separate the stops to their actual location on the ground, and if necessary, use parent station - child stop assignments to organize the stops together.

How it happens:

When editing GTFS files using a tool like Microsoft Excel, it is important to not introduce empty rows or columns without headers. Because text files do not operate exactly the same as XLSX files, or even CSV files, extra columns and rows will cause the GTFS to fail validation.

How to fix it:

Use a text editing tool, like MS Notepad, to see if there is an extra comma in the header of the file. Similarly, you will be able to see if there are rows with no values (maybe just commas) at the bottom of the file.

When using Microsoft Excel or a similar program, make sure to use Delete, not Clear or Backspace to remove values from the file. Clear Contents, or the backspace key, leave the cell behind with no values. This gets interpreted as a valid entry (since GTFS files can contain blank values), but when it ends up applying to columns and rows, it will create issues when converting the files back into text files.

Learn more about handling the GTFS files.