Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add GTFS-RT Source #33

Open
faultyserver opened this issue Mar 22, 2017 · 2 comments
Open

Add GTFS-RT Source #33

faultyserver opened this issue Mar 22, 2017 · 2 comments

Comments

@faultyserver
Copy link
Member

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.

@elliottwilliams
Copy link
Member

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.

@faultyserver
Copy link
Member Author

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants