[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.
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.
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.
Apologies, I missed this one as well. #stopstxt => #routestxt
|
+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! |
| | [fare_transfer_rules.txt](#fare_transfer_rulestxt) | Optional | Fare rules for transfers between legs of travel.<br><br>Along with [fare_leg_rules.txt](#fare_leg_rulestxt), file [fare_transfer_rules.txt](#fare_transfer_rulestxt) provides a more detailed method for modeling fare structures. As such, the use of [fare_transfer_rules.txt](#fare_transfer_rulestxt) is entirely separate from files [fare_attributes.txt](#fare_attributestxt) and [fare_rules.txt](#fare_rulestxt). | | ||
| | [areas.txt](#areastxt) | Optional | Area grouping of locations. | | ||
| | [stop_areas.txt](#stop_areastxt) | Optional | Rules to assign stops to areas. | | ||
| | [networks.txt](#networkstxt) | **Conditionally Forbidden** | Network grouping of routes.<br><br>Conditionally Forbidden:<br>- **Forbidden** if `routes.network_id` field exists.<br>- Optional otherwise. | |
There was a problem hiding this comment.
Why would networks.txt be forbidden when the relation between networks an routes is specified in routes.txt? The conditionally forbidden relation this pull request intends is only between routes.network_id and route_networks.txt
There was a problem hiding this comment.
@ferranmanya I agree and was recently confused by this as well. As currently written here and validated by MobilityData's validator (https://github.com/MobilityData/gtfs-validator/pull/1671/files), networks can't both be named (requires use of networks.txt) and be linked to routes (requires use of routes.network_id or route_networks.txt).
There was a problem hiding this comment.
@ferranmanya @sberkley
Agree this could be a bit confusing... Here’s some background information:
routes.network_id, networks.txt, and route_networks.txt were not all introduced into GTFS at the same time. routes.network_id was added to GTFS in May 2022 through PR#286. At that time, there was no dedicated networks.txt table for networks (“non-normalized”), and most producers simply defined networks using routes.network_id.
In 2023, the community raised the need to handle fares data separately—which is what this PR addresses—and that led to the addition of both route_networks.txt and networks.txt. With networks.txt, networks became normalized and have a network_id primary key.
After introducing networks.txt, what if it also became the primary table referenced by routes.network_id? This would mean the validator must check the references between the two tables, which would be a breaking change for producers who had previously only provided routes.network_id. And GTFS currently maintains strict backward compatibility for producers. We also want to avoid the confusion that could result from mixing old and new approaches. In a mixed scenario, it can become unclear which definition of a network should be treated as authoritative...
This is why the current validator rule exists. Its meaning is essentially: either use the previous routes.network_id alone, or use the new [route_networks.txt + networks.txt] combination to define networks.
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.txtandroute_networks.txtstem from Ito World's proposal, using a mechanism similar toareas.txtandstop.areas.txt, allowing fares data to be produced separately from schedule data.Changes in this PR
networks.txtandroute_networks.txtfilesroutes.network_idfare_leg_rules.network_idThis PR tries to capture consensus reached during the working group meetings:
routes.network_idandroutes_networks.txt+networks.txtin the same dataset. (presence: Conditionally Forbidden)In addition,
networks.txtindicates 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.