derhuerst
commented
4 years ago Some comments from the draft Google doc:
Finally, the consumer should ensure that updates received together in a single
FeedMessagebecome visible to an end user simultaneously. The user should never observe a state where some updates in aFeedMessagehave been applied but others have not.The GTFS-RT reference document states that the
FeedEntity.idandFeedEntity.isDeletedfields are only relevant to incremental feeds. However, given the differential semantics outlined above there is not a clear need to explicitly delete RT messages (other thanAlerts, see discussion below) as one can always simply provide an update that will supersede them.
TripUpdates: Both scheduled and added trips can beCANCELEDby sending anotherTripUpdatemessage referencing the same trip ID.VehiclePositions: When a message is received saying the vehicle isSTOPPED_ATthe last stop in a trip, or saying that a vehicle has moved on to a different trip, its state with respect to that first trip is effectively removed. However, it might be helpful to provide a means to unambiguously signal that a vehicle has gone out of service.Alerts. Unlike the other two message types, multipleAlerts may accumulate to the same GTFS entity. Without alert IDs and deletion flags, it would not be possible to remove them in differential mode. We can completely sidestep the problem by simply not using differentialAlerts.Alertdatasets are generally small and do not benefit greatly from low update latency. They seem to be a good use case for theFULL_DATASETprovider push combination.
I think these steps must be implemented for full compatibility:
- [x] consume
FeedMessages instead ofFeedEntitys - [ ] delete
TripUpdateentities usingDELETED - [ ] delete
VehiclePositionentities usingSTOPPED_AT - [x] support
ttl: Infinity - [ ]
lib/entities-store: respectFeedMessage.header.timestampwhen setting the expiry timer?
good to know:
- Differential vs. Incremental. The reference and specification use both terms: differential and incremental. We should choose only one and use it consistently. These same terms are used in backup systems, and the behavior here seems closer to incremental backups where only individual files that have changed since the last backup (be it incremental, differential, or full) are included. In some sense, GTFS-RT as a whole is “differential” with respect to scheduled GTFS, and the new mode we are discussing is “incremental” with respect to a GTFS-RT
FULL_DATASET.
We should carefully read the draft
DIFFERENTIALspec and make sure this package follow it. There are already too many homegrown almost-compatible GTFS-RT tools out there, this package shouldn't be another one!