Skip to content
Open
Changes from 1 commit
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
71 changes: 70 additions & 1 deletion gtfs-realtime/proto/gtfs-realtime.proto
Original file line number Diff line number Diff line change
Expand Up @@ -113,6 +113,7 @@ message FeedEntity {
optional Shape shape = 6;
optional Stop stop = 7;
optional TripModifications trip_modifications = 8;
optional Route route = 9;

// The extensions namespace allows 3rd-party developers to extend the
// GTFS Realtime Specification in order to add and evaluate new features and
Expand Down Expand Up @@ -424,6 +425,10 @@ message TripUpdate {
// NOTE: This field is still experimental, and subject to change. It may be formally adopted in the future.
optional string trip_short_name = 6;

// Specify the route associated with the trip, if the route has been added dynamically. The associated `Route` message should be included in the same feed.
// Optional if schedule_relationship is NEW, forbidden otherwise.
optional string route_id = 7;

// The extensions namespace allows 3rd-party developers to extend the
// GTFS Realtime Specification in order to add and evaluate new features
// and modifications to the spec.
Expand Down Expand Up @@ -796,6 +801,8 @@ message TripDescriptor {
optional string trip_id = 1;

// The route_id from the GTFS that this selector refers to.
// This field is used to identify a trip inside an existing GTFS, not to dynamically create or insert new routes
// To assign routes dynamically, use the `trip_properties.route_id` field.
optional string route_id = 5;

// The direction_id from the GTFS feed trips.txt file, indicating the
Expand Down Expand Up @@ -1222,6 +1229,68 @@ message TripModifications {
extensions 9000 to 9999;
}

// NOTE: This field is still experimental, and subject to change. It may be formally adopted in the future.
message Route {
// Identifier of the route. Must be different than any route_id defined in the (CSV) GTFS.
// Required
optional string route_id = 1;

// See definition of routes.agency_id in (CSV) GTFS.
// Conditionally Required, see reference
optional string agency_id = 2;

// See definition of routes.route_short_name in (CSV) GTFS.
// Conditionally Required, see reference
optional TranslatedString route_short_name = 3;

// See definition of routes.route_long_name in (CSV) GTFS.
// Conditionally Required, see reference
optional TranslatedString route_long_name = 4;

// See definition of routes.route_desc in (CSV) GTFS.
optional TranslatedString route_desc = 5;

// See definition of routes.route_type in (CSV) GTFS.
// Required
optional RouteType route_type = 6;
Copy link
Copy Markdown
Contributor

@leonardehrenfried leonardehrenfried Apr 9, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

cc @hbruch

Copy link
Copy Markdown
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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?

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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)

Copy link
Copy Markdown
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Previous discussions:
issue#310, PR#279

We can continue route type discussion in #310


// See definition of routes.route_url in (CSV) GTFS.
optional TranslatedString route_url = 7;

// See definition of routes.route_color in (CSV) GTFS.
optional string route_color = 8;

// See definition of routes.route_text_color in (CSV) GTFS.
optional string route_text_color = 9;

// See definition of routes.route_sort_order in (CSV) GTFS.
optional uint32 route_sort_order = 10;

// The extensions namespace allows 3rd-party developers to extend the
// GTFS Realtime Specification in order to add and evaluate new features and
// modifications to the spec.
extensions 1000 to 1999;

// The following extension IDs are reserved for private use by any organization.
extensions 9000 to 9999;
}

// NOTE: This field is still experimental, and subject to change. It may be formally adopted in the future.
enum RouteType {
// route type as defined in the (CSV) GTFS

LIGHT_RAIL = 0;
SUBWAY = 1;
RAIL = 2;
BUS = 3;
FERRY = 4;
CABLE_CAR = 5;
GONDOLA = 6;
FUNICULAR = 7;
TROLLEY_BUS = 11;
MONORAIL = 12;
}

// NOTE: This field is still experimental, and subject to change. It may be formally adopted in the future.
// Select a stop by stop sequence or by stop_id. At least one of the two values must be provided.
message StopSelector {
Expand Down Expand Up @@ -1256,4 +1325,4 @@ message ReplacementStop {

// The following extension IDs are reserved for private use by any organization.
extensions 9000 to 9999;
}
}