To ensure continued service and accurate data is served to Google Transit users, General Transit Feed Specification (GTFS) modeling is required. GTFS modeling refers to designing static and realtime (RT) feeds to work together to convey the reality on the ground.
GTFS modeling basics
- GTFS Static Feeds: Requires 24–48 hours processing time after submitting to Google, although it can be delayed if Google detects issues in the feed.
GTFS Static is for premeditated schedule and transit design. You should provide your static feed to Google a minimum of 2 days in advance. However, a week ahead is ideal in case Google detects conflicts or suspicious issues with your feed that require human review. - GTFS Realtime Feeds: Updates provided to Google are reflected immediately.
GTFS Realtime is designed to provide realtime status over static data. It communicates delays through vehicle positions and trip updates for trips or stops predefined in static. It also provides service alerts (delays, service interruptions) to users. - While there are workarounds to activate and deactivate trips in GTFS, it's limited in that addition of undefined services (shape, stop sequence, stop times, route) in under 2 days (in realtime) isn't feasible. The addition of services takes 2–7+ days due to a human review process for conflicting or “suspicious” edits.
- In your static feed, you can use feed_info.txt to pre-determine (2–7+ days in advance) when static changes should go live, making sure to be consistent with your realtime feeds. Use the feed_start_date and feed_end_date fields to specify the dates that your static feed should be active. If the feed_start_date starts in the future (based on when we process it), we’ll still process that feed, but will keep both the current and “future” version.
- Static feeds contain core data on routes, stops, and trip scheduling, but as noted above, any changes to static feeds require anywhere from 2–7 days. The following are best practices for how to make scheduling changes.
Best practices to update your static & realtime feeds
Various transit changes occur within ground transportation services, including different durations, levels of urgency, and type of entity. Generally speaking, any changes to core data, including additions, modifications, or deletions of stops, routes, or trips should be performed in the static feed. However, for some changes, particularly temporary changes that need to be made reactively and quickly, there are some methods to achieve this in the realtime feed. Check the following tables for best practices to update the data in your feed.
Overall:
| Static (2–7+ days) | Realtime (~1 minute) | |
|---|---|---|
| Add data to the feed | Most changes are possible and straightforward. | In general, this isn't possible unless adding to an existing frequency with schedule_relationship. |
| Delete data from the feed | Significant deletions get flagged as suspicious, and may undergo longer review. | The realtime feed isn't suited for static deletions. However, alerts are encouraged for temporary deletions. |
| Modify data in the feed | Most changes are possible and straightforward. | Not supported or encouraged. |
More about realtime feeds
Important: Realtime modification of shapes or paths and core elements of static feeds aren't currently supported or encouraged.
Realtime addition and deletion is possible: To allow this, a sketch of the path, stop_sequence, and stop_time (a trip to model after) must exist in the static feed.
Creative use of calendar.txt and calendar_dates.txt is encouraged. For example, to capture snow days, specify trips that may not be “in service” but may be taken in the future in case of contingencies. In other words, define the trips beforehand. This enables a quick “RT-based disabling/enabling (default)” when the moment arrives.