Les données temps réel

Spécifications pour publication d'un flux temps-réel sur le PAN

Récapitulatif des conditions de publication de données temps-réel sur le PAN

Pour être publié sur transport.data.gouv.fr, un jeu de données temps-réel de lignes régulières doit respecter toutes les conditions suivantes :

• Horaires théoriques disponibles,

• Une API Siri-lite ou une API SIRI conforme au profil France de la norme SIRI, et/ou un flux au format GTFS-RT (au minimum avec trip updates),

• Données utilisables selon les conditions de la licence ouverte (l’application d’une autre licence s’effectue sous réserve de modalités techniques ou juridiques le justifiant),

• Pas d’authentification pour accéder aux données (sous réserve de modalités techniques ou juridiques le justifiant),

• Pas de restriction de requêtage (sous réserve de modalités techniques ou juridiques le justifiant).

S'y retrouver : GTFS-RT, SIRI, SIRI-Lite, API ?

Différents types de temps réel

L’information en temps réel se décline habituellement en quatre variantes :

• Avance/retard des véhicules

  • Dans le standard GTFS-RT : Trip updates

  • Dans la norme SIRI : Estimated Timetable (ET)

• Prochains passages

  • Dans le standard GTFS-RT : Trip updates

  • Dans la norme SIRI : Stop Monitoring (SM)

• Position des véhicules

  • Dans le standard GTFS-RT : Vehicle positions

  • Dans la norme SIRI : Vehicle Monitoring (VM)

• Messages d’information et d’alerte

  • Dans le standard GTFS-RT : Service alerts

  • Dans la norme SIRI : General Messaging (GM), Situation Exchange (SX)

Ces quatre approches sont complémentaires et aucune n’est suffisante par elle même : par exemple, l’avance-retard permet de proposer des itinéraires adaptés à la situation réelle… La position des véhicules permet de rassurer l’usager qui a tendance à ne pas faire confiance aux projections et de donner une information en cas de situation très perturbée. Enfin, les messages d’alerte permettent de gérer des perturbations plus importantes (travaux, chute de neige, gros évènement sportif…) ou de donner des informations non temporelles (panne d’un ascenseur…).

Deux moyens de diffusion

• Un fichier unique « photographie » de l’ensemble du réseau à un instant t (et donc un seul fichier à télécharger toutes les 30 secondes) : format GTFS-RT,

• Une API SIRI ou Siri-Lite.

SIRI ou SIRI-Lite ? SIRI répond initialement à des problématiques d'interopérabilité « intersystèmes ». SIRI-Lite est dérivé du SIRI « pour aller vers la diffusion vers les terminaux utilisateurs et l’open-data » (C. Duquesne).

Concrètement, SIRI-Lite utilise le même modèle de représentation que SIRI mais l’interrogation des serveurs se fait en REST et non pas en SOAP.

Toutes les API pourront être référencées (« listées ») mais pas hébergées par le PAN. Le PAN peut en particulier assumer la charge de requêtes potentiellement nombreuses uniquement pour le GTFS-RT (voir chapitre Serveur proxy). Pour toutes mises à disposition de données via une API SIRI ou SIRI Lite, nous vous recommandons de contacter notre équipe qui effectue actuellement des développements en lien avec ces formats.

Spécifications pour le GTFS-RT sur le PAN

Documentation officielle du GTFS-RT

Le GTFS-RT s'appuie nécessairement sur un fichier GTFS décrivant les lignes et horaires théoriques, car il indique la différence observée par rapport à ces horaires prévus. Les identifiants doivent être les mêmes entre le GTFS et le GTFS-RT.

Certains producteurs proposent toutes les informations pouvant être diffusées dans du GTFS-RT dans un seul flux, tandis que d’autres préfèrent avoir un flux par type d’information c'est à dire un flux pour TripUpdates un pour ServiceAlerts et un autre pour VehiclePositions

Plus d'informations dans notre article de blog sur la production et la diffusion des données temps réel pour les transports en commun.

Spécifications pour le SIRI-Lite sur le PAN

Documentation officielle du SIRI

Parmi les services proposés par SIRI et SIRI-Lite, pour satisfaire les obligation de mise à disposition du temps réel, pour publication sur le PAN, il est obligatoire d’exposer EstimatedTimetable car c’est le seul qui permet de s’approcher d’une diffusion en « photographie ».

Les autres services StopMonitoring, GeneralMessage, VehicleMonitoring, StopDiscovery, LineDiscovery sont recommandés en sus.

Pourquoi ces exigences de la part du PAN ?

Le Point d'Accès National a pour mission exclusive d'améliorer l'information voyageur à travers la France et cela passe par favoriser la réutilisation de la donnée de transport.

Pour cela, l'équipe du PAN est en contact permanent avec les réutilisateurs de données. Il ressort de nombreuses concertations que :

• Les réutilisateurs ont besoin de flux de données standardisés, sous peine, au mieux, d'importants travaux d'intégration des flux, et au pire la non-exploitation de ces flux.

• Les fournisseurs de services de calcul d'itinéraires et de mobilité privilégient le téléchargement de l'intégralité du réseau en une seule requête (paramètres Mises à jour du réseau/Trip Update en GTFS-RT, EstimatedTimetable en SIRI-Lite) plutôt qu'une multitude d'appels arrêt par arrêt.

• Il est possible de reconstituer la donnée pour un point d'arrêt à partir de l'ensemble du réseau, mais pas l'inverse.

• L'identification préalable à l'accès aux données est un frein à leur réutilisation. Elle impose des démarches individualisées pour chaque réseau.

• Le GTFS-RT est le format le plus publié en opendata et le plus réutilisé actuellement.