Mises à jour de trajet

Les mises à jour des trajets vous informent des fluctuations d'horaires. Nous nous attendons à recevoir des mises à jour des trajets pour tous les itinéraires que vous avez planifiés, s'ils sont compatibles avec les flux en temps réel. Ces mises à jour donnent l'heure d'arrivée ou de départ prévue à chaque arrêt de l'itinéraire. Les mises à jour de trajet peuvent également fournir des informations concernant des scénarios plus complexes tels qu'un trajet annulé, un horaire ajouté ou même une déviation.

Rappel : Dans GTFS, un trajet est constitué au minimum d'une série de deux arrêts desservis à une heure précise.

Il doit y avoir au maximum une mise à jour pour chaque trajet programmé. S'il n'y a pas de mise à jour pour un trajet programmé, il sera conclu qu'aucune donnée en temps réel n'est disponible pour ce trajet. L'utilisateur des données ne doit pas supposer que le trajet se déroule selon l'horaire prévu.

Mises à jour des horaires d'arrêt

Une mise à jour de trajet consiste en une ou plusieurs mises à jour des horaires d'arrêt du véhicule, appelées messages StopTimeUpdate. Celles-ci peuvent être fournies pour les horaires d'arrêt passés et futurs. Il est permis, mais pas obligatoire, de supprimer les horaires d'arrêt passés. Les producteurs ne devraient pas supprimer un StopTimeUpdate passé s'il fait référence à un arrêt avec une heure d'arrivée programmée dans le futur pour le trajet donné (c'est-à-dire que le véhicule est passé à l'arrêt en avance), sinon il sera conclu qu'il n'y a pas de mise à jour pour cet arrêt.

Par exemple, si les données suivantes apparaissent dans le flux GTFS-rt :

  • Arrêt 4 : Prédiction à 10h18 (programmé à 10h20 : 2 min d'avance)
  • Arrêt 5 : Prédiction à 10h30 (programmé à 10h30 : à l'heure)

La prédiction de l'arrêt 4 ne peut pas être enlevée du flux avant 10h21, même si le bus passe effectivement à 10h18. Si le StopTimeUpdate pour l'arrêt 4 a été supprimé du flux à 10h18 ou à 10h19, et si l'heure d'arrivée programmée est 10h20, l'utilisateur pourra alors supposer qu'à ce moment-là aucune information en temps réel n'existe pour l'arrêt 4, et que les horaires de GTFS doivent être utilisés.

Chaque message StopTimeUpdate est lié à un arrêt. Habituellement, cela peut être fait en utilisant soit un stop_sequence GTFS, soit un stop_id GTFS. Cependant, dans le cas où vous fournissez une mise à jour pour un trajet sans trip_id GTFS, vous devez spécifier stop_id, car stop_sequence n'a aucune valeur. Le stop_id doit toujours faire référence à un stop_id dans GTFS. Si le même stop_id est desservi plus d'une fois dans un trajet, alors, pour ce trajet, stop_sequence doit être fourni dans tous les messages StopTimeUpdate de ce stop_id.

La mise à jour peut fournir un horaire exact pour arrival et/ou departure à un arrêt en utilisant StopTimeEvent dans StopTimeUpdate. Elle doit contenir un time ou un delay absolu (c'est-à-dire un décalage par rapport à l'horaire planifié en secondes). Le champ delay ne peut être utilisé que si la mise à jour du trajet fait référence à un trajet GTFS programmé, par opposition à un trajet basé sur la fréquence. Dans ce cas, l'horaire doit correspondre à l'horaire programmé + le retard. Vous pouvez également spécifier le paramètre uncertainty de la prédiction avec StopTimeEvent. Vous trouverez plus de détails dans la section Incertitude plus loin sur cette page.

Pour chaque StopTimeUpdate, le rapport de planification par défaut est scheduled. Notez que ceci est différent du rapport de planification pour le trajet. Vous pouvez le remplacer par skipped si l'arrêt n'aura pas lieu, ou par no data si vous n'avez des données en temps réel que pour une partie du trajet.

Les mises à jour doivent être triées par stop_sequence (ou stop_ids dans l'ordre du trajet).

Si un ou plusieurs arrêts sont manquants le long du trajet, la mise à jour est propagée à tous les arrêts suivants. Cela signifie que la mise à jour d'un horaire d'arrêt entraînera la modification des horaires aux arrêts suivants en l'absence de toute autre information.

Exemple 1

Pour un trajet comportant 20 arrêts, un StopTimeUpdate avec un retard de départ et d'arrivée de 0 (StopTimeEvent) pour l'élément stop_sequence de l'arrêt en cours signifie que le trajet est pile à l'heure.

Exemple 2

Pour le même exemple de trajet, trois messages StopTimeUpdate sont fournis :

  • retard de 300 secondes pour stop_sequence 3
  • retard de 60 secondes pour stop_sequence 8
  • retard de durée non spécifiée pour stop_sequence 10

Cela sera interprété de la manière suivante :

  • Les messages stop_sequence 1 et 2 ont un retard indéterminé.
  • Les messages stop_sequence 3, 4, 5, 6 et 7 ont un retard de 300 secondes.
  • Les messages stop_sequence 8 et 9 ont un retard de 60 secondes.
  • Les messages stop_sequence 10 à 20 ont un retard indéterminé.

Descripteur de trajet

Les informations fournies par le descripteur de trajet dépendent de la planification du trajet que vous mettez à jour. Vous pouvez définir plusieurs options :

Valeur Description
Scheduled Ce trajet est en cours selon l'horaire GTFS, ou en est encore assez proche pour y être associé.
Added Ce trajet n'était pas programmé et a été ajouté. Par exemple, pour faire face à la demande, ou remplacer un véhicule en panne.
Unscheduled Ce trajet est en cours et n'a jamais été programmé. Par exemple, lorsqu'il n'y a pas d'horaires et que les bus circulent selon un service de navette.
Canceled Ce trajet était programmé, mais il est désormais supprimé.

Dans la plupart des cas, vous devez indiquer le trip_id du trajet programmé dans GTFS auquel cette mise à jour se rapporte.

Systèmes comportant des valeurs trip_id répétées

Pour les systèmes utilisant des valeurs trip_id répétées, par exemple les trajets modélisés en utilisant frequencies.txt (c'est-à-dire les trajets basés sur la fréquence) le trip_id n'est pas un identifiant unique d'un seul trajet, car il manque une composante temporelle spécifique. Pour identifier de manière unique ce type de trajet dans un TripDescriptor, vous devez fournir les trois identifiants suivants :

  • trip_id
  • start_time
  • start_date

L'identifiant start_time doit être publié en premier. Toute mise à jour ultérieure du flux doit utiliser cette valeur start_time pour faire référence à un même trajet. Utilisez StopTimeUpdate pour signaler des changements. Notez qu'il n'est pas obligatoire que la valeur start_time corresponde exactement à l'heure de départ au premier arrêt. Il est cependant recommandé qu'elle s'en rapproche le plus possible.

Par exemple, supposons que nous décidions à 10h00 le 25 mai 2015, qu'un trajet avec trip_id=T commencera à start_time=10:10:00, et que nous fournissions ces données via le flux en temps réel à 10h01. À 10h05, nous nous rendons soudainement compte que le trajet commencera à 10h13 et non à 10h10. Dans notre nouveau flux en temps réel, nous pouvons continuer d'identifier ce trajet comme (T, 2015-05-25, 10:10:00), mais fournir un StopTimeUpdate avec un départ au premier arrêt défini sur 10:13:00.

Correspondance de trajet alternative

Les trajets qui ne sont pas calculés en fonction de la fréquence de passage peuvent aussi être identifiés de façon unique par un TripDescriptor comprenant les identifiants suivants :

  • route_id
  • direction_id
  • start_time
  • start_date

où start_time est l'heure de départ programmée dans l'horaire statique, à condition que la combinaison d'identifiants fournie corresponde à un trajet unique.

Incertitude

L'incertitude s'applique à la fois à l'heure et à la valeur de retard d'un StopTimeUpdate. L'incertitude indique de manière approximative la marge d'erreur du retard sous la forme d'un nombre entier en secondes (mais sans définir encore son incidence précise sur les statistiques). Il est possible que l'incertitude soit 0, par exemple pour les trains qui sont pilotés par un ordinateur de contrôle de temporisation.

À titre d'exemple, un bus longue distance dont le retard estimé est de 15 minutes, qui dessert son prochain arrêt dans une fenêtre d'erreur de 4 minutes (soit +2/-2 minutes) aura une valeur uncertainty de 240.