-
Notifications
You must be signed in to change notification settings - Fork 177
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
[GTFS-Fares v2] Add networks.txt & route_networks.txt #405
[GTFS-Fares v2] Add networks.txt & route_networks.txt #405
Conversation
Changed to Conditionally Forbidden
This pull request has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions. |
not stale |
Hello, We have at least one producer: Ito World. They have shared their dataset in this file, which is part of a private feed. As per the GTFS amendment process, the requirements to open a vote are met. Please vote with a +1 (for) or -1 (against) in the comments. Voting ends on 2023-11-27 at 23:59:59 UTC. ![]() |
🙇♀️ Thank you to everyone who worked on getting this working! +1 from me, UrbanLabs LLC |
+1 from Caltrans. This does raise the question of how some best practices can be defined so that both producers can properly inform consumers of potentially separate parts of the GTFS existing in separate places. |
+0 from Transit, as we said previously we don’t think independent publication is a worthy goal by itself and generally will encourage bad design practice in GTFS. We think a simple merge of data makes more sense. That said, we recognize that we are in the overwhelming minority, so we’ll just abstain. |
+1 from Trillium |
gtfs/spec/en/reference.md
Outdated
|
||
File: **Conditionally Forbidden** | ||
|
||
Primary key (`*`) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If a route_id can only be defined in one network_id
, should the primary key be route_id
?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes, thanks for catching this! - 8664074
gtfs/spec/en/reference.md
Outdated
|
||
Primary key (`route_id`) | ||
|
||
Assigns routes from [routes.txt](#stopstxt) to networks. Forbidden if `routes.network_id` field exists. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Apologies, I missed this one as well. #stopstxt => #routestxt
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks Brian! - f191923
+1 from Google |
The vote passed on 2023-11-27 at 23:59:59 UTC. 4 votes in favour and no votes against. The votes came from: Thanks to everyone who contributed and voted! |
Context
Currently network (grouping of routes) can be defined by
routes.network_id
. However, during the fares v2 working group discussions, we identified the need to separate the production of fares data. Thenetworks.txt
androute_networks.txt
stem from Ito World's proposal, using a mechanism similar toareas.txt
andstop.areas.txt
, allowing fares data to be produced separately from schedule data.Changes in this PR
networks.txt
androute_networks.txt
filesroutes.network_id
fare_leg_rules.network_id
This PR tries to capture consensus reached during the working group meetings:
routes.network_id
androutes_networks.txt
+networks.txt
in the same dataset. (presence: Conditionally Forbidden)In addition,
networks.txt
indicates networks are used for fares use case, we can release this restriction if needed in the future as well.For previous discussions, please see issue#389 and working group meeting minutes.
Please go through the changes and feel free to share your thoughts/questions here.