add trip_route_type into trips.txt GTFS static

[miklcct]

Summary

This proposal adds a new optional field, called trip_route_type, into trips.txt. It is currently in use by MBTA to denote trips inside a route where the type of transportation is not the same as the route itself.

Describe the Problem

It is impossible, in the current GTFS standard, to denote a trip using a different type of transportation within a route, where NeTEx can describe it well by assigning a mode of transport at the trip level. For example, it is possible in NeTEx, but not GTFS, to denote a bus trip running on a tram route.

Use Cases

If a rail replacement bus is associated as to a rail route, it can then be shown when querying the trips of the route such that travellers are aware of it. For example, in Stockholm, bus departures can be occasionally found on route 7, which is advertised as a tram route, intervened between tram departures.

It is not to be used when the rail replacement bus has a separate identity to the rail route (for example, in the London Underground, the replacement buses have separate codes, such as ML-1 when the tube line is closed, in this case they should be modelled as a separate route using the existing method)

Proposed Solution

Add a field trip_route_type into trips.txt which specifies the type of transportation for the particular trip.

Type of change

GTFS Schedule

• Functional Change
• Non-Functional Change
• Documentation Maintenance

GTFS Realtime

• Specification Change
• Specification Change (Experimental Field)

Additional Information

OpenTripPlanner is now facing difficulty in achieving a standard-neutral treatment of rail replacement buses because of the inability in GTFS to specify the same concept in NeTEx.

Proposed Discussion Period

This is a small, non-breaking change, so 10 days should be enough for discussion.

Testing Details

• Consumer(s): OpenTripPlanner (to be confirmed)
• Producer(s): MBTA
• Estimated Testing Period: 14 days

Proposal Update Tracker

Date	Update Description
(YYYY-MM-DD)	(Brief description of the update)

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.

[skinkie]

Against the proposal. If it is a replacement route, it should be a new route.

[miklcct]

Against the proposal. If it is a replacement route, it should be a new route.

The bus trips of the Stockholm route 7 and the tram trips of the Stockholm route 7 are not in different routes.

[eliasmbd]

@miklcct Thank you for proposing these changes.

While the changes are related, they fall under two separate governance processes: GTFS Schedule and GTFS Realtime. According to the GTFS Schedule governance, “The Advocate who publishes the proposal must focus on a single change.” This means each of these changes will need its own pull request, following the appropriate governance process - One for the Schedule change and one for the Realtime change.

I strongly recommend opening an issue first to gather initial feedback and support. This will help clarify the best path forward and ensure the proposals are well-aligned with community expectations. From there, you can proceed with splitting the issue into separate PRs.

[miklcct]

I am going to make this proposal for the static data first, as discussed at #358

[skinkie]

Against the proposal. If it is a replacement route, it should be a new route.

The bus trips of the Stockholm route 7 and the tram trips of the Stockholm route 7 are not in different routes.

For GTFS they must fall under different routes, since there is a different mode of operation.

[miklcct]

Against the proposal. If it is a replacement route, it should be a new route.

The bus trips of the Stockholm route 7 and the tram trips of the Stockholm route 7 are not in different routes.

For GTFS they must fall under different routes, since there is a different mode of operation.

Therefore I am making this proposal to remove this arbitrary limitation which does not match the reality in the real world. It is a single route from the perspective of both the operator and the customer.

[skinkie]

This is poor transport design, does not even work with Transmodel. The public name may be 7, it is likely never the system number.

[eliasmbd]

I am going to make this proposal for the static data first, as discussed at #358

Thank you. I am assuming you are looking to hold a discussion period of 10 days and then hold a the minimum 7 day review period.

[miklcct]

This is poor transport design, does not even work with Transmodel. The public name may be 7, it is likely never the system number.

GTFS is for passenger information and how the bus trips and the tram trips being represented in the internal system has completely no relevance that they are seen by the passengers and the operators as within a single route.

In NeTEx, it is modelled as a Line with TransportMode being tram, and some of the Journeys on the JourneyPatterns in the Routes belonging to the Line having the TransportMode being bus.

[skinkie]

GTFS is for passenger information and how the bus trips and the tram trips being represented in the internal system has completely no relevance that they are seen by the passengers and the operators as within a single route.

And for this reason, you could just make a new route_id, with the same route_short_name.

In NeTEx, it is modelled as a Line with TransportMode being tram, and some of the _Journey_s on the _JourneyPattern_s in the _Route_s belonging to the Line having the TransportMode being bus.

This opens a can of worms I don't want to open.

[miklcct]

I am going to make this proposal for the static data first, as discussed at #358

Thank you. I am assuming you are looking to hold a discussion period of 10 days and then hold a the minimum 7 day review period.

Yes, but they can be extended if necessary.

[miklcct]

GTFS is for passenger information and how the bus trips and the tram trips being represented in the internal system has completely no relevance that they are seen by the passengers and the operators as within a single route.

And for this reason, you could just make a new route_id, with the same route_short_name.

And this is a distortion of the reality where the operator and passenger both consider them to be the same route.

[Sergiodero]

Thanks @miklcct, I noticed that you refer to MBTA as the producer for this change, but in issue #358 that you pointed out, @jfabi explained why MBTA moved away from using this solution and the challenges associated with it. I wonder if this change is something MBTA would still support for the spec (not only for their feed and/or internal use), and if they would be ok formally playing the producer role in this PR.

Regardless, I would also strongly suggest to have this conversation at the issue level, since it seems like there is still some consensus needed to align on a potential solution based on the discussion in #358.

As mentioned in the Governance framework:

The Issue Stage is meant for discussing new ideas, identifying needs, and proposing improvements to the specification. Issues help evaluate the necessity and support for a change, while organizing the resources required to proceed to the Pull Request Stage. It’s recommended to start at the Issue stage to build consensus around new ideas.

Maybe continuing the conversation in #358 could be the best option.

[miklcct]

Thanks @miklcct, I noticed that you refer to MBTA as the producer for this change, but in issue #358 that you pointed out, @jfabi explained why MBTA moved away from using this solution and the challenges associated with it. I wonder if this change is something MBTA would still support for the spec (not only for their feed and/or internal use), and if they would be ok formally playing the producer role in this PR.

Regardless, I would also strongly suggest to have this conversation at the issue level, since it seems like there is still some consensus needed to align on a potential solution based on the discussion in #358.

As mentioned in the Governance framework:

The Issue Stage is meant for discussing new ideas, identifying needs, and proposing improvements to the specification. Issues help evaluate the necessity and support for a change, while organizing the resources required to proceed to the Pull Request Stage. It’s recommended to start at the Issue stage to build consensus around new ideas.

Maybe continuing the conversation in #358 could be the best option.

Thanks. This proposal is limited to the simple case where the type of transportation is different within a single route, such as the Stockholm route 7 example I have mentioned. This is representable in NeTEx as explained in the previous comment. This proposal is not for use in the cases where another route serves as the replacement of a route (such as a normal service bus route 40 replacing part of a train route).

[jfabi]

Thanks @miklcct, I noticed that you refer to MBTA as the producer for this change, but in issue #358 that you pointed out, @jfabi explained why MBTA moved away from using this solution and the challenges associated with it. I wonder if this change is something MBTA would still support for the spec (not only for their feed and/or internal use), and if they would be ok formally playing the producer role in this PR.

Regardless, I would also strongly suggest to have this conversation at the issue level, since it seems like there is still some consensus needed to align on a potential solution based on the discussion in #358.

Thanks to both @miklcct and @Sergiodero here—the comment I offered in #358 still accurately describes the MBTA's position on this issue. While we still publish trips.trip_route_type in our feed, we no longer use it to its original intent; that is, we do not publish any cases where a trip's trip_route_type would not match the respective route's route_type.

We could be open to re-discussing our use if there was a wide consensus on an approach across consumers, but at this time we would not feel comfortable acting as the first producer.

[miklcct]

Thanks @miklcct, I noticed that you refer to MBTA as the producer for this change, but in issue #358 that you pointed out, @jfabi explained why MBTA moved away from using this solution and the challenges associated with it. I wonder if this change is something MBTA would still support for the spec (not only for their feed and/or internal use), and if they would be ok formally playing the producer role in this PR.
Regardless, I would also strongly suggest to have this conversation at the issue level, since it seems like there is still some consensus needed to align on a potential solution based on the discussion in #358.

Thanks to both @miklcct and @Sergiodero here—the comment I offered in #358 still accurately describes the MBTA's position on this issue. While we still publish trips.trip_route_type in our feed, we no longer use it to its original intent; that is, we do not publish any cases where a trip's trip_route_type would not match the respective route's route_type.

We could be open to re-discussing our use if there was a wide consensus on an approach across consumers, but at this time we would not feel comfortable acting as the first producer.

OK, I will further discuss with @tkalvas @vpaturet (HSL) to see if there are any examples appropriate for this PR for them to take on as a producer, or if HSL's need can be delivered via a better alternative way. The example in Stockholm is that both trams and buses call at the exact same stops and run on the exact same shape.

[eliasmbd]

OK, I will further discuss with @tkalvas @vpaturet (HSL) to see if there are any examples appropriate for this PR for them to take on as a producer,

This is a good consideration. Make sure to involve the first producers, they must represent themselves in this comment section when testing the changes and showing proof of testing.

[Brickblock1]

I think it's worth noting that SL line 7 is in fact represented as two lines in Transmodel/NOPTIS/NeTEx. This could be do to stopping at different parts of the platform due to differing platform heights and at some stop platforms. Or more likely to assign it to a different GroupOfLines which is used to have it show "Ersättningsbuss" (Replacement buss) instead of "Spårväg city".

<Line version="100727" id="SE:001:Line:9011001000700000">
    <Name>Spårväg city</Name>
    <TransportMode>tram</TransportMode>
    <TransportSubmode>
        <TramSubmode>unknown</TramSubmode>
    </TransportSubmode>
    <PublicCode>7</PublicCode>
    <PrivateCode>7</PrivateCode>
    <RepresentedByGroupRef ref="SE:001:Network:9010001000000000"/>
</Line>
<Line version="130914" id="SE:001:Line:9011001097000000">
    <Name>Ersätter Spårväg City</Name>
    <TransportMode>bus</TransportMode>
    <TransportSubmode>
        <BusSubmode>unknown</BusSubmode>
    </TransportSubmode>
    <PublicCode>7</PublicCode>
    <PrivateCode>970</PrivateCode>
    <RepresentedByGroupRef ref="SE:001:Network:9010001000000000"/>
</Line>

Swedish GTFS feeds for trains do also suffer from the issue of having the replacement buses assigned the same route as the trains. So I can certanly see the point of making this change, on the other hand I don't know that it's really accomplices much. A NeTEx Line and GTFS Route would not become anymore interchangeable than they already are. An example of this is SL line 28 which has to be split into route 28, 28X and 28S in GTFS due to the differing route_short_names. GTFS-RT SA still then needs to refer to all there compared to SIRIs 1 Line. Therefore I'm of the opinon that using a GTFS route for conceptual grouping doesn't really work, its more a way of assigning attributes to trips than anything else.

Perhaps one solution would be to be able to designate a route as a parent of another one, that way you can have differing route level field values while still being able to tell which is the main one.

[Bertware]

The bus trips of the Stockholm route 7 and the tram trips of the Stockholm route 7 are not in different routes.

The tram line is line 7, the bus line is line 970 designated 7. This PR would not affect this example, since they are different different lines. They are not grouped together either, the bus line belongs to a different group of lines (replacement buses) than the tram line (which is in its own group). It is not technically feasible for us to join these two lines into one GTFS route. From a policy point of view, Trafiklab does not want to deviate from the source structure defined by the PTA when converting to GTFS/NeTEx, which is another reason why we would not implement this.

From a producer point of view, @Brickblock1 s note on split journeys due to different short_names would be more relevant, and a valid addition to any discussion on routes and trips. I'd say however that the current situation, where we as a producer split transmodel lines into different routes due to different designations is a good thing for data consumers, as these X, S, .., variants of lines are often treated as different lines when communicating with travellers.

[miklcct]

The bus trips of the Stockholm route 7 and the tram trips of the Stockholm route 7 are not in different routes.

The tram line is line 7, the bus line is line 970 designated 7. This PR would not affect this example, since they are different different lines. They are not grouped together either, the bus line belongs to a different group of lines (replacement buses) than the tram line (which is in its own group). It is not technically feasible for us to join these two lines into one GTFS route. From a policy point of view, Trafiklab does not want to deviate from the source structure defined by the PTA when converting to GTFS/NeTEx, which is another reason why we would not implement this.

From a producer point of view, @Brickblock1 s note on split journeys due to different short_names would be more relevant, and a valid addition to any discussion on routes and trips. I'd say however that the current situation, where we as a producer split transmodel lines into different routes due to different designations is a good thing for data consumers, as these X, S, .., variants of lines are often treated as different lines when communicating with travellers.

Do you mean that the bus below is actually on line 970? It is mixed between the tram departures.

The above is not a replacement bus for tram line closure. It is run in addition to the trams.

[Bertware]

That bus is technical line 970, designated 7 (in the same way one agency can have "bus line 1" in 5 different cities by using different technical line numbers, for example 1, 101, 201, 301, 401). The bus shown in the picture is, in the PTA data, on a different line than the trams.

The bus is replacement/reinforcement traffic making up for a lack in available seating on the trams compared to the expected number of riders. They usually are used as replacement buses, but during the summer months they are scheduled continuously. Given that the replacement bus line already exists, it likely makes more sense (and is technically/operationally easier) to run the reinforcement traffic on the replacement line. Additionally, the reinforcement traffic is using the replacement bus line color. This means that, if the color were to be included in the GTFS feed, there would be a need for two different routes with their own route_color. even if route types could be defined on trip level.

A deviation message is available in the realtime feed, and on the PTA website.

[miklcct]

That bus is technical line 970, designated 7 (in the same way one agency can have "bus line 1" in 5 different cities by using different technical line numbers, for example 1, 101, 201, 301, 401). The bus shown in the picture is, in the PTA data, on a different line than the trams.

The bus is replacement/reinforcement traffic making up for a lack in available seating on the trams compared to the expected number of riders. They usually are used as replacement buses, but during the summer months they are scheduled continuously. Given that the replacement bus line already exists, it likely makes more sense (and is technically/operationally easier) to run the reinforcement traffic on the replacement line. Additionally, the reinforcement traffic is using the replacement bus line color. This means that, if the color were to be included in the GTFS feed, there would be a need for two different routes with their own route_color. even if route types could be defined on trip level.

A deviation message is available in the realtime feed, and on the PTA website.

Thanks. This is convincing enough for me they are operationally two different routes, but this runs against the GTFS Best Practice that

All trips on a given named route should reference the same route_id.
Different directions of a route should not be separated into different route_id values.
Different spans of operation of a route should not be separated into different route_id values. i.e. do not create different records in routes.txt for “Downtown AM” and “Downtown PM” services).

[skinkie]

It does not go against the GTFS Best Practice, because GTFS does not allow a route to be multi modal.

[miklcct]

However it is extremely confusing to passengers if there are two different routes with the same public code in the same geographical area.

[skinkie]

Passengers have absolutely 0 to do with routes.txt.

[miklcct]

Passengers have absolutely 0 to do with routes.txt.

It will result in your journey planner telling your partners to take route 7 or route 7 (with different background colours) to your destination, if both route 7 and route 7 serve the journey, and that becomes confusing.

[skinkie]

It won't.

1. If the operator chose the same name, why wouldn't they choose the same colours?
2. Generally don't operate on the same time (unless the new trips are actually reinforcement trips), they they don't compete.
3. Routes never compete, trips compete.

[github-actions]

This pull request has been automatically marked as stale because of lack of recent activity. It may be closed manually after one month of inactivity. Thank you for your contributions.

[jspetrak]

And concerning fares and ticket retail, rail replacement bus may technically be treated as "train of category Bus" because it calls bus stations but it is ticketed to rail stations. Then you start to work around station equivalence (this bus stop replaces that rail station) 🙈 so having rail route and putting bus trip and bus stops into it may be exact information for journey planning but make the feed useless for ticketing.