Best practices follow logically from the specification but may not be obvious. Many are critical to avoiding nonsense.
GTFS And GTFS-R Always In Sync
Remember GTFS and GTFS-R are designed to work together and should always be a snapshot of your service. All data used by GTFS-R must always be contained in the dataset pointed to at the static GTFS URL.
If your static GTFS URL at any time does not contain data used by GTFS-R, expect real-time to stop working.
Always post new data in a merged dataset at your static URL that uses the same identifiers as your GTFS-R. Please remember that maintaining a snapshot is the only way software can track your schedules and work as a rule (GTFS is a cacheless specification).
If you run GTFS-R and publish a non-merged dataset early, the update will not be processed until the earliest date in calendar.txt or calendar_dates.txt of the new dataset (this is necessary to maintain GTFS and GTFS-R synchronization).
We have updated our system to track changing
route_ids, but any such system must rely on heuristics and will therefore not work as a rule. If you run GTFS-R, update your software to generate data that does not change
route_ids (and is therefore suitable for general application use).
Please remember to support the General Transit Feed Specication (GTFS).
Model your data as intended by the specficiation to include all trips in each calendar.txt entry with any modifications in calendar_dates.txt. If trips vary day to day, use the calendar dates only method.
Using the specification as intended means less work and a better user experience. See the GTFS documentation for the recommended approach.
Populate All Attributes
In general, populate all attributes if data is available. Code paths increase exponentially with each optional attribute and GTFS-R has many. You can promote quality software and the best possible user experience by simply populating all attributes.
TripDescriptor should always include
trip_id where available. Otherwise, scheduled times and direction may not be discernable and user experience will suffer in the extreme. In
current_status so stop predictions and trip inquiries can resolve to vehicles to the extent possible. Also, include
bearing for visual directional cues.
Don't Drop Past Events Too Soon
Don't drop past
StopTimeEvents too soon. If so, users could see a trip status showing vehicle departure as scheduled 15 minutes ago and the vehicle just leaving the station.
Update frequently to avoid appearing obsolete and prove you value on-time performance.
Update vehicle positions every 3-5 seconds so users can watch the vehicle approach and catch it in time. For example, passengers can move from a sheltered area to an outside stop just in time.
If your GTFS-R includes email auto-replies, be sure it responds to the
address header if present. Anti-abuse configurations for email servers often reject email sent from a different domain, which means relayed requests can't be
the user and responses must be sent to
If your system responds to the
address if present, mention it so feature support is known.
Publish Helpful Info
Publish other information that might be helpful to consuming applications, such as alert sources and types. It can be difficult to monitor publications to figure out what information is published where so it can be properly configured into a user interface. Also consider publishing information about the update frequency of vehicle locations and trip updates, non-abusive request frequencies, or any special or additional meaning attached to attributes.
Don't rely on the public to discover an outage. By that time there may be thousands of frustrated users. Maintain a notification system so you can discover outages and promptly restore service.