Dans le cadre de la création d’une application MaaS, la donnée est une ressource primordiale. En effet, elle joue un rôle important dans l’échange entre les acteurs de la mobilité. Dans un article précédent, nous parlions de planificateurs de trajets intermodaux, outil indispensable de toutes solutions MaaS. Les algorithmes à l’origine de ces planificateurs sont alimentés en partie par des données de transports publics. Sans un standard adapté, elles seraient impossibles à intégrer. On se rend compte aujourd’hui, que plus il y a de données variées, plus la portée d’une application MaaS est grande. Celles-ci permettent notamment d’alimenter le calculateur d’itinéraires en augmentant son champ de recherche et en le rendant plus personnalisable.
En Europe, on dénombre plusieurs millions de stations de transports collectifs, incluant métro, bus, tramway, etc. Les données relatives que nous allons appeler données transports sont multiples et possèdent diverses fonctions. En effet, elles nous détaillent et nous informent sur les différents éléments qui constituent un réseau de transports en commun. Par exemple : les horaires, les lignes, les arrêts, etc. En réalité, nous pouvons classer ces données en 2 types : les données de transports théoriques et en temps réel.
Dans cet article, nous allons faire un zoom sur le monde des données de transports. Afin de favoriser l’échange entre les différents acteurs de la mobilité, vous allez comprendre de quelle manière ces données ont été formalisées.
Transmodel, le modèle de référence
Avant de vous présenter les différents formats de données de transports, il est important de vous présenter le modèle de référence, Transmodel. Dans le cadre du développement des systèmes d’information des transports publics, il arrive parfois que deux systèmes souhaitent échanger et/ou être intégrés l’un à l’autre. Néanmoins, il se peut que cette intégration soit difficile à effectuer car le système est incapable de comprendre les données de l’autre.
Voici un schéma concret qui démontre la complexité de l’échange des différentes applications métiers dans un système d’information de transports publics.
Ici les différentes interfaces métiers communiquent ensemble 2 à 2, ce qui rend impossible la scalabilité du système.
Pour répondre à ce problème, Transmodel au travers de sa documentation, propose un modèle conceptuel de donnée. Ce MCD décrit les principales structures de données qui sont utilisées pour les systèmes d’informations de transports publics, y compris pour la planification de trajets, planification des horaires, les tarifs, les données en temps réels, etc. Grâce à cela, Transmodel devient la clé d’interopérabilité des systèmes. En 2005, Transmodel V5.1 a été adopté comme norme européenne EN12896 par le Comité Européen de Normalisation. En tant que référence standard, sa documentation décrit donc la sémantique des données de transports publics. Ce modèle est utile à deux types de publics : les autorités organisatrices des transports publics et les concepteurs de logiciels et systèmes.
Transmodel se définit donc comme une interface centrale facilitant l’échange entre les différentes applications métiers. Ici MCD Transmodel est un modèle de référence unique de la donnée et va concerner l’ensemble des métiers du transporteur.
Les formats d’échanges de données que nous allons voir se sont tous basés (sauf exceptions) sur le modèle conceptuel de référence que fournit Transmodel V6.
Les données de transports théoriques
Les premiers formats de référence dont nous allons parler sont dits statiques. En effet, ceux-ci correspondent aux données de transports théoriques, ils sont composés d’horaires, de stations, d’arrêts, de lignes, etc. Ce type de données n’est pas mise à jour régulièrement.
NeTex
Basé sur le modèle abstrait Transmodel, NeTex ou Network Transport Exchange est un format d’échange de données théoriques pour le transport public, défini au niveau européen. Dans le cadre d’interopérabilité des systèmes et afin d’harmoniser les échanges d’informations, NeTex fournit un moyen d’échanger les informations telles que les arrêts, les horaires des itinéraires et les tarifs, entre les différents systèmes informatiques. En effet, il va mettre en place des règles communes pour la diffusion et l’échange de ces données entre différents acteurs pouvant être les opérateurs de transports, les collectivités, les développeurs d’applications, etc. NeTex propose un périmètre fonctionnel très large, plus large que GTFS notamment.
Comme expliqué dans le portail des normes pour les données d’offre du transport collectif, un fichier de format NeTex est un fichier XML. Cet ensemble de fichiers xml qu’on appellera profil, définira l’ensemble d’un réseau : arrêts, lignes, horaires, tarifs, etc. Chaque pays d’Europe définit lui-même la manière dont il souhaite échanger ces fichiers XML. La France a défini 5 profils NeTex :
- Le profil “Arrêts“, qui est le profil d’échange pour la description des arrêts de transports en commun.
- “Réseaux”, qui présente la topologie des réseaux de transports en commun.
- Le profil “Horaires“, est un profil d’échange pour la description des horaires de transports en commun.
- “Accessibilité“, profil d’échange pour la description de l’accessibilité des réseaux de transports en commun.
- Le profil “Tarifs” couvre les informations tarifaires, y compris les modèles tarifaires complexes.
Le format NeTex est déjà bien utilisé au niveau Européen. En effet, plusieurs entreprises ont déjà adopté ce format. En Angleterre il a été utilisé pour les JO de Londres et d’autres pays européens sont déjà en train de finaliser leurs profils.
GTFS
En 2011, Google développa un nouveau standard non officiel, General Transit Feed Specifications. Il définit un format de fichier pour les horaires de transports en commun et les informations géographiques associées. Aux USA, il est considéré comme standard de base, ainsi que pour la publication de données de transports en commun en open data. Toute une communauté de développeurs et d’outils s’est développée autour de ce format et il est aujourd’hui le format le plus connu et utilisé au monde. GTFS est connu aussi sous le nom GTFS statique pour le différencier de GTFS realtime, spécification pour les données en temps réel.
Le standard comporte ce qu’on appelle des flux GTFS, elles sont en fait un ensemble de fichier texte regroupé dans un dossier ZIP. Chacun de ces fichiers est de format CSV et présente un type de données (arrêts, horaires, etc.). GTFS est en effet plus simple que NeTex.
Les flux GTFS
Comme je le disais un peu plus haut, plusieurs fichiers que nous appelons flux composent le format GTFS, ces flux sont en fait des fichiers textes. Chacun de ces fichiers modélise et définit un aspect spécifique des informations de transports en commun (arrêts, itinéraires, trajets et informations liées aux horaires). Une agence de transports publics a la possibilité de produire un flux GTFS pour partager ces informations de transports en communs. Les développeurs qui souhaitent intégrer ces informations dans leurs applications, pourront se servir de ces flux. Prenons l’exemple de Lyko : dans le cadre de la création de son planificateur de trajets intermodaux, il a utilisé des données open data notamment via la plateforme transport.data.gouv. Ces données de format GTFS ont donc permis d’alimenter son calculateur. Voyons ensemble, les principaux flux présents dans le format GTFS :
- agency.txt, définit les agences de transports.
- stops.txt, liste tous les points d’arrêts.
- routes.txt, définit les itinéraires sous format origine-destination (ensemble de trajets).
- trips.txt, présente les différents trajets pour chaque itinéraire (composé d’au moins deux arrêts)
- stops_times.txt, liste les heures d’arrivée et de départ depuis un arrêt spécifique
D’autres flux de données peuvent être présents mais sont facultatifs. Si vous souhaitez en prendre connaissance, vous pouvez vous rendre sur la page dédiée. GTFS est en effet très pertinent et est le format le plus répandu pour l’open data. Néanmoins il reste beaucoup moins riche qu’un format comme NeTex.
> Téléchargement : Djikstra, Raptor, CSA,… Tout savoir sur les algorithmes de calculs d’itinéraires “>Les données de transports en temps réel
A l’instar des données de transports dites statiques, les données de transports en temps réel sont mises à jour régulièrement. Il existe 2 types de formats : SIRI, norme basé sur Transmodel et GTFS realtime, standard populaire et développé par Google. Ils permettent tous les deux de répondre à un besoin d’échanges en temps réel, notamment vis à vis des applications de calculs d’itinéraires. Ils permettent aussi d’améliorer la pertinence des solutions MaaS.
SIRI
Le premier format d’échange en temps réel que nous allons voir est la norme SIRI (Service Interface for Real time Information) qui se base sur le modèle de référence TRANSMODEL. En octobre 2006, le CEN (Comité Européen de Normalisation) l’a établi comme norme européenne. SIRI va permettre l’échange d’informations des opérateurs de transports publics en temps réel entre serveurs sous format XML. Ces informations vont être intégrées pour des usages divers et précis. En effet, ils vont être utilisés notamment pour mettre à jour les horaires des arrêts en temps réel sur internet, mobile etc. Pour distribuer les messages d’états à propos des services ou encore coordonner les mouvements des bus sur un territoire. SIRI propose 8 différents web services qu’on appelle profils, conformes à la norme et répondant à un ensemble de besoins identifiés :
- SM – Stop Monitoring, horaires par arrêt
- GM – General Message, messages d’information
- ET – Estimated Timetable, horaires par ligne
- VM – Vehicle Monitoring, suivi des véhicules
- PT – Production Timetable, horaires planifiés par ligne
- CT – Connection Monitoring, supervision des correspondances
- SX – Situation Exchange, information détaillé sur les perturbations
- FM – Facility Monitoring, état des équipements (accessibilité)
Pour obtenir une explication détaillée de ces profils, vous pouvez consulter le site du VDV (groupe leader du CEN).
SIRI est avant tout une norme spécifiée et complexe. Très complète, la dernière mise à jour de ses spécifications a été faite en 2015. Elle est composée de 3 parties :
- Context and Framework ( CEN TS 15531-1:2015 )
- Communications infrastructure ( CEN TS 15531-2:2015 )
- Functional service interfaces ( CEN TS 15531-3:2015 )
Deux parties additionnelles ont été publiés en 2010 :
- Functional service interfaces – Facility Monitoring ( CEN/TS 15531-4 )
- Functional service interfaces – Situation Exchange ( CEN/TS 15531-5 )
Vous pouvez accéder aux spécifications de SIRI ainsi qu’au schéma XSD via le portail des normes pour les données d’offre du transport collectif.
La norme SIRI est donc utile pour des échanges système à système, elle utilise le protocole SOAP (Simple Object Access Protocol) sous format XML et englobe un ensemble de sous domaines (profils).
Siri Lite
SIRI n’étant pas adapté pour l’open data et la conception d’applications web, une norme dérivée a été développée : Siri Lite. En effet, les informations en temps réel ont aussi une utilité lors du développement d’applications, notamment pour fournir des informations sur les prochains passages, les alertes perturbations, etc. De plus, il utilise le protocole REST afin de faciliter son intégration. Ce protocole est utilisé de manière quasi systématique en contexte open data. Afin d’être rendu beaucoup plus compact, Siri Lite n’utilise que quelques services de SIRI :
- SM – Stop Monitoring, horaires par arrêt
- ET – Estimated Timetable, horaires par ligne
- GM – General Message, messages d’information
- VM – Vehicle Monitoring, suivi des véhicules
Pour obtenir plus d’informations notamment sur le profil de Sire Lite, nous vous suggérons de vous rendre sur le portail des normes pour les données d’offre du transport collectif.
GTFS realtime
GTFS-RT ou GTFS realtime est une extension de GTFS (General Transit Feed Specification). Il permet aux utilisateurs de bénéficier d’une mise à jour en temps réel sur les transports en commun. En effet, les agences de transports en communs, à travers GTFS realtime, fourniront aux développeurs d’applications une mise à jour en temps réel de leurs flottes. Cela nécessite donc un échange GTFS préalable avec une cohérence entre les données planifiées et temps réel. On parle ici de spécification de flux, ce terme peut paraître assez complexe mais en réalité il n’en est rien. Il s’agit en fait de flux de données, mis à jour selon un intervalle régulier par les agences de transports en communs.
Ce sont donc les agences de transports en commun qui publient les flux GTFS realtime, présentés sous 3 types ils sont appelés entités de flux :
- Mises à jour des trajets : retards, annulations, itinéraires modifiés.
- Alertes de service : arrêt déplacé, événements imprévus affectant une station, un itinéraire ou l’ensemble du réseau.
- Position du véhicule : informations sur les véhicules, notamment leur localisation et la densité du trafic.
Si vous souhaitez en savoir plus les différentes entités de flux, cliquez ici.
Le format d’échange de données de GTFS-RT n’est pas basé sur un format CSV comme GTFS mais est basé sur le Protocol Buffers. Ce système est beaucoup plus compact et optimisé que SIRI, mais il reste beaucoup moins adapté sur le marché public.
Entre formats normés et standards populaires
Nous avons pu voir dans cet article, les principaux formats de données. D’un coté, nous avons les formats NeTex et SIRI basé sur Transmodel, modèle normé et avec des spécifications complexes. De grandes institutions ont promu et développé ces formats. Ils ont de plus, la volonté de démocratiser ces normes. En effet, elles poussent les agences de transports publics à les utiliser pour la publication de leurs données.
D’un autre côté, nous avons le standard populaire GTFS, développé et promu par le géant Google. Ce standard, à l’origine, a été mis en place pour alimenter l’outil Google Maps. Une grosse communauté de développeurs a ensuite permis de porter le projet. Celui-ci est aujourd’hui le plus utilisé, et convient le plus à l’open data , au développement d’applications et aux calculateurs d’itinéraires. Lyko a d’ailleurs décidé de faire de GTFS son format d’échange pour alimenter son calculateur de trajets intermodaux.
On voit donc bien un parallèle entre formats normés et standards populaires, institutions publiques et institutions privés, groupements européens et membres du GAFA. Néanmoins, ce parallèle tend vers un but commun, rendre la donnée de transports la plus accessible possible afin de favoriser le développement de la mobilité et du MaaS.
Conclusion
Dans cet article, nous avons pu voir la liste des différents formats d’échanges de données liées au transport collectif. Ces échanges entre les différents acteurs de la mobilité sont favorables à l’évolution du concept de MaaS et des nouveaux calculateurs de trajets intermodaux. Néanmoins, les données de transports collectifs ne sont pas les seuls à favoriser cela. En effet, c’est en 2014 qu’un groupement d’organisation du secteur public et privé a décidé de développer le format de données de mobilité partagée GBFS. General Bikeshared Feed Specification est un nouveau standard uniforme pour l’échange de données en temps réel, pour les mobilités en free floating et la voiture partagée. La NABSA (North American Bikeshare Association) est l’organisme qui promeut ce standard.
Retrouvez les spécifications de GBFS sur Github.
Vous pourriez aussi aimer :
Comment le machine learning peut-il faire évoluer le MaaS ?
