Describe the problem
Many transit agencies rely on variations of routes (also known as “route branches”) to service different populations or destinations of interest which do not have enough demand for a dedicated route or a reroute of the existing service. It is important for customers to quickly recognize these route branches and understand how they may or may not serve their travel plans. Agencies often use a letter after the route’s number (ex: 11A or 11C) to differentiate these branches on signage and other transit information materials. The current best practice for agencies that define branches at the trip level is to include this branch information as a part of trips_headsign (11A 4Av S / To 46St-Nic or 11C 2nd St NE / Central-41). This limits how GTFS consumers can display routes with different branches.
Use cases
• Make it easier for consumers to list route variations on timetable views, route information pages, and map views.
• Enable more modular route and trip information to describe route branches in different levels of detail. Obscuring branch identifiers in headsigns is poor data management practices.
o 11
o 11A
o 11A 4Av S / To 46St-Nic
• Simplify the relationship between different route variants and the shapes of branch trips for displaying how branches differ on a map.
o This could potentially be used to help communicate if a TripModification is impacting a route branch vs the trunk vs branch + trunk.
Example: The Metro Transit route pages display route variants in timetables with a simplified route number & branch letter configuration.
Example: Metro Transit uses a custom branch_letter field in trips.txt to present route branch short names in user experiences where space is limited, like the “Show real-time bus locations” feature on our routes pages.
Example: Metro Transit bus stop signage for stops that are only serviced by a route branch displaying the abbreviated route number + branch letter
Example: Transit app uses the Metro Transit custom branch_letter field in trips.txt to present route branch identifiers in user experiences where space is limited and this information is critical for customers.
Branches in GTFS from other providers
AC Transit (East Bay, CA) has a few examples of branched routes (72, 72L, 72M and 51A, 51B). These are listed as different routes in routes.txt in AC Transit’s GTFS feed. WMATA (Washington, DC) uses prefixed letters combined with number to denote different route types based on areas served (D60, D74, D44 are “downtown routes” and C51, C57, C31 are “crosstown” routes). These branches are also listed as separate routes in routes.txt. WMATA also adds an “X” suffix to denote express routes. Both of these examples represent the route_long_name and/or route_short_name from the published MobilityData best practice.
While researching this proposal, I was not able to find an agency that is currently following the published best practice - the GoDurham link provided on the gtfs.org page returns a 404 and I could not find a branched route example on the GoDurham site. I welcome examples of a GTFS producer that is publishing branch information using the trip.trip_short_name field method.
Proposed solution
I propose the addition of an optional branch_code field to trips.txt to identify if a trip is operating a route branch. This new field would allow consumers to more easily display route branch-specific information using the ‘shorthand’ (ex: 11A) in the context of specific trips or alerts that only impact a specific branch.
Trips.txt to include a new optional field branch_code Primary key (trip_id)
<style>
</style>
| Field name |
Type |
Presence |
Description |
| branch_code |
Enum |
Optional |
Defines how an agency identifies a specific branch on a given route as presented on other transit information materials. Many agencies use letters after the route number to identify branches so the expected values could be A-Z. Naming this field branch_code provides flexibility to present these identifiers as the agency prefers. |
This branch_code notation would be used to communicate different trip patterns or terminals of a route branch. The branch_code associated patterns can be repeated on a timetable multiple times a day. If an agency’s service operates trips that need to be distinctly communicated to customers, the trips.trip_short_name field could still be used to identify these unique trips in a daily service schedule.
Google Transit Branch Reference
MobilityData Best Practices for Branch Routes
Type of change
GTFS Schedule
Functional Change
☑️Non-Functional Change
Documentation Maintenance
GTFS Realtime
Specification Change
Specification Change (Experimental Field)
Additional information
Checklist
• I have read and understood the GTFS Change process.
• I have read and understood the GTFS Guiding Principles.
• I understand the Role of Advocate and the Responsibilities attached to it.
• I have signed the Contributor License Agreement (CLA).
• I have ensured that this proposal is not covered by an existing Pull Request.
Describe the problem
Many transit agencies rely on variations of routes (also known as “route branches”) to service different populations or destinations of interest which do not have enough demand for a dedicated route or a reroute of the existing service. It is important for customers to quickly recognize these route branches and understand how they may or may not serve their travel plans. Agencies often use a letter after the route’s number (ex: 11A or 11C) to differentiate these branches on signage and other transit information materials. The current best practice for agencies that define branches at the trip level is to include this branch information as a part of trips_headsign (11A 4Av S / To 46St-Nic or 11C 2nd St NE / Central-41). This limits how GTFS consumers can display routes with different branches.
Use cases
• Make it easier for consumers to list route variations on timetable views, route information pages, and map views.
• Enable more modular route and trip information to describe route branches in different levels of detail. Obscuring branch identifiers in headsigns is poor data management practices.
o 11
o 11A
o 11A 4Av S / To 46St-Nic
• Simplify the relationship between different route variants and the shapes of branch trips for displaying how branches differ on a map.
o This could potentially be used to help communicate if a TripModification is impacting a route branch vs the trunk vs branch + trunk.
Example: The Metro Transit route pages display route variants in timetables with a simplified route number & branch letter configuration.
Example: Metro Transit uses a custom branch_letter field in trips.txt to present route branch short names in user experiences where space is limited, like the “Show real-time bus locations” feature on our routes pages.
Example: Metro Transit bus stop signage for stops that are only serviced by a route branch displaying the abbreviated route number + branch letter
Example: Transit app uses the Metro Transit custom branch_letter field in trips.txt to present route branch identifiers in user experiences where space is limited and this information is critical for customers.
Branches in GTFS from other providers
AC Transit (East Bay, CA) has a few examples of branched routes (72, 72L, 72M and 51A, 51B). These are listed as different routes in routes.txt in AC Transit’s GTFS feed. WMATA (Washington, DC) uses prefixed letters combined with number to denote different route types based on areas served (D60, D74, D44 are “downtown routes” and C51, C57, C31 are “crosstown” routes). These branches are also listed as separate routes in routes.txt. WMATA also adds an “X” suffix to denote express routes. Both of these examples represent the route_long_name and/or route_short_name from the published MobilityData best practice.
While researching this proposal, I was not able to find an agency that is currently following the published best practice - the GoDurham link provided on the gtfs.org page returns a 404 and I could not find a branched route example on the GoDurham site. I welcome examples of a GTFS producer that is publishing branch information using the trip.trip_short_name field method.
Proposed solution
I propose the addition of an optional branch_code field to trips.txt to identify if a trip is operating a route branch. This new field would allow consumers to more easily display route branch-specific information using the ‘shorthand’ (ex: 11A) in the context of specific trips or alerts that only impact a specific branch.
Trips.txt to include a new optional field branch_code Primary key (trip_id)
<style> </style>This branch_code notation would be used to communicate different trip patterns or terminals of a route branch. The branch_code associated patterns can be repeated on a timetable multiple times a day. If an agency’s service operates trips that need to be distinctly communicated to customers, the trips.trip_short_name field could still be used to identify these unique trips in a daily service schedule.
Google Transit Branch Reference
MobilityData Best Practices for Branch Routes
Type of change
GTFS Schedule
Functional Change
☑️Non-Functional Change
Documentation Maintenance
GTFS Realtime
Specification Change
Specification Change (Experimental Field)
Additional information
Checklist
• I have read and understood the GTFS Change process.
• I have read and understood the GTFS Guiding Principles.
• I understand the Role of Advocate and the Responsibilities attached to it.
• I have signed the Contributor License Agreement (CLA).
• I have ensured that this proposal is not covered by an existing Pull Request.