We’ve been working to understand how we can make transit data more real time, and one of the obstacles we have hit was that the General Data Transit Feed (GTFS) Real-time standard, which is the dominant standard in the United States can’t be easily proxied using Streamdata.io. The GTFS message format isn’t in the JSON format, making it incompatible with streaming using JSON Patch. We noticed that New York, San Francisco, and other transit authorities had begun to provide feeds using the Service Interface for Real Time Information (SIRI) standard, which is used primarily in Europe, and wanted to see if we can help incentivize the development of more SIRI compatible transit feeds, as it is something we can easily make real time with Streamdata.io.
After learning more about SIRI, we wanted to better understand how we could evolve it beyond its SOAP and XML roots, and make it more of a modern web API that speaks JSON. We found a nice set of SIRI 2.0 examples created by OneBusAway, which were in XML format. With a little voodoo we were able to convert them to JSON, and then generate JSON schema for each of the SIRI services. There are nine services available, that we converted as part of this round of work.
– Connection Monitoring (Distributor Example & Schema) (Feeder Example & Schema) * Not sure why there are two here?
– Connection Timetable (Example & Schema)
– Estimated Timetable (Example & Schema)
– Facility Monitoring (Example & Schema)
– General Message (Example & Schema)
– Situation Exchange (Example & Schema)
– Stop Monitoring (Example & Schema)
– Stop Timetable (Example & Schema)
– Vehicle Monitoring (Example & Schema)
Then there are five discovery services available that we added as well to the round of the available APIs for each of the transit APIs.
– Product Categories (Example & Schema)
– Lines (Example & Schema)
– Service Features (Example & Schema)
– Stop Points (Example & Schema)
– Vehicle Features (Example & Schema)
I have avoided the common services that provide subscription and status, as I think these things can be handled through the API infrastructure, and by making things more real time using Streamdata.io. It is tough taking a SOAP web service and translating into a web API, as things aren’t always as intuitive, but the JSON versions should help simplify things a little bit. Next, I’ll craft a handful of API paths for getting at the SIRI transit data. I’m going to make them all GET requests, further simplifying things so that they are easier to proxy and stream, but then also maybe down the road, we can properly use the HTTP verbs POST, PUT, and even DELETE when relevant.
The next major hurdle will be mapping GTFS to SIRI. It’s not a perfect match, and there is some loss that will occur. Once we have the schema mapped we can show how to easily convert GTFS into SIRI format, making available via API, and then provide truly real-time transit updates using Streamdata.io. Both GTFS Real-time and SIRI use a POST API request to get the job done, and neither are truly streaming, so once we have available in a JSON format we can use Server-Sent Events (SSE), ad JSON Patch to make any transit feed stream via the web, via mobile phones, or even directly between systems, without all the polling of existing transit APIs.
Follow us on social