Why is it recommeded that short term service modifications are excluded from GTFS?

[doconnoronca]

The GTFS specification reference says, "If a service modification will go into effect in 7 days or fewer, this service change should be expressed through a GTFS-realtime feed (service advisories or trip updates) rather than static GTFS dataset."

I was wondering what was the justification for that is? It seems to me that including modifications, even if just effects one stop on one trip that you know in advance, would be useful to both trip planners and arrival predictions.

The only reason I can think of is that people using trip planners might wrongly assume that is how the route normally operates. This could be addressed by added an indicator that it is modified service.

[timMillet]

Transit follows this rule and has included it in its Guidelines for producing GTFS static data for Transit's partners.

The main reason is GTFS data consumption is not an instantaneous process. At best it can take a couple of hours, but it can certainly take longer. Moreover, errors might occur (either in data production or data consumption) and this will require human intervention (and hence, some time) to resolve them. At a scale where a trip-planner application consumes hundreds of datasets, it happens every day. Having a few days as a buffer time between the moment the dataset is released and the moment the schedules are active helps a lot in displaying the new schedules on time, any time. We are not against consuming changes last-minute but IMHO, it shouldn't be the golden rule and should be reserved for urgent fixes.

[skinkie]

@doconnoronca think about the situation where a producer has to maintain multiple GTFS-RT publications, while there is currently no recommendation to resolve the GTFS-RT URL for a specific version of the feed. If you as a producer assume that with publishing the latest version of your timetable has been exported, and therefore will not include any alterations in your GTFS-RT feed, it is likely that any consumer that did not proces the latest version will not have that change. Now in case the situation exists where there is a newer GTFS file and the GTFS-RT would contain the alternation, it would not really make sense either. There are more issues at play here, and some operators actually have versioned GTFS-RT running.

[doconnoronca]

I'm sorry. I misread the specification as "go into effect for 7 days or fewer" rather then "go into effect in 7 days or fewer". Nevertheless this would require GTFS real time to include changes for the next 7 days to get them to be included in trip planning. I am unaware of any public feed the provides changes beyond one day. Certainly even if loading a GTFS isn't 100% reliable, it is far more likely to get it included then depending on the real time data.

[skinkie]

I am unaware of any public feed the provides changes beyond one day.

I think the dutch open (openov-nl) should give you cancellations and skipped stops beyond one day (if they are provided).