You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
GTFS-RT (RT abbreviating Real Time) is an official extension of GTFS that allows agencies to push live updates to consumers about trip updates, service alerts, and sometimes vehicle positions (though the last is almost always better handled by a different source).
At some point in the future, it would be nice to be able to proxy GTFS-RT events through shark so that these updates are present in our ecosystem.
An example update that could come through is a station being closed due to construction, where receiving this event could mark a station as closed, and middlewares/consumers could use that information to accurately indicate next_station.
This and other events result in somewhat-mangled responsibilities between Shark and the soon-to-be-implemented Providence, so whether Shark is the proper location for this functionality is up for debate. Perhaps Providence could simply provide a heartbeat of updates received from GTFS (translated to use our ecosystems parlance: identifiers, namespacing, etc.) and consumers could apply these events in whatever manner they wish.
The text was updated successfully, but these errors were encountered:
Perhaps Providence could simply provide a heartbeat of updates received from GTFS...
So in this system, I'm imagining that Providence posts delay information to the vehicle/station/route topics. Then, clients can get the most recent delay information via meta.last_update(<identifer>, providence) or something similar. New events from Providence get handled automatically along with Shark events.
I like this approach. The only alternative I can think of, which I think goes back to a discussion we had before, is why not roll Providence as Shark middleware? The downside (and I think the reason why we abandoned this design) is that then Shark would have to talk to Timetable, but the upside would be that the Providence middleware could modify route/station/vehicle objects with information like delays and closures, and the client would get this information automatically.
I like the idea of pushing to the individual topics. This is definitely something that needs more investigating in terms of understanding the extent of events that GTFS-RT is capable of producing and how they map to our domain models.
I also really like the current isolation of Shark as a service that only pushes information. Providence is really a complement to the pair of Shark+Timetable. It can't exist unless both of those exist (either of which might not for an agency), and so bringing it inside of Shark seems like a conflation of responsibilities.
GTFS-RT (RT abbreviating Real Time) is an official extension of GTFS that allows agencies to push live updates to consumers about trip updates, service alerts, and sometimes vehicle positions (though the last is almost always better handled by a different source).
At some point in the future, it would be nice to be able to proxy GTFS-RT events through shark so that these updates are present in our ecosystem.
An example update that could come through is a station being closed due to construction, where receiving this event could mark a station as closed, and middlewares/consumers could use that information to accurately indicate
next_station
.This and other events result in somewhat-mangled responsibilities between Shark and the soon-to-be-implemented Providence, so whether Shark is the proper location for this functionality is up for debate. Perhaps Providence could simply provide a heartbeat of updates received from GTFS (translated to use our ecosystems parlance: identifiers, namespacing, etc.) and consumers could apply these events in whatever manner they wish.
The text was updated successfully, but these errors were encountered: