Expand / Add definition around route_type

[e-lo]

Customer Need

On behalf of Amtrak...

As a customer, I'd like to know (and potentially select a route by) if I can expect the bus route I've chosen to provide a comfortable amount of space to sit and some space for my personal items - so that I can evaluate if it is an appropriate route for me or if is worth any difference in costs.

As a customer, I'd like to know (and potentially select a route by) if I can expect the bus route I've chosen to requires me to navigate across vehicle rows where I cannot stand and sit, next to individuals that I may not know without the option to move during the trip - so that I can evaluate if it is an appropriate route for me (my ability and comfort level in being in close proximity to others) or if is worth any difference in costs.

Current Spec

routes.route_type :

Indicates the type of transportation used on a route. Valid options are:

0 - Tram, Streetcar, Light rail. Any light rail or street level system within a metropolitan area. 1 - Subway, Metro. Any underground rail system within a metropolitan area. 2 - Rail. Used for intercity or long-distance travel. 3 - Bus. Used for short- and long-distance bus routes. 4 - Ferry. Used for short- and long-distance boat service. 5 - Cable tram. Used for street-level rail cars where the cable runs beneath the vehicle, e.g., cable car in San Francisco. 6 - Aerial lift, suspended cable car (e.g., gondola lift, aerial tramway). Cable transport where cabins, cars, gondolas or open chairs are suspended by means of one or more cables. 7 - Funicular. Any rail system designed for steep inclines. 11 - Trolleybus. Electric buses that draw power from overhead wires using poles. 12 - Monorail. Railway in which the track consists of a single rail or a beam

Proposed Solutions

1. Add coach as a route_type | Update bus

3: Bus,

• customers may be seated or standing
• differentiated from a van by customers being able to navigate across rows via an aisle that is standing-height

9: Coach,

• a bus with premium features such as:
  • more comfortable, dedicated seating.
  • May or may not include: space underneath and above the rider for luggage, individual climate control, on-board restrooms, entertainment, and connectivity.

2. Add van as a route_type

8 : van, a slightly larger auto where

• a single or pair of doors provides access to multiple rows of seats, access to which is typically provided via a small side aisle or folding seats.
• Interior ceiling is below typical standing height.

3. Add BRT as route_type

10: Bus Rapid Transit (BRT), a bus service (bus, coach, or electric trolleybus) with supporting infrastructure designed to improve travel time and service reliability where:

• all or a significant portion of the route operates on dedicated transit right-of-way;
• dwell times are minimized through strategies such as all-door-boarding, ticket pre-payment, and level-boarding; and
• travel times are enhanced using strategies such as transit signal priority or higher-speed roadway design.

BRT may or may not include enhancements to:

• customer communication and branding; and
• on- and off-board rider amenities.

We could also just reference: "What is BRT", ITDP

Previous discussion

174 considered several additional route_type values and settled on adding one for monorail and one for trolleybus. There is a lot of great discussion in the issue thread that is worth reviewing.

• Intercity bus/coach was not added at the time due to concerns that it was:
  • Potentially not backwards compatible because many feeds currently code intercity bus as bus
    • I see this is non-breaking because old versions of the feed would still "make sense" to users and would not fail validation
    • Arguably trolleybus would have had the same issue?
  • Lack of specificity in the definition of intercity bus
    • I think we can get to a good definition.

I am unaware of any previous discussions about "vans" (vs autos) but would welcome them.

Relevant Pull Requests

279 has the text for all previous proposed extended route types

Relevant open proposals

The following proposals are also relevant:

• GTFS-Vehicles
  • proposes very granular features available on various vehicle types.
  • This proposal does not inhibit any of the GTFS-Vehicles proposal
• GTFS-ModesAndNetworks
  • Considers additional expansion of route_type and grouping of routes and route types into networks and modes.
  • This proposal does not inhibit any of the GTFS-ModesAndNetworks proposal and provides a lower-effort shortcut to achieve several of its basic user needs.
• GTFS-OnDemand
  • Proposes the addition of an enum value for car/auto/van.
  • This proposal would modify the GTFS-OnDemand definition of car/auto to exclude "van"

[skinkie]

I would suggest you to revive the extended route types #125 pull request. Because one-of adding does not make sense either, since everything has been specified before.

[e-lo]

I would suggest you to revive the extended route types https://github.com/google/transit/pull/125 pull request.

I get a 404 on that one? I did a search on route_types in this repo of issues/PRs and linked everything that came up above but would love to add any I missed!

[skinkie]

My bad #279

[carlfredl]

Thanks for sharing this proposal, these are very good needs. I'm worried this proposal wouldn't actually would meet the user needs without better definitions.

By the definitions above, SDTJ Passport's Mercedes Sprinters (image) should be defined as a "Coach" since the people appear to be able to stand between the seats and they have "premium features," yet that might not solve the user needs for information about comfort (that is subjective and the user may have had something different in mind as a "Coach") and ability to change seats (that is not yet part of the definition).

We've been discussing additional bus granularity on and off for the last decade. The challenge seems to be a lack of shared understanding of what we are standardizing (similar to Occupancies). I'd say we'll need more clear, widely accepted definitions of coach, bus, and van.

[rafapereirabr]

A quick two cents here, that perhaps it would also be a good idea to create a BRT code for route_type.

[e-lo]

I'd say we'll need more clear, widely accepted definitions of coach, bus, and van.

I'd encourage us not to let the perfect in the way of "pretty good" here and solving a bunch of potential customer needs. The consequences of a customer being disappointed with SDTJ's "coach" definition seems pretty low (and it likely meets the category of a "mini coach" per wikipedia, at least)

[gcamp]

I'd encourage us not to let the perfect in the way of "pretty good" here and solving a bunch of potential customer needs.

+1

A quick two cents here, that perhaps it would also be a good idea to create a BRT code for route_type.

Even if defining BRT is its own problematic, this would be the route type addition that's the most useful to us

[e-lo]

Updates:

• Referenced #279 proposal/discussion
• Added proposed definitions for BRT 😓 😬 🛡️ based on feedback from @gcamp and @rafapereirabr

[carlfredl]

Even if defining BRT is its own problematic, this would be the route type addition that's the most useful to us

Indeed, treating all buses as equal until we can agree on how to classify BRT seems like a high cost, vs moving forward with some room for discretion (this likely already exists between types like rail and light rail).

I'd encourage us not to let the perfect in the way of "pretty good" here and solving a bunch of potential customer needs.

Agreed. I don't think we can fully solve these user stories, but we could probably improve their experience by improving expectations.

Data consumers (@gcamp): how is route_type actually used? What would it allow you to improve if we added Van or BRT?

[gcamp]

Specifically on BRT, we add that definition internally on some buses when we want to 1) show that bus line on a global transit maps. BRT are often structural elements in a city and are worth showing next to rail lines 2) Nudge the trip planner to take the BRT vs a regular bus when possible.

If this becomes reality, we would add default images and display for coach, van and BRTs.

[drewda]

One point of reference: for @transitland as a consumer of thousands of feeds, we handle the full list of extended route type. There are some producers who use them, especially outside of the US. However, we also map the extended route types back on to the spec's short list: https://github.com/interline-io/transitland-lib/blob/master/tl/enum/routetypes.go

I assume some other large consumers do this as well, just with a different style for which extended route type they map onto a smaller subset of their choosing. Based on that assumption, I think many consumers may be fine voting to extend the number of route_types. A longer list may be somewhat arbitrarily defined and used inconsistently by producers, but each consumer can decide which route_types warrant their own styling (or other treatment like @gcamp mentions) vs. consolidated into a smaller set of route_types.

[jgysland]

Indeed, treating all buses as equal until we can agree on how to classify BRT seems like a high cost, vs moving forward with some room for discretion (this likely already exists between types like rail and light rail).

Also monorail vs rail. And "Cable Tram" versus "Tram, Streetcar, Light rail"? If these are distinctions worth making, then then adding a code for BRT seems like it should be uncontroversial.

BRT are often structural elements in a city and are worth showing next to rail lines

I only learned GTFS existed about an hour ago, after asking some friends who work for my local transit agency why BRT routes which have been put into service over the past couple years aren't drawn on Google Maps' transit view like LRT routes (but are drawn in other apps, e.g. Apple Maps and TransitApp).

Looking into it, I was initially disappointed when I saw the specification for routes.txt included no way to distinguish between BRT and non-BRT buses, but then delighted to see its an open-source project and there's an open issue suggesting that this be amended.

Of course for a change like this to be useful to me as a user, my local transit agency would have to update their feed to mark BRT routes with whatever the new route_type enum value, and Google Maps maintainers would have to implement changes to render it, but putting it in the spec seems like it would be a good start.

[miklcct]

I would like to see a distinction between a bus and a coach in the UK because they are regulated differently.

Currently, the ITO World producer uses 200 for the coach routes.

Also, in Hong Kong, there are minibus routes which use 16 to 19 seaters and are regulated differently to normal bus routes, and unregulated share taxi routes as well.

I suggest that we formalise a hierarchical structure, which is compatible with Google but without actually including Google's definition for the specific modes, such that distinctions can be made for local consumers while consumers not locally supporting the extended numbers can map it into base types. In other words, we should get the major route types (ending in the hundreds) into the spec.