About the Validator

Are the validation checks the same between the Google Feed Validator and the ones provided by the Reflect GTFS Validator site?
The checks run by the two validators are largely the same, but not identical. You can see a comparison between the gtfs-lib library used by Reflect and the Google Feed Validator here and review the list of items checked by the Google Feed Validator here.

Does the GTFS Validator validate GTFS-flex feeds?

The GTFS-flex extensions to GTFS are not validated by Reflect. As a result, if you attempt to validate a GTFS feed that uses the GTFS-flex extensions, you may see “Referential Integrity” and other errors in your results. Interpretation of results is described in more detail below.

Interpreting results

What is the signficance of “Low”, “Medium”, and “High” severity errors?
The Conveyal gtfs-lib validator defines these errors in the following ways:

• High: Something that is likely to break routing results, e.g., e.g. stop times out of sequence or high-speed travel.
• Medium: Something that is likely to break display, but still give accurate routing results, e.g. broken shapes or route long name containing route short name.
• Low: Something that will not affect user experience but should be corrected as time permits, e.g. unused stops.

What do the columns of the results table mean?
Each row corresponds to a single issue.

• error_id: The unique identifier for each error in the table, such as ‘1’.
• error_name: The type of error obtained, such as ‘Stop unused’.
• message: A more detailed description of the error, such as “This stop is not referenced by any trips”.
• priority: The significance of the error obtained, such as Low, Medium, or High. For more details, see “What is the signficance of “Low”, “Medium”, and “High” severity errors?” above.
• entity_type: A table within the GTFS feed relevant to the issue, generally speaking (e.g., “Trip” corresponds to “trips.txt”). In some cases, this entity refers to a cross-cutting relationship, such as a “Pattern” defined as a set of stop sequences. In other cases this column may be blank if it does not directly apply to a specific table or entity (e.g., the error “No service on a date” with message “No service_ids were active on a date within the range of dates with defined service.”).
• entity_id : This is generally the primary key field found in the given table. For instance, if the entity_type is “Trip”, the entity_id refers to the “trip_id” found in that table.
• entity_sequence: This most often refers to the sequence of a stop within a trip when issues are found within the stop_times table. For instance, in the error “Timepoint missing times”, the entity_type of “StopTime” is found; entity_id will reference the trip_id related to the issue, entity_sequence will refer to the sequence value (e.g., “3”) of a stop at issue within the trip.
• line_number: Given an entity_type that refers to a particular GTFS table (e.g., “Stop” for “stops.txt”), the row number (inclusive of the first-row header) that the error is found on.
• bad_value: If relevant, the value for the given GTFS table row that is at issue. This may be the entity_id referenced earlier or another value, such as the calculated speed between two stops when the validator detects that the vehicle is moving very quickly between two stops.
• related_routes: If relevant, the related route_short_name(s) associated with the error, with the agency_name provided in parentheses. Though a particular error may not be related to the route or agency table, identifying a related route by name may assist with addressing the underlying problem. If the route_short_name or agency_name fields are blank or cannot be associated with the given entity_id, placeholder values may be inserted.