Spatial coverage of SIRI implementation

[Maya Tzunz]

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 https://groups.google.com/g/siri-developers/c/0QWYQOv3UHQ/m/ayLm3iqEoEoJ so I assume there's some logic to my question.

Thank you and peace to all

[Christophe Duquesne]

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]

If you want to take a look at a concrete example here are MTA's BusTime SIRI API docs:

https://bustime.mta.info/wiki/Developers/SIRIIntro

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

Sean

Sean Barbeau

Center for Urban Transportation Research

University of South Florida

[kim....@gmail.com]

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.