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, too 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!