What Is a Useful Exercise for Inspecting a GTFS Table?
From the earlier reference collection. Read the current software blog.
A short inspection exercise can teach how a GTFS file's columns and rows express a transit dataset's concepts.
Choose one file and inspect its header
Start with one CSV file from a GTFS schedule dataset, such as stops.txt or routes.txt. Read the header row first and write down each field name in order. The header identifies the columns present in that file; it does not by itself explain every value or whether every field is required.
Keep the dataset's version or download source beside your notes. A table should be interpreted using the applicable specification and feed documentation, not solely from a familiar field name. This also makes the exercise repeatable if the producer later changes the dataset.
Select one record
Choose a single row and copy its values into a small working table with one column for field name and another for the row's value. Preserve the original text, including leading zeros and punctuation. Avoid opening and resaving the file in a tool that might silently reformat identifiers.
For each field, look up the definition in the GTFS reference. Note the expected type, whether the field is required or optional, and any relationship to another file. For a stop record, for example, ask whether its identifier is used elsewhere and what location information the row describes.
Trace a relationship
A table becomes easier to understand when one key is followed into another file. If you inspect a route, look for trips that refer to its route identifier; then inspect a relevant trip's stop_times records. The goal is not to reconstruct an entire journey but to see how identifiers connect rows across files.
Keep the row's literal values separate from your interpretation. If a code looks meaningful but the definition does not assign it that meaning, mark the interpretation as uncertain and check the dataset documentation. This habit prevents plausible guesses from becoming undocumented assumptions.
Write down what you learned
Record the file name, header, chosen row, field definitions, and any cross-file key you followed. Note questions the reference does not answer, such as producer-specific conventions. A short record of the exercise is useful when someone else repeats it or when you compare a later feed version.
The GTFS schedule reference defines file structure, field definitions, and presence conditions, so use it as the authoritative guide for the format. This exercise builds a practical reading habit: start from the header, inspect one concrete record, and map values to documented definitions before drawing conclusions.