Temps réel¶

Le temps réel a une seule source — l'appareil du conducteur — et deux débouchés : la supervision côté exploitant, et l'information voyageurs côté public.

La chaîne, du véhicule au voyageur¶

1. L'appareil du conducteur remonte sa position et l'avancement de la course qu'il assure.
2. L'API en déduit l'avancement réel : arrêts desservis, avance-retard, position sur le tracé.
3. Ces éléments alimentent les flux normalisés que consomment les calculateurs d'itinéraire et les écrans.

Chaque étape se lit dans l'API, mais pas au même endroit ni avec la même fraîcheur : la position d'un véhicule s'interroge à l'instant, tandis que la trace de ce qui s'est produit se consulte dans l'historique.

Sans appareil, pas de temps réel¶

C'est la dépendance à retenir : une course dont l'appareil n'est pas en service n'est pas suivie. Elle reste prévue au référentiel, mais aucune donnée réalisée ne la concerne — ni position, ni avance-retard, ni passage aux arrêts.

L'appareil connaît la course qu'il assure à un instant donné, désignée par le triplet décrit page précédente. Il porte aussi son état de connexion, ce qui permet de distinguer un véhicule à l'arrêt d'un véhicule qui ne remonte plus.

Un appelant non authentifié reçoit une réponse réduite sur la liste et le détail des appareils : position, cap, fraîcheur, ligne/course et occupation sont conservés, tandis que les champs réservés à l'exploitant sont retirés et les appareils archivés écartés.

Ce qui ressort vers les voyageurs¶

Deux formats normalisés diffusent le même état du réseau, avec deux formalismes différents. Le choix dépend de ce que le consommateur attend, pas de ce que Pysae préfère.

Ces flux sont un produit, pas une source : ils agrègent le référentiel, les positions des appareils, les alertes et les modifications de course. Un écart constaté dans un flux se diagnostique donc en remontant à celle de ces entrées qui le porte.

Dans les TripUpdate GTFS-RT, un départ observé reste associé à l'arrêt quitté, y compris lorsque le véhicule se dirige directement vers un arrêt plus loin. Une évolution du retard ne décale pas ce départ déjà observé. Tant qu'aucun départ n'est connu, l'horaire publié reste une estimation fondée sur le retard courant, y compris pour l'arrêt où le véhicule stationne encore.

Dans les positions GTFS-RT, position.bearing indique le cap en degrés dans le sens horaire depuis le nord : 0° correspond au nord et 90° à l’est. Lorsqu’il est connu, le cap est normalisé dans [0, 360) dans le flux complet comme dans le flux de positions, en binaire et en JSON. Un cap inconnu reste absent ; 0° indique un cap connu vers le nord.

Les perturbations¶

Deux objets distincts alimentent la partie « perturbation » des flux, et il ne faut pas les confondre :

• une alerte est un message destiné aux voyageurs — travaux, événement, arrêt non desservi ;
• une modification de course est un changement du service lui-même — arrêt supprimé, course déviée. Dans le flux GTFS-RT, elle est publiée à la fois comme TripUpdate (arrêts sautés, retard) et comme entité TripModifications (arrêts de remplacement, tracé modifié).

Une même perturbation réelle donne souvent lieu aux deux : le service change, et on l'annonce.

Un arrêt de remplacement que le GTFS statique ne contient pas — un arrêt créé pour la déviation, ou un arrêt existant desservi ailleurs — est publié dans le flux comme une entité Stop accompagnant la TripModifications, sous un identifiant propre préfixé de rt-stop:. Cet identifiant désigne la position décrite par la déviation, et lui seule : il ne réutilise jamais l'identifiant de l'arrêt du GTFS statique, de sorte qu'un arrêt déplacé pour certaines courses reste inchangé pour toutes les autres.

Et ensuite¶

Le temps réel dit ce que font les véhicules. Reste à savoir qui les conduit et selon quelle organisation — c'est l'objet de la page Exploitation.