More clarifications on trip modifications

[gcamp]

Hi everyone,

While we're having more and more producer creating trip modifications, we identified a couple common misconception that can be clarified in the specification.

This PR clarifies the following point :

• Specify that the shape provided should be the full shape and not just the detour
• Clarification on usage of ids inside a GTFS-rt (should reference the shape_id or stop_id, not id of the FeedMessage)
• Clarification that linked entities should be done inside the same feed
• Even if not about trip modifications, the definition of shape_id that's inside TripProperties was also not in sync between reference and the proto, took the opportunity to fix this.

[jfabi]

@gcamp Is this proposed clarification meant to imply that linked entities (new Stops and Shapes) must be within the same feed file/URL, or just that it be within a some known/published file/URL? If the former, should the same requirement apply to service_alert_id as well?

As far as I know, there isn't a best practice as to whether producers should have only combined GTFS-realtime URL. Are there any producers publishing separate Stops.pb and Shapes.pb files, or are all current examples of TripModifications including these within the same Protobuf URL?

[doconnoronca]

Is there a publically available feed that regularly includes Trip Modifications?

[gcamp]

@jfabi yes it was meant to mean they should be inside the same file. All the trip modifications producers we've seen except one had everything in the same feed. We asked that producer to change it because it was required in our implementation. We have seen 5 producers so far, but not all of them are in production at the moment.

I think it make sense for it to be required to be in the same file because they are an absolute requirement for a trip modification to be processed. Without the linked Shape/Stop, we just can't do anything (not even partially) with it. There are some linked information in other feeds but they are not required for processing the feed. I think service_alert_id is also not required for a trip modification to mean anything so I don't think I would require it.

@doconnoronca the examples feeds given here are still valid. Baltimore (almost?) always has a detour live.

[doconnoronca]

I detected a trip modification in the wild with the Santa Cruz METRO who uses a Clever Devices system.

The feed is at https://rt.scmetro.org/gtfsrt/trips

[gcamp]

I'll start the vote on Monday if there are no further objections to the proposal!

[gcamp]

I’m opening a vote on this PR.

The changes are only clarification and are still experimental. Consumer : Transit. Producers : Swiftly, exo, Clever, GMV.

Voting ends on May 5th at 23:59:59 UTC.

[mads14]

+1 Swiftly

thanks for the clarifications and clean up.

[skinkie]

Only some minor typo's.

OpenGeo +1

[stevenmwhite]

+1 GMV

[ckraatz]

+1 from SimplifyTransit. I appreciate the additional clarity about shapes in particular.

I’ll also note that this is a very good example of why GTFS governance needs to:

1. continue encouraging a pipeline of innovation and experimentation
2. lengthen the testing phase to catch issues while organic adoption expands from the Early to Late Majority
3. vote to adopt the change once there’s already so much actual adoption the vote is a mere formality. (and a signal to the laggards that they’d better catch up!)

[gcamp]

The voting period has concluded. The voting passed with 5 votes in favor.

• Swiftly
• Clever
• GMV
• OpenGeo
• SimplifyTransit

Thanks, everyone!

[tzujenchanmbd]

@gcamp It looks like this branch has conflicts...(possibly since merging #504)
Could you have a look and resolve the conflicts before we merge?

[tzujenchanmbd]

Thanks! @gcamp

[doconnoronca]

TransSee is now consuming Trip Modifications starting with Kitsap Transit (Clever Devices).

Example modified trip