[GTFS-Fares v2] Add networks.txt & route_networks.txt

[tzujenchanmbd]

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. The networks.txt and route_networks.txt stem from Ito World's proposal, using a mechanism similar to areas.txt and stop.areas.txt, allowing fares data to be produced separately from schedule data.

Changes in this PR

• Add networks.txt and route_networks.txt files
• Modify presence of routes.network_id
• Modify description of fare_leg_rules.network_id

This PR tries to capture consensus reached during the working group meetings:

• Adding these two files
• Not allowing both routes.network_id and routes_networks.txt + networks.txt in the same dataset. (presence: Conditionally Forbidden)
• Not allowing many-to-many relationship (A route can be defined in 1 network). We can release this restriction if needed in the future.

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.

[github-actions]

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.

[tzujenchanmbd]

not stale

[tzujenchanmbd]

Hello,

We have at least one producer: Ito World. They have shared their dataset in this file, which is part of a private feed.
We have at least one consumer: Apple Maps. Please see the screenshot below for the same dataset.

As per the GTFS amendment process, the requirements to open a vote are met.
We are opening a vote for adding networks.txt and route_networks.txt.

Please vote with a +1 (for) or -1 (against) in the comments. Voting ends on 2023-11-27 at 23:59:59 UTC.

[e-lo]

🙇‍♀️ Thank you to everyone who worked on getting this working!

+1 from me, UrbanLabs LLC

[evansiroky]

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

[gcamp]

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

[westontrillium]

+1 from Trillium

[bdferris-v2]

If a route_id can only be defined in one network_id, should the primary key be route_id?

[tzujenchanmbd]

Yes, thanks for catching this! - 8664074

[bdferris-v2]

Apologies, I missed this one as well. #stopstxt => #routestxt

[tzujenchanmbd]

Thanks Brian! - f191923

[bdferris-v2]

+1 from Google

[tzujenchanmbd]

The vote passed on 2023-11-27 at 23:59:59 UTC.

4 votes in favour and no votes against.

The votes came from:
UrbanLabs LLC (@e-lo)
Caltrans (@evansiroky)
Trillium (@westontrillium)
Google (@bdferris-v2)

Thanks to everyone who contributed and voted!