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.
Update .pb Files In A Background Process
The .pb files should be updated at an interval by a background service or process that is fully decoupled from GET or POST requests for the .pb file.
Updating .pb files in a separate process eliminates any latency issues. The service scales with high volume since no additional execution time is required per request.
The smaller the update interval the better the user experience, especially for vehicle locations. Use the smallest interval possible given your hardware resources.
For example, updating vehicle positions every 3-5 seconds allows users to watch and move from a sheltered area to the stop just in time.
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.
Post TripUpdate for Vehicles
If you follow best practices, treat a vehicle assignment as a trip update so predictions can be coupled to the vehicle even when it is "on time". It's also a pleasure to see the system is up and working and the trip is "on time".
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.
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.
Successful services always make sense. Fine tune your system. Watch and compare to confirm it never displays nonsense or contradicts itself. Final testing is where work pays of the most.
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.