Le présent rapport décrit le travail effectué par Claire Christol lors de son stage effectué au CETE Méditerranée de mars à juin 2009.

Transcription

1 Résumé Ce document est un rapport de stage de Licence Professionnelle SIG effectuée au CETE Méditerranée de mars à juin Il s inscrit dans le cadre du projet Potimart qui vise à développer des logiciels SIG transport open source, et fait suite au développement en partenariat avec la société Mobigis de requêtes permettant de produire des indicateurs concernant les impasses et mailles du réseau à partir de données décrivant la voirie (initialement issues de la BD Topo IGN), et concernant les fréquences de passage et vitesses moyennes des bus à partir des données décrivant l offre théorique de transport collectif à partir du format standard Trident/Chouette. Les tests ont été effectuées sur le site de Toulouse en association avec l autorité de transport collectif Tisseo. L objectif du stage est de valider les développements produits, et de proposer des améliorations, en vue de la réalisation ultérieure d un démonstrateur diffusé librement sur le web. Le test des outils a permis de confirmer le bon fonctionnement général des logiciels open source postgis et QGIS, ainsi que d identifier et corriger quelques problèmes. Les améliorations proposées consistent d une part à utiliser les données OpenStreetMap, d autre part à envisager dans un 2 ème temps d utiliser les données diffusées par l Insee en vue de produire des analyses plus riches en croisant population et réseaux de transport. 1.Introduction Le présent rapport décrit le travail effectué par Claire Christol lors de son stage effectué au CETE Méditerranée de mars à juin Contexte Le CETE Méditerranée Le CETE Méditerranée est l un des 7 centres d'études techniques du ministère du développement durable. Le stage est proposé par le service DCEDI/TIER qui travaille dans le domaine de l ingénierie du trafic et des systèmes d information sur les transports. Le CETE Méditerranée est un bureau public d'études et d'ingénierie pour tous les acteurs de l'aménagement: service de l'état, collectivités territoriales et organismes para-publics ou privés. L'équipe du CETE est composée de 524 agents dont 140 ingénieurs ou experts. Les statuts du CETE lui confèrent l'opportunité d'offrir à ses clients l'impartialité et l'indépendance d'un service de l'état. Il intervient sur la base de contrats et répond aux appels d'offre des collectivités publiques. Il bénéficie de l'appui du réseau scientifique et technique du Ministère de l'écologie, de l'énergie, du développement durable et de l'aménagement du territoire. Les activités du CETE sont très nombreuses : études, expertises, conseils, assistance à maîtrise d'oeuvre, recherche, méthodologie, animations de réseaux, formation, avis technique, essais de laboratoire et contrôles de chantier. L'information multimodale et la PREDIM Le CETE Méditerranée contribue à l action du ministère du développement durable en vue de développer l information sur tous les modes de transports, dite information multimodale : programme PREDIM, normalisation de l information concernant les Transports Collectifs (TC). Dans ce cadre, le CETE a produit notamment en 2006 un rapport sur l utilisation des SIG pour l analyse des réseaux piétons et cyclables (modes doux, et a participé par ailleurs en à un projet visant à développer des solutions SIG transport open source pour l information multimodale (Potimart). 1

2 Le domaine de l information est présenté plus en détail en annexe. Requêtes spatiales et SIG transport open source Dans le prolongement du projet Potimart, fin 2008, le CETE a confié à un prestataire (la société MOBIGIS) le développement d un démonstrateur d une base de données permettant de produire des analyses simples sur des données de voirie routière et de transport collectif. La 1 ère phase de cette étude a permis de développer des requêtes ou scripts SQL permettant de produire des cartes ou et des indicateurs relatifs d une part aux réseaux routiers (calculs d impasses et de mailles), d autre part à la fréquence et vitesse des lignes d un réseau TC. Le démonstrateur devra fonctionner avec des données réelles provenant du site de Toulouse, partenaire du projet. Le réseau de transport collectif Tisseo est issu de la base de données Chouette ) et la voirie provient de la BD Topo de l IGN 1. A terme, l objectif de ce démonstrateur, dans la continuité du projet Potimart, est de valider l'intérêt des utilisateurs potentiels (collectivités autorités de transport, bureaux d'études) pour une solution open source SIG d analyse de réseaux de transport, et de mieux comprendre leurs besoins. Le rapport technique fourni à l issue de la première phase de la prestation comprend un mode d emploi permettant à un utilisateur d exécuter ces requêtes sur le jeu de données initial ou sur un autre jeu de données conforme à des spécifications de format. 1.2 Objectifs du stage L objectif de ce stage est de tester ces outils de manière approfondie, le cas échéant sur d autres données, en vue de préparer la deuxième phase de la prestation commmandée à Mobigis, qui consistera à livrer le démonstrateur permettant à des utilisateurs potentiels de manipuler les données et les outils de requête et visualisation, facilement diffusables, ainsi qu'un manuel d'utilisation et un rapport proposant des perspectives d extension et de mise en oeuvre. L'objectif du projet est de fournir un démonstrateur mettant en oeuvre des logiciels open source pour analyser des données de transport ; les analyses sont limitées à quelques requêtes concernant la voirie et le réseau de transport collectif. L'objectif du stage est de tester les requêtes SQL développées et documentées par le prestataire sur un jeu de données réelles pour l'agglomération de Toulouse, de vérifier le bon fonctionnement et montrer des utilisations possibles. 1.2 Contenu du rapport Après cette introduction, le rapport présentera plus en détail l environnement technique du projet (logiciels et données), puis les résultats obtenus, y compris des propositions d extension et d amélioration pour le démonstrateur et les suites du projet. Le rapport contient en annexe quelques références et un glossaire. 2. Données et Outils 2.2Les données Nous avons travaillé sur 2 principaux types de données, celles concernant la voirie d'une part, d'autre part celles décrivant les réseaux de TC. 1 le CETE a acquis une licence de la BD TOPO ; on verra ensuite que compte tenu des difficultés pour obtenir l autorisation de diffuser le jeu de données dans le démonstrateur, les données Open Street Map seront finalement utilisées. 2

3 Par ailleurs, nous avons également, pour compléter le travail initial de Mobigis, utilisé des données de recensement de population Insee. La BD Topo présente plusieurs intérêts : sa précision, sa couverture nationale, le fait que beaucoup de collectivités et de services de l'état ont la licence d'utilisation Les données de voirie La BD Topo de l IGN présente plusieurs intérêts : sa précision, sa couverture nationale, le fait que beaucoup de collectivités et de services de l'état (y compris le ministère du développement durable et le CETE) ont la licence d'utilisation. Les données nous ont été fournies sous forme de 2 tables CHEMIN et ROUTE au format Mapinfo.TAB en Lambert2 Carto. Ce sont 2 couches d objets linéaires. Il est apparu en pratique après discussion avec la direction commerciale de l IGN que la licence de la BD Topo faisait l'objet de limitations qui compliquaient sa diffusion, de sorte que le CETE a finalement renoncé à utiliser ces données dans le démonstrateur. Nous avons donc par ailleurs testé l'utilisation de données librement téléchargeables : Open Street Map Les données de transport collectif Dans le cadre de groupes de travail nationaux et européens de normalisation de l information transport, un modèle de données ainsi que des profils d'échange de données XML ont été spécifiés pour les données décrivant l offre théorique d un réseau de transport collectif. Le ministère a financé dans ce cadre le développement d un logiciel open source implémentant ce profil d'échange, l'application Chouette, qui permet donc des imports / exports et la gestion d'une BD TC. L'objectif du projet Potimart et du démonstrateur de requêtes Voirie/TC est en partie de valoriser ces formats d échange standard : dans la mesure où les données sont potentiellement disponibles à terme sur l ensemble des réseaux française, les mêmes bases de données, requêtes et outils d analyse devraient pouvoir en effet être mis en oeuvre sans difficulté. En l'occurrence, les données utilisées proviennent du réseau TC toulousain Tisseo et ont été fournies par l'autorité organisatrice de transport urbain (qui s appelle aussi Tisseo, mais qui est en passe d être rattachée aux services de la Communauté Urbaine du Grand Toulouse). Elles nous été livrées directement en tant que tables postgresql (sous forme de fichier «backup»). Elles sont issues d un export de fichiers XML au profil Trident/Chouette produit par l exploitant du réseau TC et réimportées dans l outil Chouette (qui utilise la base postrgresql/postgis). L application Chouette est disponible sur le site Il faut comprendre que la description complète des horaires d un réseau de TC est assez complexe ; elle s appuie sur un modèle conceptuel de données normalisé au niveau européen baptisé Transmodel, qui comprend des notions génériques qui décrivent un réseau de transports en commun, et que l on retrouve sous forme de tables dans la base CHOUETTE, par exemple : - Réseau (PTNetwork) Le réseau représente les lignes de transport qui le constituent. Cette notion renseigne sur l'identification du réseau. - Transporteur (Company) Il s agit de l exploitant de la ligne. Chaque transporteur dispose d'un identifiant unique pour toute la base CHOUETTE, quel que soit le réseau ; il est donc important que le gestionnaire de la base CHOUETTE le renseigne d une manière bien définie et pérenne. - Ligne (Line) Une ligne se définit par des propriétés telles que l'indice et le nom, qui sont connues des usagers. 3

4 Une ligne référence un réseau et un transporteur ; par ailleurs la ligne se compose d'un ou plusieurs itinéraires. - Itinéraire ( ROUTE ) L'itinéraire est une sélection ordonnée de références aux points d'arrêt. Un itinéraire est spécifique à une ligne, mais les itinéraires peuvent référencer des arrêts communs. - Course (VehiculeJourney) et Horaire (VehicleJourneyAtStop) Une course décrit le déplacement d'un véhicule de transport public sur un itinéraire de la ligne. La course parcourt les arrêts de l'itinéraire dans l'ordre, sans nécessairement s'arrêter à chacun des arrêts. La course est rattachée à un nombre variable de calendriers d'application. - Mission (Journey Pattern) Si on considère la suite ordonnée des arrêts d'un itinéraire, la mission se définit comme une suite. Autrement dit, toutes les courses d'un itinéraire qui desservent les mêmes arrêts et dans le même ordre, à des horaires différents éventuellement, référencent la même mission. - Correspondance (ConnectionLink) La correspondance permet d'établir des liaisons entre les arrêts. Les liaisons définissent une durée de parcours entre les arrêts ou zones reliées. La description des données permet d'appréhender la composition des tables de la base de données. copie d écran listant les tables d une base Chouette En pratique, les tables que nous avons directement utilisées, car représentables sous forme de couches SIG, sont surtout les tables Stoparea (points d arrêt) et MissionLink (tronçons de ligne). Les tables timetable contiennent les calendriers d'application des horaires de transports. Ils permettent de définir les horaires d'une course. Toutes ces données doivent être renseignées par le gestionnaire du réseau, qui utilisé en général pour cela des outils informatiques, dits de «production horaire». 4

5 2.2.3 Autres données: population Pour enrichir les analyses, nous avons également lors de notre stage utilisé les données issues du recensement de la population par îlot IRIS, disponibles en téléchargement sur le site de l Insee. Elles sont livrées sous forme de fichier Excel, avec un grand nombre de d attributs (population par âge, par sexe, etc.). Outre les attributs décrivant nom, commune et identifiant des zones IRIS, nous n avons gardé que 3 attributs : nombre de logements, nombre de résidences principales, population totale par IRIS (le tableau comprend une ligne par IRIS). Malheureusement, la géométrie des zones IRIS n est pas disponible sur l internet (sans doute pour des raisons de droits d utilisation). Le CETE disposant de la licence pour ces données de contour des IRIS, nous avons obtenir des fichiers Shapefile contenant la couche de polygones des IRIS de Toulouse, via le CETE du Sud-Ouest. Une fois ce fichier.shp importé dans la base en tant que table IRIS, une fusion de la table XL du recensement sur l identifiant de la zone IRIS permet d obtenir une couche contenant les attributs souhaités de population et de logements, visible dans un SIG. 2.3 Les logiciels L essentiel des traitements effectués lors de ce stage l a été avec des logiciels open source : base de données et client SIG Base de données: PostgreSQL / postgis La base de données PostgreSQL est la principale base de données relationnelles open source avec MySQL et SQLlite. PostgreSQL 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.) Les performances de Postgresql permettent de traiter de gros volumes. PostgreSQL se prend rapidement en main pour les fonctionnalités de base, grâce à l outil graphique PgAdmin. L'aide pour la réalisation des requêtes est accessible (mais en anglais). Le langage SQL permet facilement d effectuer des requêtes simples de manière interactive. Postgis comprend un certain nombre de fonctions permettant en outre d effectuer des requêtes spatiales sur les données (proximité, intersection, etc.). En revanche, dès qu on veut obtenir des réponses à des requêtes plus compliquées, la syntaxe de SQL est difficile, a fortiori quand on a besoin d écrire des fonctions (en langage PL/SQL ou python, comme c est le cas des scripts produits par Mobigis dans le cadre du projet du CETE). Quand on ne connaît pas bien le langage, débugger s'avère un véritable casse-tête. En pratique, lors ce stage, le travail a surtout consisté à tester des scripts et fonctions déjà écrits, et à faire des requêtes SQL «élémentaires» Système d'information géographique QGIS Quantum GIS (QGIS) est un des clients SIG open source les plus répandus, qui permet très facilement de se connecter à une base Postgis, un point essentiel dans notre cas. Quantum gis gère de nombreux formats de fichiers. Il peut travailler des images vectorielles et raster, ainsi que des couches postgis. L'existence de formats standard pour les données géographiques (shapefile, etc.) fait que d'autres outils commerciaux auraient pu aussi être utilisés (Mapinfo, etc.), et permettraient éventuellement des fonctionnalités plus élaborées de cartographie dont nous n'avions pas besoin 5

6 dans le cadre de ce stage. Les principaux atouts de ce logiciel sont qu il est simple à l'utilisation et donc abordable par une personne ayant une connaissance minimum des SIG. QGIS intègre un outil de mise en page. Néanmoins, il est à noter que la version actuelle (1.0) de Qgis présente des défaillances sous Windows (fermeture du logiciel lors de certaines opérations) que j'ai rencontrées lors de la réalisation de mes cartes Autres logiciels a) Machine virtuelle Virtual Box Virtual Box est un logiciel permettant d'installer une machine virtuelle sous Windows ou Linux. Il est prévu de l utiliser pour le démonstrateur : Virtual Box permettra de livrer un démonstrateur préinstallé, avec les bonnes versions et le bon paramétrage des logiciels, les requêtes SQL déjà installées, les données déjà importées en base. La démonstration tournera sous linux (ubuntu) puisqu'elle doit pouvoir être diffusée librement. Lors du stage, nous n'avons pas mis en oeuvre Virtual Box, mais l'application sera sans doute diffusée sur une machine virtuelle. b) Chouette Ce logiciel open source est utilisé en amont pour produire les données TC de manière standardisée. L'outil chouette (Création d'horaires avec un OUtil d'échange de données TC selon le format Trident Européen) a été réalisé par la société Dryade pour le compte du CERTU sur financement PREDIM. Actuellement, l'outil se limite aux échanges d'informations concernant la description statique de l'offre de transports en commun et ne couvre pas les messages de perturbations. Les objectifs affichés de cet outil sont de: Donner aux utilisateurs qui le souhaitent la possibilité de tester les spécificités de l'outil TRIDENT sur des données réelles et de fournir des propositions d'amélioration pouvant être prises en compte. Transformer les fiches horaires de petits exploitants aux formats TRIDENT, et générer un mini site web par la même occasion si cela s'avère une nécessité pour l'exploitant. Permettre à de petites autorités organisatrices de transports de gérer des centrales d'informations Donner aux réseaux et autres acteurs la possibilité de télécharger le logiciel lui-même pour pouvoir l'analyser et l'intégrer à leurs systèmes d'informations sur les voyageurs. Nous n avons pas mis en oeuvre Chouette, simplement réimportées dans notre base les tables issues directement de la base postgis de l application. c) utilitaires Nous avons utilisé notamment pour les conversions de systèmes de projection et les imports/exports l outil ogr2ogr, qui est un logiciel open source de traitement de données (d ailleurs utilisé aussi dans QGIS). 2.4 Les requêtes Voirie / TC Requêtes voirie : mailles et impasse L objectif de ces requêtes est de calculer des indicateurs qui renseignent sur la perméabilité (la facilité à traverser) le réseau de voirie. Elles permettent de qualifier la facilité de se déplacer à pied (ou à vélo) dans un quartier, dans la mesure où ces modes de déplacement dits «doux» (ou «actifs») sont très sensibles aux détours, aux «effets de coupure» qui empêchent de prendre la ligne droite pour aller d un point à un autre. Le taux d impasses, ou le périmètre des pâtés de maison (ilots, blocs, ou mailles, selon le vocabulaire) sont les indicateurs calculés. Il est clair qu un 6

7 quartier dont les mailles font par exemple 700 mètres (10 minutes à pied) ne sont guère pratiqués par les piétons. Cet indicateur mesure aussi indirectement la facilité d accès aux TC, puisqu en général les usagers vont à pied prendre le bus. Le réseau piéton n est pas forcément confondu avec le réseau routier accessible aux voitures. La BD TOPO contient également des chemins (sentiers, escaliers, etc.), que nous avons intégrés dans la table ROUTE à traiter. A contrario, il faut supprimer de cette couche le réseau autoroutier. Une analyse plus fine impliquerait un travail très lourd de vérification sur le terrain. Pour ce projet, l important est de démontrer la faisabilité des outils, l objectif n est pas une étude opérationnelle sur la voirie urbaine. En pratique, l utilisation des requêtes est le suivant. Dans un premier temps, une table MAILLES est créée, contenant un polygone par. La requête de création des mailles s appuie sur la fonction postgis polygonize pour créer à partir d une couche de lignes (la table ROUTE contenant la voirie étudiée) les mailles du réseau de voirie. Il est ensuite assez simple d en calculer le périmètre ou la surface. Dans un second temps, un script SQL ajoutent une colonne «impasse» à la table de voirie (ROUTE), colonne pouvant prendre la valeur true/false. La fonction PL/SQL isdeadend évalue l appartenance de chaque tronçon de voirie à A partir de ces éléments, on peut calculer des indicateurs sur les mailles et impasses, sur un territoire donné (par exemple sur une commune, ou sur les zones IRIS de l Insee) : - taux d impasses en % - valeur min, max, moyenne, médiane du périmètre des mailles Il est ensuite possible de visualiser ces indicateurs sur un SIG, en créant des cartes thématiques Requêtes TC : fréquences et vitesse moyenne L objectif des fonctions de requêtes développées par Mobigis est de produire des indicateurs de base sur tous les arrêts du réseau TC, pour une tranche horaire et un jour donnés : - vitesse moyenne d une ligne, tronçon par tronçon - fréquence de passage à un arrêt pour une ou plusieurs lignes Le calcul du nombre de bus passant à un arrêt pendant une période (jour, tranche horaire) donnée consiste à compter le nombre de courses (vehicle journey). Ce nombre est inséré comme une colonne attributaire JOURNEYNB supplémentaire dans la table STOPAREA. Le calcul des vitesses moyennes est compliqué par le fait que tous les bus ne passent pas à tous les arrêts (il y a des lignes, directes, semi-directes, express, etc.) et la notion de tronçons n est donc pas immédiatement disponible en base : il faut d abord créer la table des tronçons (MissionLink). Par ailleurs, les horaires étant arrondis à la minute près, ils ne sont pas significatifs entre 2 arrêts consécutifs. Les vitesses moyennes sont donc calculées comme des moyennes glissantes sur plusieurs tronçons. Cette fonction plus complexe a été écrite en python. 3. Résultats obtenus Nous présenterons rapidement le résultat des tests effectués et nos remarques : c est un travail assez fastidieux mais indispensable, puis nous présenterons plus longuement les compléments que nous avons réalisés, consistant (après «debuggage» des données) à réaliser en outre des analyses des indicateurs VP / TC sur les zone IRIS de l Insee et à la croiser avec les données de population de l Insee, ce qui enrichit quand même beaucoup les analyses possibles. 7

8 3.1. Test des fonctions de calcul des indicateurs VP/TC Le travail a consisté à reprendre point par point les indications décrites dans le rapport fourni par MOBIGIS sur la base du Cahier des Charges initial du CETE : installation des logiciels, création de la base, import des données, puis exécution des requêtes et tests de visualisation des résultats sur SIG.. La relecture du «manuel d utilisateur» (qui est en fait un rapport technique plutot qu un manuel, celui-ci devant être produit dans la phase suivante de réalisation d un démonstrateur) a permis d apporter quelques compléments et corrections à la documentation initiale Installation des logiciels L installation des logiciels se fait en téléchargeant des exécutables d installations sous Windows et ne pose pas de problème particulier, encore que l installation en postgresql est un peu compliquée car il faut ensuite installer postgis, bien vérifier les versions que l on a installée, le choix du compte administrateur, etc. En outre, la dernière version de Qgis 1.0 sur laquelle je devais travailler à été installée avec du retard à cause d'une composante DLL manquante sur mon PC, problème qui a été résolu grâce à la personne du support informatique Création de la base de données Il s'agit de l'étape préalable au contrôle des requêtes spatiales la conception de la base de données. Le chemin de création de la base de données est le suivant pgadmin III => Postgresql (serveur) => Base de données => fonction «ajouter une base de données». Tout d'abord on renseigne les caractéristiques de la base de données, le nom, le langage du serveur et l'utilisateur de la base. Il n'existe pas de problème majeur dans la réalisation de cette étape, il faut toutefois faire attention lorsque l'on renseigne l'utilisateur. En cas d'erreur sur ce renseignement, le risque est de ne pas pouvoir utiliser la base. Une fois cette étape franchie, on peut commencer le traitement des requêtes spatiales, en utilisant PGAdmin. Les requêtes peuvent aussi être exécutées en ligne de commande (sous DOS), mais ce mode d'utilisation est moins riche, il ne renseigne pas sur le temps d'exécution des requêtes et est beaucoup moins pratique. Transformation de la BD topo dans Postgis Les données de la bd topo sont au format Mapinfo(.tab). Le module SPIT «importer des shapefiles dans Postgresql» de Quantum GIS est utilisé pour importer les données IGN de la BD Topo dans la base de données Postgis. Les données TC quant à elle sont déjà disponibles sous forme de fichier «backup». Dans 8

9 PostgreSQL, il suffit d utiliser le menu Restaurer pour les importer dans un base existante. Pour vérifier si l'import des données a bien fonctionné le chemin à suivre est PgAdmin II => Postgresql => Base de données => sigvptc => Schéma => public => table Qualification des données et vérification des scripts SQL Ces tables sont désormais accessibles dans la base de données PostgreSQL, on peut donc exécuter des requêtes (créer les fonctions de calcul d indicateurs et scripts). Les tables peuvent aussi être accédées depuis le logiciel Quantum gis en vue de produire des cartes. Correction du problème d'encodage des caractères (win 1252) En ce qui concerne les données de voirie, le seul problème qui est apparu concernait l affichage des caractères accentués lors de l import des tables Mapinfo de la BDTopo dans Postgis. La solution que nous avons trouvée est de préciser le bon encodage pour les caractères (win1252 en l occurrence). La fusion des données routes et chemins a fonctionné sans problème. Les données BdTopo sont sinon de bonne qualité ; nous avons eu 2 ou 3 erreurs lors du calcul des requêtes spatiales sur les mailles mais qui sont plutôt dues à la complexité des géométries des polygones qu à des données erronées à proprement parler. Nous avons également traité les données Open Street Map qui sont bien sûr de moins bonne qualité, mais néanmoins très correctes. Une difficulté sur les tronçons OSM est qu ils ne vont d une intersection à une autre mais peuvent représenter toute une rue et croiser d autres tronçons : ce point a demandé de faire un prétraitement avant de pouvoir effectuer la détection des mailles et des impasses. 9

10 Les requêtes et fonctions suivantes ont été testées : Détection d'erreurs avec les données TC et utilisation d'une nouvelle version Au niveau des données TC, plusieurs erreurs sont apparues lors du lancement des requêtes de comptage des passages de bus ou de vitesse moyenne. Elles sont dues à une qualité imparfaite des données. Les données Tisseo de départ sont évidemment bonnes puisqu elles permettent de faire fonctionner le réseau TC et notamment le site internet mais elles ne sont pas «nativement» au format Trident/Chouette, elles sont exportées vers ce format pour les besoins d un projet de Centrale d Information Multimodale encore en développement et l export est en cours de recette dans le cadre de ce projet. Nous avons perdu un temps important à ce niveau et pu récupérer auprès de Mobigis une nouvelle version des données un peu «nettoyée», qui contenait seulement une partie des lignes du réseau, qui a permis de faire fonctionner correctement le comptage des passages de bus aux arrêts. Identification d'un bug sur la requête de vitesse moyenne par tronçon En revanche la fonction de calcul des vitesses moyennes, malgré des échanges avec Mobigis, qui a pu obtenir des valeurs correctes pour les vitesses moyennes, mais pas nous. La fonction python get_average_speed, après quelques corrections (prise en compte d une nouvelle version envoyée par Mobigis) fonctionnait sans bug, mais nous retournait des valeurs de Vitesse Moyenne toutes à zéro. Ce point reste mais le problème reste sans doute imputable aux données de départ, et devrait être corrigé avec les prochaines mises à jour attendues de la base Tisseo. Conversion de référentiel pour les données voirie IGN ( Lambert 2 vers WGS84) Il est apparu une seconde difficulté à résoudre, concernant le système de référentiel spatial des données, qui était différent pour les données voirie et TC, ce qui faisait qu il était impossible de superposer dans le SIG les couches de voirie mailles ou routes et les couches TC stoparea ou pathlink par exemple : les unes étaient en Lambert2 (code EPSG 27852) et les autres en coordonnées GPS (code EPSG 4326). Pour résoudre ce problème nous avons utilisé la commande ogr2ogr, puis nous avons chercher à convertir les fichiers en shp avec un système de référence similaires aux autres tables. Une fois ceci achever les cartes n ont de nouveau pas été superposables. La conversion des fichiers a été réalisé en ligne de commande avec le programme utilitaire ogr2ogr pour les fichiers shp dont on a changé les références spatiales. «ogr2ogr t_srs «+init=epsg=4326» =_s_srs«+init:27582» pt2 pt.shp pt Gestion des données Les divers tests s avèrent vite nombreux et impliquent une certaine organisation dans la gestion des données. Au minimum, il faut : - faire une copie des données avant de travailler (en cas d erreur fatale!) ; - commencer par extraire un petit jeu de données pour tester le bon fonctionnement avant de lancer 10

11 des requêtes plus lourdes. Les requêtes et fonctions dans leur version actuelle utilisent un nom de la table «en dur», qu il faut modifier à la main. Il faudrait que le nom puisse être passé en paramètre, que le code SQL soit mieux documenté, surtout les hypothèses concernant les données d'entrée et les spécifications des données de sortie. 3.2 Propositions de compléments Utilisation de données Insee Sur la base des tests effectués, nous avons cherché à compléter les données en s appuyant sur celles diffusées par l Insee sur son site Internet, issues du recensement de la population. Nous avons complété les scripts SQL en vue de pouvoir réinstaller complètement la base VP/TC, créer les tables mailles, impasses, arrêts, tronçons, ainsi que la table iris des zones Insee. Cette table comporte une ligne par zone IRIS ; nous avons ajouté des colonnes supplémentaires en vue de produire des cartes thématiques, sur des attributs dérivés des calculs d indicateurs sur la voirie et les TC : - pourcentage d impasses (c es-à-dire longueur totale des impasses divisé par longueur totale de voirie) par IRIS - périmètre moyen des mailles comprises dans un IRIS - nombre d arrêt, nombre de passages de bus par IRIS, densité d arrêts ou de passage à l hectare - nous n avons pas pu créer de colonne «vitesse moyenne» des bus dans l IRIS car la requête ne fonctionnait pas, mais ce serait facile de la compléter sur le même principe. Nous n avons utilisé que les population et nombre de logements dans les données Insee, mais il serait possible d utiliser des données plus fine (par sexe, par classe d âge, éventuellement par catégorie socio-professionnelle) pour affiner les indicateurs et les analyses Utilisation de données OSM Open Street Map est une initiative privée visant à produire une cartographie vectorielle en librediffusion du réseau routier mondial. Partie d Angleterre, OSM a désormais largement franchie les frontières et la qualité des données OpenStreetMap (OSM) s est améliorée de manière spectaculaire à partir de 2008, comme en témoigne l ouverture du service OpenRouteService, qui démontre la mise en oeuvre d un service de calcul d itinéraire routier s appuyant sur les données OSM et les spécifications OGC OpenLS. Grâce à des outils de saisie très évolués et à l effort des bénévoles, les données disponibles en France, notamment autour de Toulouse, sont désormais assez complètes. Compte tenu des difficultés à obtenir l accord de l IGN à diffuser l extrait de la couche voirie utilisée pour le démonstrateur, à cause des contraintes de la license d utilisation de la BD Topo, le CETE et Mobigis ont convenu de s appuyer sur les données OSM, qui peuvent être téléchargés au format Shapefile sur le web et diffusées librement. La qualité des tronçons du réseau OSM est tout à fait correcte, d autant plus que les bénévoles d OSM ont obtenu l accord du ministère des finances pour s appuyer sur le fond de plan cadastral diffusé sur le web, ce qui permet une saisie du réseau en ligne, sans faire de relevé GPS sur le terrain. Une difficulté en revanche sur les tronçons OSM est qu ils ne sont pas forcément tracés d une intersection à une autre mais peuvent représenter toute une rue, et croiser d autres tronçons : ce défaut les rend inutilisables directement pour détecter les mailles (polygones) à partir de la table des 11

12 tronçons routiers, comme nous avons pu le faire avec la BD Topo. Cela nous a demandé de faire un pré-traitement avant de pouvoir effectuer la détection des mailles et des impasses. Heureusement, un script SQL de création d une couche de points d intersections entre les tronçons d une couche polyligne avait déjà été développé par la communauté postgis, et notre script l utiliser, ce qui l a largement simplifié. Le script figure en annexe. Il fonctionne correctement (en tout cas sans produire d erreur), mais il semble que certains cas particuliers de géométries n ont pas été traités comme il l aurait fallu. Nous n avons pas eu le temps d approfondir ce point et cela devra l être par Mobigis pour la réalisation du démonstrateur, en gardant à l esprit que ce démonstrateur vise à montrer les principes des outils et n ambitionne une qualité parfaite de données. 3.3 Production de cartes thématiques et d analyses Principe de production des cartes dans QGIS Les tables produites ou complétées dans postgis sont ensuite accessibles depuis un SIG en tant que couches géographiques pour autant qu elles possèdent une colonne de type «géométrie» correctement renseignée. Une fois que l'on s est connecté sur la base de données contenant les tables sur lesquelles on veut travailler. Pour visualiser les données dans QGIS, il y a deux méthodes principalement : - soit ouvrir un fichier Shapefile. Il peut être plus pratique selon les cas d exporter les données en base sous cette forme. Il suffit d utiliser le programme utilitaire ogr2ogr pour réaliser cet export en ligne de commande DOS. - soit ouvrir directement une table en base de données : QGIS sait se connecter facilement à la base de données (à condition bien sûr que le serveur soit lancé, et avec le bon mot de passe!), et il détecte automatiquement les tables de la base qui possèdent une colonne géométrie correcte, qui permet de les ouvrir en tant que couche dans Postgis On peut ensuite travailler à la fois avec des couches Shapefile ou Postgis, ou créer de nouvelles couches si besoin. Il ne reste plus qu'à composer des cartes suivant les analyses que l'on veut faire. Les différentes couches se superposent correctement, pour autant que le système de référencement spatial soit cohérent. Le but de mon stage n était pas de produire une étude particulière d analyse géospatiale, mais de tester des outils en vue de faire des analyses de réseaux voirie et transports. Les données testées portant sur le site pilote de Toulouse, les informations que je pouvais représenter sous forme carte portaient sur les lignes, les arrêts, la fréquence des arrêts, le graphe de voirie ainsi que les données complémentaires portant sur la population. Les cartes qui suivent ont pour but d illustrer les possibilités des outils, pas à proprement parler d analyser les transports à Toulouse, d autant plus que les données ne sont pas complètes. La symbologie utilisée dans les cartes pourrait être améliorée, mais Qgis ne permet pas une richesse d utilisation de symboles pour les cartes thématiques aussi riche que Mapinfo, notamment seule une analyse thématique en valeur unique permet d'utiliser des symboles dans ce logiciel (et apparemment on ne peut pas mixer symboles et taille proportionnelle à la valeur d un attribut). J'ai donc choisi de représenter le réseau Tisseo dans la ville de Toulouse pour voir si un impact peut être mis en avant sur l'évolution de la ville, et si la disposition actuel est un facteur discriminant ou non. La réalisation des analyses thématiques se fait dans propriétés de la carte dans le logiciel. Qgis reste limité tout en étant performant dans ces fonctionnalités. Les contraintes pour réaliser les cartes sont que les analyses ne permettent pas de coupler plusieurs types de données Exemples de cartes 1. Cartes des mailles L'information viaire de cette carte montre le tissu urbain de la ville de Toulouse. La zone 12

13 représentée montre le centre ville. Il n'est pas apparu nécessaire de faire le maillage de toute l agglomération, l objectif étant de tester les outils, pas une analyse particulière. Réaliser une carte de mailles permet de mettre en évidence les zones ou la marche à pied et le vélo sont difficiles. Il suffit de remplacer les périmètres des mailles pour des minutes de marche (350m=5min) pour se rendre compte que les quartiers dont les pâtes de maison dépassent 500m (ou plus) ne sont pas favorables aux modes doux, ni même à l accès aux arrêts de bus. Grâce aux couleurs employées, le vieux Toulouse ressort nettement. Le traitement effectué pour produire la carte thématique est un calcul de classes : il y a cinq classes de valeur du périmètre des mailles, réparties par quantiles c'est-à-dire le même nombre de valeurs dans chaque classe. On peut choisir la couleur de chaque classe, mais on ne peut pas jouer sur l'épaisseur des éléments. Qgis reste assez limité pour les analyses thématiques. 2. Carte des fréquences de passage Dans cette carte sont représentées deux couches, la densité de population et la fréquence de passage des bus à un point d arrêt donné (attribut JOURNEYNB de la table STOPAREA). On constate à la lecture de la carte que celle ci est en effet très variable, certains arrêts ne sont desservis qu une fois par une ligne dans la journée (sans doute par une ligne de transport à la demande), tandis que certains arrêts sont desservis jusqu à 39 fois (mais il faut rappeler que les données aussi que les données sont incomplètes). L information présente sur cette carte peut servir à mettre en évidence des «trous» ou mauvaises adaptations de l offre à la demande, même si c est de manière un peu sommaire, devant être complétée avant d envisager de modifier l offre de transport. Toutes les lignes ne sont pas représentées sur cette carte, comme dit. Qgis permet de réaliser des cartes tout à fait lisibles et esthétiques. Pour comparer avec Mapinfo j ai réalisé le même modèle avec le logiciel de Mapinfo. Au final, même si Qgis est limité au niveau des analyses thématiques, les deux apportent un résultat similaire bien que Mapinfo possède plus de fonctionnalités. Pour quelqu un qui démarrerait dans la cartographie, je conseillerais même plutôt Qgis. 3.carte du réseau Tisseo La carte du réseau Tisseo montre l implantation des lignes dans la ville de Toulouse. Les données fournies étant incomplètes toutes les lignes ne sont pas représentées ici (voir le plan du réseau sur le site On pourrait améliorer la lisibilité de la carte en jouant sur l épaisseur des traits et leurs couleurs claires pour mieux les faire ressortir par rapport au fond. Qgis ne permet pas de diviser la légende en deux colonnes, ce qui est un petit défaut pour la présentation, qu il y aurait moyen d atténuer en renommant éventuellement les lignes de bus afin d avoir une légende plus petite qui ne prenne qu une demi page. La carte serait ainsi plus lisible. 4. Carte composition de la voirie La carte «nature des voies de circulations de Toulouse» renvoie aux caractéristiques des routes de la ville. Cette carte représente aussi les points d arrêts. On peut donc voir quelles types de voie empruntent les lignes de bus. Ce serait intéressant de corréler cette information par exemple avec la vitesse commerciale des bus (ce qui devrait être possible avec une version corrigée des données horaires). La carte donne aussi des indications sur la plus ou moins bonne desserte des quartiers ; il serait intéressant de lui appliquer un fond de plan présentant les principaux pôles d activité et 13

14 d emplois. Qgis ne m a pas posé de problème particulier pour réaliser cette carte, j ai pu modifier comme je le voulais les attributs de la légende de la couche voirie (bien que celle ci ne puisse pas être divisée en colonnes comme dans MapInfo). 5. Carte fréquentation des points d arrêts, Toulouse et ses villes alentours Cette carte présente la caractéristique «fréquence de passage aux point d arrêts» sur une territoire plus large autour de Toulouse. J ai choisi de faire cette carte pour connaître l environnement extérieur de Toulouse, montrer le nom des villes alentours. Sur cette carte aussi, nous avons comparé la conception dans MapInfo et dans Qgis, pour voir dans lequel la réalisation est plus aisé. J ai trouvé l outil de mise en page de Qgis plus pratique que celui de MapInfo, il n y a moins de blocages ou ralentissement du PC dû au traitement des données ; il est également très simple d ajouter une échelle et de l intégrer au document Autres analyses possibles Les indicateurs calculés sur les réseaux de voirie et TC peuvent également être analysés et croisés avec les données de population par exemple, indépendamment d une représentation cartographique. Cela permet d observer simplement, avec un simple tableur, quitte à produire aussi des cartes avec les mêmes attributs pour voir si le facteur géographique peut expliquer des observations qui n apparaîtraient pas autrement. Ainsi, la table IRIS comprend un grand nombre de colonnes contenant des valeurs d indicateurs pour des zones Iris de l Insee, où il est intéressant de chercher à corréler. Des outils statistiques tels que le logiciel open source R (qui peut d ailleurs de sonnecter à Postgres/postgis) permettraient des analyses plus sophistiquées que Calc (ou Excel), mais ce n est pas l objet de ce stage que d étudier ces questions. Visuellement (et un calcul de corrélation le confirme), nous n observons pas de lien évident entre population et logements, ni entre périmètre de mailles et densité de population par IRIS. à compléter 4. Conclusions 4.1. Retours d expérience Appréciation de postgis La base de données postgresql/postgis est clairement un logiciel de qualité professionnelle, bien documenté et maintenu. Néanmoins, l emploi des utilitaires associées à ce logiciel, ainsi que la conception et le développement de requêtes SQL ou de scripts et fonctions PL/SQL ou dans d autres langages nécessitent vite des compétences informatiques qui dépassent celles d un simple utilisateur de SIG ou d un analyste chargé d étude transports. C est d ailleurs pourquoi le CETE envisageait avec Mobigis de livrer le démonstrateur préinstallé avec les logiciels, les données et les requêtes pour éviter de nombreuses manipulations qui s avèrent 14

15 complexes. Néanmoins, la mise en oeuvre d une telle base de données en amont d un SIG dans le cadre de ce stage m a permis de comprendre beaucoup d éléments techniques nécessaires en pratique, dans l utilisation de divers logiciels, que dans la méthode de travail et notamment en termes de rigueur et d organisation pour la gestion des données. Dans un 2 ème temps ces outils permettent aussi de produire dynamiquement des cartes conçues à l avance et de les publier sur le web pour des utilisateurs non avertis ou pressés Appréciation générale de QGIS : Lors de la réalisation de mes cartes, j ai appris à apprécier Quantum GIS. Tout d abord, l entrée en matière est assez facile quand on s est servi auparavant de logiciels comme Mapinfo et ArcGis. L atout de Qgis est de pouvoir lire les formats tab et shp et de convertir de manière très simple les formats tab en shp, ainsi que la connexion native à postgis. On peut ainsi travailler tous ces fichiers ensemble, et si besoin les insérer dans une base de données. Par ailleurs, le mécanisme de «plug-in» de QGIS permet à l active communauté de développer des fonctionnalités supplémentaires rapidement mise à disposition des utilisateurs ; il existe ainsi un plug-in donnant accès à GRASS, le SIG open source sans doute le plus complet (et le plus complexe, raison pour laquelle nous n avons pas testéz ce plug-in). Après ces quelques mois à travailler avec Qgis, je le conseillerais pour des utilisateurs occasionnels qui n ont pas à mettre en oeuvre les fonctionnalités avancées de MapInfo. Néanmoins, QGIS «plante» parfois dans certaines remises en page lorsque le volume de données sous-jacentes est trop important : le logiciel semble gérer difficilement des demandes concernant trop de données, il sature alors et se ferme. Je dirais qu il s agit là du seul vrai problème de Qgis que j ai rencontré. En outre, il n existe pas dans ce logiciel autant de possibilités pour les analyses thématiques que dans Mapinfo, ni sans doute dans l édition géométrique et le dessin. 4.2 Suites à donner Le CETE est en mesure de lancer avec Mobigis la 2 ème phase du projet, consistant en la réalisation d un démonstrateur librement diffusable. Mon stage aura donc permis de préparer cette étape, d identifier des difficultés et de proposer des améliorations : - pour les données voirie, il est apparu qu il faudrait utiliser OSM plutot que IGN ; j ai pu tester les requêtes SQL de pré-traitement des données OpenStreetMap en vue du calcul des mailles et impasses ; - pour les données TC, il est apparu qu il faudrait utiliser la version la plus récente des données Tisseo, mais elles devraient répondre ; le CETE a obtenu en amont l accord de l autorité de transport de Toulouse quant à la diffusion des données pour le démonstrateur ; - les requêtes et scripts ont été testés et l enchainement des étapes repris point par point. - le démonstrateur comprendra le logiciel QGIS, et les cartes thématiques que j ai réalisées permettront de proposer à l utilisateur des exemples d utilisation et de représentation ; - le démonstrateur sera livré grâce à l outil logiciel Virtual Box que je n ai pas testé ; le seul problème éventuel viendra du fait qu il faudra fonctionner sous linux (ubuntu) mais postgis et QGIS fonctionnent également très bien sous linux, et l interface utilisateur du système est tout à fait conviviale. Les améliorations proposées concernent notamment l utilisation des données de population diffusées par l Insee, qui pourraient enrichir beaucoup l intérêt du démonstrateur, en permettant leur 15

16 croisement avec les données transport. Il serait nécessaire pour cela d obtenir l autorisation de diffuser les géométries (contours) des zones IRIS utilisées par l Insee dans les recensements. Les prochaines étapes envisagées par le CETE et ses partenaires Mobigis et Dryade dans le cadre du projet Potimart consisteraient à ajouter d autres requêtes, notamment d utiliser la librairie postgresql pgrouting, qui permet des calculs de plus court chemin, ainsi que de pouvoir accéder aux données de la base à partir d un langage de haut niveau plus convivial que SQL, ou d associer un serveur web à la base postgis. Ces développements ne nécessitent pas à proprement de nouveaux logiciels, mais demandent néanmoins des adaptations, des tests et un effort assez lourd de mise au point, qui ne pourra être effectué compte tenu des ressources très limitées affectées au financement de ce projet. 16