Spatial coverage of SIRI implementation

Skip to first unread message

Maya Tzunz

Mar 7, 2022, 7:05:20 AM3/7/22
to SIRI Developers
Hey friends!

A newbie here, with a high level question. Who, what and where determine the scope/subset of data SIRI can query?
I'm more familiar with GTFS (regardless of the static vs. RT diff), where I can wrap my head around the idea of plotting stops locations on a map and learn what's the data coverage (I won't expect a trip plan from Paris if my data only covers London).

Closest I've got is this comment so I assume there's some logic to my question.

Thank you and peace to all

Christophe Duquesne

Mar 11, 2022, 9:42:08 AM3/11/22
to SIRI Developers
SIRI is for realtim, so you can't really compare it to GTFS, but more to GTFS-RT
SIRI is implemented as a set of service, and each request can have some parameters, so you define the scope using the parameters to your request (available parameters are of course different depending on the request: stop, line, area, time interval, etc.).

Also note that most SIRI (and NeTEx) objects have a location structure information. In SIRI the information about stop point location can be received thanks to the StopPointsDiscovery however it's usually more likely hat you receive them previously via NeTEx StopPlaces (remember that SIRI is for realtime and NeTEx for scheduled information: SIRI Discovery services are available for convenience when you don't have a NeTEx dataset, but it only provides a very limited set of information).
Realtime location information (like vehicle location) is of course part of SIRI messages.

Sean Barbeau

Mar 16, 2022, 10:16:24 AM3/16/22
to SIRI Developers
If you want to take a look at a concrete example here are MTA's BusTime SIRI API docs:

Here they've paired GTFS for schedule data with a REST API formatted after SIRI for real-time data.


Sean Barbeau
Center for Urban Transportation Research
University of South Florida

Mar 22, 2022, 8:38:47 PM3/22/22
to SIRI Developers
At a high level, the scope is determined by Topic parameters passed in the request.

For example with ProductionTimetable (PT) or EstimatedTimetable (ET) you may only be interested in a subset of routes.  In this case you pass the optional LineRef element for each route (or train line) that you are interested in.  You can also filter based on the company operating the service with OperatorRef.

For StopTimetable (ST) or StopMonitoring (SM) you are generally only interested in a single stop ID, or perhaps a list of stop IDs.  In this case you would include a MonitoringRef element for each stop ID you are interested in.

You can also filter SM/ET responses by including a PreviewInterval value to limit what is returned to only those services within say the next hour.  Because real-time updates are not generally much use more than an hour or two into the future.

Reply all
Reply to author
0 new messages