How Should a GTFS Consumer Treat Optional Fields?
From the earlier reference collection. Read the current software blog.
A robust GTFS consumer follows each field’s stated presence condition and handles valid omission without inventing a replacement value.
Optional means omission can be valid
A data consumer should not assume that every field mentioned in a specification appears in every valid dataset. GTFS distinguishes required, optional, and conditionally required or forbidden elements. An optional file may be omitted; an optional field may be absent from a table’s header. A consumer that treats every known field as mandatory can reject a valid feed or fail before it reaches the information it actually needs.
Check the current definition for each field
Presence is field-specific. A consumer should consult the current reference to learn whether a field is required, what condition makes it applicable, and what its values mean. A header can be present while a particular cell is empty, so software should also follow the field’s value rules rather than equating column existence with usable data. This distinction is important for parsing, validation, and downstream display.
For instance, code reading a table can first inspect the header, then handle a permitted absent column as unavailable. If the field is present but a row’s value is empty, the consumer should apply the defined fallback or omission behavior, if one exists. It should not silently substitute an unrelated value.
Design a parser around graceful absence
A practical parser can represent optional information explicitly as present, absent, or empty where those states matter. That makes later decisions easier: a map can omit an unavailable descriptive detail, while a validator can report a missing required field as an error. Avoid using a plausible default such as a zero coordinate, blank identifier, or guessed label unless the specification defines that behavior; a fabricated value can make bad data look valid.
When a feature depends on a conditionally required field, verify that condition before processing the feature. This avoids both rejecting datasets that do not use the feature and accepting incomplete data when they do.
Keep compatibility checks focused
Unknown fields may appear as a specification evolves or a producer adds permitted information. A consumer should follow the format’s documented compatibility guidance and avoid failing solely because it encounters an unrecognized column, unless its role requires strict validation. At the same time, it must not treat an unknown field as if its meaning were understood. The GTFS reference explains presence conditions and field definitions; using those definitions lets software tolerate valid variation while reporting missing required data precisely.