Annonce préalable GTFS-SA: Répartition des flux et autres nouveautés

À partir de l’un des prochains flux (probablement en septembre ou plus tard), nous prévoyons quelques nouveautés dans GTFS RT Service Alerts.

Flux séparés

Afin de mieux répondre aux besoins de nos utilisateurs et de réduire le volume de données, nous allons introduire quatre flux distincts pour les données relatives aux événements:

Flux Type
(Prévu)
Perspective
(perspective)
Type
(Progress)
Flux 1 planifié Renseignements sur l’horaire (whileplanningtrip) Messages principaux (published)
Flux 2 non planifié Renseignements sur l’horaire (whileplanningtrip) Messages principaux (published)
Flux 3 planifié Indicateurs aux arrêts
(atStopPoint)
Annonces principales et finales
(publié|closing)
Flux 4 non planifié Indicateurs aux arrêts
(atStopPoint)
Annonces principales et finales
(publié|closing)

Un événement est publié dès qu’il est disponible, c’est-à-dire qu’il soit déjà actif ou non (StartTime se situe dans le futur).

Remplacement de active_period par impact_period et communication_period

Dans le même temps, nous planifions: active_period par impact_period et communication_period afin d’illustrer la chronologie des annonces:

communication_period

Durant ce laps de temps, l’annonce est visible. Les valeurs correspondent à la structure SIRI-SX. PublicationWindow.

communication_period nous n’utilisons que la perspective «Téléaffichage aux arrêts» (atStopPoint) et sert à gérer la publication. Le producteur de données peut, par exemple, définir l’affichage d’un événement pour l’arrêt avant le début de l’événement.

impact_period

Durant ce laps de temps, l’événement annoncé est actif. Les valeurs correspondent à la structure SIRI-SX. ValidityPeriod.

informedEntity: Messages relatifs aux trajets avec limitation à certains arrêts

Les annonces relatives à Trip peuvent désormais être activées sur Stops (stop_id). Cela peut être indiqué dans le champ informedEntity comme dans l’exemple suivant:

"informedEntity": [ 
   {
     "agencyId": "11", 
     "stopId": "ch:1:sloid:3000", 
     "trip": { 
        "tripId": "115.TA.91-2G-Y-j26-1.28.R", 
        "startTime": "19:32:00", 
        "startDate": "20250310", 
        "originalTripId": "ch:1:sjyid:100001:719-001" 
     }, 
   }, 
   { 
      "agencyId": "11", 
      "stopId": "8102336", 
      "trip": { 
         "tripId": "115.TA.91-2G-Y-j26-1.28.R", 
         "startTime": "19:32:00", 
         "startDate": "20250310", 
         "originalTripId": "ch:1:sjyid:100001:719-001"
      } 
   }
 ]

informedEntity: l’élément stopId correspond désormais à l’élément stopId GTFS de la bordure d’arrêt

Le champ est désormais stopId à l’intérieur d’un informedEntity avec le stopId de la bordure d’arrêt (selon GTFS Static) au lieu du SLOID de l’arrêt. Dans le champ originalStopId est également disponible la valeur SLOID de la bordure d’arrêt.

Pour les références de lignes ou de parcours, stopId ou originalStopId des bordures d’arrêt empruntées.

Les URL ne sont plus affichées

Les URL dans le champ url ne sont plus diffusées. Les URL sont toujours émises dans le cadre du descriptionText.

Priorité

La priorité des messages est représentée par leur ordre dans JSON. Les messages de plus grande priorité apparaissent plus loin dans la liste.

La priorité est définie selon les critères suivants:

Classement Critère Description
1 Priorité à partir du système source Priority ou ActionPriority de SIRI-SX (ActionPriority a priorité)
2 Statut («Progrès» dans le système source) Publié avant clôture
3 Date de début (impact_period ou communication_period) Plus petite valeur «start» de impact_period ou communication_period