Add NewRoutes to GTFS-RT to support dynamic service (#606)

[cleveramarquet]

Description

This proposal introduces a NewRoutes message to the FeedEntity in GTFS Realtime. As discussed in Issue #606, the current specification lacks a standard way to define route metadata for services that do not exist in the static GTFS schedule.

The full technical specification and field definitions can be found in the GTFS-NewRoutes Google Doc.

By allowing a Route to be defined directly within the real-time feed, consumers can provide a complete and accurate experience for riders without requiring agencies to "reuse" unrelated static IDs.

Implementations

• Producer: Clever Devices Test Feed
• Consumer: Transit App (Development in progress)

[leonardehrenfried]

As I did in the Google doc, I'm requesting this to be changed to an int so it can reflect the full range of extended route types. As a benefit this enum would then not have to be kept in sync with static GTFS.

[leonardehrenfried]

cc @hbruch

[cleveramarquet]

I see your point about the extended route types. However, I used an enum here to stay consistent with how the rest of the current GTFS-RT specification handles route types. Perhaps we could stick with the enum for this PR to keep the scope focused on NewRoutes, and then address a global move to int32 for route types across the entire spec in a separate proposal?

[leonardehrenfried]

Well, since GTFS has ironclad backwards-compatibility guarantees, I don't think I will be able to convince the community that there are two ways to define the mode.

[felixguendling]

100% agree with @leonardehrenfried.
We need extended route types support from the beginning so the feature can be useful.

(off topic: IMO the current GTFS route types should be deprecated and replaced with extended route types)

[cleveramarquet]

I've updated route_type to int32 to support extended types as suggested. Thanks for the catch!

[gcamp]

The move to int32 (should probably be uint32?) doesn't bother me, but it's really not obvious to me that extended route type is the way to go. There's been discussion in the past about this and it was contentious

[leonardehrenfried]

I agree that the status of the extended route types have been pretty frustrating for many years.

I'm aware that they are pretty unimportant in North America (correct?) but in Europe people very much like to separate their services into distinct types. From the perspective of a routing algorith, it may not matter much, but regular commuters care quite a lot about the difference between regional rail and suburban rail, for example.

I'm in favour of these distinctions, too, and would like to hear your opinions. If @gcamp, @felixguendling and I agree that it's worthwhile, we could try another attempt at standardising.

[felixguendling]

we could try another attempt at standardising

I would support this as it's a very obvious shortcoming of GTFS compared to NeTEx and commercial proprietary data formats like HRDF, DIVA, ISA, etc. And it should be easy to fix because extended route types are used in practice in a lot of places already.

[tzujenchanmbd]

Previous discussions:
issue#310, PR#279

We can continue route type discussion in #310

[gcamp]

@cleveramarquet You're missing the reference.md updates!

[leonardehrenfried]

Thanks, @cleveramarquet, for yielding to my request.

[tzujenchanmbd]

Hi @cleveramarquet, Just a quick reminder based on CHANGES.md, a few conditions need to be met before initiating a vote:

The discussion lasts for as long as the advocate feels necessary, but must be at least 7 calendar days.

(Counted from when the PR is opened)

Before calling for a vote, at least one GTFS-realtime producer and one GTFS-realtime consumer should implement the proposed change. It is expected that the GTFS-realtime producer(s) include the change in a public-facing GTFS-realtime feed and provide a link to that data within the pull request comments, and that the GTFS-realtime consumer(s) provides a link in the pull request comments to an application that is utilizing the change in a non-trivial manner (i.e, it is supporting new or improved functionality).

("Development in progress" does not meet this requirement)

Given that these conditions are not currently met, we consider the current vote invalid. You may initiate another vote once all requirements are met.

[cleveramarquet]

Thanks @leonardehrenfried and @felixguendling for the feedback. I have updated route_type to int32 in the .proto file and updated the documentation in reference.md to reflect this. This ensures we support the full range of extended route types from the start.

@gcamp I’ve just pushed an update that includes the reference.md changes. It now contains the full definitions for the Route message, including the route_sort_order, start_date, and end_date fields.

@tzujenchanmbd Thank you for the reminder on the CHANGES.md requirements. I’ve retracted the formal 'Call for Vote' for now.

I will leave the PR open for the required discussion period. In the meantime, I am working with the Transit App team to move their implementation from 'in-progress' to a state that meets the voting requirements. I'll provide the updated links once those are ready.

Regarding the route_type discussion, I’ve updated my PR to int32 to ensure NewRoutes is compatible with extended types immediately. However, to avoid overloading this proposal with a broader debate on global transit mode definitions, I suggest we move any further discussion on standardizing route_type across the rest of the spec to Issue #310 as suggested by @tzujenchanmbd.