Sommaire

Opération
Mode

CheckStatus

Permet de vérifier l'état du serveur

Il est nécessaire d’implémenter la surveillance du serveur par un client. Ceci est particulièrement crucial en mode abonnement avec mise à jour incrémentale. La période d’interrogation par le client est un paramètre du système (voir ci-dessous).


Requête
CheckStatusRequest Obligatoire Requête de vérification d'état Exemple
RequestTimestamp 1:1 Oui Datation de la requête. 2023-03-07T15:00:00
yyyy-MM-ddTHH:ii:ss
RequestorRef 1:1 Oui Identifiant du demandeur. Toujours utilisé "opendata". opendata
MessageIdentifier 0:1
1:1		 Oui Identifiant de la requête. opendata:Message::{IDENTIFIANT_UNIQUE_MESSAGE}:LOC

Réponse
CheckStatusResponse Réponses aux requêtes de vérification d'état
ResponseTimestamp 1:1 Date d'émission de la requête.
ProducerRef 0:1
1:1		 Identifiant du répondant.
ResponseMessageIdentifier 0:1
1:1		 Identifiant unique du message de réponse.
RequestMessageRef 0:1
1:1		 Identifiant de la requête à laquelle on répond.
Status 0:1
1:1		 Signale si le système est bien disponible.
ErrorCondition : 0:1 Signalement d'erreur.
Au choix :
a) ServiceNotAvailableError -1:1 Service indisponible
b) OtherError Autre erreur.
Description 0:1 Description de l'erreur.
ServiceStartedTime 0:1 Dernière date et heure de (re)démarrage du serveur SIRI

LinesDiscovery

Permet de récupérer l'ensemble des lignes commerciales ainsi que les destinations associées

Requête
LinesDiscoveryRequest Obligatoire Requête d'accès à la liste des lignes Exemple
RequestTimestamp 1:1 Oui Date d'émission de la requête. 2023-03-07T15:00:00
yyyy-MM-ddTHH:ii:ss
RequestorRef 1:1 Oui Identifiant du demandeur. Toujours utilisé "opendata". opendata
MessageIdentifier 0:1 Oui Identifiant unique de ce message. opendata:Message::{IDENTIFIANT_UNIQUE_MESSAGE}:LOC
OperatorRef 0:1 Non Filtre permettant de n'obtenir que les lignes exploitées par un opérateur donné.

Réponse

La structure ci-dessous présente la description d'une ligne tel que retourné par le service (mais sans les entêtes génériques de réponse SIRI).

AnnotatedLineStructure Description simplifiée d'une ligne
LineRef 1:1 Identifiant de la ligne (issu du référentiel des lignes).
LineName 1:* Nom de la ligne (issu du référentiel des lignes)
Monitored 1:1 Le champ obligatoire "Monitored" sera toujours égal à "true" indiquant ainsi que l'on dispose bien d'information temps réel à ce point (inutile de traiter les arrêts et lignes pour lesquels on n'a pas d'information temps réel)
Destinations 0:* Le champ facultatif "Destinations" reste facultatif et permettra d'indiquer, en plus des extrémités de la ligne, si elle est composée de plus de deux itinéraires (aller et retour) (1)

La structure suivante présente la liste des terminus destination des parcours de la ligne

AnnotatedDestinationStructure Description d'une destination
DestinationRef 1:1 Identifiant du point d'arrêt terminus.

StopPointsDiscovery

Permet d'afficher la liste des arrêts commerciaux

Requête
StopPointsDiscoveryRequest Obligatoire Requête d'accès à la liste des arrêts Exemple
RequestTimestamp 1:1 Oui Date d'émission de la requête. 2023-03-07T15:00:00
yyyy-MM-ddTHH:ii:ss
RequestorRef 1:1 Oui Identifiant du demandeur. Toujours utilisé "opendata". opendata
MessageIdentifier 0:1 Oui Identifiant unique de ce message. opendata:Message::{IDENTIFIANT_UNIQUE_MESSAGE}:LOC
OperatorRef 0:1 Non Filtre permettant de n'obtenir que les arrêts utilisé par un opérateur donné.
LineRef 0:1 Non Filtre permettant de n'obtenir que les arrêts utilisé par une ligne donnée. LIAOD:Line::01:LOC
Le numéro de ligne commerciale doit être indiqué.

Réponse

La structure ci-dessous présente la description d'un arrêt tel que retourné par le service (mais sans les entêtes génériques de réponse SIRI)

AnnotatedStopPointStructure Description simplifiée d'un arrêt
StopPointRef 1:1 Identifiant du point d'arrêt.
StopName 0:*
1:*		 Nom du point d'arrêt.
Lines 0:* Liste des lignes passant à l'arrêt.

StopMonitoring

Permet de récupérer l'information temps réel à un point d'arrêt spécifié

La requête d'information temps réel au point d'arrêt permet de retourner, à un instant t, les prévisions de passage de véhicules sur ce point d'arrêt.


Requête
StopMonitoringRequest Obligatoire Requête pour obtenir des informations temps réel sur les heures d'arrivée et de départ à un point d'arrêt Exemple
Version 1:1 Non Version du service "Stop Monitoring".
RequestTimestamp 1:1 Oui Date d'émission de la requête. 2023-03-07T15:00:00
yyyy-MM-ddTHH:ii:ss
RequestorRef 1:1 Oui Identifiant du demandeur. Toujours utilisé "opendata". opendata
MessageIdentifier 0:1 Oui Identifiant unique de ce message. opendata:Message::{IDENTIFIANT_UNIQUE_MESSAGE}:LOC
PreviewInterval 0:1 Non Si ce paramètre est présent, il indique que l'on souhaite recevoir des informations sur toute arrivée et tout départ intervenant dans la durée indiquée (comptée à partir de l'heure indiquée par le paramètre suivant : StartTime).
Dans le cas contraire où le paramètre StartTime n'est pas présent, l'heure courante est utilisée.		 PT{VALEUR_DUREE}{TYPE_DUREE}0.000S
Le champ "TYPE_DUREE" propose :
  • H => Heure,
  • M => Minute

Le champ "VALEUR_DUREE" peut être renseigné selon le type de durée (ci-dessus) :
  • 1 à 23 => Heures
  • 1 à 59 => Minute

Exemple avec un temps défini pour un interval de 2H :
PT2H0.000S
StartTime 0:1 Non Heure à partir de laquelle doit être compté le PreviewInterval 2023-03-07T15:00:00
yyyy-MM-ddTHH:ii:ss
MonitoringRef 1:1 Oui Identifiant du point d'arrêt concerné par la requête Correspond à la valeur de l'arrêt retournée avec StopPointsDiscovery => LIAOD:StopPoint:Q:{IDAP_ARRET}:LOC

En mode requête, on peut renseigné un arrêt unique : LIAOD:StopPoint:Q:3188:LOC pour l'arrêt R. COTY par exemple.

Et en mode abonnement, on peut renseigné un ou plusieurs arrêts : LIAOD:StopPoint:Q:3188:LOC pour l'arrêt R. COTY et LIAOD:StopPoint:Q:4520:LOC pour l'arrêt PL. THIERS.

Depuis le simulateur, il est possible de mettre plusieurs arrêts délimités par des ';'. Exemple pour l'abonnement aux deux arrêts ci-dessus : "3188;4520".
LineRef 0:1 Non Filtre permettant de n'obtenir que les départs et arrivées pour une ligne donnée (dont on fournit l'identifiant) Correspond à la valeur de la ligne retournée avec LinesDiscovery => LIAOD:Line::T:LOC pour la ligne du Tramway (A et B) par exemple.
DestinationRef 0:1 Non Filtre permettant de n'obtenir que les départs et arrivées pour une destination donnée (dont on fournit l'identifiant de point d'arrêt) Correspond à la valeur de la destination d'une ligne retournée avec LinesDiscovery => LIAOD:StopPoint:Q:3188:LOC pour l'arrêt R. COTY par exemple.
StopVisitTypes 0:1 Non Indique si l'on souhaite avoir les départs, les arrivées ou les deux.
Seule la valeur « departures » est obligatoire. Si le champ n’est pas renseigné, la valeur par défaut est « all ».

Quelques règles de gestion sont précisées :

  • dans le cas du StopVisitTypes = all ou departures, si l’heure de départ n'est pas connue (pour les SAEIV bus notament) alors l'heure de départ sera renseignée égale à l'heure d’arrivée et les 2 champs sont renseignés
  • Inversement (pour la SNCF notamment), dans le cas du StopVisitTypes = all ou arrivals, si l’heure d’arrivée n'est pas connue alors l'heure d’arrivée prend la valeur de l'heure de départ et les 2 champs sont renseignés
Il faut noter que, pour la gestion des correspondances, l’heure d’arrivée sera particulièrement utile. 		Toujours renseigné à "all" par défaut, ou possibilité de mettre soit :
  • all => Tous,
  • departures => Départs,
  • arrivals => Arrivées
MaximumStopVisits 0:1 Non Nombre maximal d'informations de départ ou d'arrivée que l'on souhaite recevoir sur l’arrêt requêté. Si aucune valeur n’est fournie, toutes les informations disponibles seront remontées.
De plus « 0 » est une valeur interdite pour ce champ (erreur). 		Valeur par défaut : 5
MinimumStopVisitsPerLine 0:1 Non Ce paramètre permet de demander un nombre minimum de réponses par ligne passant à l'arrêt.

Ces passages doivent toutefois rester dans le PreviewInterval

Il est recommandé de ne pas utiliser simultanément MaximumStopVisits et MinimumStopVisitsPerLine : si toutefois cela arrivait, le MaximumStopVisits serait dominé par le MinimumStopVisitsPerLine et la liste des informations disponibles pourrait être plus importante que stipulé par MaximumStopVisits. 		Pour avoir les 3 prochains passages par ligne passant à l'arrêt souhaité, on peut renseigner la valeur : 3.

Demande d'abonnement
StopMonitoringSubscriptionRequest Obligatoire Requête d'abonnement pour obtenir des informations temps réel sur les heures d'arrivée et de départ à un point d'arrêt Exemple
SubscriberRef 0:1
1:1		 Oui Identifiant du système demandeur. Toujours utilisé "opendata" opendata
SubscriptionIdentifier 1:1 Oui Identifiant de l'abonnement pour le système demandeur. opendata:Subscription:{OPERATION}:{IDENTIFIANT_UNIQUE}:LOC
InitialTerminationTime 1:1 Oui Date et heure de fin de l'abonnement. Pour un abonnement se terminant le 09 mars 2023 à 17h00 :
2023-03-09T17:00:00
StopMonitoringRequest 1:1 Oui Voir StopMonitoringRequest (ci-dessus)
ChangeBeforeUpdates 0:1 Oui Permet d'indiquer un écart de temps en dessous duquel on ne souhaite pas être notifié (si l'on demande un seuil de 5mn et qu'un horaire de départ ou d'arrivée change de 2mn, on ne sera pas notifié, évitant ainsi des flux d'information inutiles).

Si ce champ n'est pas présent, une valeur de 5mn est prise par défaut. 		PT{VALEUR_DUREE}{TYPE_DUREE}0.000S
Le champ "TYPE_DUREE" propose :
  • H => Heure,
  • M => Minute

Le champ "VALEUR_DUREE" peut être renseigné selon le type de durée (ci-dessus) :
  • 1 à 23 => Heures
  • 1 à 59 => Minute

Exemple avec un temps défini pour un interval de 1MN :
PT1M0.000S

Réponse
StopMonitoringDelivery Delivery for Stop Monitoring Service
version 1:1 Numéro de version du service StopMonitoring
MonitoringRef 0:*
1:1		 Identifiant du point d'arrêt concerné par la requête.
MonitoredStopVisit 0:* Description des passages à l'arrêt
MonitoredStopVisitCancellation 0:* Indication qu'un passage précédemment signalé ne doit plus être affiché (indique généralement que le véhicule a franchi l'arrêt).

Notifications abonnement

Pour fournir les données temps réels liés aux horaires de passages, la méthode notifyStopMonitoring doit être émise par le client SIRI en mode abonnement.

Les informations contenues par cette structure sont les mêmes que l'on soit dans le mode requête/réponse. La première notification contiendra l’intégralité des données temps réel correspondant à la requête. Par la suite, seules les structures MonitoredStopVisit modifiées et répondant aux critères suivants déclenchent la transmission d’une notification :

  • L’horaire estimé et/ou l’horaire réalisé d’arrivée (ActualArrivalTime et/ou ExpectedArrivalTime) à l’arrêt ont varié d’une valeur supérieure au seuil déclenchant l’envoi d’une notification (ChangeBeforeUpdates) depuis la dernière notification.
  • L’horaire estimé de départ de l’arrêt (ExpectedDepartureTime) a varié d’une valeur supérieure au seuil déclenchant l’envoi d’une notification (ChangeBeforeUpdates) depuis la dernière notification.
  • Le statut de l’horaire d’arrivée et/ou de départ (ArrivalStatus et/ou DepartureStatus) a changé depuis la dernière notification.
  • La destination de la course (DestinationRef) correspondant à l’horaire de passage a changé depuis la dernière notification.
  • Le quai de départ (DeparturePlatformName) de l’horaire de passage a changé depuis la dernière notification.
  • Le véhicule desservant l’arrêt lié à l’horaire arrive ou quitte cet arrêt (VehiculeAtStop).


Structure MonitoredStopVisitCancellation


Le MonitoredStopVisitCancellation sert, en mode abonnement, à "annuler" un passage précédemment notifié. Il est utilisé systématiquement en cas de réalisation d'un passage (au départ dans le cas général, à l'arrivée dans le cas d'un terminus destination ou si seules les arrivées sont demandées). Il existe deux modes de gestion des passages supprimés (*) :

  • transmission immédiate (lors de la suppression) d'un MonitoredStopVisitCancellation
  • gestion en deux phases :
    • notification de la suppression par un MonitoredStopVisit avec xxxStatus égal à 'cancelled',
    • puis envoi d'un MonitoredStopVisitCancellation à l'échéance du AimedxxxTime.

(*) Sont concernés : les passages supprimés par manœuvre de régulation, les passages supprimés par une déviation, les passages dont le véhicule est neutralisé, et les passages commerciaux transformés en haut-le-pied.

MonitoredStopVisitCancellation Indication qu'un passage précédemment signalé ne doit plus être affiché (indique généralement que le véhicule a franchi l'arrêt).
RecordedAtTime 1:1 Heure à laquelle l'annulation de passage a été signalée/publiée.
ItemRef 0:1 Identifiant du passage annulé.
MonitoringRef 1:1 Identifiant du point d'arrêt.
LineRef 0:1 Identifiant de la ligne (celle de la course pour laquelle le passage à l'arrêt est annulé, la course elle-même peut être identifiée par le paramètre FramedVehicleJourneyRef).
VehicleJourneyRef 0:1 Identification de la course concernée.
Reason 0:* Message expliquant la cause de l'annulation.

Notes :
Renseigné avec les valeurs suivantes :

  • 'diversion' dans le cas d'une déviation
  • 'cancellation' dans le cas d'une suppression par manoeuvre
  • 'vehicle neutralization' dans le cas de la neutralisation d'un véhicule
  • '' (chaine vide) dans le cas du départ du véhicule (de son arrivée pour le terminus destination)


Les descriptions de passage à l’arrêt sur course sont réalisées au moyen du MonitoredStopVisit

MonitoredStopVisit Description du passage d'un véhicule à un arrêt (dans le cadre d'une course)
RecordedAtTime 1:1 Heure à laquelle la donnée a été mise à jour.
ItemIdentifier 0:1
1:1		 Identifie cette information : cela correspond en fait à une identification du couple arrêt-course, et permettra par la suite une éventuelle annulation (cas où l’arrêt n’est plus desservi). Il doit être unique et pérenne et bien identifier le passage à l'arrêt.
MonitoringRef 1:1 Référence du point d'arrêt.
MonitoredVehicleJourney 1:1 Description de la course.

La structure MonitoredVehicleJourney décrit les attributs temps réel de la course.

MonitoredVehicleJourney Description du passage d'un véhicule à un arrêt (dans le cadre d'une course)
LineRef 0:1
1:1		 Identifiant de la ligne.
FramedVehicleJourneyRef 0:1 Identification de la course.
JourneyPatternInfo 0:1 Voir JourneyPatternInfoGroup.
VehicleJourneyInfo 0:1 Voir VehicleJourneyInfoGroup.
DisruptionGroup 0:1 Voir DisruptionGroup.
JourneyProgressInfo 0:1 Voir JourneyProgressInfoGroup.
OperationalInfo 0:1 Voir OperationalInfoGroup.
BlockRef & CourseOfJourneyRef.
TrainNumberRef 1:1 Numéro de train.
MonitoredCall 0:1 Informations sur les horaires concernant l'arrêt considéré.

La structure FramedVehicleJourneyRef identifie une course.

FramedVehicleJourneyRef (0:1) Identification d'une course.
DataFrameRef 0:1
1:1		 Contexte d'identification de la course.
DatadVehicleJourneyRef 0:1 Identification de la course elle-même.

Liste des blocs (JourneyPatternInfoGroup, VehicleJourneyInfoGroup, ServiceInfoGroup, JourneyEndNamesGroup)

JourneyPatternInfoGroup Groupe d'attributs pour la description.
JourneyPatternRef 0:1 Identifiant de la mission.
JourneyPatternName 0:1 Nom ou numéro de course présenté au public.
VehicleMode 0:1 Mode de transport pour cette mission (bus / tram / rail).
PublishedLineName 0:*
1:1		 Nom de la ligne.
DirectionName 0:* Nom de la direction de la mission.
VehicleJourneyInfoGroup Description de la course.
ServiceInfo 0:1 Voir ServiceInfoGroup.
JourneyEndName 0:1 Voir JourneyEndNamesGroup.
ServiceInfoGroup
OperatorRef 0:1 Identifiant de l'exploitant.
VehicleFeatureRef 0:* Service spécifique disponible dans la véhicule ('shortTrain' : Train court / 'longTrain' : Train long, 'lowFloor' : Accès PMR)
JourneyEndNamesGroup
DestinationRef 0:1
1:1		 Identifiant du dernier arrêt de la course.
DestinationName 0:* Nom de l'arrêt de destination (si l'identifiant DestinationRef est fourni, le nom doit l'être aussi).

Structure JourneyProgressInfoGroup

JourneyProgressInfoGroup Groupe d'attributs précisant l'avancement sur la mission.
Monitored 0:1 Indique si le véhicule est toujours localisé (la valeur "false" indique une délocalisation du bus). Valeur par défaut: "true".
VehicleLocation 0:1 Indique la position du véhicule (voir LocationStructure).
Ce champ est obligatoire quand cette structure fait partie d'une réponse à une requête de type "VehicleMonitoring" (il reste facultatif dans les autres cas).
Bearing 0:1 Indique l'orientation (cap) du véhicule.
Delay 0:1 Indique le niveau de retard du véhicule (une valeur négative indique une avance).

Structure Location

LocationStructure (0:1) Geospatial Location.
srsName 0:1 Identifiant du référentiel de projection (conforme EPSG, défini par l'OGC, et tel qu'utilisé par GML).
choix La localisation peut être fournie soit en WGS84 soit dans un référentiel projeté (Lambert 2 étendu, par exemple).
a) Longitude & Latitude -1:1 Longitude à partir du méridien de Greenwich : -180° (East) à +180° (West). Degrés décimaux.
Latitude à partir de l'équateur. 90° (South) à +90° (North). Degrés décimaux.
b) Coordinates -1:1 Coordonnées au format GML avec cohérence avec l'attribut srsName.

Structure MonitoredCall

MonitoredCall Informations horaires pour l'arrêt.
StopPointRef 0:1 Identifiant du Point d'arrêt.
Order 0:1 Numéro d'ordre de l'arrêt dans le chaînage.
StopPointName 0:*
1:1		 Nom du point d'arrêt
VehicleAtStop 0:1 La Valeur « true » indique que le véhicule est à l'arrêt
Valeur par défaut : « false »
DestinationDisplay 0:*
1:1		 Destination telle qu'elle est affichée sur la girouette du véhicule à cet arrêt (ou sur l'afficheur local).
AimedArrivalTime 0:1 Heure d'arrivée théorique (ou commandée).
ActualArrivalTime 0:1 Heure d'arrivée effectivement mesurée.
ExceptedArrivalTime 0:1 Heure d'arrivée estimée par le SAE.
ArrivalStatus 0:1 Caractérisation de l'horaire d'arrivée attendu (ou mesuré si le véhicule est à quai)
Paramètres disponibles (onTime / early / delayed / cancelled / missed / arrived / notExpected / noReport)
Valeur par défaut : « onTime ».

Les codes suivants sont égalements disponible :
  • missed : le véhicule n'a pas marqué l'arrêt alors qu'il aurait dû, mais la course continue.
  • notExpected : départ ou arrivée non planifié(e)
ArrivalPlatformName 0:1 Identification ou nom du quai d'arrivée.
AimedDepartureTime 0:1 Heure de départ théorique (ou commandée).
ActualDepartureTime 0:1 Heure de départ effectivement mesurée.
ExpectedDepartureTime 0:1 Heure de départ estimé par le SAE.
DepartureStatus 0:1 Caractérisation de l'horaire de départ attendu (ou mesuré si le véhicule est à quai).
Paramètres disponibles (onTime / early / delayed / cancelled / missed / arrived / notExpected / noReport)
Valeur par défaut : "onTime"
DeparturePlatformName 0:1 Identification ou nom du quai de départ.

1 : ActualDepartureTime n'est jamais transmis car :

  • en requête directe, un passage dont le départ est réalisé n'est pas fourni
  • en abonnement, la réalisation d'un départ est signifiée par la notification d'un MonitoredStopVisitcancellation
2 : DestinationDisplay = DestinationName
3 : Order = rang du point d'arrêt dans le chainage (dans le chainage de déviation s'il s'agit d'un point d'arrêt de déviation)

GeneralMessage

Permet de récupérer l'information temps réel de l'info-traffic (Perturbations, Infos commerciales, Déviations ...)

Requête
GeneralMessageRequest Obligatoire Requête d'accès aux messages Exemple
Version 1:1 Non Version du service « GeneralMessage ».
RequestTimestamp 1:1 Oui Date d'émission de la requête. 2023-03-07T15:00:00
yyyy-MM-ddTHH:ii:ss
MessageIdentifier 0:1
1:1		 Oui Numéro d'identification du message. opendata:Message::{IDENTIFIANT_UNIQUE_MESSAGE}:LOC
InfoChannelRef 0:* Oui Identifie le canal pour lequel on souhaite obtenir les messages. Si ce champ n'est pas présent, la requête concerne tous les canaux.
Seules les valeurs suivantes seront utilisées pour identifier les canaux:

  • «Perturbation»
  • «Information»
  • «Commercial»
Note : ce sont bien ces libellés texte précis, qui sont utilisés pour instancier l'attribut InfoChannelRef (et non une codification équivalente). Les travaux prévus et non prévus seront transmis en messages de type « Perturbation ».
Extensions 0:1 Oui Champ réservé pour un usage libre.

Demande d'abonnement
GeneralMessageSubscriptionRequest Obligatoire Requête d'abonnement au service SIRI GeneralMessage Exemple
SubscriberRef 0:1
1:1		 Oui Identifiant du système demandeur. Toujours utilisé "opendata" opendata
SubscriptionIdentifier 1:1 Oui Identifiant de l'abonnement pour le système demandeur. opendata:Subscription:{OPERATION}:{IDENTIFIANT_UNIQUE}:LOC
InitialTerminationTime 1:1 Oui Date et heure de fin de l'abonnement. Pour un abonnement se terminant le 09 mars 2023 à 17h00 :
2023-03-09T17:00:00
GeneralMessageRequest 1:1 Oui Voir GeneralMessageRequest (ci-dessus)

Réponse
GeneralMessageDelivery Contenu et modification des messages.
version 1:1 Version du service.
GeneralMessage 0:* Le message lui-même (voir InfoMessage ci-dessous).
GeneralMessageCancellation 0:* Annulation d'un message précédent (voir ci-dessous).

Notifications abonnement

Pour fournir les données temps réels liés à la messagerie, la méthode notifyGeneralMessage doit être émise par le client SIRI en mode abonnement.
La première notification contient l’intégralité des données temps réel correspondant à la requête. Par la suite, seules les structures InfoMessage ayant un paramètre modifié sont transmises.
Si un InfoMessage préalablement transmis ne correspond plus aux critères de la requête celui-ci doit être retiré à l’aide de la structure InfoMessageCancellation décrite ci-dessous.

GeneralMessageDelivery Contenu et modification des messages.
version 1:1 Version du service.
GeneralMessage 0:* Le message lui-même (voir InfoMessage ci-dessous).
GeneralMessageCancellation 0:* Annulation d'un message précédent (voir ci-dessous).

Structure InfoMessageCancellation

InfoMessageCancellation Annulation d'un message émis précédemment.
RecordedAtTime 1:1 Heure à laquelle le message a été annulé.
ItemRef 0:1
1:1		 Identifiant unique du message.
InfoMessageIdentifier 1:1 Référence InfoMessage du message à annuler.
InfoChannelRef 0:1 Canal auquel appartient le message.
Seules les informations suivantes seront utilisées pour identifier les canaux :

  • «Perturbation»
  • «Information»
  • «Commercial»

Structure InfoMessage

InfoMessage Message d'information.
formatRef 0:1
1:1		 Identifie le format du contenu (ouvert pour ce service).
RecordedAtTime 1:1 Heure d'enregistrement du message.
ItemIdentifier 0:1
1:1		 Identifiant unique du message SIRI fourni par son émetteur.
InfoMessageIdentifier 0:1 Identifiant InfoMessage (sera utilisé pour les mises à jour et les abandons de message: toutes les mises à jour du message porteront le même InfoMessageIdentifier).
InfoChannelRef 0:1
1:1		 Canal auquel appartient le message.
Seules les informations suivantes seront utilisées pour identifier les canaux :

  • «Perturbation»
  • «Information»
  • «Commercial»
ValidUntilTime 0:1
1:1		 Date et heure jusqu'à laquelle le message est valide. Si toutefois l'heure de fin d'incident n'est pas connue, cette heure sera fixée en fin de journée d'exploitation.
Message 1:1 Le message lui-même sous la forme <Content xsi:type="siri:IDFGeneralMessageStructure">.

Structure IDFGeneralMessage

IDFGeneralMessage Contenu du message.
LineRef 0:* Identifie la ou les lignes concernées par le message. Si une ligne est indiquée, le message porte sur toute la ligne sans restriction.
StopPointRef 0:* Identifie le ou les points d'arrêts concernés par le message.
Message 1:* Contient le message lui-même (éventuellement sous différentes déclinaisons de format (MessageType) et/ou de langue).

Structure IDFGeneralMessage

IDFMessage Contenu du message.
MessageType 1:1 Type du contenu du message. (longMessage / shortMessage / codedMessage / textOnly / formattedText / HTML / RTF.
Par défaut : textOnly
MessageText 1:1 Texte du message lui-même.

CancelSubscribe

Permet de mettre fin à un abonnement en cours

Requête
TerminateSubscriptionRequest Obligatoire Demande de fin d'abonnement Exemple
RequestTimestamp 1:1 Oui Date de la demande. 2023-03-07T15:00:00
yyyy-MM-ddTHH:ii:ss
RequestorRef 1:1 Oui Identifiant du demandeur. Toujours renseigné "opendata" opendata
MessageIdentifier 0:1
1:1		 Oui Identifiant unique du message opendata:Message::{IDENTIFIANT_UNIQUE_MESSAGE}:LOC
SubscriptionRef 0:1 Oui Identifiant de l'abonnement à clôturer. opendata:Subscription:{OPERATION}:{IDENTIFIANT_UNIQUE}:LOC

Réponse
TerminateSubscriptionResponse Reponse aux demandes de fin d'abonnement
ResponseTimestamp 1:1 Date et heure de la réponse.
ResponderRef 0:1
1:1		 Identifiant du système répondant.
RequestMessageRef 0:1
1:1		 Identification de la requête.
TerminationResponseStatus 0:* Statut de la demande de clôture d'abonnement.
ResponseTimestamp 0:1 Heure de réponse (pour l'abonnement ci-dessous).
SubscriberRef 0:1 Identifiant du souscripteur.
SubscriptionRef 1:1 Identifiant de l'abonnement.
Status 0:1
1:1		 Indique si l'abonnement a bien pu être clôturé.
ErrorCondition 0:1 Signale une éventuelle erreur.
Cas d'erreur, au choix :
a) CapabilityNotSupportedError Fonction non supportée.
b) UnknownSubscriberError Souscripteur inconnu.
c) UnknownSubscriptionError Abonnement inconnu.
d) OtherError Autre erreur.
Description Description de l'erreur.

Mode Requête

Permet de demander une information temps réel à un instant T

Le mode requête sert principalement pour les demandes d'informations souhaitées sur le moment. Il est préconisé de l'utiliser principalement 1 fois par jour pour les opérations suivantes :

  • StopPointsDiscovery
  • LinesDiscovery

L'intérêt de ses opérations est qu'ils permettant de récupérer l'ensemble du réseau avec toutes les lignes, les arrêts et les destinations. Les informations ne sont mise à jour qu'une seule fois par jour, c'est pour cela qu'il est inutile de requêter ses opérations plus d'une fois.

Mode Abonnement

Permet de suivre les informations en temps réel sur la durée.

Demande d'abonnement
SubscriptionRequest Obligatoire Structure générale de requêtes d'abonnement Exemple
RequestTimestamp 1:1 Oui Date de la requête d'abonnement. 2023-03-07T15:00:00
yyyy-MM-ddTHH:ii:ss
RequestorRef 1:1 Oui Identifiant du demandeur de la réponse. Toujours renseigné "opendata" opendata
MessageIdentifier 0:1
1:1		 Oui Identifiant unique de la requête de souscription (utilisé dans la réponse). opendata:Message::{IDENTIFIANT_UNIQUE_MESSAGE}:LOC
ConsumerAddress 0:1 Oui Adresse (URL) de destination des notifications. Exemple : https://monsite/api/notificationSIRI
StopMonitoringSubscriptionRequest - Dépend si l'on souhaite des informations sur les passages aux arrêts.
GeneralMessageSubscriptionRequest - Dépend si l'on souhaite des informations sur l'infos traffic.

Réponse
SubscriptionResponse Réponse à une demande d'abonnement.
ResponseTimestamp 1:1 Date et heure de production de la réponse.
ResponderRef 0:1
1:1		 Identifiant du système répondant.
RequestMessageRef 0:1
1:1		 Identifiant unique du message (de cette réponse).
ResponseStatus 1:* Statut de la réponse (en erreur et donc refusée, ou Ok).
ServiceStartedTime 0:1 Heure de démarrage du service en mode abonnement
ResponseStatus Qualificateur des réponses.
ResponseTimestamp 0:1 Date de création de ce statut de réponse.
RequestMessageRef 0:1
1:1		 Référence de la requête.
SubscriberRef 0:1
1:1		 Identification du souscripteur.
SubscriptionRef 1:1 Identification de l'abonnement.
Status 0:1
1:1		 Indique si la requête a été traitée normalement ou pas.
ErrorCondition 0:1 Signalement d'erreur (voir le paragraphe sur la gestion des erreurs).
a) CapabilityNotSupportedError -1.1 Fonction non supportée.
b) AccessNotAllowedError Accès refusé.
c) NoInfoForTopicError Pas d'information pour cette requête.
d) AllowedResourceUsageExceededError Réponse trop volumineuse.
e) OtherError Autre erreur.
e) Description Description de l'erreur.
ValidUntil Date de validité maximale de la réponse. Présent uniquement si ValidUntil est inférieur à InitialTerminationTime de la requête.

Test de vie d'un abonnement

Il est important de savoir si le système avec lequel on "dialogue" est toujours disponible, tout particulièrement dans le cadre d'un mécanisme d'abonnement pour pouvoir différencier le cas où le serveur ne répond plus du cas où aucune donnée n'a évolué.
Afin de garantir un contrôle régulier, un délai maximal de 60 secondes est défini entre deux notifications.

Si à l’échéance du délai de 60 secondes, aucune notification n’a été reçue, alors il est nécessaire d'effectuer un test de vie à l’aide du service CheckStatus. En cas d’échec du test de vie, les abonnements vers ce fournisseur sont annulés et toutes les données temps réel associées à ces abonnements sont effacées.
Dans ce cas, il est important d'effectuer à nouveau la phase d’initialisation des abonnements : il faut envoyer à intervalles réguliers un CheckStatus pour surveiller le retour à la normal de la connexion avec le système SIRI. Lorsque celui-ci sera rétabli, il faut renvoyer une demande de fin d’abonnement suivie d’une demande d’abonnement.