Mises à jour de trajet

Les mises à jour de trajet représentent des fluctuations dans les horaires. Nous nous attendons à recevoir des mises à jour de trajet 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 une prédiction d'heure d'arrivée ou de départ pour 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'une annulation de trajet, un ajout d'horaire ou même une déviation.

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

Il doit y avoir au maximum une mise à jour pour chaque trajet prévu. 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 StopTimeUpdates. 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 prévue 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 à 10 h 18 (programmé à 10 h 20 : 2 min d'avance)
  • Arrêt 5 : Prédiction à 10 h 30 (programmé à 10 h 30 : à l'heure)

La prédiction de l'arrêt 4 ne peut pas être enlevée du flux avant 10 h 21, même si le bus passe effectivement à 10 h 18. Si le StopTimeUpdate pour l'arrêt 4 a été supprimé du flux à 10 h 18 ou à 10 h 19 et que l'heure d'arrivée prévue est 10 h 20, 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 élément StopTimeUpdate est lié à un arrêt. Habituellement, cela peut être fait en utilisant soit une stop_sequence GTFS, soit un stop_id GTFS. Cependant, dans le cas où vous fournissez une mise à jour pour un trajet sans GTFS trip_id, 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 éléments StopTimeUpdate de ce stop_id.

La mise à jour peut fournir un timing exact pour l'arrivée et/ou le départ à un arrêt en utilisant StopTimeEvent dans StopTimeUpdates. Elle doit contenir un horaire ou un retard absolu (c'est-à-dire un décalage par rapport à l'horaire planifié en secondes). Le retard 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 l'incertitude de la prédiction avec StopTimeEvent. Vous trouverez plus de détails dans la section Incertitude en bas de la page.

Pour chaque StopTimeUpdate, le rapport de planification par défaut est programmé. Notez que ceci est différent du rapport de planification pour le trajet. Vous pouvez le remplacer par ignoré si l'arrêt n'aura pas lieu, ou par aucune donnée si vous avez seulement des données en temps réel 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, une mise à jour StopTimeUpdate avec un retard de départ et d'arrivée de 0 (StopTimeEvents) 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 mises à jour StopTimeUpdate sont fournies :

  • 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 :

  • stop_sequences 1, 2 ont un retard indéterminé.
  • stop_sequences 3, 4, 5 6, 7 ont un retard de 300 secondes.
  • Stop_sequences 8, 9 ont un retard de 60 secondes.
  • stop_sequences 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 Commentaire
Scheduled Ce trajet est en cours d'exécution selon l'horaire GTFS, ou en est encore assez proche pour y être associé.
Added Ce trajet n'était pas prévu 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 prévu, mais il est désormais supprimé.

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

Systèmes avec répétitions de trip_id

Pour les systèmes utilisant des trip_id répétés, par exemple les trajets modélisés en utilisant frequency.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 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 la même valeur start_time lorsque le trajet en question est référencé. Pour apporter des modifications à l'heure de départ, utilisez le champ StopTimeUpdate. 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 qu'à 10 h 00, le 25 mai 2015, un trajet associé à l'identifiant trip_id=T commence à start_time=10:10:00, et que nous fournissions ces données via le flux en temps réel à 10 h 01. Peu avant 10 h 05, nous nous rendons soudainement compte que le trajet ne commencera pas à 10 h 10, mais plutôt à 10 h 13. Dans notre nouveau flux en temps réel, nous pouvons continuer d'identifier ce trajet comme (T, 25/05/2015, 10:10:00) mais fournir une StopTimeUpdate avec une heure de départ au premier arrêt à 10 h 13.

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 prévue 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 retard d'une StopTimeUpdate. L'incertitude définit grossièrement la marge d'erreur du retard sous la forme d'un nombre entier en secondes (mais notez que la signification statistique précise n'est pas encore définie). Il est possible que l'incertitude soit égale à 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 d'incertitude de 240.