Understanding The Service Interface for Real Time Information (SIRI) 2.0 Transit Standard

As part of our wider research into smart cities, and the real time data that make our cities go round, we have been studying transit systems, which includes developing an awareness of the standards being used to make transit data available via APIs. So far we have profiled the General Data Transit Feed (GTFS) standard, both static and real time formats. Next up, is profiling another standard that is used in Europe, which we are beginning to see adoption within the United States, called the Service Interface for Real Time Information (SIRI).

The Service Interface for Real Time Information is made up of eight different services that are comparable to GTFS, but provide a different view of the data that makes transit systems operate.

– Production Timetable Service – Supports the dynamic exchange of planned schedules, including updates. These may be used by AVMS systems to predict and monitor vehicle progress.
– Estimated Timetable Service – Supports the exchange of target schedules in real time, including updates. These may be used by AVMS systems to predict and monitor vehicle progress.
– Stop Timetable Service – Provides information about schedules for arrivals and departures at a Stop point.
– Stop Monitoring Service – Provides information about arrivals and departures at a Monitoring, i.e. Stop point.
– Vehicle Monitoring Service – Provides information about the movement of a vehicle, and its progress against the target schedule.
– Connection Timetable Service – Provides information about schedules for for interchanges at a connection point.
– Connection Monitoring Service – Provides information for interchanges at a connection point to support guaranteed connection services
– General Message Service – Supports the exchange of general messages.

We are currently mapping some GTFS Realtime feeds to SIRI for a couple major cities, learning more about how the transit standards differ. The SIRI standard leverages SOAP as the transport layer, and returns XML as message format. After seeing MTA Bus authority in New York provide a SIRI API using a more RESTful approach, we wanted to learn more. The message format of GTFS makes it difficult for us to proxy using Streamdata.io, as the service is meant to work with common web APIs that speak JSON. However, the Service Interface for Real Time Information APIs provide a much more compatible approach, so we want to explore a little more to see what is possible, and potentially transform GTFS into SIRI and stream using Server-Sent Events (SSE), delivering truly real time transit data update using JSON Patch.

Next, we are converting the Siri 2.0 examples we have found into JSON examples, complete with JSON schema. Then we will invest more time into converting GTFS to SIRI 2.0 once we have the schema mapped to both the static and real time feeds. We’ve found SIRI feeds in New York, and San Francisco, and have begun identifying other transit authorities who have adopted. While being somewhat verbose, SIRI provides a much more accessible format than GTFS, which has the potential to speak to a wider audience of API consumers–as well as being something that we can easily proxy and deliver transit data in real time using Streamdata.io.