To ensure that information about your transit schedule is accurate, you need to keep your static feed up to date.
Maintain continuous coverage
You receive an email if your feed is going to expire soon. We recommend that you upload a new feed with extended service coverage. Access the Transit partner dashboard and configure your notifications to ensure that you receive these emails.
The auto-extension feature allows Google Transit to extend the end date of an expired static feed. This helps maintain continuous coverage of transit services that expire soon.
Period of validity of your feed
To help you keep your static feed up to date, Google recommends these practices:
Always provide the dates of your feeds
The start and end dates of your feed are based on the feed_start_date and feed_end_date in feed_info.txt. To avoid unintentional service coverage gaps or extensions, make sure that both the feed_start_date and feed_end_date are provided explicitly in the feed_info.txt file.
feed_end_date isn't explicitly populated, but is close to its expiration date, Google Transit will try to deduce it based on individual service dates in the feed.Ensure coverage between feed_start_date and feed_end_date is at least 28 days
The service should cover at least 4 weeks from the day when the data is available to Google Transit or feed_start_date, whichever is latest.
Use calendar.txt for scheduled services
Important: Scheduled services include but not exclusively refer to year-round services. These services can run for extended periods of time. Use the calendar.txt file to define the scheduled services. To define exceptions to the regular schedule, use calendar_dates.txt only. Avoid the use of calendar_dates.txt to define services that run for extended periods of time.
If the feed doesn’t receive updates before the feed_end_date, Google may automatically extend the feed services beyond the end date to ensure continuous coverage. Read more about the auto-extension functionality.
The auto-extension is the last resort and might result in out-of-date schedules. To ensure that service schedules stay up-to-date, provide an updated version of your feed well before the feed_end_date.
Avoid gaps in service
Service information in calendar.txt that starts after the feed_start_date or ends before the feed_end_date may result in coverage gaps.
The start of service coverage in calendar.txt after the feed_start_date is treated as an intentionally late start of a temporary or seasonal service. The end of service coverage in calendar.txt at least one week prior to feed_end_date of your feed is treated as an intentional termination of a temporary or seasonal service.
If the gap between the end of service in calendar.txt and the end date of your feed is less than one week, Google uses its own criteria to decide whether to continue or stop the service.
To ensure intentional termination of a seasonal or temporary service, adjust the termination date of your feed so that there’s a gap of at least one week between it and the date in calendar.txt. You can also make an update to your feed with extended coverage dates available later, well ahead of the service termination.
Define a feed_end_date no later than the end of valid service as defined in the calendar.txt file, unless there are no services available between these dates. The same restrictions apply if your feed_start_date is earlier than the start of valid service information as defined in the calendar.txt file. This would create a gap in coverage for that extra period. Google Transit might also reject the feed in this case, based on the size of the loss or whether the previous version had coverage.
Extend the feed expiration date
Important:
- When a feed expires, Google may automatically extend the services based on the assumption that most schedules continue the same as before. Google doesn’t extend services that end at least a week earlier than the feed expiration date.
- In case the expired routes disappear from Google Maps search results, try to update the static feed and upload a new version. If you encounter unusual routing results because of an auto-extension, contact the Google Transit Support Team.
Control the auto-extension
To control the way auto-extension works, define a feed_start_date and feed_end_date in the feed_info.txt file.
In some cases, like a seasonal service, the deduced majority end date might not correctly reflect when the feed is valid. A service like this can end before the latest service end date and doesn’t need to be automatically extended. If you have a seasonal service but don’t want auto-extension, we recommend that you make your feed_end_date greater than one week after the service_end_date.
Examples
Example of a feed with five winter-only routes and one route that operates throughout the year.
routes.txt:
route_id,route_short_name,route_long_name,route_desc,route_type,route_color
1,,Winter Route,,3,
2,,Winter Route,,3,
3,,Winter Route,,3,
4,,Winter Route,,3,
5,,Winter Route,,3,
a,,Regular Route,,3,
calendar.txt:
service_id,monday,tuesday,wednesday,thursday,friday,saturday,sunday,start_date,end_date
1,1,1,1,1,1,1,1,20211001,20220430
1,1,1,1,1,1,1,1,20211101,20220331
2,1,1,1,1,1,1,1,20211101,20220331
3,1,1,1,1,1,1,1,20211101,20220331
4,1,1,1,1,1,1,1,20211101,20220331
5,1,1,1,1,1,1,1,20211101,20220331
The following table summarizes the various start and end dates for this feed:
Latest start_date in calendar.txt |
20211001 |
Latest end_date in calendar.txt |
20220430 |
| Deduced start date | 20211101 |
| Deduced end date | 20220331 |
Feed_start_date in feed_info.txt |
20211001 |
Feed_end_date in feed_info.txt |
20220430 |
With this configuration, Google shows that the winter routes (1, 2, 3, 4, 5) won’t operate after 2022-03-31 (March 31, 2022). Without the feed_end_date, we use the deduced end date 2022-03-31 and extend the winter routes indefinitely.