route_ids Changing?

[RideSchedules]

My data suggests route_ids are changing.

It is not possible to tell which route in the old data new times refer to when you change route_ids. This makes your data unusable to track route schedules.

It is worth while to update or replace your GTFS generating software. Otherwise, heuristics in other attributes must be used with results not guaranteed.

[kevinsmgov]

You data is correct. The route_id value is unique for each service period. This is a product of the underlying data from the motor coach operator management system we use.

We have found this use to be consistent with the GTFS specification. It also allows us to modify route names appropriately at service changes as our routes are altered over time.

Upon reviewing your developer information, our current approach of providing our previous and next schedule data in a single GTFS file two weeks before our service change should result in your system only publishing a single GTFS file at a time. There should be no need on your end to try and merge two GTFS files and heuristically match route names.

Our static GTFS feed, http://gtfs.bigbluebus.com/current.zip, should be polled daily with a HEAD request - last-modified value is provided. It also contains _feedinfo.txt with version information and effective date range. We anticipate adding some additional stops on our routes before the next service change so there will be some minor changes to stops.txt and _stoptimes.txt over the next few months.

[thekaveman]

@RideSchedules I'm closing this for now. Please feel free to submit more issues if you have additional questions.

However do note that this repository is for our historical GTFS data. As @kevinsmgov mentioned, check out http://gtfs.bigbluebus.com for our current GTFS schedule and GTFS real-time information. The corresponding GitHub repo is https://github.com/CityofSantaMonica/gtfs.bigbluebus.com

[RideSchedules]

kevinsmgov,

Sorry to comment so late.

Just a little correction on your assessment of the impact on our system of legacy software that changes route_ids.

The static GTFS data can still be usable, but GTFS-R can be a problem. When you publish merged, route_ids for the latest service_id are assigned to that route. However, GTFS-R sill reports using old route_ids until service for the new route_id begins (there is no work around since GTFS-R doesn't include attributes to resolve changing route_ids).

One solution is to publish new data at end of the last service date of the old data. Since you say you are not doing that, I've updated our settings for your data to manual updates so new data will be processed when the old expires thereby preventing GTFS-R from failing.

GTFS was formerly known as the Google Transit Feed Specification but is now the General Transit Feed Specification. I think updating your legacy software for consistent use of identifiers would minimize confusion and be worth the greater application support.

We do have plans to update our own system to handle this one issue of legacy behavior coupled with GTFS-R, but so few people are still doing it that it is not high on our todo list.

Thanks for checking this out, though.