Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add Feed Version and GTFS url to the GTFS real time FeedHeader #434

Open
wants to merge 2 commits into
base: master
Choose a base branch
from

Conversation

doconnoronca
Copy link

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.

Copy link

google-cla bot commented Feb 15, 2024

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 isabelle-dr added GTFS Realtime Issues and Pull Requests that focus on GTFS Realtime Change: Addition New function proposed to the specification. labels Feb 15, 2024
Co-authored-by: Antoine Augusti <[email protected]>
@davidr1234
Copy link

+1 on this from SKI+ (SBB) in Switzerland our GTFS is updated frequently and such a linkage is highly needed.

@skinkie
Copy link
Contributor

skinkie commented Mar 7, 2024

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.

@doconnoronca
Copy link
Author

+1 on this from SKI+ (SBB) in Switzerland our GTFS is updated frequently and such a linkage is highly needed.

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.

@davidr1234
Copy link

@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.

@skinkie
Copy link
Contributor

skinkie commented Mar 8, 2024

I am not sure if I correctly understand your comment. Do you suggest making gtfs_url "optional" as a field?

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:
https://gtfs.ovapi.nl/nl/archive/NL-20240308.gtfs.zip
https://gtfs.ovapi.nl/nl/archive/NL-20240305.gtfs.zip

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.

@davidr1234
Copy link

I am not sure if I correctly understand your comment. Do you suggest making gtfs_url "optional" as a field?

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: https://gtfs.ovapi.nl/nl/archive/NL-20240308.gtfs.zip https://gtfs.ovapi.nl/nl/archive/NL-20240305.gtfs.zip

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.

@doconnoronca
Copy link
Author

I am not sure if I correctly understand your comment. Do you suggest making gtfs_url "optional" as a field?

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: https://gtfs.ovapi.nl/nl/archive/NL-20240308.gtfs.zip https://gtfs.ovapi.nl/nl/archive/NL-20240305.gtfs.zip

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.

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.

@skinkie
Copy link
Contributor

skinkie commented Mar 9, 2024

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.

Which doesn't happen. The stable URL is updated earlier. But it also does not mean that the next version is instantly incompatible.

@doconnoronca
Copy link
Author

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.

@davidr1234
Copy link

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.

@doconnoronca
Copy link
Author

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.

@davidr1234
Copy link

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!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Change: Addition New function proposed to the specification. GTFS Realtime Issues and Pull Requests that focus on GTFS Realtime
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants