CETE Méditerranée Analyse de Temps de Parcours en différé

Rapport CETE Méditerranée Analyse de Temps de Parcours en différé Centre d'etudes Techniques de l'equipement Méditerranée www.cete-mediterranee.fr

DCEDI/ALR Direction Générale des Infrastructures, des Transports et de la Mer Service des Affaires Générales et de la Stratégie/Mission des Transports Intelligents Analyse de Temps de Parcours en différé le cas de Marius à Marseille et perspectives dans d'autres agglomérations date : avril 2009 auteur : CETE Méditerranée responsable de l'étude : Patrick Gendre, DCEDI participants : Didier Goudergues, Gildas Lemaître, DCEDI résumé de l'étude : Le système Marius de la DIRMED (ex- DDE13) calcule des temps de parcours (TP) depuis plusieurs années sans les utiliser. Le CETE a obtenu en 2007 une commande de la DIR pour permettre l'affichage des TP sur PMV : le cahier des charges d'évolution du logiciel Marius pour gérer l'affichage des TP a été produit en 2008, mais le marché pourrait être lancé par la DIRMED en 2009 après diverses difficultés notamment de maintenance informatique. Quoiqu il en soit, avant d'afficher des TP sur les PMV, il faut vérifier qu'ils sont de bonne qualité. Le présent document résume le travail de qualification des données effectué par deux stagiaires encadrés par le CETE début 2009. Le rapport détaillé de ce stage étant disponible par ailleurs, l'objectif de ce document est plutôt d'une part de lister les suites possibles à ce travail au niveau du CETE avec la DIRMED, d'autre part la transférabilité des résultats : à savoir, d'éventuelles actions d'échange au niveau du réseau technique des CETE et de mutualisation des compétences en matière de traitement des données de trafic et de déplacements : méthodes et outils logiciels. Dans le cadre de ce travail, le CETE a utilisé des logiciels open source qui semblent pertinents et souhaiterait partager ce retour d'expériences avec d'autres collègues et bureaux d'études. zone géographique : PACA, Bouches-du-Rhône, Marseille nombre de pages : 26 n d'affaire : 08C000295 maître d'ouvrage : DGITM/SG/MTI (M. LAMBERT Roger) référence : proposition de devis du 6 octobre 2008 BD TP GPS Capvista v2 janvier 2009 2

SOMMAIRE 1 INTRODUCTION... 4 1.1 Objet du document... 4 1.2 Contexte... 4 1.2.1 Le système Marius... 4 1.2.2 Les temps de parcours... 4 1.3 Objectifs de l'étude... 5 1.4 Contenu du rapport... 5 2 DE L'OPPORTUNITÉ D'INVESTIR DANS LES OUTILS DE TRAITEMENT DES DONNÉES DE TRAFIC EN TEMPS DIFFÉRÉ... 6 2.1 de plus en plus de données... 6 2.2 des besoins réaffirmés... 6 2.3 une opportunité pour les CETE... 7 2.4 un besoin d outils et de savoir-faire... 7 3 ETUDE DES TEMPS PARCOURS ARCHIVÉS PAR MARIUS... 8 3.1 Environnement technique... 8 3.1.1 Chaîne de traitement... 8 3.1.2 les données... 9 3.1.3 Les outils... 11 3.2 Analyse des Temps de Parcours... 12 3.2.1 Éléments de méthode... 12 3.2.2 Disponibilité des TP calculés... 13 3.2.3 Quantiles et variabilité des TP... 14 3.3 Comparaisons TP calculés et TP mesurés par GPS... 16 3.3.1 Cadre de l'expérience... 16 3.3.2 Exploitation des données GPS... 17 3.3.3 Comparaison avec les résultats issus du système Marius... 18 3.4 Autres outils... 18 3.4.1 analyse de données individuelles, diagrammes iso-trafic... 18 3.4.2 positionnement d'événements... 18 4 CONCLUSIONS ET PERSPECTIVES... 20 4.1 Bilan de cette étude d'analyse de TP historisés... 20 4.1.1 Chaîne de traitement en temps différé.... 20 4.1.2 Comparaison des TP issus de traces GPS... 21 4.1.3 Calcul d'indicateurs... 21 4.2 Suites à donner pour la DIRMED... 21 4.3 Suites à donner pour les CETE... 22 4.3.1 Transférabilité de ces outils à d'autres CIGT que Marius: capitalisation... 22 4.3.2 groupe d échanges techniques... 22 4.3.3 échanges sur les montages partenariaux (observatoires, modèles de trafic)... 23 5 ANNEXES... 24 5.1 Bibliographie... 24 avril 2009 3

1 Introduction 1.1 Objet du document Le système Marius de la DIRMED (ex- DDE13) calcule des temps de parcours (TP) depuis plusieurs années sans les utiliser. Le CETE a obtenu en 2007 une commande de la DIR pour permettre l'affichage des TP sur PMV : le cahier des charges d'évolution du logiciel Marius pour gérer l'affichage des TP a été produit en 2008, mais le marché pourrait être lancé par la DIRMED en 2009 après diverses difficultés notamment de maintenance informatique. Quoiqu il en soit, avant d'afficher des TP sur les PMV, il faut vérifier qu'ils sont de bonne qualité. Le présent document résume le travail de qualification des données effectué par deux stagiaires encadrés par le CETE début 2009. Le rapport détaillé de ce stage étant disponible par ailleurs, l'objectif de ce document est plutôt d'une part de lister les suites possibles à ce travail au niveau du CETE avec la DIRMED, d'autre part la transférabilité des résultats : à savoir, d'éventuelles actions d'échange au niveau du réseau technique des CETE et de mutualisation des compétences en matière de traitement des données de trafic et de déplacements : méthodes et outils logiciels. Dans le cadre de ce travail, le CETE a utilisé des logiciels open source qui semblent pertinents et souhaiterait partager ce retour d'expériences avec d'autres collègues et bureaux d'études. 1.2 Contexte 1.2.1 Le système Marius Le trafic des autoroutes urbaines Marseillaises est exploité par la DIR Méditerranée, une des 11 directions interdépartementales nouvellement créées en 2006 pour exploiter le Réseau Routier National. Le Centre d'ingénierie et de Gestion du Trafic (CIGT) implanté à Septèmes-les-Vallons gère les autoroutes urbaines (VRU) de l'aire marseillaise et des Bouches-du-Rhône; pour la surveillance et l'exploitation du trafic, les opérateurs s'appuient sur le Système d'aide à la Gestion de Trafic, appelé MARIUS. Marius permet de recueillir les données en temps réel (état du trafic, vitesses,...) afin d'informer l'usager en temps réel des conditions de trafic (bouchons, accidents,...). Ainsi, le CIGT transmet ses informations directement à l'usager par le biais des Panneaux à Message Variable (PMV), et également par l'internet (sites Bison Fûté, ainsi que www.lepilote.com, le site d'information sur tous les déplacements à Marseille et dans les Bouches-du-Rhône). Le système informatique actuel date de 1999 et devrait évoluer dans les années qui viennent. 1.2.2 Les temps de parcours Le temps de parcours (TP) est de plus en plus reconnu comme un indicateur clé pour la qualité de service des réseaux routiers et pour l information aux usagers. Dès la conception du système à la fin des années 90, les temps de parcours ont été pris en compte et le système Marius calcule chaque minute des temps de parcours sur les tronçons autoroutiers depuis plusieurs années. Il était prévu par exemple dès sa création que le site web Lepilote tire parti des données de TP ( une nouvelle version du site est en cours de développement et ouvrira en 2009). Cependant, pour diverses raisons organisationnelles, budgétaires et techniques, ces informations n'ont pas été diffusées aux usagers ni même utilisées ou évaluées en interne. Le CETE a notamment contribué en 2005 à une évaluation des temps de parcours et les résultats, encourageants, ont eu une suite concrète mi-2007, après création de la DIR Méditerranée, avec la décision de faire évoluer le système Marius en vue d'afficher les TP sur PMV. Actuellement, les TP sont calculés et peuvent être diffusés sur internet ou analysés en temps différé, mais leur affichage sur les PMV n'est pas activable au niveau du poste opérateur du CIGT. La DIR MED a demandé au avril 2009 4

CETE Méditerranée d'élaborer un cahier des charges d'évolutions du logiciel Marius, qui a été produit début 2008. Le système Marius a fait l'objet par ailleurs en 2007 et 2008 de plusieurs évolutions techniques et fonctionnelles, qui pour diverses raisons, ont pris beaucoup de retard. Pour ces raisons l'appel d'offres pour implémenter les évolutions d'affichage des ne pourra être lancé qu'en 2009. En attendant ces évolutions, le CETE a proposé à la DIR MED d'analyser les TP en temps différé (par opposition au temps réel), afin d'avoir une idée de la pertinence des valeurs de TP qui pourraient être diffusées aux usagers, et de réfléchir en amont à la manière de qualifier ces TP et aux indicateurs qui pourront en être tirés. 1.3 Objectifs de l'étude L'objectif est d'analyser les TP archivés en temps différé par Marius afin de valider leur pertinence en vue d'une diffusion aux usagers. L'ambition visée n'est pas de donner une réponse permettant de décider dès maintenant d'une diffusion des TP aux usagers, d'autant plus que l'affichage des TP sur PMV n'est pas encore développé. Elle est plutôt de préparer le travail de qualification et d'analyse de données. En outre, les exploitants de la DIR MED ont déjà une bonne idée de la qualité du recueil de données de trafic, et savent notamment dans quels secteurs ou sur quels tronçons du réseau les données sont de bonne (ou de mauvaise) qualité. Par ailleurs, l'algorithme de calcul des TP a déjà été validé. Par conséquent, les résultats attendus portent sur les outils ou les méthodes plus que sur l'évaluation des données proprement dite : chaîne de traitement des données en temps différé méthode de comparaison avec des TP issus de traces GPS indicateurs calculés à partir des TP, représentations graphiques ou cartographiques mise en œuvre pratique des outils une fois l'évolution Marius TP sur PMV implémentée transférabilité de ces outils à d'autres CIGT que Marius 1.4 Contenu du rapport Après cette introduction qui présente le contexte, le rapport commence par expliquer pourquoi l'analyse du trafic en temps différé devrait faire l'objet dans les CETE. La partie la plus importante du rapport concerne l'étude d'évaluation des TP archivés par Marius: on y décrit d'abord les éléments techniques nécessaires à la compréhension du travail effectué (données Marius, principes de calcul des TP, outils logiciels mis en œuvre), puis l'analyse de données effectuée sur la base d'une quinzaine de jours de données TP moyens calculés sur 1 minute (avec propositions d'indicateurs), une comparaison avec des TP issus de traces GPS, et divers autres outils, dont la localisation des évènements de la main courante informatisée en vue de produire des cartes. La conclusion présente les principaux résultats obtenus, propose des suites à donner tant pour la DIR que pour les CETE, et propose des recommandations pour la suite du projet. Enfin, sont annexés au rapport un glossaire et une bibliographie. avril 2009 5

2 De l'opportunité d'investir dans les outils de traitement des données de trafic en temps différé Les services d étude «Exploitation / Gestion de trafic» des CETE sont sollicités pour évaluer a priori ou a posteriori l efficacité des mesures et systèmes d exploitation, ou pour analyser finement certains phénomènes de trafic. Or, en tout cas au CETE Méditerranée 1, il apparaît que les données de trafic historisées servent essentiellement à produire des états statistiques usuels (TMJA...), mais que nous ne disposons pas d'outils satisfaisants pour analyser et représenter facilement les données de trafic en réponse aux besoins précités d analyse et d évaluation. De tels outils seront par ailleurs indispensables si nous souhaitons nous développer des activités de simulation dynamique du trafic, en réponse aux besoins de plus en plus importants d'optimiser l'usage de la voirie. 2.1 de plus en plus de données Même si les systèmes d aide à la gestion du trafic ne se sont pas déployés sur tous les réseaux, le nombre de capteurs de trafic routiers continue à croître, sans parler des autres sources de données potentielles (caméras, radars, péages, résultats d'enquêtes, traces GPS voire de téléphones portables, etc.). Des mains-courantes informatisées ont également été mises en place chez bon nombre d exploitants routiers. Bien que ces données ne soient pas toujours facilement disponibles, surtout quand il faut remonter dans les archives, elles constituent néanmoins une matière première assez abondante. 2.2 des besoins réaffirmés Les rapports du CERTU, du SETRA ou du CGPC (devenu depuis CGEDD) sur l évaluation des opérations d exploitation soulignent la demande de plus en plus forte de l'administration central (DGITM) et des maîtres d ouvrages locaux (DIR et collectivités, sociétés concessionnaires) de demander des comptes aux exploitants, soit a posteriori pour estimer le service rendu par les Centres d Ingénierie et de Gestion de Trafic (au fil de l eau rapports d activité annuels, ou pour évaluer l intérêt d une mesure d exploitation en particulier, par exemple de régulation des accès autoroutiers), soit a priori pour justifier de nouveaux investissements. En outre, il nous semble que l analyse des données historisées doit aussi permettre de mieux caractériser la congestion récurrente sur les réseaux routiers, afin d améliorer les interventions en situation perturbée, d améliorer les éventuelles mesures de traitement de la congestion récurrente, et améliorer l information aux usagers. C est un aspect qui est rarement mis en avant mais qui nous semble essentiel. En termes de méthode, il est intéressant de regarder ce qui se fait aux USA en terme d'approche systématique pour le traitement de la congestion. La méthode américaine suit en 1ère approche des étapes simples, dont on retrouve d ailleurs les grandes lignes dans la note «stratégie d exploitation» du ministère : 1) mesurer la congestion : TP, heures perdues... 2) identifier les causes : bouchons, météo, événements, accidents, travaux... 3) distinguer congestion récurrente et non récurrente, concevoir et mettre en place des mesures permettant de les traiter (régulation et gestion de la demande pour le récurrent, gestion coordonnée des incidents, travaux et événements, gestion de crise et PGT pour le non-récurrent); 4) suivre dans le temps la congestion récurrente et non-récurrente et évaluer en conséquence les mesures d exploitation et d information prises. 1 C'est sans doute différent ailleurs, notamment avec l'équipe de la ZELT du CETE Sud-Ouest à Toulouse, ou le pôle ingénierie de trafic et déplacements du CETE Lyon en cours de création. avril 2009 6

2.3 une opportunité pour les CETE Dans le contexte de la réorganisation des services du ministère, et de la volonté croissante des collectivités de gérer globalement les déplacements sur les principales agglomérations, les CETE sont bien placés pour contribuer à la mise en place d observatoires de trafic et des déplacements et à l'analyse des données correspondantes, ainsi qu'à la modélisation et simulation des trafics, non seulement sur le réseau national mais plus globalement de manière partenariale sur des bassins de déplacements. Cela dit avant d atteindre ces ambitions, il est essentiel de prouver nos compétences sur les données de trafic du réseau géré par les DIR. 2.4 un besoin d outils et de savoir-faire Les exploitants routiers les plus importants (SISER/DIRIF au ministère, Concessionnaires autoroutiers, ville de Paris ou Grand Lyon hors ministère) possèdent des outils dédiés et des compétences, mais ce n est à notre connaissance pas le cas des autres CIGT, qui ont au mieux une base de donnée historisées, mais souvent sans personnel affecté à l analyse des données. Les études de simulation de trafic sont parfois sous-traitées pour des besoins ponctuels (gros projets d aménagements ou nouvelle stratégie de régulation), les exploitants ne possédant les compétences en interne. Limité au RRN, le système d information trafic (SIT et futur SICOT) répond essentiellement aux besoins de planification, sécurité routière, entretien: statistiques mensuelles, TMJA et peu aux besoins d étude de gestion du trafic des exploitants (évaluation de mesures, analyse fine de la congestion, croisement entre trafic et événements, etc.). Dans les CETE, les activités et les équipes du domaine transport/déplacements sont souvent séparées de celles du domaine trafic/exploitation, alors qu'elles concernent parfois le même territoire, les mêmes maîtres d'ouvrage, et peuvent faire appel à des données, méthodes ou outils similaires ou voisins. avril 2009 7

3 Etude des Temps Parcours archivés par Marius 3.1 Environnement technique 3.1.1 Chaîne de traitement La figure ci-dessous donne une vue d'ensemble de la chaîne de traitement, ce qui permet de situer les principales données et leur cheminement à travers les outils. Point de Mesure PMV Opérateurs M A R IU S te m p s ré e l S E R V E U R te m p s d iffé ré Configuration TP Évènement QTV 1,6 bilans DUMP de la BD Marius Archive HMVL Export des coordonnées des PM B D p o s tg re s lo c a le Q G is TP 1 PM,VOIE,SEG,ITI L o g ic ie l R Visualisation cartographique : - du réseau -des évènements avril 2009 -TP,trafic 8

3.1.2 les données 3.1.2.1 Modélisation du réseau routier L'informatique oblige à définir de manière précise les différents concepts utilisés, ce qui est une bonne chose. Ce travail a été réalisé lors des spécifications du système à la fin des années 90. Les données décrivant le réseau Marius sont décrites et gérées dans un Système d'information Géographique (SIG) appelé GeoMarius qui alimente les applications temps réel et temps différé. Les termes et leurs définitions ne sont pas forcément les mêmes que ceux employés pour d'autres systèmes de gestion de trafic, le vocabulaire n'étant pas normalisé. Il nous semble utile de présenter brièvement les termes principaux qui sont utilisés dans le référentiel GéoMarius.. définition du vocabulaire: - Axes: les axes sont les différentes autoroutes gérées par Marius; ils sont précisés par la notion de secteur-sens (maille autoroutière - en général entre 2 nœuds du réseau) - Sens: le sens est une partie orientée d'un axe. - Point de mesure: Un point de mesure construit ses mesures avec toutes les voies d'un seul sens d'un site. Les points de mesures sont répartis tous les 500m environ, en tout cas pour la partie centrale du réseau Marius, où sont calculés les TP et qui représente environ la moitié du linéaire des VRU gérées. - Segments: Un segment est un ensemble de points de mesures contigus. - Itinéraire: Un itinéraire est un ensemble de segments contigus. Une vingtaine d'itinéraires a été validée par la DIRMED, sur lesquels seront calculés des TP destinés à être affichés sur les PMV existants. carte du réseau Marius et itinéraires PMV sous GéoMarius avril 2009 9

3.1.2.2 Calcul des TP (en temps réel) Le réseau des voies rapides urbaines, en tout cas dans sa partie centrale qui est la seule que nous étudierons ici, est divisé en tronçons de 500 mètres environ, rattachés chacun à un point de mesure (PM). L'algorithme de calcul est très simple: il suppose que la vitesse des véhicules est homogène sur chaque tronçon (ce qui est vrai dans la mesure où le tronçon est court), et calcule le temps de parcours en divisant la longueur du tronçon par la vitesse moyenne dans la minute considérée. Le temps de parcours sur un segment est ensuite calculé comme la somme des TP sur les tronçons des Points de Mesure (PM) du segment, et de même le TP sur un itinéraire est la somme des TP sur les segments constituant l'itinéraire. Marius calcule actuellement, chaque minute, des temps de parcours pour une vingtaine d'itinéraires définis à l'aide de Géomarius. Ces itinéraires actuellement configurés correspondent aux grandes mailles du réseau Marius. De nouveaux itinéraires ont été définis dans le cahier des charges d'évolution de Marius, plus adaptés aux sites où sont implantés les PMV. Chaque tronçon est défini géographiquement par les coordonnées d'un objet linéaire de Géomarius. Les tronçons actuellement configurés correspondent aux segments entre deux échangeurs. La géométrie des 70 tronçons actuellement définis a été exportée sous forme d'une table au site "LePilote", pour affichage sur l'image circulation temps réel de ce site. Le serveur Marius calcule également un niveau de service (fluide, dense, saturé, bloqué) sur les segments qui est exporté en temps réel, toutes les minutes, vers les sites internet de LePilote et de BisonFuté, où il est représenté par une carte avec un code couleur des tronçons (image circulation Lepilote, dont une nouvelle version est en cours de développement et ouvrira début 2009). Le niveau de service est une fonction des vitesses et des débits mesurés sur tous les points de mesure du tronçon. 3.1.2.3 Le serveur temps différé Marius Le serveur principal de Marius fonctionne en temps réel pour piloter les équipements de terrain, traiter les données et fournir une interface aux opérateurs du CIGT (Centre d'ingénierie et de Gestion du Trafic). Un second serveur permet d'archiver les données produites par Marius, d'y accéder sur intranet, de produire des statistiques et de les analyser en temps différé. Une première version de ce serveur temps différé a été mise en service en 2005. Elle ne comprenait pas la totalité des données produites par Marius. Une seconde version, plus complète, comprenant notamment les temps de parcours, et les événements de la main-courante Marius, avait été prévue dès la conception de ce serveur en 2002, mais sa réalisation n'a pu être lancée qu'en 2007. Suite à des retards importants dans la maintenance des logiciels de Marius, cette seconde version n'était pas complètement en service quand a débuté le stage objet de ce rapport fin novembre 2008. Dans cette base temps différé sont stockées toutes les données produites par Marius: la description du réseau (secteurs, points de mesure, segments, itinéraires..) les données de trafic débit, taux d'occupation, vitesse (Q, T, V) sur 1 et 6 minutes les événements de la main-courante informatique (accidents, etc.) les temps de parcours 1 et 6 minutes des bilans du trafic et des événements par jour, semaine, mois, ou année Il s'avère qu'en pratique, comme on l'a vu, les temps de parcours 1 minute, et 6 minutes seront archivés quand la version définitive du serveur temps différé sera livrée, mais ils n'étaient pas disponibles pour cette étude. Heureusement, les informaticiens du CIGT ont archivé les données brutes de Marius sur l'ensemble de l'année 2008, et ont pu mettre à notre disposition des fichiers de mesures individuelles que nous avons utilisés pour reconstituer le calcul des TP 1 minute. Les mesures individuelles sont stockées dans un fichier dit HMVL (Heure Minute Vitesse Longueur). A la avril 2009 10

DIRMED, il existe un fichier par minute, qui contient une ligne par passage d'un véhicule détecté sur un point de mesure. Marius est l'un des rares systèmes sinon le seul à exploiter ces données individuelles, néanmoins les stations de recueil Siredo permettent de les obtenir, au moins ponctuellement sur demande. 3.1.3 Les outils La plupart des logiciels que nous avons utilisés sont open source, ce qui nous a permis de les utiliser librement sans licence d'utilisation à acquérir. Chaque outil a une fonction différente, et d'autres outils pourraient être utilisés pour accomplir les mêmes tâches, mais la chaîne de traitement et les compétences nécessaires pour l'analyse des données de trafic resterait la même: pré-traitements (extraction, filtrage, conversion de formats) analyse de données / statistiques analyse spatiale / cartographie base de données en outre nous avons utilisé l'application CapVista, récemment développée par le CETE en vue de produire des temps de parcours en différé à partir de traces GPS. 3.1.3.1 Base de données: PostgreSQL La base de données PostgreSQL est la principale base de données relationnelles open source avec MySQL et SQLlite. Elle présente deux intérêts principaux : elle est utilisée par la DIR MED pour le serveur temps différé, nous avons donc pu récupérer les données par un simple «dump» (export SQL) de la base. Pour information, l'application de la DIR était initialement sous MySQL mais a été portée sous Postgres, qui est la BD choisie par l'ensemble du ministère. elle dispose d'une extension géographique Postgis, qui a pratiquement le monopole dans le domaine open source. Cette extension permet de décrire la géométrie des objets gérés dans les tables, de manière à pouvoir les visualiser sous forme de «couche» dans un Système d'information Géographique (SIG), et à pouvoir faire des requêtes spatiales et topologiques (proximité, inclusion, etc.), que nous utiliserons notamment pour localiser les événements de la main-courante Marius. 3.1.3.2 Pré-traitement des données Le pré-traitement de données est une activité incontournable quoiqu ingrate avant l analyse proprement dite. En pratique, même si les données sont disponibles via un serveur temps différé jouant le rôle d infocentre, qui permet d extraire simplement ce que l on cherche via une base de données, il reste indispensable de savoir manipuler des fichiers, pour réaliser divers filtres et pré-traitements selon les analyses particulières à conduire. Dès que le nombre de données à manipuler est important, par exemple s'il dépasse quelques centaines, l utilisation d un tableur comme Excel ou de langages comme Visual Basic s avère lourde. Pour l analyse des fichiers temps de parcours issus du système Marius, nous avons utilisé le logiciel libre awk (version Windows) ; c est un langage spécialisé dans la manipulation de fichiers et notamment de chaînes de caractères, et on peut le recommander pour les diverses "moulinettes" et conversions de formats. Mais il existe bien d'autres outils de ce type. Éventuellement, pour traiter un grand nombre de fichiers, on peut utiliser des scripts (Shell DOS, VBS ou WSH sous Windows) pour lancer successivement plusieurs traitements de fichiers. avril 2009 11

3.1.3.3 Analyse des données: le logiciel R Pour l analyse des données, nous avons utilisé R, un logiciel de calcul statistique disponible pour les systèmes d exploitation Windows et Unix. R est un logiciel libre, qui est distribué selon la licence GPL (General Public licence). Principaux points forts : R est un logiciel gratuit, assez bien documenté et régulièrement amélioré, qui dispose d une grande palette de fonctions statistiques et de fonctions d import/export (y compris pour se connecter à des bases de données) et graphiques relativement conviviales. En revanche, R s appuie sur un langage de programmation et exige un réel investissement avant une quelconque utilisation sérieuse, mais c est sans doute le cas aussi de ses concurrents commerciaux comme Statlab ou SAS. Il existe bien sûr d'autres logiciels, à commencer par Excel et Calc, mais aussi Matlab ou Scilab (open source et d'origine française) dans le domaine du calcul scientifique, qui aurait pu être utilisés, mais R nous semble un bon compromis, et nous aurions tendance à le recommander, même si il nécessite un réel apprentissage. 3.1.3.4 Système d'information géographique QGIS QGIS est un des SIG open source les plus répandus, qui permet très facilement de se connecter à une base Postgis, un atout important dans notre cas. L'existence de formats standards pour les données géographiques fait que d'autres SIG commerciaux auraient pu aussi être utilisés (Géomarius est géré sous GeoConcept, le logiciel SIG du ministère est Mapinfo, l'application CapVista pour les TP GPS est sous GrfMap), et permettraient éventuellement des fonctionnalités plus élaborées de cartographie dont nous n'avions pas besoin dans le cadre de ce stage. 3.1.3.5 Temps de parcours GPS : CapVista CapVista est une application développée par le CETE en vue de produire des temps de parcours en temps différé à partir de traces GPS; c'est un module du SIG GrfMap de la société ICIA. La nouvelle version développée fin 2008 apporte deux grandes fonctions supplémentaires: la possibilité de télécharger les traces collectées par le terminal GPS sur un site web où il est possible de les visualiser; le calcul de TP entre zones plutôt que sur des tronçons routiers, qui ne nécessite pas de définir de cartographie routière car les zones peuvent être définies simplement dans le SIG GrfMap sur un fond de carte par l'utilisateur de l'application, ce qui peut être un avantage pour des études de ce type. 3.2 Analyse des Temps de Parcours 3.2.1 Éléments de méthode Quelle que soit la méthode de calcul pour les obtenir (données TP archivées, ou reconstitution des TP par d'autres algorithmes effectués en temps différé, dans R en l'occurrence), on suppose que l'on dispose désormais d'une base de données comprenant un historique des TP et autres données de trafic sur une période de temps. Comment valider la pertinence de ces temps de parcours? L'objectif n'est pas ici d'analyser une situation de trafic, par exemple, à l'occasion d'une perturbation exceptionnelle, ou pour identifier des tendances, ou mettre en évidence des zones accidentogènes. Il est seulement de proposer des indicateurs. avril 2009 12

Le premier indicateur à identifier est la disponibilité des TP : compte-tenu du taux de disponibilité du recueil de données de trafic sur le terrain, et des règles de validation du calcul de TP, combien de minutes dans une journée peut-on s'attendre à ce qu'un TP d'un itinéraire soit à zéro (et donc non diffusable)? Le second indicateur concerne le niveau de congestion. Pour cela nous utilisons la notion de quantile. Le quantile à x% est le plus petit élément q des valeurs des termes d'une série tel qu au moins x % des données soient inférieures ou égales à q. Le quantile à 50 %, ou médiane, est un indicateur «robuste», insensible aux valeurs extrêmes de l'échantillon contrairement à la moyenne. Le troisième type d'indicateurs concerne la variabilité du TP, d'une heure à l'autre, d'un jour à l'autre, d'une voie à l'autre... Le travail a été conduit sur un échantillon de données d'une quinzaine de jours en octobre 2008, suffisamment pour être significatif, en période ouvrée et après la rentrée étudiante pour obtenir le maximum de congestion, et dans une période récente de sorte que les résultats soient encore pertinents. Pour une diffusion opérationnelle, la DIRMED pourra répéter ces traitements sur d'autres périodes, ou pour des qualifications périodiques, hebdomadaires par exemple. 3.2.2 Disponibilité des TP calculés La disponibilité des TP par itinéraires ou par segments (c'est à dire la proportion de TP non nuls - donc validés par Marius) est le 1er indicateur à traiter. On peut le représenter sur une carte ou dans une table en même temps que les quantiles (médianes, etc.). représentation schématique de l'indisponibilité des segments avril 2009 13

En résumé, environ vingt itinéraires peuvent servir à l'étude du trafic, mais le seuil de disponibilité pour la diffusion aux usagers est à décider par l'exploitant DIRMED, il peut d'ailleurs être différent pour une diffusion PMV que sur l'internet, où l'on peut être moins exigeant. On peut approfondir l'analyse de l'indisponibilité (TP nuls) en étudiant plus en détail les segments et les itinéraires. Il apparaît que sur certains itinéraires, les TP peuvent être hors service seulement pendant quelques jours, alors que d'autres ont chroniquement une qualité inacceptable. En conclusion, on peut considérer que pour l'exploitant, il faudrait à la fois : maintenir une liste d'itinéraires avec des TP diffusables, qui pourrait par exemple être mise à jour chaque mois ou chaque trimestre, en fonction des opérations de maintenance des équipements de terrain en cours; invalider chaque matin / chaque soir avant l'heure de pointe au niveau de l'opérateur les itinéraires dont les TP seraient trop dégradés. 3.2.3 Quantiles et variabilité des TP Le tableau ci-dessous indique pour chaque itinéraire, la valeur de TP de référence à 90 km/h, la médiane, et les quantiles Q90, Q99, ainsi que le taux de disponibilité calculé précédemment. Cela permet d'identifier les itinéraires les plus congestionnés. Une analyse à la journée, du graphique ci-dessous, pour les mêmes itinéraires permet notamment d'identifier la journée du 8 octobre comme particulièrement chargée : pour cette journée, il faudrait pouvoir corréler le trafic avec les événements de la main-courante Marius, mais nous ne disposions pas de ces données. itinéraire TP de reférence quantile à 50% quantile à 90% quantile à 99% taux d'indisponibilité Luynes-VxPort 23' 7'' 48'' 55'' 2' 6'' 0,02 Luynes-Plombieres 14' 25'' 0 0 0 100 Caillols-Plombieres 9' 55 0 0 0 100 Caillols-Septemes 4' 45 '' 2' 5' 29'' 17' 14,63 Aygalades-Plombieres 48 '' 0 0 0 100 Aygalades-Vieux Port 2' 1'' 21' 4'' 54' 13'' 139' 5'' 0 Janet-VieuxPort 2' 54'' 15' 45'' 0 0 100 Janet-Joliette 1'41'' 15' 45'' 49' 29'' 134' 47'' 0 Agavon-VieuxPort 10' 36'' 12' 56'' 15' 51'' 22' 40'' 0,02 Agavon-Plombieres 10' 19 0 0 0 100 Rebuty-VieuxPort 9' 51'' 0 0 0 100 Rebuty-Plombieres 9' 34'' 12' 10'' 15' 1'' 21' 49'' 0,02 Marseille-Vitrolles 0 0 0 0 100 Marseille-Luynes 15' 52'' 13' 23 16' 33'' 29' 47'' 0,02 StAntoine-Agavon 0 9' 34'' 12' 31'' 25' 28'' 0,02 StAntoine-Luynes 11' 18'' 4' 30'' 5' 24'' 15' 15'' 0,58 Bourbonne-Pologne 11' 21'' 13' 7'' 18' 25'' 38' 51'' 13,14 Bourbonne-Penne 4'42'' 4' 50'' 6' 20'' 16' 51'' 7,51 Solans-Pologne 12' 55'' 13' 53'' 19' 34'' 40' 55'' 27,26 Solans-Penne 3' 38'' 3'22'' 4' 28'' 18' 21'' 7,5 Lignieres-Pologne 11' 17'' 12' 22'' 17' 41'' 34' 34'' 27,26 Lignieres-Penne 2' 1' 51'' 2' 39'' 10' 31'' 7,47 Penne-Pologne 9' 17'' 10' 28'' 15' 22'' 29' 20'' 27,21 Penne-Florian 4' 29'' 4' 23'' 6' 29'' 16' 40'' 6,54 Pologne-Penne 6' 33'' 6' 12'' 7' 30'' 13' 18'' 45,88 Pologne-Aubagne 8' 33'' 8' 12'' 9' 31'' 17' 4'' 6,84 Penne-Aubagne 2' 1' 48'' 1' 59'' 3' 54'' 6,71 Penne-Bourbonne 4' 42'' 4' 53'' 6' 49'' 10' 34'' 22,59 avril 2009 14

3.2.3.1 variabilité intra-journée La variabilité du TP à l'intérieur d'une même journée permet bien sûr d'estimer l'importance de la congestion et des pointes. Elle permet aussi de voir les instabilités du TP d'une minute sur l'autre, qui peuvent être réelles («accordéon»), mais aussi être un artefact de la méthode de calcul des TP. C'est ce qui semble être le cas dans les données que nous avons observées, notamment pointe du matin du 8 octobre : en pratique, on ne peut pas afficher sur un PMV un TP qui passe disons de 21 à 29, puis à 18 et à 25, d'une minute sur l'autre, et il faut donc que les TP soient lissés (avec une moyenne glissante sur plusieurs minutes serait sans doute le plus simple). TP du 5,8 et 9 oct sur l'itinéraire StAntoine-Agavon TP 0 10 20 30 40 50-5 oct - 8 oct - 9 oct 01:00 05:00 09:00 13:00 17:00 21:00 heure TP des 5,8 et 9 octobre 2008 sur l'itinéraire St Antoine-Agavon 3.2.3.2 variabilité entre voies L'étude de la variabilité des TP d'une voie à l'autre présente selon nous 2 intérêts : - elle donne une idée de la fourchette des TP réels entre les différents usagers, et donc aussi de l'erreur acceptable pour les TP diffusés sur PMV ou sur le web; - elle permet d'analyser plus finement le niveau de service aux échangeurs, notamment si le réseau est maillé ou pour mettre en place des dispositifs de régulation. Par exemple, sur le simple trajet Pologne-Penne (A50), le TP passe de 22 à 31 minute selon que l'usager avril 2009 15

resterait toujours sur la voie la plus rapide ou la plus lente. Nous avons représenté ci-dessous l'évolution du temps de parcours par voie au cours de la journée du 01/12/08 au niveau du PM M8H, appartenant à l'itinéraire «Pologne-Penne». Nous constatons que la voie de gauche (en rouge) est majoritairement la plus rapide sur l'ensemble de la journée. En revanche, dans les zones critiques de bouchons, cette dernière ne semble pas être l'option la plus avantageuse. On constate aussi que les voies de droite et du centre sont, lors des périodes fluides, sensiblement équivalentes. En régime fluide, on observe une différence de 30km/h entre la voie de gauche et les deux autres voies. légende Voie de droite : bleu voie centrale : vert voie de gauche : rouge évolution du TP par voie pour le PM M8H 3.3 Comparaisons TP calculés et TP mesurés par GPS De manière générale, les TP des boucles peuvent être comparés avec d'autres méthodes de mesure (véhicule flottant, lecture de plaques, etc.). Cela a été fait ces dernières années par exemple sur le réseau francilien, lyonnais, ou dans la vallée de la Romanche en Isère. Nous renvoyons sur ce sujet aux guides du CERTU sur les temps de parcours. A Marseille, nous avions déjà en 2004-2005 effectué des comparaisons entre les TP calculés par Marius et ceux mesurés par GPS dans la navette autoroutière Aix-Marseille du Conseil Général (la différence entre les deux s'est avérée d'ailleurs tout à fait acceptable, en général de moins de 10%). L'intérêt de la comparaison présenté ici est qu'il s'agit d'une méthode simple et peu coûteuse, et que l'application CapVista est conçue pour permettre de cumuler les données GPS si on le souhaite dans une base de données en temps différé que l'on peut compléter progressivement. 3.3.1 Cadre de l'expérience Afin de comparer les temps de parcours calculés par le système Marius, nous avons envisagé de relever ces TP de manière autonome directement sur le réseau. Ainsi, à l'aide de boitiers GPS, nous sommes capables de relever les données de vitesses et de temps de parcours effectuées au cours d'un trajet. Nous avons donc, afin de recueillir un maximum de données, réparti nos boitiers GPS entre des agents ou stagiaires du CETE et des agents de la DIR (au CIGT de Septèmes-les-Vallons). avril 2009 16

Grâce au site web associé au logiciel CapVista (http://opencarto.fr/gpsviewer/map/), un utilisateur peut visualiser ses trajets, préalablement enregistrés grâce à un boitier GPS et envoyés sur le site puis sur une carte. Le site calcule la longueur du trajet, le temps de parcours, donne visuellement la vitesse du conducteur. Le trajet envoyé est stocké et peut être exploité par l'administrateur via le logiciel Capvista en cours de développement, pour calculer plus précisément les temps de parcours sur tout le trajet. Visualisation du trajet sur un carte Trajet GPS de l'utilisateur CAPVISTAWEB Données sur le vitesse moyenne, le temps du trajet, le kilométrage... Fichier du trajet 3.3.2 Exploitation des données GPS Dans le cadre de cette expérience, nous avons choisi comme exemple le trajet Bouc Bel Air-Septèmes effectué le 01/12/08 à 13h45. A l'aide des boitiers GPS et du site CapVistaWeb, nous pouvons extraire de nombreuses informations. Ainsi, nous avons effectué ce jour un parcours de 15,1 kilomètre en 13 min 13 sec, dont 6 min 35 passées sur le réseau Marius. Notre vitesse moyenne était de 67km/h. Entrée sur le réseau Marius D: Départ A : Arrivée Fin de la prise de mesure représentation du parcours test sur CapVistaWeb avril 2009 17

Le système divise le temps de parcours en dix parties égales, symbolisée par des points blancs. Dans cet exemple, deux points blancs représentent une durée écoulée de 1 minute 19. 3.3.3 Comparaison avec les résultats issus du système Marius Afin d'effectuer une comparaison cohérente, nous avons recalculé le temps de parcours que nous aurait annoncé Marius lors de notre départ à 13h45. Le système Marius calcule alors un temps de parcours de 6min18, soit 17 secondes de moins pour 15 kilomètre, une différence négligeable. Nous avons donc vérifié sur un exemple simple mais caractéristique, que le temps de parcours calculé par Marius était satisfaisant. La comparaison se fait visuellement sur le site web de Capvista. Pour travailler de manière plus systématique, il faudrait calculer des statistiques avec l'application Capvista afin de faire des comparaisons chiffrées sur un plus grand nombre de mesures. Il aurait fallu pour cela effectuer un grand nombre de traces GPS (ce que la DIR pourrait faire au fil de l'eau si elle le souhaite), nous n'avons donc pas effectué ce travail (à noter qu'on avait déjà validé la qualité des TP calculés en 2005, mais une nouvelle validation serait utile pour tester les TP sur les nouveaux itinéraires définis en vue d'un affichage sur les PMV). 3.4 Autres outils 3.4.1 analyse de données individuelles, diagrammes iso-trafic De tels outils ont été développés au niveau du poste opérateur Marius. Lors d'un stage en 2006, ils ont été portés sous scilab, un logiciel libre de calcul scientifique. De même, l'application Marius dispose d'un outil de visualisation des mesures individuelles de trafic issues de stations Siredo ; le CETE a fait porter ses fonctionnalités en 2005 dans un logiciel baptisé LAMI. Ces deux développements peuvent être mis à la disposition de la communauté. Plus largement, le CETE avait fait des propositions sur la mise en place d'un processus de qualification des données Marius, un sujet qui mériterait des échanges entre les CIGT des DIR et autres exploitants, et une capitalisation au niveau du Réseau Technique et des CETE. 3.4.2 positionnement d'événements Dans le cadre du stage effectué, il n'a malheureusement pas été possible d'analyser les données de manière plus approfondies, notamment de corréler le trafic avec les événements de la main-courante d'exploitation. Néanmoins, il a été possible a minima d'utiliser cette main-courante pour visualiser la position des événements en utilisant la même base de données Marius archivée. Les opérateurs du CIGT Marius ont une vision d'ensemble de ce qui se passe sur le réseau et consignent la situation dans ce qu'on appelle une main-courante informatique, qui contient les événements situés sur le réseau. Ces événements sont repérés classiquement dans le métier de l'exploitation routière, par des points de repère kilométriques (PR) indiquant leur position linéaire par rapport à un point de référence (PR 0). La nouvelle version de la base de données Marius temps différé intègre non seulement les temps de parcours, mais aussi les événements de la main-courante. Il était donc intéressant de chercher à les exploiter, par exemple, pour ce qui nous concerne, en vue de corréler des TP dégradés avec des événements particuliers tels que des accidents ou des restrictions de voies. Pour permettre la visualisation des événements dans un système d'information géographique, il faut au préalable convertir les positions localisées par PR + abscisse relativement à un axe, en positions géo- avril 2009 18

référencées (coordonnées x,y). Postgis, l'extension géographique de PostgreSQL, comprend des fonctions de géocodage qui permettent, connaissant la géométrie d'un tronçon et l'abscisse curviligne du point sur le tronçon, de calculer sa position x,y dans n'importe quel système de coordonnées. Il nous suffit donc d'associer à chaque événement, en plus de son PR, la géométrie du secteur sens où il est situé, pour pouvoir calculer ses coordonnées, ce qui permettra de voir les événements cartographiés dans un SIG. exemple de représentation d'évènements dans QGIS avril 2009 19

4 Conclusions et perspectives 4.1 Bilan de cette étude d'analyse de TP historisés En introduction, nous avions indiqué nos objectifs portaient plutôt sur les outils ou les méthodes de validation des TP que sur l'évaluation des données proprement dite, à savoir : chaîne de traitement des données en temps différé méthode de comparaison avec des TP issus de traces GPS indicateurs calculés à partir des TP, représentations graphiques ou cartographiques mise en oeuvre pratique des outils une fois l'évolution Marius TP sur PMV implémentée transférabilité de ces outils à d'autres CIGT que Marius L'indisponibilité des TP 1 minute nous a contraints à développer un algorithme de calcul de ces TP et ne nous a pas permis de travailler autant que souhaitable sur l'analyse des données proprement dite, néanmoins on peut considérer que les objectifs ont été atteints. Notre travail a permis de valider une chaîne complète de traitement des données de trafic, d'obtenir des résultats significatifs et de faire des propositions en termes de méthodes et d'outils. Bien évidemment, nous n'avons produit que des pistes qui restent à travailler de manière opérationnelle par la DIRMED, le cas échéant avec l'assistance du CETE ou d'un autre prestataire. 4.1.1 Chaîne de traitement en temps différé. Les logiciels utilisés (Postgis, R, QGIS...) nous ont semblé pertinents pour les besoins. La seule difficulté technique rencontrée réside dans le problème de taille mémoire en cas de traitement sur un très grand nombre de données. Il ne sert à rien de lancer d'emblée des traitements sur plusieurs millions de données, il vaut mieux planifier dès le départ et découper en plusieurs étapes avant de lancer des traitements lourds! Il nous apparaît que cette chaîne de traitement en temps différé est indispensable pour la validation et l'analyse des données, et complémentaire du serveur temps différé Marius, qui propose sur intranet des bilans statistiques et extractions de données. De manière à ne pas perturber le fonctionnement du serveur de données, il nous semble que la solution consistant à travailler sur une copie locale («dump») de la base de données temps différé est la plus pertinente. La base locale et les outils de traitement pourraient être mis en place soit à la DIR, soit au CETE, soit chez un bureau d'études dans le cadre d'une prestation, les conditions de mise à jour des données Marius restant à préciser. Ces outils peuvent servir à identifier les itinéraires dont les temps de parcours sont diffusables, à partir d'indicateurs produire diverses analyses de données tester de nouvelles méthodes de calcul En effet, la reconstitution des TP 1 minute à partir des fichiers HMVL nous a pris beaucoup de temps, mais cela présente de l'intérêt dans la mesure où la même démarche pourrait être utilisée pour tester d'autres algorithmes de calcul des TP : méthode des stocks, calcul sur des sections de plus de 500 mètres (jusqu'à 3 km), test de règles de validation des TP sur itinéraires moins contraignantes (autorisant un TP segment manquant, en vue d'améliorer la disponibilité des TP diffusés), etc. avril 2009 20

4.1.2 Comparaison des TP issus de traces GPS L'outil CapVista peut certainement permettre une validation des TP calculés par Marius, ainsi que donner des éléments sur les TP d'itinéraires non équipés de points de mesure. Cela implique néanmoins des campagnes de mesures GPS un peu systématiques par la DIRMED. 4.1.3 Calcul d'indicateurs Les indicateurs que nous proposons sont de 3 types : taux de disponibilité des TP quantiles permettant d'identifier le niveau de congestion des segments variabilité: de voie à voie, selon l'heure de la journée, selon le type de jour Nous n'avons eu le temps que d'esquisser ce travail, compte tenu du temps passé pour développer le re-calcul des TP 1 minute. Ces indicateurs pourraient être produits par exemple chaque mois, ou trimestre, et servir à identifier les itinéraires dont les TP sont diffusables. Au quotidien, le taux de disponibilité des TP devrait être calculé chaque matin et chaque soir avant l'heure de pointe, pour permettre à l'opérateur du CIGT de désactiver l'affichage sur les itinéraires trop défectueux. Le seuil du taux de disponibilité acceptable reste à préciser. Il aurait également fallu approfondir le comportement des TP calculés. En cas de forte congestion, les TP 1 minute varient-ils beaucoup d'une minute à l'autre? Y a-t-il des valeurs aberrantes? Quel retard éventuel y a-t-il entre les TP calculés, et la congestion réelle, lorsque la congestion évolue à la hausse ou à la baisse dans un bouchon? De même, nous aurions désiré représenter, sur un même graphique, l'évolution du TP sur trois voies différentes corrélée avec la présence des bretelles d'accès à l'autoroute. Il sera également souhaitable de corréler les TP élevés avec les évènements enregistrés au niveau de la maincourante Marius. A moyen terme, il sera utile de calculer systématiquement des statistiques par itinéraire sur toute une année, afin de produire des estimations de prévision de TP (fourchettes) selon le type de jour, à l'instar de Sytadin (http://www.sytadin.fr) en Ile-de-France. Ces fourchettes historiques peuvent d'ailleurs être diffusées aux usagers. Il y a suffisamment de données pour qu'on puisse espérer rapidement des premiers résultats significatifs. 4.2 Suites à donner pour la DIRMED Pour une utilisation pratique avant la diffusion des, il faudra impérativement que la version définitive du serveur temps différé soit livrée. A partir de là, il faudra notamment vérifier toutes les informations de configuration GeoMarius. Dans la base dont nous disposions, plusieurs points de mesure actifs sur le réseau ne sont pas référencés. La base de données Marius est donc incomplète. De même, des points de mesures sont référencés dans la base de données, mais n'ont pas été activés sur le réseau. En outre, la longueur des itinéraires dans la base n'est pas forcément cohérente avec la somme des longueurs des tronçons affectés à chaque Point de Mesure constituant l'itinéraire. A noter que sans doute à cause d'erreurs dans nos informations de configurations des itinéraires, certaines valeurs de TP par itinéraire sont manifestement erronées (pour les itinéraires 1001, 1006 et 1005). Ce point reste à corriger mais de toutes façons lorsque la nouvelle version du serveur temps différé sera opérationnelle, les données utilisées seront les archives des TP 1' et pas les TP que nous avons reconstitués. Cette étude a été présentée à la DIRMED en mars 2009. Les principales propositions de suites à donner sont listées ci-dessous, avec 3 niveaux de priorité. Leur mise en oeuvre impliquera de faire appel à des prestataires, mais pas forcément le CETE, qui pourra contribuer en partie. avril 2009 21

1. - réceptionner la nouvelle version opérationnelle du serveur temps différé - identifier les tronçons où l on pourrait diffuser de l info TP par PMV à court/moyen terme - envisager les évolutions nécessaires du système informatique Marius pour la diffusion des TP 2. - utilisation du serveur temps différé Marius pour produire un rapport d activité annuel - calcul et visualisation des heures perdues dans les bouchons à partir des temps de parcours - envoi des événements Marius vers le site Bison Futé ; - corréler TP/trafic et événements/météo - qualifier systématiquement le recueil et le trafic par tronçon - faire des propositions pour la mise en place d un observatoire de trafic (partenarial) - analyse des besoins de la DIR MED en matière de données et d information trafic - analyse de la base historique du CIGT VRU de Toulon 3. - proposer des présentations possibles de l info sur la congestion récurrente (cf. Sytadin) - étudier l algorithme TP de Marius - étendre le calcul des TP aux recueils Siredo 6 4.3 Suites à donner pour les CETE 4.3.1 Transférabilité de ces outils à d'autres CIGT que Marius: capitalisation La seule spécificité de Marius est l'utilisation de mesures individuelles, la plupart des autres CIGT travaillant sur des données de vitesse ou débit moyennées sur 20 secondes ou 1 minute. En revanche, la mise en place d'une base de données et d'une chaîne d'analyse en temps différé est également pertinente pour les autres DIR (ou pour les exploitants de trafic autoroutiers ou des collectivités urbaines ou départementales). A notre connaissance, seule la DIRIF (DIR Ile de France) à Créteil a mis en place une équipe d'analyse en temps différé du trafic, mais cela reste à approfondir avec les autres DIR et notamment les CIGT VRU (Voie Rapide Urbaine) des principales agglomérations (Lyon, Lille, Bordeaux, Grenoble, etc.). Les outils open source utilisés sont intéressants pour les DIR dans la mesure où l'utilisation de logiciels libres fait partie de la politique informatique du ministère. 4.3.2 groupe d échanges techniques Peut-être parce que nous commençons seulement à investir le sujet et que avons beaucoup à apprendre, nous sommes très demandeurs d un groupe permettant d échanger nos retours d expériences sur l analyse de trafic temps différé pour le suivi des CIGT et l'évaluation des systèmes d'exploitation dynamique en temps différé ; ce club pourrait d ailleurs être ouvert aux collectivités et sociétés d autoroute, et s appuyer sur un site web pour diffuser documents et informations. Le club pourrait aussi servir, si ce n est à mettre en place des formations, du moins à identifier celles qui existent. Il devrait surtout être utile pour connaître les pratiques dans les CIGT, au moins au ministère. Nous ne savons pas bien sous quelles formes les données sont archivées et mises à disposition, si des outils ont été développés ou acquis, qui les utilise pour quoi faire, etc., ni surtout quelles sont les vraies attentes des exploitants et en quoi le réseau technique des CETE peut y répondre. Les points à traiter dans le périmètre d'un tel groupe (ou les rubriques d'un site web) pourraient être : Les données Référentiel routier, Trafic (y compris temps de parcours), Equipements, Evénements, etc. Les traitements (méthodes) qualification, caractérisation de la congestion, évaluation, études ponctuelles, alimentation de modèles, avril 2009 22