Defining a route type at the trip level

[vpaturet]

The current GTFS specification allows for defining a route type ("route_type" in routes.txt) at the route level which applies to every trips in that route.
There are cases however where some trips in a given route are scheduled with an alternate transport mode. A typical example is replacement bus, where train trips are temporarily replaced by bus trips due to construction work on the railways.
From a passenger's perspective, these replacement bus trips belong to the original route.
There is no way to model this with the current GTFS specification.

MBTA came up with a solution for this use case: adding a custom field "trip_route_type" in trips.txt
See:

• https://groups.google.com/g/massdotdevelopers/c/M35VgMBM2qk/m/up6lYUTpCQAJ
• https://github.com/mbta/gtfs-documentation/blob/master/reference/gtfs.md#tripstxt

Would it make sense to standardize this custom field "trip_route_type" in the GTFS specification?

[jspetrak]

From the rail perspective, replacement bus is technically a train with commercial category bus, and it calls train stations, not bus stations. I know it is confusing.

If we allow to modify route data on trip level, I would think also about routeless trips which most of the trains are, at least in Europe. And there usually less than more successful workarounds for that.

[hannesj]

Another possibility would be to mark a route to be part/replacement of another route. That way we could link those together and use the information to link the real-time alerts to both routes.

[JohanEntur]

The problem that arose here was that a deviation message said "train is cancelled" but the GTFS data showed a train (which was actually a bus).

[barbagus]

@jspetrak

From the rail perspective, replacement bus is technically a train with commercial category bus, and it calls train stations, not bus stations. I know it is confusing.

In #409 I make the case for regular bus services mixed with train services within the same route (French regional railways). Would you say your remark applies there as well ?

If we allow to modify route data on trip level, I would think also about routeless trips which most of the trains are, at least in Europe.

Could you elaborate on this please ? I am not sure to understand.

[jfabi]

Following here from #409, sharing a bit more about the @mbta's experience with rail replacement buses:

Another possibility would be to mark a route to be part/replacement of another route. That way we could link those together and use the information to link the real-time alerts to both routes.

We are doing exactly this via another extension we designed and implemented, multi_route_trips.txt.

In the example below from our Needham Line route timetable, Train 839 and Train 841 are actually part of a different route_id for the Providence/Stoughton Line (they continue on to another destination beyond Forest Hills), but because the trips are linked to the Needham Line via multi_route_trips.txt, we are able to show them on this webpage.

A similar treatment is used if, say, a shuttle bus replaced a portion or whole of a Needham Line trip.

We originally added the trip_route_type extension in order to be able to distinguish "replacement bus" trips with normal rail trips on the same route_id, however ultimately moved to using separate routes; having trips on both rail and bus route_ids stopping at shared stop_ids caused issues with more than one feed consumer. Perhaps this could be overcome with an addition to the spec, but backward-compatibility should be considered.

In our case, using a distinct route_id also allows us to give the bus service route/text colors that match the replacing buses, as well as separate route names—particularly useful in situations when a single bus service replaces multiple rail routes.

[miklcct]

Following here from #409, sharing a bit more about the @mbta's experience with rail replacement buses:

Another possibility would be to mark a route to be part/replacement of another route. That way we could link those together and use the information to link the real-time alerts to both routes.

We are doing exactly this via another extension we designed and implemented, multi_route_trips.txt.

In the example below from our Needham Line route timetable, Train 839 and Train 841 are actually part of a different route_id for the Providence/Stoughton Line (they continue on to another destination beyond Forest Hills), but because the trips are linked to the Needham Line via multi_route_trips.txt, we are able to show them on this webpage.

A similar treatment is used if, say, a shuttle bus replaced a portion or whole of a Needham Line trip.

We originally added the trip_route_type extension in order to be able to distinguish "replacement bus" trips with normal rail trips on the same route_id, however ultimately moved to using separate routes; having trips on both rail and bus route_ids stopping at shared stop_ids caused issues with more than one feed consumer. Perhaps this could be overcome with an addition to the spec, but backward-compatibility should be considered.

In our case, using a distinct route_id also allows us to give the bus service route/text colors that match the replacing buses, as well as separate route names—particularly useful in situations when a single bus service replaces multiple rail routes.

Why do bus and rail sharing a platform cause an issue for your consumers? I think it is the fault of your consumers not handling multi-modal stops correctly.

It is common that subway / rail, subway / tram, bus / tram, etc., share platforms.

[miklcct]

I think we should continue discussion here as we have now having problem with NeTEx / GTFS compatibility.

It is not possible to specify a concept related to passenger information in GTFS compared to NeTEx.

[felixguendling]

Another way to model this would be to add one level on top that groups routes, so they can be shown as one (e.g. in printed departure boards at the bus/tram stop).

In my city, the replacement buses usually are called ${line-number}E where "E" stands for "Ersatz" (=replacement). So if more than just the route_type changes, but you still want to be able to group routes together, it would help to have another grouping mechanism on top.

[leonardehrenfried]

As background reading material, here is a discussion if having distinct lines and routes in NeTex was a good idea: https://public.3.basecamp.com/p/Cdz5FsVwJRDS61YVsamVBSnP

[felixguendling]

From the NeTEx documentation:

ROUTE is classically used as an interfacing object between operational planning and infrastructure description.

Line in NeTEx is routes.txt in GTFS. And GTFS does not have any concept that mirrors Route. On the other hand, all attributes I mentioned such as route_short_name and route_type are defined on the NeTEx ServiceJourney (which is similar to a trip in GTFS). So obviously NeTEx can already have separate OperatorRef, TransportMode, trainNumbers, etc., all in the same Line. And on top of this, NeTEx has GroupOfLines and Network. So even if Route is not a rider-facing construct (as discussed in the link), NeTEx still has two more grouping mechanisms on top AND the important attributes such as TransportMode on the ServiceJourney instead of Line. So NeTEx would not have this problem we're discussing here for at least two separate reasons not related to Route.

In general, I see two options:

• enable override of all important attributes of routes.txt in trips.txt (only route_type doesn't cover all use cases but would be a starting point)
• add another construct on top of route to be able to group routes

NeTEx kind of has both.

I have no real opinion on what's better - just wanted to mention that there are different options.