Repository navigation
Add NewRoutes to GTFS-RT to support dynamic service (#606) - #621
cleveramarquet wants to merge 6 commits into
Conversation
Add NewRoutes to proto
|
|
||
| // See definition of routes.route_type in (CSV) GTFS. | ||
| // Required | ||
| optional RouteType route_type = 6; |
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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)
There was a problem hiding this comment.
I've updated route_type to int32 to support extended types as suggested. Thanks for the catch!
There was a problem hiding this comment.
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
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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.
Change route_type to int32 to support extended route types per PR feedback
|
@cleveramarquet You're missing the reference.md updates! |
|
Thanks, @cleveramarquet, for yielding to my request. |
|
Hi @cleveramarquet, Just a quick reminder based on CHANGES.md, a few conditions need to be met before initiating a vote:
(Counted from when the PR is opened)
("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. |
Adding documentation for the Route message including route metadata, sort order, and activation dates to align with the NewRoutes proposal
Updated gtfs-realtime.proto to include: route_sort_order (uint32) for display sequencing. start_date and end_date (string) for route activation periods. Added comments referencing the corresponding (CSV) GTFS definitions to maintain specification consistency.
|
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. |
etienne0101
added
GTFS Realtime
Updated agency_id, route_short_name, and route_long_name to match the requirements in the GTFS-NewRoutes proposal document.
|
The |
That's correct @felixguendling, this should not stop us from making progress here. We can take care of standardizing more values for route_type in another pull request. We are very close to having both public endpoints in between Hitachi (Clever Devices) and Transit running so we can officially put this pull request for a vote soon. |
…#34) Repoints the gtfs-spec submodule from the bare head of google/transit#621 to TransitApp/transit@vendored-with-proposals, which is upstream master plus a merge commit per proposal we adopt early: #611 cyclist positions VehiclePosition 12/13, CarriageDetails 6/7 #621 NewRoutes Route, FeedEntity.route, TripProperties.route_id Previously the pin could only carry one in-flight proposal at a time, since a submodule pin is a single commit and each PR head sits on its own base. Pinning an integration branch lifts that limit and also recovers the 15 master commits both heads were missing (Alert.communication_period, Alert.impact_period, Cause.SPECIAL_EVENT). The pin stays fetchable through the existing .gitmodules URL: GitHub serves any commit in a public fork network by SHA from the parent repo, which is the same mechanism that made the previous pin work. No .gitmodules change and no `git submodule sync` needed. Node bindings regenerated (CJS + ESM + both .d.ts); version 1.11.0. The diff against 1.10.0 is purely additive - no types removed. Refreshing the branch: reset it to upstream master and re-merge each still-open PR head. Never merge master into it - google/transit squash-merges, so a landed PR arrives as a new commit that git will not recognise as already applied. Deleting it: once #611 and #621 have both landed upstream, repin gtfs-spec to google/transit master and delete the branch. Co-authored-by: Claude Opus 5 <noreply@anthropic.com>
|
Hi @tzujenchanmbd /@gcamp, whenever you have a moment, could you please approve the pending workflow runs on this PR so the security scan can execute? Thank you! |
7 participants
Description
This proposal introduces a
NewRoutesmessage to theFeedEntityin 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
Routeto 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