Add GTFS Feed Version to the GTFS real time FeedHeader #434
Conversation
|
Thanks for your pull request! It looks like this may be your first contribution to a Google open source project. Before we can look at your pull request, you'll need to sign a Contributor License Agreement (CLA). View this failed invocation of the CLA check for more information. For the most up to date status, view the checks section at the bottom of the pull request. |
isabelle-dr
added
GTFS Realtime
Co-authored-by: Antoine Augusti <antoine.augusti@gmail.com>
|
+1 on this from SKI+ (SBB) in Switzerland our GTFS is updated frequently and such a linkage is highly needed. |
|
One comment about the gtfs_url. Once you have a stable GTFS URL, so clients can automatically download (and use their ETag headers to see if something has changed!), having an absolute URL to that stable location would not really make sense. Sure, if you have different variants it would work, but you can not differentiate between them, unless feed_version is provided. I don't mind having a URL, but let's keep it as a reference field. |
Thanks for the vote, but the voting process hasn't started. What would really help is if you can implement this feature in your feed. |
|
@skinkie > One comment about the gtfs_url. Once you have a stable GTFS URL, so clients can automatically download (and use their ETag headers to see if something has changed!), having an absolute URL to that stable location would not really make sense. Sure, if you have different variants it would work, but you can not differentiate between them, unless feed_version is provided. I don't mind having a URL, but let's keep it as a reference field. I am not sure if I correctly understand your comment. Do you suggest making gtfs_url "optional" as a field? Generally, I agree that the feed_version is the more decisive field, while I do understand the potential benefit of having the URL. |
It is already optional ;-) But I mean this: https://gtfs.ovapi.nl/nl/gtfs-nl.zip which points to https://gtfs.ovapi.nl/nl/NL-20240308.gtfs.zip Historic variants here: It is obvious that when gtfs_url would be https://gtfs.ovapi.nl/nl/NL-20240308.gtfs.zip it is pretty "unique" (under the constraint data is exported once per day). But as consumer you rather want to have https://gtfs.ovapi.nl/nl/gtfs-nl.zip as a stable url. Having a URL in GTFS-RT makes sense, but I would not want it to be the unstable url. I don't want to throw the baby out with the bathwater with this significant improvement. |
True :-). OK, this makes sense. I agree with this. I actually read it the other way around and that's why I couldn't follow your line of thought. |
As long as the stable url switches over at the same time the it is activated in the real time data, I think either option would fully meet the criteria for gtfs_url. Perhaps having a field for the current url and the upcoming url is an option, but that might be making a simple feature more complex then necessary. |
Which doesn't happen. The stable URL is updated earlier. But it also does not mean that the next version is instantly incompatible. |
|
I guess the question comes down to should the url point to the active GTFS or the upcoming GTFS. The upcoming GTFS would work better for consumers who are capable of preloading the GTFS before goes into effect. The current GTFS would be good for consumers who aren't capable of preloading the GTFS or are activating the agency for the first time. |
|
We will likely realize the feed_version in the next months. After some discussions we decided against an URL. The reason is a bit complicated to explain, but basically updating the RT-feed and the static file happen at different points in time, which is also related to the fact that the preparation and provision of the static file requires a varying amount of time and only after the switch has surely happened the GTFS-RT feed(version) is(would be) updated. |
Including the URL in the GTFS-RT seems like it would be particularly useful for your agency. It took me quite a lot of searching to find your current GTFS Data and it appears the url is different every version. Could you update the url in the feed to point to the new GTFS data at the same time that the feed version switches over? That is the process I recommend in the documentation. |
Hi @doconnoronca thank you for the feedback! If you don't mind, and not to spam this PR, may I kindly ask you to send us a small description (using https://opentransportdata.swiss/en/contact-2/) on how you searched for the dataset and what issue you had exactly with finding it (e.g., did you use the search function?, etc.)? Thanks! |
|
The feed_version has been implemented in the Open data platform mobility Switzerland trip updates feed. I am working on supporting some of the Swiss real time data in TransSee and using this feature to apply the GTFS files when the go into effect. |
|
TransSee successfully applied a GTFS update after the Feed Version was updated in the Switzerland real time feed. I was planning on removing the GTFS URL from the change and then moving to the vote. |
Remove the addition of gtfs_url because it wasn't clear if it should the current or upcoming file and it hasn't been implemented.
doconnoronca
changed the title
Based on the Issue Static file version information is missing in the real-time data feed opened by @Gerriko, I am proposing adding two new fields to the feed header to provide information on the GTFS file to be used with the GTFS real time data.
The feed_version would match the feed_version in the feed_info.txt file of the GTFS. This indicates which version of the GTFS file is currently being used by the real time data so the consumer knows exactly when to switch to a new file. It can also be used to identify when to check for a new GTFS file.
The GTFS_url would point to the url of the GTFS file. Sometimes agencies have multiple GTFSs and it's not clear which one is to be used. It provides the flexibility to allow the url to point to the upcoming GTFS file, but it is recommended to point to the one being used.
The next step would be for a producer to add support for this feature. This might be well suited for the @mbta to implement it as they update their GTFS every few days, sometimes with last minute changes.