Développement d’un portail web d’indicateurs sur la voirie ...mim.cete-aix.fr/IMG/pdf/portail-voirie-chemins.pdf · 1. Introduction 1.1. Contexte Ce rapport est le résultat

Développement d’un portail web d’indicateurssur la voirie en France

un prototype centré sur les modes marche et vélo réalisé avec drupal/postgis et les donnéesOpenStreetMap / BD Topo

DterMed - Direction Territoriale Méditerranée (CEREMA)

Développement d’un portail webd’indicateurs sur la voirie en Franceun prototype centré sur les modes marche et vélo réalisé avec

drupal/postgis et les données OpenStreetMap / BD Topo

date : Octobre 2014

responsable de l'étude : Patrick GENDRE, DCEDI/DERIS/MIM

participants : Maxime CHEMIN, Lalaina RASAMOELINA, stagiaires 4ème année PolyTechMarseille. Bernard RONGIONE, service DCEDI/AGIL, DTerMed

résumé de l'étude :

Ce rapport est le résultat d’un stage effectué au Cerema à Aix-en-Provence de juin à août 2014 par Maxime CHEMIN etLalaina RASAMOELINA, en 2ème d’année d’études d’ingénieur à Polytechique Marseille.Dans un contexte où- les politiques de développement de la marche et du vélo en ville se sont développées et l’utilisation des SIG pourdécrire et gérer les réseaux généralisée;- les logiciels libres du domaine géographique et analyse de réseaux se sont consolidés et diffusés très largement,notamment QGIS et postgis ; les coûts d'hébergement de données massives se sont effondrés;- les données publiques ou collaboratives (OpenStreetMap) réutilisables ont beaucoup progressé en qualité et endisponibilité, le CEREMA, en partenariat avec le CRIGE PACA, a proposé d'encadrer 2 stagiaires afin de réaliser ce prototype aucours de l'été 2014 et de le soumettre à la communauté. Les résultats sont librement réutilisables, notamment tous leslogiciels seront sous licence libre.Il existe déjà des applications professionnelles autour des SIG de gestion de voirie ou de réseau, et des projets derecherche ou études sur des indicateurs favorables à la marche et au vélo. Ce travail n'a pas l’ambition de développer denouvelles méthodes ou algorithmes de calculs d'indicateurs, ni un nouveau modèle de données de la voirie, ni deproposer une organisation pour saisir et renseigner des données de voirie, mais plus modestement de s'appuyer sur lesdonnées et outils logiciels existants. Les principaux résultats sont:- un portail opérationnel en ligne sur le web ;- une couverture nationale qui permet potentiellement des comparaisons entre territoires ;- une mise à disposition de résultats librement réutilisables valorisant les données OSM et pouvant inciter à terme àmieux renseigner les attributs concernant les modes doux ;- une comparaison avec les données BD Topo de l’IGN sur un département.En pratique, le portail peut être utilisé à 3 niveaux :- pour se faire une idée de ce qui a été développé : naviguer dans le site et afficher de quelques indicateurs ou cartes ;- pour étudier les résultats et faire ses propres analyses : télécharger les données (fichiers Shapefile des indicateurs, dontle fichier .DBF contient une ligne par commune ou département, et une colonne par indicateur) ;- pour reprendre les développements, il est possible de partir des scripts et codes sources pour installer la base complètesur un serveur et relancer puis compléter les indicateurs existants.Le rapport présente les fonctionnalités et le détail des développements effectués, et conclut par quelques propositionsd'amélioration et des perspectives de développement pour de tels portails nationaux sur la voirie et les transports.

mots-clés : OpenStreetMap, IGN, voirie routière, portail, postgis

zone géographique : France Métropolitaine et Corse

nombre de pages : 40

SOMMAIRE

1. INTRODUCTION............................................................................................................................4

1.1. Contexte.......................................................................................................................................4

1.2. Objectifs.......................................................................................................................................4

1.3. Contenu du rapport......................................................................................................................6

2. RÉSULTATS OBTENUS.................................................................................................................6

2.1. présentation du portail.................................................................................................................6

2.2.Présentation des indicateurs.......................................................................................................7

2.3.Liste des indicateurs....................................................................................................................8

3.1. ARCHITECTURE TECHNIQUE DU PORTAIL...........................................................................9

3.1. Organisation des développements..............................................................................................9

3.2. Les logiciels...............................................................................................................................10

3.3. Architecture REST.....................................................................................................................12

3.4. Implémentation..........................................................................................................................13

3.5. Contenu Web.............................................................................................................................14

3.6. Carte interactive.........................................................................................................................15

3.7. Mise en place du système REST sur Drupal.............................................................................16

3.8. Choix de l’hébergeur..................................................................................................................16

4. CONCEPTION DES REQUÊTES ET TRAITEMENT SUR LES DONNÉES...............................18

4.1. Les données..............................................................................................................................18

4.2. Conception des requêtes...........................................................................................................22

5. CONCLUSIONS...........................................................................................................................36

5.1. En résumé..................................................................................................................................36

5.2. Difficultés rencontrées, points restant à traiter, leçons..............................................................36

5.2. Perspectives..............................................................................................................................37

1. Introduction

1.1. Contexte

Ce rapport est le résultat d’un stage effectué au Cerema à Aix-en-Provence de juin à août2014 par Maxime CHEMIN et Lalaina RASAMOELINA, en 2ème d’année d’étudesd’ingénieur à Polytechique Marseille.

Ce travail s’appuie sur une étude exploratoire réalisée en 2005 sur l’utilisation dessystèmes d’information géographiques (SIG) pour l’analyse des réseaux “modes doux” :marche à pied et vélo (http://mim.cete-aix.fr/spip.php?article101)Cette étude mentionnait notamment le travail de Frédéric Héran publié en 2003 :http://www.innovations-transports.fr/Indicateurs-pour-des-amenagements , qui proposaitenviron 25 indicateurs pour des voiries praticables à pied et autant pour des voiriespraticables à bicyclette, reposant chacun sur un principe d'aménagement et utilisant lespossibilités des SIG.

Dans la continuité de cette étude, nous avions en 2009 fait déveloper un démonstrateur decalcul d’indicateurs des réseaux de voirie et de TC avec des logiciels libres et desdonnées publiques (http://mim.cete-aix.fr/spip.php?article255), qui nous confirmait lamaturité croissante de logiciels comme postgis et QGIS.

Depuis ces premiers travaux:- les politiques de développement de la marche et du vélo en ville se sont développées etl’utilisation des SIG pour décrire et gérer les réseaux généralisée;- les logiciels libres du domaine géographique et analyse de réseaux se sont consolidés etdiffusés très largement, notamment QGIS et postgis ;- les données publiques ou collaboratives (OpenStreetMap) réutilisables ont beaucoupprogressé en qualité et en disponibilité. En particulier, les données routières issuesd’OpenStreetMap sont de plus en plus utilisées par des logiciels libres de calculd’itinéraires tels que OpenTripPlanner ou OSMR.

Pour toutes ces raisons, il a semblé pertinent de reprendre les travaux précédents pour lescompléter afin de réaliser un prototype de portail national d’indicateurs pour la voirie.

Le CEREMA, en partenariat avec le CRIGE PACA, a proposé d'encadrer 2 stagiaires afinde réaliser ce prototype au cours de l'été 2014 et de le soumettre à la communauté. Lestage est conduit en relation avec l’association OSM France, et avec l'appui desgéomaticiens du Cerema. Les résultats sont librement réutilisables, notamment tous leslogiciels seront sous licence libre.

1.2. Objectifs

L'objectif du stage est de montrer qu'il est possible (pour un coût modéré) de mettre enplace un portail qui calcule des indicateurs sur l'ensemble de la voirie de FrancemétropolitaineL’idée est de calculer des indicateurs par commune (et par département), un peu sur lemodèle de l’état des communes OSM (http://openstreetmap.fr/outils/etat-commune).

Développement d’un portail web d’indicateurs sur la voirie en France - Octobre 20144/40

http://mim.cete-aix.fr/spip.php?article101


http://www.innovations-transports.fr/Indicateurs-pour-des-amenagements

Les indicateurs sont calculés à partir des données disponibles dans la baseOpenStreetMap, qui présente le gros intérêt d'avoir une structure de donnéesrelativement simple et facile à compléter, et une licence sur les données facilitant un travailcollaboratif entre les acteurs :- gestionnaires de la voirie publique, chargés de mission modes doux des collectivités ;- associations locales de promotion du vélo ou des modes actifs ;- ministère du développement durable et ses services d'études ;- chercheurs et bureaux d'études.Bien sûr, les données de voirie de référence de la BD TOPO de l'IGN, qui présententl'avantage d'une couverture complète et homogène du territoire, pourraient également êtrecomplétées pour mettre en place un tel portail, et pour le démontrer également, nousavons calculé les mêmes indicateurs avec les données de la BD TOPO sur 2départements. Cela permet de comparer les données et les indicateurs obtenus, unrésultat qui intéressait notamment notre partenaire dans ce projet, le CRIGE PACA.Enfin, les indicateurs s'appuient également sur des données complémentaires, celles durecensement de population Insee, qui permettent de calculer des indicateurs pluspertinents.

Deux familles d’indicateurs sont calculés pour ce prototype:- des indicateurs généraux sur la voirie, typiquement le nombre de kilomètres par type devoie ;- des indicateurs plus adaptés aux modes doux, typiquement la taille des ilots et laproportion d’impasses, qui donnent une idée de la perméabilité du réseau viaire.Ces indicateurs simples mettent déjà en évidence l'intérêt d'étudier , et l'importance d'unedéfinition précise. Ils devraient bien sûr être affinés et complétés dans le cadre d'unprojet .

Enfin, nous avons choisi pour ce prototype de travailler sur les modes doux (marche etvélo) dans la mesure où nous avions déjà travaillé sur le sujet, où les données utiles pourcommencer sont relativement simples, et où ces résultats pourraient intéresser, outre lescollectivités gestionnaires de voirie et les bureaux d’étude qui gèrent des SIG décrivant lavoirie sur un territoire, également des associations de promotion du vélo et de la marche àpied dont certains renseignent activement la base OSM.Néanmoins, sur le principe, un tel portail d'indicateurs de voirie pourrait être développépour étudier d'autres modes, VP, TC, stationnement, etc. en complétant les cas échéantles sources de données (trafic, congestion, surface occupée...).

Il existe déjà des applications professionnelles autour des SIG de gestion de voirie ou deréseau, et des projets de recherche ou études sur des indicateurs favorables à la marcheet au vélo. Ce travail n'a pas l’ambition de développer de nouvelles méthodes oualgorithmes de calculs d'indicateurs, ni un nouveau modèle de données de la voirie, maisde s'appuyer sur les données et outils logiciels existants. En résumé, les objectifs portent plutôt sur:- une couverture nationale qui permet potentiellement des comparaisons entre territoires ;- une mise à disposition de résultats librement réutilisables valorisant les données OSM etpouvant inciter à terme à mieux renseigner les attributs concernant les modes doux ;- une comparaison avec les données BD Topo de l’IGN sur un département.


1.3. Contenu du rapport

Le rapport commence par présenter les indicateurs que nous avons calculés, puisprésente l'architecture logicielle, les requêtes de calcul des indicateurs, puis conclut parquelques pistes de travail pour des suites possibles.

2. Résultats obtenus

2.1. présentation du portail

Le présent rapport est téléchargeable sur le site du Cerema : http://mim.cete-aix.fr/spip.php?article373 , qui donne aussi le lien vers le portail.Le prototype de portail est accessible à l'adresse suivante :http://4253f2d422.url-de-test.ws/voirie-france/

Le portail est un simple site web avec les choix suivants:- la page d'accueil (HOME) donne accès à la recherche des indicateurs pour les donnéesOSM par commune (attention ! la première lettre du nom de la commune doit être tapéeen MAJUSCULE, le reste en minuscules; il faut ensuite sélectionner dans la liste desnoms de commune commençant par les premières lettres saisies pour afficher lesindicateurs pour cette commune)- le menu INDICATEURS permet d'obtenir, sur le même principe, les indicateurs pardépartement, et pour les données de la BD TOPO (uniquement pour le Loiret et lesBouches-du-Rhône plutôt qu'OSM), là aussi par commune ou par département;- il est également possible d'afficher les mêmes indicateurs en saisissant directement larequête dans l'URL (exemple : http://4253f2d422.url-de-test.ws/voirie-france/?commune=Meyreuil+-+13060);- le menu COMPARATEUR permet d'afficher côte à côte les indicateurs calculés avec lesdonnées OSM et IGN pour une même commune, ou un même département;- le menu DONNEES permet de télécharger directement l'ensemble des résultats, sousforme de 2 fichiers au format Shapefile, l'un pour les communes, l'autre pour lesdépartements; le menu DONNEES permet aussi d'afficher soit des cartes interactives desindicateurs par département, ou par commune (pour le 13 et le 45), soit des cartesthématiques produites pour quelques indicateurs (indicateur par département pour laFrance, indicateur par communes pour le 13 et le 45);- le menu POUR EN SAVOIR PLUS donne accès à la documentation technique.

En pratique, le portail peut être utilisé à 3 niveaux :- pour se faire une idée de ce qui a été développé : naviguer dans le site et afficher dequelques indicateurs ou cartes ;- pour étudier les résultats et faire ses propres analyses : télécharger les données(fichiers Shapefile des indicateurs, dont le fichier .DBF contient une ligne par commune oudépartement, et une colonne par indicateur) ;- pour reprendre les développements: il est possible de partir des scripts et codes sourcespour installer la base complète sur un serveur et relancer puis compléter les indicateursexistants.




2.2. Présentation des indicateurs

Les indicateurs calculés pour le prototype sont le résultat d'un compromis entre l'intérêt« métier » et la facilité technique pour les calculer à partir des données et des outilsdisponibles.Les indicateurs sont calculés sur deux sous-ensembles des tronçons de voirie :- la voirie ouverte à la circulation automobile ;- la voirie autorisée aux piétons et aux cyclistes (pour simplifier nous avons regroupémarche et vélo, mais on pourrait bien sûr analyser plus séparément le réseau cyclable etle réseau piéton, qui pourrait comprendre des escaliers, sentiers ou autres aménagementsnon cyclables). Deux familles d'indicateurs sont calculées:- des indicateurs généraux: typiquement le nombre de kilomètres par type de voie, pourles 2 types de voirie ;- des indicateurs sur la topologie du réseau, plus pertinents pour le vélo et à la marche, quivisent à donnent une idée de la perméabilité du réseau viaire aux modes doux : taille desîlots, proportion d'impasses, etc.

Les indicateurs sont calculés par commune et par département. On pourrait bien sûr lescalculer sur d'autres territoires, par exemple les intercommunalités.

Les données utilisées sont celles de la voirie d'OpenStreetMap et de la BD Topo IGN,mais également des données complémentaires, en particulier de population (sur la basedu recensement Insee synthétisé par carreau de 200 mètres de côté), qui permettent decalculer des indicateurs plus pertinents.


2.2.1. Définition du réseau VP, Modes doux

Comme indiqué ci-dessus, on travaille en fait sur deux sous-ensembles des tronçons devoirie, pour définir le réseau ouvert à la circulation automobile d'une part, d'autre part leréseau ouvert aux piétons et cyclistes (pour simplifier, on n'a pas distingué dans le détailce qui pourrait être praticable aux seuls piétons, ou aux seuls cyclistes, dans deuxréseaux séparés).Typiquement, la voirie VP ne comprend pas les sentiers et les pistes cyclables, et la voirie« modes doux » ne comprend ni les autoroutes ni les « 2 x 2 voies » (qui toutefois sontparfois autorisées aux vélos).Les règles de sélection de tronçons sont détaillées plus bas, pour la voirie OSM commepour la BD Topo.

2.2.2. Notions de maille (ilot), d'impasses

La topologie du réseau viaire est importante pour comparer deux réseaux. Les détoursqu'oblige à faire le réseau sont particulièrement importants pour la marche ou le vélo. Typiquement :- un grand nombre d'impasses (et surtout d'impasses longues) oblige à de nombreuxdétours ;- des ilots trop grands (par exemple de plus 700 mètres, distance qu'il faut 10 minutespour parcourir à 4 km/h) sont défavorables à la marche ;- par ailleurs des grands ilots qui sont en fait des parcs ou des espaces naturels sontmoins problématiques que des ilots résidentiels, d'où l'intérêt de calculer la population parilot.Pour calculer des indicateurs, il faut commencer par s'assurer que les tronçons sontconnectés et forment un graphe. Cela nécessite un pré-traitement, éventuellement unnettoyage des données, en particulier pour OpenStreetMap, qui sera décrit plus loin.Ces indicateurs auraient pu utiliser la notion de TOPOLOGY qui existe dans postgisdepuis la version 2, néanmoins (renseignements pris) il semble que les temps de calculavec ce type de données sont mauvais, et nous ne l'avons pas mise en oeuvre : nosrequêtes s'appuient surtout sur la fonction POLYGONIZE de postgis (utilisant le typeGEOMETRY), qui permet d'identifier les polygones d'un ensemble de tronnçons, c'est àdire nos ilots (les mailles du réseau).

2.2.3. Les limites des indicateurs calculés

Les indicateurs sont très basiques et reflètent le contenu des bases de données.Notamment, il manque des éléments sur les aménagements spécifiques de voirie ou sur lasécurité qui peuvent exister dans un SIG du gestionnaire de voirie.

La dernière partie du rapport propose d'autres indicateurs qui pourraient être calculés.

2.3. Liste des indicateurs

Les indicateurs sont téléchargeables sous forme de fichiers Shapefile visualisables dansun SIG, ou analysables dans un tableur (en utilisant uniquement le fichier .DBF : chaquefichier - indicateur par commune, par département, pour OSM, pour BD TOPO - comprend


une ligne par territoire, et une colonne par indicateur). Le format shapefile limite le nomdes colonnes à 8 caractères. Il est difficile de trouver un nom parlant en moins de 8caractères, il a donc fallu utiliser des abréviations. Voici la liste des noms d'indicateurs etleur signification :

l_impasse longueur totale des impasses (en Km)smoy_ilot surface moyenne des îlots dans une commune ou un département.densi_voi nombre de kilomètres de voirie par kilomètre carré. On divise donc lalongueur totale du réseau par la surface de la commune ou du départements (densi_voi =l_totale / surf_km2 ).l_totale Longueur totale du réseau accessible en vélo, voiture ou à la marche.l_aut_m Longueur totale du réseau accessible à pied.l_aut_v Longueur totale du réseau accessible à vélo.l_vp_aut Longueur du réseau autoroutier.l_vp_nat Longueur totale de routes nationalesl_vp_dep Longueur totale de routes départementalespop_ilot Population moyenne dans un îlotperimilot Périmètre moyen d'un îlotpopulation Population totale (de la commune ou du département)l_vp_autre Longueur des voies qui ne sont ni des autoroutes, ni des nationales, ni desdépartementales mais accessibles en véhicule.l_vp_total Longueur de tout le réseau accessible au véhicule.l_mapv_tot Longueur de l'ensemble du réseau accessible à la marche ou en vélol_mapv_aut Longueur du réseau partagée entre piéton et vélo.l_marche Longueur du réseau réservé à la marche à piedl_velo Longueur du réseau réservé aux vélosnb_maille nombre d'ilotsppop700 pourcentage de population d'une commune ou d'un département vivant dansun îlot de moins de 700 mètres de périmètre.

3.1. Architecture technique du portail

L'ensemble du code est téléchargeable sur le site : instructions pour l'installation, scriptsde requêtes OSM et BD TOPO, et code du serveur drupal.

3.1. Organisation des développements

Le projet comporte deux grandes composantes : - la base de données (incluant le calcul des indicateurs), - la publication sur le web. Ce découpage permet une répartition simple des tâches pour les stagiaires. Néanmoinsvu le grand volume de donnée OSM pour les traitements sur toute la France, et pouréquilibrer la charge entre les 2 étudiants, un binôme a traité la partie Web et les donnéesIGN, tandis que l’autre s’est occupé de la base de données OSM.Le prototype a été développé en petites étapes améliorant progressivement le prototype etsa documentation ; des scripts ont été écrits, qui permettent de relancer l’ensemble destraitements, de manière reproductible


Les tâches réalisées ont été suivantes :

A. côté données

- comprendre le contenu de la BD OSM, analyser ce qu'il faut en extraire pour le projet- mettre en place une BD postgis et extraire les données pour un périmètre limité (parexemple la métropole de Marseille)- tester des premiers calculs d'indicateurs (requêtes simples pour compter le nombre dekm par type de voie)- importer une table des contours des communes, qui permettra le calcul sur des territoires- tester des premiers calculs d'indicateurs (créer la table des indicateurs en base)- étudier la qualité de la topologie du réseau de voirie1 - nettoyer les données pour assurer la connectivité des tronçons- faire un travail similaire avec la BDTOPO IGN avec de pouvoir comparer les données- consolider les premiers scripts de calcul d'indicateurs- calculer des indicateurs concernant les impasses- calculer des indicateurs concernant les ilots (pâtés de maison)- essayer d'importer la totalité du réseau OSM pour la France, étudier les éventuelsproblèmes de performance- ajouter une couche sur la population (par exemple sur la base du carroyage à 200 mètrede l'Insee), afin de calculer des indicateurs complémentaires- améliorer progressivement les indicateurs et documenter...

B. côté web

- regarder comment fonctionne la page état des communes, dont le code est disponible ici:https :// gist . github . com / cquest /7 f 3 d 3067 f 1 f 572 f 1 cce 8- étudier la mise en place d'une API REST, service web permettant d'accéder à unindicateur calculé sur la base via une URL telle que proto-indic-voirie.org/commune/indicateur - choisir l'environnement de développement (après avoir envisagé python c'est finalementPHP qui a été retenu)- mettre en place le service web en local- compléter le service web par une page portail- compléter progressivement la page avec les nouveaux indicateurs et les nouveauxterritoires disponibles- étudier s'il est plus pertinent que les indicateurs soient pré-calculés ou calculés à la volée- trouver un hébergeur- mettre en production- compléter progressivement le portail et documenter...

3.2. Les logiciels

Le portail s'appuie sur des logiciels libres existants.

1il s'est avéré non pertinent car trop lent de s'appuyer pour cela sur le type de donnéesTOPOLOGY de postgis : http :// blog . mathieu - leplatre . info / use - postgis - topologies - to - clean -up - road - networks . html


https://gist.github.com/cquest/7f3d3067f1f572f1cce8






















http://blog.mathieu-leplatre.info/use-postgis-topologies-to-clean-up-road-networks.html



























3.2.1. côté base de données

Postgresql, pgagmin, postgisPostgresql est un logiciel libre de gestion de base de données relationnelles. Il estparticulierement connu pour sa capacité à gérer des bases de données de très grandeenvergure. Postgis est une extension de Postgres indispensable pour gérer des donnéesspatiales.Pgadmin est l'outil de gestion des bases de données de référence pour PostgreSQL.

QGisQuantum GIS est un système d'information géographique qui dispose d'une interfacegraphique permettant de visualiser les données spatiales. Les données enregistrées danspostgresql peuvent être visualisées à partir de cet outil.

Osm2pgsqlCette commande permet d'importer des données d'OpenStreetMap dans une basePostgreSQL.

shp2pgsqlCette commande sert à importer des données avec le format .shp dans une base dedonnées PostgreSQL. Cette commande est généralement incluse avec PostgreSQL etPostgis.

pg_tuneCet outil permet de configurer son serveur postgres et génère automatiquement uneconfiguration adaptée au matériel utilisé. Cette configuration ne sera pas optimale maistout de même bien supérieure à celle par défaut.

3.2.2. côté portail web

Le choix initial a été fait de s'appuyer sur l'outil de gestion de contenu web (CMS) Drupalpour le portail, qui est en PHP, ce qui a conditionné les autres choix.

• drupal7

Ce CMS libre très répandu apporte un bon compromis de simplicité et de souplesse.

• Php5PHP sera le langage utilisé pour produire les pages web.

• phppgadminCette application Web en PHP facilite la gestion du SGBD PostgreSQL et permet d'écriredes scripts php faisant appel à la base de donnée Postgresql .

• apache2Apache est le serveur web sur lequel est installé notre portail Drupal.

• REST REST est la brique technique pour la publication des données sur le web; il existe deslibraires standard pour mettre en place une API REST dans la plupart des langages.

• ZendZend le framework PHP utilisé pour notre serveur REST.


3.3. Architecture REST

Pour la réalisation du portail, nous avons choisi d’utiliser une architecture REST2.Cette architecture permet de bien séparer les parties « présentation des données » avecl’interface utilisateur et « accès aux données », et permettrait à d’autres applicationsd’accéder aux données (sans dépendre de drupal). Le serveur REST accède aux donnéesen base (en l'occurrence les indicateurs de voirie) et les fournit au client qui les présente àl’utilisateur.

3.3.1. Serveur REST

Le serveur est chargé de récupérer les données dans la base et de les fournir auportail web réalisé avec drupal : indicateurs de voirie pour chaque commune, informationssur une commune ou département, auto complétion et compte rendu.

Les indicateurs de voirieLes indicateurs sont récupérés dans la base en fonction du nom de la commune et

de son numéro Insee : longueur du réseau par rapport à la surface de la commune,longueur des impasses, surface moyenne ou périmètre des mailles, longueur du réseaupar type de voie, etc.

Les informations sur une communePour chaque commune, grâce aux deux premiers chiffres de son code Insee, nous

récupérons le numéro et le nom du département auquel il appartient, la surface de cettecommune ainsi que le nombre d’habitants.

L'auto complétionUn système d'autocomplétion pour le nom et le code Insee de la commune a été

en place pour faciliter la recherche des indicateurs de chaque commune. Pour cela, nousavons créé un fichier (ajax.php) sur le serveur qui récupère la liste de communes dans labase de données en fonction des premières lettres entrées par l’utilisateur sur leformulaire.

Le compte rendu du stagePour mettre en ligne le rapport de stage, nous avons enregistré le dossier pdf dans

le dossier où sera stocké le service.

3.3.2. Client REST

Drupal est considéré comme le client qui consomme les services REST mis àdisposition sur notre serveur via la bibliothèque curl. En REST, la ressource est eneffet appelée à l’aide de l’url du serveur. L’appel au service se fait en deux étapes:

Etape 1:Initialisation du client, et configuration des options : type d’en-tête, url du service,

2 http://fr.wikipedia.org/wiki/Representational_State_Transfer


type de transfert (xml, json, texte brut)... Etape 2:On exécute ensuite une commande curl en récupérant la réponse dans unevariable. La réponse obtenue au format json est décodée et affichée (de plusieursmanières selon la feuille de style CSS).

3.4. Implémentation

Pour la mise en place de ce serveur REST, nous avions choisi initialement d’utiliserle framework phalcon de php : écrit en C, optimisé et très performant, tout en étant simpled’utilisation, il nous semblait le meilleur choix.

Mais la comparaison des hébergeurs nous a orienté vers l'hébergeur Gandi, pourlequel ce n'est pas Phalcon mais un autre framework PHP qui est pré-installé: Zend. Notreserveur REST utilisera donc le framework Zend et non phalcon.

i. L’installation du framework Zend sur phpLe framework Zend étant déja installé sur le serveur de Gandi, il suffit de créer un dossiercomprenant un 1er sous-dossier pour l’application, un second pour le dossier public.Pour bien démarrer : http :// framework . zend . com / manual /1.12/ fr / zend . application . quick -start . html #Les contenus des fichiers application.ini et index.php se trouvent sur cette page.

ii. Création de l’applicationL’arborescence du dossier:


http://framework.zend.com/manual/1.12/fr/zend.application.quick-start.html#






















Les deux dossiers public et application sont les plus importants pour la création duservice.

Le dossier application contient des sous-dossiers et fichiers qui vont permettre à lamachine de rediriger l’utilisateur vers la fonctionnalité qu’il a choisie en fonction de l’urltapé.Le fichier application.ini (qui se trouve dans configs) stocke les paramètres du frameworkZend, c’est le fichier de configuration de l’application.Bootstrap.php est exécuté au lancement de l’application et initialise le projet. Pour chaqueurl entré, il se chargera d’appeler le controller. Pour cela on utilise Zend_Rest_Route (http :// framework . zend . com / manual /1.10/ fr / zend . controller . router . html )IndexController.php contient les fonctionnalités du service. Les résultats dépendront del’url reçu. ErreurController.php gère les erreurs.

Le dossier public contient deux fichiers index.php et .htaccess.Le fichier .htaccess va réécrire l’url en le simplifiant mais aussi en redirigeant tous les urlvers la page index.php.Le fichier index.php va donc initialiser l’application et appelle le bootstrap pour qu’il orientel’url vers l’action à réaliser dans le controller.

Les autres fichiers :- compte_rendu.pdf est le rapport de stage en version pdf.- ajax.php se charge de l'auto complétion, en récupérant dans la base de donnée lesnoms et codes des communes entrés par l’utilisateur dans le formulaire de recherche.

iii. Format de retour des requêtesLa réponse de Zend peut être soit en json, xml ou une page html.Nous avons choisi de coder les données de retour en Json. Drupal se charge alors dedécoder le résultat et l’afficher en fonction du style de css qui a été préalablement défini.

3.5. Contenu Web

Notre serveur Drupal ne contient que 6 pages: la page d’accueil, le formulaire derecherche et resultats des indicateurs, les détails d'une commune, contact, guided’installation des logiciels utilisés et le rapport de stage.Les pages sont stockées dans la base de donnée de drupal, donc il n’existe aucun fichierde page dans le répertoire du dossier drupal.Les fonctionnalités associées aux pages sont :- Recherche des indicateurs d'une commune à partir des données OSM et IGN- Recherche des indicateurs d’un département à partir des données OSM et IGN- Comparaison entre les indicateurs issus des données OSM et IGN d’un département - Comparaison entre les indicateurs issus des données OSM et IGN d’une commune

Le dossier site contient deux sous dossiers : all et default. Le sous-dossier default contientles fichiers de configuration du site, et all contient les modules et le thème utilisés pournotre site. Pour modifier les css, il faut se placer dans le dossier theme (sous dossier deall) et ouvrir le fichier style.css.


http://framework.zend.com/manual/1.10/fr/zend.controller.router.html



















Voici l’arborescence du site :

Installer le thème :Plusieurs thèmes de drupal sont disponibles gratuitement. Pour installer un, il suffit soit decopier le dossier directement dans le dossier “themes“ décrit précédemment, soit l’installervia l’interface web de drupal.

3.6. Carte interactive

Avec l’extension de QGIS « html image map plugin », nous avons pu transformer lescartes des départements et communes réalisées à partir de nos fichiers Shapefile enimage map. Tous les polygones de la couche sont transformés en coordonnées etexportés dans un fichier html sous forme d’une balise map. Simultanément, ce plugingénère une image png. On peut maintenant utiliser ce fichier html et cette image pourcréer une carte interactive. Pour rendre ces cartes interactives, nous avons installé le module maphighlight dansdrupal. Maphighlight est un plugin jquery qui ajoute un effet lumineux sur une image detype map. Grâce à ce plugin, lorsqu’on survole un département ou une commune, soncontour et son intérieur sont tracés avec une autre couleur.

Pour afficher les indicateurs (sous forme de tableau / Info-bulle) correspondant à lacommune ou département où la souris est posée, nous utilisons des fonctions javascriptqui appellent le service REST et affichent les résultats dans un tableau .

Deux fichiers distincts ont été créés dans le dossier REST. Le premier se charge derenvoyer les données des communes et le second celles des départements.Pour le fichier php du département, si le département est le 13 ou le 45, alors les donnéesIGN et OSM sont affichés en même temps dans un tableau, sinon seules les donnéesOSM sont affichées.


3.7. Mise en place du système REST sur Drupal

Nous avons mis en place un système permettant à un utilisateur d'accéder directementaux indicateurs via l’url. Pour cela, nous devons réécrire les règles d’écriture des url dansle fichier .htaccess de drupal.Pour la commune:

RewriteRule ^indicateur/commune/(.*)/code/(.*)$ indicateur_par_commune?commune=$1+-+$2#result [L,QSA]

Tous les url de type indicateur/commune/nom_commune/code/code_insee seront traitéscomme l’url de type indicateur_par_commune?commune=nom_commune+-+code_inseeL’url permettant d'accéder aux indicateurs(OSM) de la commune sera:

● http://4253f2d422.url-de-test.ws/voirie-france/indicateur/commune/Marseille/code/13055

L’url permettant d'accéder aux indicateurs(OSM) du département sera:● http ://4253 f 2 d 422. url - de - test . ws / voirie - france / indicateur / departement / Bouches - du -

Rhone / code /13L’url permettant de comparer les indicateurs OSM et IGN:

● Commune○ http://4253f2d422.url-de-test.ws/voirie-

france/indicateur/comparateur_commune/code/13055● Département

○ http://4253f2d422.url-de-test.ws/voirie-france/indicateur/comparateur_departement/code/13

3.8. Choix de l’hébergeur

Dans un premier temps, le portail a été développé en local sur un serveur de test. Une foisla première version du site opérationnelle, on l'a migrée vers un serveur pour mettre leportail en ligne. Avant cela il fallait trouver un hébergeur.

Pour faire le choix nous nous sommes basé sur l'ensemble de critères suivant :● support de Postgresql (version récente)● prix● support du langage de programmation utilisé● mémoire suffisante● accès à distance

Hébergeur Mémoire LimiteBDD

Postgres Service Prix/moisLangage

Gandi 10 Go Aucune Version 9.2

git, sftp,ssh

€4.00 php, python, ruby, node.js(au choix)

Ovh 100 Go 1x200 MB

version 8.4

€1.99 php, perl, python


http://4253f2d422.url-de-test.ws/voirie-france/indicateur/comparateur_departement/code/13

http://4253f2d422.url-de-test.ws/voirie-france/indicateur/comparateur_departement/code/13

http://4253f2d422.url-de-test.ws/voirie-france/indicateur/departement/Bouches-du-Rhone/code/13































Firstheberg 50 Go 5x300 MB

rien €1.49 php

online.net 1 Go 100 MB par table

rien €0.99 php

evxonline 30 Go SSD

Aucune rien €1.00 php

alwaysdata 10 Go Aucune 9.0 et

postgis 1.5

accès

externe

€9.00 php, python, ruby, perl

Pour nos besoins, 10 Go sont amplement suffisants : à part online.net, tous leshébergeurs ont un espace de stockage satisfaisant. Notons que OVH a le plus d'espace etque evxonline le stockage le plus rapide. Online.net ne correspond pas à nos besoins.

Au niveau de la base de données, il serait avantageux d'être seulement limité par l'espacedisque disponible. Par exemple, Drupal crée une table pour chaque module installé. Labase de données contient donc rapidement un nombre conséquent de tables. Pour garderune bonne visibilité, il est donc intéressant de séparer les indicateurs et les tables Drupalen deux bases différentes. De plus, d'un point de vue sécurité Drupal a seulement besoinde consulter les indicateurs.

OVH ne fournit qu'une seul base de 200 MB. Pour l'instant l'espace sera suffisant mais sile contenu du portail grandit, il est possible que à l'avenir on dépasse ce quota. Gandi,evxonline et alwaysdata ne posent pas de limite à la base de données à part le volume destockage global. L'offre de OVH sur ce point ne correspond pas à notre besoin.

Passons au support de Postgresql. Même si Postgresql devient de plus en plus populaire,il reste encore assez difficile à trouver un hébergeur avec une version récente dePostgresql. Dans nos premiers développements, nous avons utilisé la 9.3, il serait doncsouhaitable de garder une version la plus proche possible. Seulement Gandi, OVH etalwaysdata parlent clairement de Postgresql dans leur offre. Et des trois hébergeurs,Gandi est celui qui a la plus récente (version 9.2). Dans les autres offres, Postgresql n'estpas indiqué. Le choix final se fera donc entre Gandi et alwaysdata.

Gandi et alwaysdata proposent à peu près les mêmes langages (node.js et perl n'étantpas utilisés dans notre projet), Gandi est moins cher et propose la version Postgresql laplus récente. En outre, Alwaysdata propose une vieille version de Postgis, or nousutilisons la 2.1 donc la compatibilité n’est pas certaine. Enfin, pour 7 euros par mois chezGandi, on peut avoir un serveur dédié où l’on peut installer tous les programmes que l’onsouhaite, donc aussi Postgis 2.1.2 et Postgres 9.3 si le besoin apparaissait. Nous avonsdonc retenu Gandi comme hébergeur pour le portail.


4. Conception des requêtes et traitement sur les données

Dans cette partie, nous commençons les données utilisées avant de décrire commentnous avons conçu les requêtes produisant les indicateurs de voirie.

4.1. Les données

4.1.1. IGN BD Topo

“L’IGN est l’opérateur public de référence pour l’information géographique et forestière.Producteur et diffuseur de référentiels faisant autorité, de données géographiquesmultithématiques, il est également fournisseur de services d’utilisation des données. L’IGNintervient en appui d’autorités publiques pour contribuer à l’analyse des territoires, faciliterla mise en œuvre des projets d’aménagement et de développement durable commel’application des réglementations.”3

La base BD Topo est divisée en un ensemble de classes (ex: voie ferrée, hydrographie,etc ). Pour notre projet, il existe 7 classes en relation avec le réseau routier :

● Classe Route● Classe Route nommée● Classe Chemin● Classe Route Primaire● Classe Route Secondaire● Classe surface Route● Classe Toponyme Communication

Parmi ces classes, “Surface Route” et “Toponyme Communication” ne sont pas utiles pourl’instant dans nos calculs. Les classes “Route nommée”, “Route Primaire”, “RouteSecondaire” et “chemin” sont en fait filtrées à partir de la classe principale “Route”. Pourles calculs nous ne garderons donc que la classe la classe “Route”.

Classe Chemin :

Définition Voie de communication terrestre non ferréedestinée aux piétons, aux cycles ou aux animaux, ou route sommairement revêtue (pas de revêtement de surface ou revêtement de surface fortement dégradé).

Topologie Simple

Genre Linéaire 3D

Attributs IDPREC_PLANIPREC_ALTI

Identifiant du tronçonPrécision planimétriquePrécision altimétrique

3 http :// www . ign . fr / institut / institut / statut - et - missions


http://www.ign.fr/institut/institut/statut-et-missions

















NATUREFRANCHISSTNOM_ITIPOS_SOLZ_INIZ_FIN

Nature de la voieNature du franchissementNom d’itinérairePosition par rapport au solAltitude du sommet initial du tronçonAltitude du sommet final du tronçon

Classe Route4 :

Définition Portion de voie de communication destinéeaux automobiles, aux piétons, aux cycles ou aux animaux, homogène pour l'ensemble des attributs et des relations quila concerne. Le tronçon de route peut être revêtu ou non revêtu (pas de revêtement de surface ou revêtement de surface fortement dégradé). Dans le cas d’un tronçon de route revêtu, on représente uniquement la chaussée,

Topologie Simple

Genre Linéaire 3D

Attributs IDPREC_PLANIPREC_ALTINATURENUMERONOM_VOIE_GNOM_VOIE_DIMPORTANCECL_ADMINGESTIONMISE_SERVIT_VERTIT_EUROPFICTIFFRANCHISSTLARGEURNOM_ITINB_VOIESPOS_SOLSENSINSEECOM_GINSEECOM_DCODEVOIE_G

Identifiant du tronçonPrécision planimétriquePrécision altimétriqueNature de la voieNuméro de la voie (D50, N106...)Nom du côté gauche de la voieNom du côté droit de la voieImportanceClassement administratifGestionnaire de la voieDate de mise en serviceAppartenance à un itinéraire vertNuméro de l’itinéraire europeenIndique la nature réelle ou fictive du tronçonNature du franchissementLargeur de la chausséeNom d’itinéraireNombre de voiesposition par rapport au solsens de circulation de la voieNuméro Insee de la commune à gauche de la voieNuméro Insee de la commune à gauche de la voieIdentifiant du côté gauche de la voie

4 http :// professionnel . ign . fr / sites / default / files / DC _ BDTOPO _2-1. pdf


http://professionnel.ign.fr/sites/default/files/DC_BDTOPO_2-1.pdf



















CODEVOIE_DTYP_ADRESBORNEDEB_GBORNEDEB_DBORNEFIN_GBORNEFIN_DETATZ_INIZ_FINALIAS_GALIAS_DCODEPOST_GCODEPOST_D

Identifiant du côté droit de la voieType d’adressage de la voieBorne gauche de début de voieBorne droite de début de voieBorne gauche de fin de voieBorne droite de fin de voieIndique si le tronçon est en constructionAltitude du sommet initial du tronçonAltitude du sommet final du tronçonAncien ou autre nom utilisé côté gauche de la voieAncien ou autre nom utilisé côté droit de la voiecode postal du côté gauche de la voiecode postal du côté droit de la voie

4.1.2. OpenStreetMap

OpenStreetMap (OSM) est un peu l’Open-Source de la cartographie : tout le monde peutcontribuer à améliorer la carte et accéder aux données brutes de la carte. Avant d'être unecarte sur le web, OSM est avant tout une base de données comprenant notamment desobjets linéaires (ways), des points (nodes) et des objets plus complexes décrits par desrelations.Les données OSM peuvent être extraites de la base mondiale et retraitées grâce à denombreux outils sous licence libre, en particulier osmosis.

FormatUn fichier typique contenant des données OpenStreetMap est au format .osm , quicontient des balises XML suivant certaines règles. Un fichier XML est très redondant, onobtient donc des fichiers très volumineux pour des grandes zones géographiques.Pour réduire la taille d'un fichier osm, il est possible de le compresser, par exemple leformat osm.bz2 est très répandu, ou alors de le convertir sous un format binaire( osm.pbf). Les fichiers pbf et bz2 ont l’avantage de réduire significativement la taille dufichier, mais les fichiers pbf ont l'avantage supplémentaire d'être plus rapides à lire etpermettent donc d’aller plus vite pour certains traitements.

Représentation des donnéesOn distingue trois types d’entités dans les données d’OpenStreetMap :➔ node➔ way➔ relation

Un node ou noeud est un point sur la carte défini par sa longitude et sa latitude. Un noeudpeut simplement servir à définir une entité way mais aussi (et surtout!) indiquer des lieuxsur le terrain, comme un banc ou une intersection.

Un way n’est pas forcement une voie, c’est en fait simplement une liste ordonnée de deuxà deux mille noeuds qui définissent une ligne. Une entité way peut aussi représenter unefrontière, une rivière, etc .

Une relation est une entité qui définit une relation entre plusieurs éléments (way, node ou


relation). On peut par exemple définir un multipolygone, qui délimite une zone avec destrous à l'intérieur.

Chaque entité représente un objet sur le terrain et est identifiable par un ensembled’attributs (tags) ; par exemple, une autoroute aura comme tag highway=motorway.

Ces attributs sont donc très utiles pour filtrer les données, de manière à garder seulementles entités liées à notre problématique.

Les données OSM peuvent être récoltées depuis plusieurs sites tel que:• https :// www . data . gouv . fr / fr / dataset / decoupage - administratif - communal - francais -

issu - d - openstreetmap• http :// download . geofabrik . de / europe / france . html

4.1.3 Données de population

Les données de recensement de la population viennent du site de l’Insee.Elles sont fournies sous forme d’un quadrillage. La France est découpée en carreaux detaille égale (200 mètres de côté) et on compte le nombre d’habitants par carreau. Seulsles carreaux avec au moins un habitant sont retenu dans le jeux de données. Sur la figure1 ci-dessous, vous pouvez voir les carreaux autour de Marseille.

Figure 1

Les données associées aux carreaux comprennent plusieurs attributs :

Nom Attribut Libellé

Id Identifiant du carreau habité

IdINSPIRE identifiant INSPIRE du carreau habité


http://download.geofabrik.de/europe/france.html













https://www.data.gouv.fr/fr/dataset/decoupage-administratif-communal-francais-issu-d-openstreetmap




























Idk Identifiant du rectangle d'appartenance ducarreau habité

Ind_c Nombre d'individus résidant dans lecarreau

Nbcar Nombre de carreaux habités du rectangled'appartenance

Dans notre cas, seul l’attribut “ind_c” nous intéresse.

4.2. Conception des requêtes

Les traitements ont d'abord été conçus et développés avec les données de la voirie autourde la métropole de Marseille. En effet, des grands jeux de données ne peuvent pas êtregérés de la même manière que des jeux plus restreints : des problèmes de performancesapparaissent rapidement dès que le volume de données augmente.

On s'est donc concentré dans un premier temps sur le calcul d’indicateurs avec ce jeurestreint. On commence par décrire les pré-traitements, puis les règles de filtrage pourgarder les données de voirie pertinentes, les calculs d'indicateurs généraux, puis portantsur la topologie (mailles et impasses), et les indicateurs croisés avec la population. Le §4.2.6. décrit enfin comment nous avons adapté les traitements et les calculs à un jeux dedonnées plus conséquent (la voirie de la France métropolitaine).

4.2.1. Pré – traitements

Modification des référentiels

Un des premiers traitements à effectuer consiste à associer une commune à chaquetronçons de voirie. Après visualisation des voies et des communes OSM sous QGIS, ils’est avéré que les deux jeux de données n'étaient pas dans le même référentiel spatial.Les données des communes sont dans le référentiel EPSG:4326 (correspondant auxcoordonnées GPS usuelles) alors que les données des voies sont dans le référentielEPSG:9009013. Il a donc été nécessaire de d’effectuer via une fonction postgis unetransformation sur un des jeux de données pour passer d’un référentiel à un autres.

On a décidé de faire passer les voies du référentiel EPSG:9009013 dans le référentielepsg:4326, qui correspond aux coordonnées GPS..

Assignation des voies à une commune

Pour calculer un ensemble d’indicateurs par commune, il faut en premier lieu déterminer àquelle commune chaque tronçon de voirie appartient.

Dans le cas le plus simple (et le plus fréquent), la voie est entièrement incluse dans lacommune. Il est alors trivial de déterminer l’appartenance de la voie.


Que faire cependant d'un tronçon sur deux communes (ou plus)? Dans ce cas, il fautdécouper ce tronçon en plusieurs tronçons, aux intersections des frontières communales.

4.2.2. Filtrage des données

OSM

L'importation des données OSM (au format osm.pbf) dans la base de données esteffectuée avec Osm2pgsql et produit 4 tables, dont seule la table des lines nous intéresse.La table planet_osm_line contient tous les objets linéaires, pas seulement les tronçons devoirie. Les données OSM possèdent un grand nombre d’attributs, dont on peut ignorer unegrande partie5. Par exemple, les frontières administratives, les lignes ferroviaires oumaritimes ne nous intéressent pas. Pour filtrer les données, seuls trois attributs sont utilespour ne garder que la voirie:➔ highway➔ foot➔ bicycle

L’attribut ‘highway’ précise la nature d’une voie (la valeur motorway pour une autoroute parexemple).L’attribut ‘foot’ définit les droits d’accès à une voie par les piétons.L’attribut ‘bicycle’ joue un rôle similaire à ‘foot’ mais pour les vélos.

On peut ensuite affiner encore plus en éliminant des valeurs non pertinentes de cesattributs. Par exemple, voici la liste des attributs non pertinents pour l’attribut highway :

● disused (route très peu utilisée)● proposed (route pas encore construite)● elevator (ascenseur)● service (route réservé pour certain service ex: maintenance)● bus stop (arrêt de bus )● construction (route en construction )● platform ● rest area (aire de repos )● raceway (circuit de course )

Comme nous souhaitons identifier les routes nationales, départementales et communales,nous conserverons aussi l’attribut “ref”, qui contient le numéro de la voie, par exemple“A51” pour l’autoroute 51.

Type de voirie Valeurs d'attributs à proscrire6

autorisée aux piétons ‘motorway’, ‘motorway link’, ‘trunk’, ‘trunk link’, ‘bridleway’, ‘cycleway’ETfoot <>7 ‘no’

5 http :// wiki . openstreetmap . org / wiki / Map _ Features 6 http :// wiki . openstreetmap . org / wiki / OSM _ tags _ for _ routing / Access - Restrictions # France7 opérateur d’inégalité


http://wiki.openstreetmap.org/wiki/OSM_tags_for_routing/Access-Restrictions#France























http://wiki.openstreetmap.org/wiki/Map_Features













autorisée aux cyclistes ‘motorway’, ‘motorway link’, ‘trunk’, ‘trunk link’, ‘bridleway’, ‘footway’ETbicycle <> ‘no’

ouverte à la circulation des véhicules motorisés

‘bridleway’, ‘cycleway’, ‘footway’, ‘path’, ‘pedestrian’ETfoot <> ‘designated’ et bicycle <> ‘designated’OUref non null

autorisée aux piétons et/ou cyclistes ‘motorway’, ‘motorway link’, ‘trunk’, ‘trunk link’, ‘bridleway’ETfoot<>’no’ and bicycle<>’no’

Ces règles sont certainement à discuter et à affiner, c'est en tout cas celles que nousavons appliquées pour les calculs.

BD TOPO

Les données IGN sont relativement plus simples à traiter.La classe “Route” comprend un grand nombre d'attributs parmi lesquels on peut garder lanature de la voie, pour pouvoir séparer les tronçons en catégorie d’utilisation (vélo,marche, etc ). On pourrait aussi garder l’altitude d’un tronçon pour prendre en compte ledénivelé dans le calcul d’indicateurs (ce que nous n'avons pas fait toutefois). Nousconservons aussi l’attribut “cl_admin” qui permet de classer les tronçons appartenant àune voie departementale, nationale et autoroute.

Route● nature● Z_INI● Z_FIN● cl_admin

Les voies en construction et les tronçons fictifs ne doivent pas être pris en compte dansles calculs. Tous les tronçons appartenant à la classe “Route” qui sont fictifs (fictif=’Oui’)ou en construction (ETAT=’En Construction’) seront donc supprimés.

Les voies maritimes ou fluviales ne sont prises en compte dans nos calculs. Or l’attribut“nature” comprend les valeurs :

● Bac auto● Bac piéton

Nous avons donc supprimé les tronçons dont l’attribut “nature” est “Bac auto” ou “Bacpiéton”.

Seules les routes qui ne sont pas considérées comme des Autoroutes, desDépartementales ou des Nationales sont prises en compte pour la marche et vélo. (note :c'est sans doute une erreur du stagiaire, à vérifier dans le code des requêtes en tout cas !


Les routes nationales et surtout départementales peuvent faire partie du réseau cyclableet éventuellement piéton!!).

Pour les valeurs 'autre' de cl_admin, on peut ensuite établir le type de voirie selon lavaleur de l'attribut 'nature'. Le tableau ci-dessous fait la relation entre la valeur de l’attribut“nature” et le type de voirie (autorisée aux vélos, aux piétons, aux voitures). Par exemplesi l’on prend la catégorie “vélo” et la valeur “autoroute” la case est rouge, car les tronçonsd’autoroute ne peuvent pas être empruntés par des vélos.

Valeur Autoroute

Quasi-autoroute

Bretelle Route à deux chaussées

Route à une chaussée

Route empierrée

Chemin piste cyclable

sentier Escalier

Vélo x x x x x x

Marche x x x x x x

Véhicule x x x x x x x

4.2.3. Calcul des indicateurs généraux

Les indicateurs généraux sont les suivants :• longueur du réseau total ouvert à la circulation automobile• longueur des voies départementales• longueur d’autoroutes• longueur de nationales• longueur des autres voies

Pour OSM, le classement des voies se fait gràce à l’attribut OSM “ref”. Si on a affaire à ladépartementale numéro 49 par exemple, on aura la valeur ‘D 49’ dans “ref”. Avec cetteinformation on peut donc établir le mapping suivant :

Indicateur Couple Attributs/Valeurs

longueur des voies départementales ref = ‘D%’8

longueur de routes nationales ref = ‘N%’

longueur de voirie communale ref = ‘C%’

longueur du réseau d’autoroutes highway=’motorway’ ou ‘motorway_link’

longueur des autres voies ref non défini ou ref différent de ‘D%’,’N%’ et ‘A%’highway différent de ‘motorway’ et de ‘motorway_link’

8 % peut être remplacé par n’importe quelle chaîne de caractère


4.2.4. Calcul des indicateurs “modes doux"

Longueur de réseaux

Il s'agit de calculer la longueur des tronçons de voirie réservés aux piéyons, aux cyclistes,ou autorisée aux deux.

Mailles ( îlots )

Une maille du réseau est une liste chaînée d’arcs qui forme une boucle, c’est à dire que laliste part et aboutit au même noeud. Une maille est la représentation abstraite, dans lesdonnées, d’un pâté de maison (ou d’un ilôt).

Pour calculer les mailles, on a repris les scripts décrits dans le rapport de stage de 2010.On a donc simplement appliqué ces scripts sur notre jeu de données. A partir de toutes lesvoies qui ne sont pas des boucles, l'idée est d'identifier l'ensemble de mailles. Les maillesdoivent être minimales, c’est à dire qu’une maille ne doit pas contenir d’autres mailles. Lafonction POLYGONIZE de postgis permet précisément d'obtenir ce résultat.

Le calcul des mailles sur les données brutes d'OSM nous a montré que l’on ne pouvaitpas utiliser directement ces données brutes. Le problème est par exemple visible dans lafigure ci-après. On voit dans la figure que deux segments se coupent en bas à droite del’image mais il n’y a pas de point au niveau de l’intersection : la fonction polygonize depostgis ne détecte donc pas la maille alors que visiblement cela en est une. Ce problèmeavait déjà été identifié en 2010, il faut redécouper les tronçons de manière que lesintersections soient des extrémités de tronçons (sauf en cas de passage supérieur ouinférieur : pont, tunnel). Il faut également vérifier que deux voies reliées sur le terrain lesont effectivement aussi dans le données (mais ce second problème ne semble pas trèsimportant).

figure 3

Il faut donc procéder à un traitement sur les données pour marquer les intersections des


voies. Il faut donc marquer chaque endroit où deux voies se croisent. Dans la figure 4, onvoit le résultat d’un calcul de maille après une coupe de toutes les voies aux intersections.Le résultat est bien plus satisfaisant que le précédent.

figure 4

Cependant, il ne faut pas considérer comme intersection un pont qui passe au dessusd’une route, ou un tunnel qui passe en dessous d’une voie. Ce traitement est plus délicatet demande une réflexion plus poussée que nous n'avons pas eu le temps de traiter.

Voyons ensuite comment calculer des indicateurs associés aux mailles du réseau

Surface moyenne d’une maille :

Pour le calcul de moyenne de la surface (ou du périmètre) des ilots d’une commune (oude manière similaire pour les départements), la question est de savoir comment traiter lesmailles qui ne sont pas comprises sur le territoire d'une commune et chevauchentplusieurs communes. : on peut soit exclure ces mailles du calcul, soit décider de prendreen compte seulement la partie des mailles comprise dans la commune.

Dans notre calcul, nous avons fait le second choix (note : ce choix est discutable, et ilaurait sans doute plus clair d'exclure les mailles à cheval sur plusieurs communes). Nousavons donc sommé la surface de toutes les mailles incluses dans la commune, plus lessurfaces où les mailles et la commune se chevauchent, puis divisé ensuite le total par lenombre total de mailles dans la commune (chaque chevauchement comptant comme unemaille).


figure 5

Ci-dessus, en bleu, on voit la commune contenant ou intersectant un certain nombre demailles. Parmis ces mailles, 5 sont contenues dans la commune. La sixième maille est àcheval sur la commune. La partie rayée correspond à la surface contenu dans lacommune. Notre calcul sera donc le suivant :

périmètre moyen d’une maille :

Pour cet indicateur, on utilise la même procédure : on prend l’ensemble des mailles qui sesuperposent avec la commune (ou le département). Puis on prend soit le périmètre totalde la maille, soit le périmètre de l’intersection de la maille avec la commune (si la maillechevauche plusieurs communes.

Calcul des impasses

Une voie est considérée comme une impasse si elle est n'appartient pas à une maille.Pour le calcul, nous utilisons aussi les scripts du stage de 2010 comme pour le calcul demaille précédent.

Après avoir calculé les mailles, on marque les tronçons étant des impasses avec unattribut « deadendflag=true ».


Illustration 6: Impasses dans une zone de Marseille (en rouge)

Indicateurs associés aux impasses :● longueur totale

Pour calculer la longueur totale, il suffit de chercher tous les tronçons qui sont marquécomme étant des impasses (deadendflag=true).

4.2.5. Indicateurs croisant les données de population

Pour calculer les populations de chaque maille, nous nous sommes appuyés sur lesdonnées de recensement de l'Insee, carroyées à 200 mètres. En effet, la base OSMpossède un attribut population mais celui-ci n’est pas clairement défini.Indicateurs associés à la population :

● population moyenne par maille d’une commune/département● pourcentage de la population vivant dans des mailles de périmètre inférieur à 700

mètres (c-à-d dont il faut 10 minutes pour faire le tour à 4 km/h)

population moyenne par maille :En premier lieu nous allons calculer la population dans chaque maille. Pour cela, on vacalculer le pourcentage de recouvrement d’un carreau par une maille. Ensuite, enmultipliant la population du carreau par le pourcentage de recouvrement on connaîtra lenombre de personnes habitant à la fois dans le carreau et dans la maille.

Ce calcul suppose que la population est répartie uniformément dans le carreau. La tailleraisonnable du carreau (200*200 m²) permet d’admettre que ce calcul donnera une bonnevaleur approchée.

La figure 3.7 illustre ce calcul. Le carreau 2 est intégralement compris dans la maille, onpeut donc considérer que toute la population du carreau habite aussi dans la maille. Le


carreau 1 est à cheval sur la maille : on peut dire que 50% du carreau est contenu dans lamaille. On va donc faire une approximation en disant que 50% de recouvrement avec lecarreau signifie 50% de la population du carreau habite dans la maille.

figure 3.7

Pour calculer la population moyenne par maille dans une commune, nous retrouvonsensuite le problème des mailles chevauchant plusieurs communes.

Lorsqu'une maille chevauche la commune, nous calculons le pourcentage de la maille quise trouve dans la commune et multiplions ce pourcentage par la population de la maillepour obtenir la partie de la population dans la commune. Par exemple si 30% d’une mailleest dans la commune, alors 30% de la population de la maille se trouve aussi dans lacommune. (note : comme indiqué plus haut, la manière de traiter les mailles chevauchantplusieurs communes est discutable et peut être remise en cause).

pourcentage de la population vivant dans des maille avec un périmètre inférieur à 700mètre :Comme dans le calcul précedent, on cherche toutes les mailles qui se recouvrent avec lacommune mais en ajoutant le critère d'un périmètre inférieur à 700 mètres. On sommeensuite le nombre d’habitants des mailles respectant ce critère (et en traitant aussi le casdes mailles chevauchant plusieurs communes, comme ci-dessus). Il suffit ensuite dediviser par la population totale de la commune (ou du département).

4.2.6. Améliorer les performances

Configuration du serveur pour une utilisation normale

Il est possible d'améliorer la vitesse d'exécution des requêtes en modifiant la configurationpar défaut du serveur. Cette configuration est prévue pour fonctionner sur toutes lesmachines et sur tous les systèmes : son but premier est la compatibilité et pas laperformance. Les valeurs par défaut sont donc souvent bien en dessous de ce que lamachine est capable de faire.


Configuration pour l’import 9

Dans notre cas il s’agit d’importer plusieurs gigaoctets de données, d’où le soucid'optimiser au maximum le processus. L’optimisation décrite ci-dessous ne sert que à accélérer l’importation de données et nedoit surtout pas être utilisée dans le cadre d’une utilisation normale au risque d’avoir desperformance extrêmement mauvaises.

Ajout d'index

Un index peut être extrêmement intéressant, selon le type de requêtes effectuées et lesdonnées manipulées. Par exemple, la requête d'assignation d'une commune à un tronçonest très lente sans index : après création d'un index sur la colonne GEOMETRY des ligneset sur celle des communes, on peut énormément accélérer la chose.Avant l'ajout d'index, la requête prenait 2780 secondes, avec index nous descendons à157 secondes. Soit une amélioration d'un facteur 17, ce qui n'est pas négligeable !

Passage à l’échelle de la France

Le fichier OSM contenant les données sur la France métropolitaine pèse environ 2,7 Godans un format compressé. L’import de l’ensemble des données dans une base Postgres(avec osm2pgsql et l’option multi-thread) prend presque 2 jours sur une machine avec unprocesseur 4 coeurs et 4 Go de RAM.

Une fois les données en base, nous avons vite eu des problèmes de performance auniveau de certains traitements, notamment lors du découpage des lignes au niveau desintersections. Ce problème apparaît entre autres quand la base charge toutes les donnéesde la table dans la RAM pour faire des traitements.

La table contenant tous les tronçons de la France métropolitaine pèse environ 3Go. Avecun ordinateur dtoé d'une RAM de 4GO, cela représente ¾ de la mémoire occupée rienque par les données !

Pour aller plus vite, il faut soit se procurer une machine plus puissante ou arriver àparalléliser les requêtes.

Pour paralléliser une requête, on a le choix entre fractionner les tâches ou fractionner lesdonnées. Il se trouve trouve que les tâches respectent une certaine localité dans leurtraitement des données, c’est-à-dire que pour effectuer un traitement, chaque tâche n’apas besoin de voir l’ensemble des données à chaque instant. Par exemple, pour découperles tronçons au niveau des intersections, seuls les tronçons dans une zone précise sontutiles (les tronçons du Pas-de-Calais ne vont pas influencer le découpage les tronçons duFinistère).

Nous avons donc choisi de fractionner la table principale contenant tous les tronçons enun ensemble de sous-tables par département, pour respecter cette localité des données.

9 voir section paramétrage de la base de donnée en Annexe


figure 7 : Fractionnement

Lors du fractionnement par département, nous n'avons gardé que les tronçonsintéressants, en rapport avec la voirie. Cette partie se fait séquentiellement et prendenviron une demi-journée soit 4h, pour la France entière.

Dans le tableau ci-dessous, nous rappelons les critères utilisés pour filtrer les tronçons:

Nom Attribut Valeurs Rejetées

highway ‘construction’, ‘proposed’, ‘disused’, ‘raceway’, ‘elevator’, ‘service’, ‘bus stop’, ‘platform’, ‘rest area’

railway Tous10

waterway Tous

Une fois le fractionnement fait, on peut commencer à paralléliser les requêtes. Il esttechniquement possible de lancer toutes les requêtes une à une manuellement. En effet,on ouvre un certain nombre de sessions, puis on exécute une requête par session ou unensemble de requêtes par session, mais ce n’est pas très pratique, c’est pourquoi nousavons opté pour une automatisation des requêtes grâce à un petit script en python.

Le script en python lance un certain nombre de threads11 et initialise une liste de travail àfaire (en fait une liste de tables à traiter). Chaque tâche va prendre un travail dans la listeet l’effectuer. Lorsqu'une tâche a fini un travail, elle passe au suivant en regardant dans laliste. Ce cycle se répète tant qu’il y a du travail à faire.

10 Tous signifie ici que toutes les valeurs sont refusé11 http://fr.wikipedia.org/wiki/Thread_%28informatique%29


figure 8: découpage des tronçons aux intersections

La figure 8 illustre la parallélisation du découpage des tronçons aux intersections. Leschéma est le même pour tous les traitements en parallèle : on a un ensemble de tablesinitial auxquelles on applique un certain nombre d’opérations.

La figure 9 montre le déroulement des traitements du début jusqu’au calcul des indicateurspour les départements. A l’étape 1, on a l’importation de l’ensemble des données (lignes,communes, départements). A l'étape 2, on a le traitement décrit dans la figure 7.

Dans l’étape 3 on trie les tronçons en 2 catégories12 :● autorisés aux voitures● autorisés aux piétons / cyclistes

Le tronçon peut être empruntable en voiture (vehicule=true), ou le tronçon peut être utilisépar des piétons ou des vélos (marchvelo=true). Ces deux catégories ne sont pasmutuellement exclusives : un tronçon peut être ouvert aux voitures et aux modes doux !

L’étape 4 du schéma correspond au traitement décrit dans la figure 8. Une fois que lestronçons sont bien découpés, on peut calculer les ilots : c’est l’étape 5. Comme dans lafigure 8, à chaque table de tronçons bien découpés, on fait correspondre un ensemble demailles. L’étape 6 consiste à marquer tous les tronçons qui sont des impasses. L’étape 7consiste à calculer la population pour chaque maille. Nous avons alors tous les élémentspour calculer les indicateurs. L'étape suivante 8, consiste à calculer les indicateurs à partirdes lignes par département, des tronçons découpés et des mailles.

12 Voir partie 3.2.1 pour voir quels attributs correspond à quels catégories


figure 9

Une fois les indicateurs calculés pour chaque département, il faut faire de même pour lescommunes. Pour cela, il faut d'abord assigner chaque tronçon à une commune (sur lafigure 10, cela correspond au point 1 et 2). Puis on procède au calcul d’indicateurs sur lescommunes avec ces nouvelles tables.


figure 10


5. Conclusions

5.1. En résumé

Comme indiqué en introduction, ce travail n'avait pas l’ambition de développer denouvelles méthodes ou algorithmes de calculs d'indicateurs, ni un nouveau modèle dedonnées pour la voirie, ni de proposer une organisation collaborative pour saisir etrenseigner des données de voirie, mais plus modestement de s'appuyer sur les donnéeset outils logiciels existants pour construire un prototype opérationnel. Les principauxrésultats sont donc:

- le portail en ligne sur le web ;

- une couverture nationale qui permet potentiellement des comparaisons entre territoires ;

- une mise à disposition de résultats librement réutilisables valorisant les données OSM etpouvant inciter à terme à mieux renseigner les attributs concernant les modes doux ;

- une comparaison avec les données BD Topo de l’IGN sur deux départements.

En pratique, le portail peut être utilisé à 3 niveaux :

-1- pour se faire une idée de ce qui a été développé : naviguer dans le site et afficher dequelques indicateurs ou cartes ;

-2- pour étudier les résultats et faire ses propres analyses : télécharger les données(fichiers Shapefile des indicateurs, dont le fichier .DBF contient une ligne par commune oudépartement, et une colonne par indicateur) ;

-3- pour reprendre les développements, il est possible de partir des scripts et codessources pour installer la base complète sur un serveur et relancer puis compléter lesindicateurs existants.

Nous espérons que ce travail pourra intéresser d'autres acteurs et que certainsdéveloppements pourront être repris et complétés.

5.2. Difficultés rencontrées, points restant à traiter, leçons

Nous avons identifié plusieurs points qui devraient être corrigés et améliorés :

- au niveau des données:

- modélisation plus systématique des différents types de réseau, et définition de règlesplus strictes de filtrage en fonction de la valeur des attributs OSM (ou BD TOPO): voiesautorisées / interdites / réservées aux piétons, cyclistes, voitures;

- au niveau des calculs:

- traitement des ilots à cheval sur plusieurs communes : il semble à la réflexion pluspertinent de ne pas prendre en compte ces ilots, plutôt que de les inclure dans les calculsde moyenne; on pourrait en revanche calculer des indicateurs représentant la connectivitéd'une commune (ou territoire) aux communes voisines : nombre de voies sortant de lacommune, etc.;


- prise en compte des ponts et tunnels dans l'extraction des ilots;

- calcul de la pente des tronçons;

- calcul d'indicateurs plus pertinents sur les impasses: regroupement des impasses en« arbres » sur lesquels calculer la longueur moyenne, plutôt que moyennes agrégeanttoutes les impasses (les petites impasses dont plutôt favorables, les grandes impassesplutôt défavorables);

- au niveau du portail :

- mettre en ligne plus de cartes, des graphes montrant les relations entre les indicateurs etle « nuage des points » correspondant à chaque territoire...

5.2. Perspectives

Ce prototype n'étant qu'un démonstrateur, un « proof of concept » comme on dit enfrançais, il reste beaucoup de points à traiter avant d'espérer aboutir à un portailopérationnel, même pour des besoins d'études ou recherche. Par ailleurs, ce type deportail peut bien sûr s'envisager pour les modes doux, mais aussi pour les autres modes:TC, VP, stationnement. Voici nos suggestions de pistes de travail, bien que nous n'ayons ànotre niveau pas vraiment de levier pour les faire progresser.

- processus de gestion et mise à jour des données de voirie

Idéalement, les géométries des tronçons de voirie et les données métier associées(attributs décrivant la cyclabilité, etc.) devraient pouvoir associer le meilleur des 3mondes : homogénéité et couverture nationale de la BD TOPO, détail des SIG urbains outerritoriaux, souplesse et réactivité des contributeurs bénévoles d'OSM, notamment viades associations de promotion du vélo ou de la marche qui sont à même de renseignertrès efficacement. Cela reste un vrai challenge, tant pour des raisons juridiques,qu'organisationnelles et de ressources.

- nouvelles sources de données, niveaux de service

Rien n'oblige à se limiter aux données de tronçons de voirie, et d'autres données sontutiles pour calculer des indicateurs de cyclabilité ou marchabilité. Par exemple, lesdonnées ponctuelles telles que parkings à vélo, vélociste, points VLS, accidents peuventêtre pertinentes, des données surfaces également.

En outre, à côté d'indicateurs résultant de calculs, on pourrait tenir à jour des indicateursplus qualitatifs et. ou calculer des pourraient être résumés dans des indicateurs de niveaude service Vélo ou Marche sur la base de ces indicateurs.

- indicateurs d'accessibilité

L'accessibilité transport mesure la facilité avec laquelle on peut accéder à différentsservices ou points d'intérêt depuis un lieu donné; elle diffère bien sûr selon les modes detransport employés pour se déplacer. Des outils de recherche d'itinéraires s'appuyant surOpenstreetmap, tels que OSMR ou OpenTripPlanner, permettent de calculer assezfacilement des isochrones, ou des scores d'accessibilité, qui pourraient donc compléter lesindicateurs d'un portail.

- portails dédiés à un mode de transport

Notre prototype a esquissé ce qui pourrait être fait pour les modes actifs, mais il pertinentaussi, si ce type de portail peut être mise en oeuvre, que soient développés (par des


acteurs différents sans doute) en fait un portail par type d’usager : automobiliste, cycliste,piéton...

Les réseaux routiers peuvent notamment faire l’objet de nombreux développements,notamment en fusionnant avec des données de temps de parcours ou de vitesses afin deproduire des indicateurs d’accessibilité en VP, de congestion voire de niveau de service.Cela pourrait faire l’objet d’un projet en soi (estimation de la vitesse moyenne en heurecreuse et de pointe par tronçons à partir de la population et du type de route, ou de laprésence de feux, estimation du temps de recherche de place de stationnement encroisant avec infos urbaines et parkings d’OSM ou autres sources, sélection des tracesGPS OSM pertinentes, couplage avec une recherche d’itinéraire...), de manièrecomplètement indépendante d'un portail dédié aux modes actifs.

Plus largement, donc, à côté de la « France des routes et des chemins », rien n'empêchede voir émerger d'autres portails : la « France des bouchons », la « France des TC », la« France des Nouveaux Services de Mobilité », ou sur d'autres thèmes documentés parFrédéric Héran, la « France des coupures », ou « la France de la consommation d'espaceviaire »...


références(les outils sont listés dans le corps du rapport et faciles à trouver sur le web)

1. Le Cerema : www.cerema.fr2. La mission Information Multimodale : http://mim.cete-aix.fr/3. Notre projet http://mim.cete-aix.fr/spip.php?article3734. Notre portail http://4253f2d422.url-de-test.ws/voirie-france/5. Indicateurs Modes doux (rapport de F. Héran 2002) http://www.innovations-

transports.fr/Indicateurs-pour-des-amenagements6. Rapport CETE Med SIG modes doux : http://mim.cete-aix.fr/spip.php?article687. Rapport Stage 2010 : http://mim.cete-aix.fr/spip.php?article2558. Balises OSM http://wiki.openstreetmap.org/wiki/Map_Features#Highway et

http :// wiki . openstreetmap . org / wiki / OSM _ tags _ for _ routing / Access -Restrictions # France

9. Données carroyées de population INSEE http :// www . insee . fr / fr / themes / detail . asp ?reg _ id =0& ref _ id = donnees - carroyees & page = donnees - detaillees / donnees -carroyees / donnees _ carroyees _ diffusion . htm

10.L'IGN http :// www . ign . fr / institut / institut / statut - et - missions11. La BD TOPO http :// professionnel . ign . fr / bdtopo # tab -112.Les départements http :// fr . wikipedia . org / wiki / Liste _ des _ d % C 3% A 9 partements _ fran

% C 3% A 7 ais _ class% C 3% A 9 s _ par _ population _ et _ superficie # Liste _ des _ d . C 3. A 9 partements

13.Les communes françaises http :// fr . wikipedia . org / wiki / Liste _ des _ communes _ de _ France _ les _ plus _ peupl% C 3% A 9 es # Classement _ des _ communes


http://fr.wikipedia.org/wiki/Liste_des_communes_de_France_les_plus_peupl%C3%A9es#Classement_des_communes






































http://fr.wikipedia.org/wiki/Liste_des_d%C3%A9partements_fran%C3%A7ais_class%C3%A9s_par_population_et_superficie#Liste_des_d.C3.A9partements



























































http://professionnel.ign.fr/bdtopo#tab-1





























http://www.insee.fr/fr/themes/detail.asp?reg_id=0&ref_id=donnees-carroyees&page=donnees-detaillees/donnees-carroyees/donnees_carroyees_diffusion.htm







































































http://wiki.openstreetmap.org/wiki/Map_Features#Highway





http://4253f2d422.url-de-test.ws/voirie-france/


http://mim.cete-aix.fr/

http://www.cerema.fr/

Connaissance et prévention des risques - Développement des infrastructures - Énergie et clima t - G estion du patrimoine d’infrastructures I m p a c t s s u r l a s a n t é - M o b i l i t é s e t t r a n s p o r t s - T e r r i t o i r e s d u r a b l e s e t r e s s o u r c e s n a t u r e l l e s - V i l l e e t b â t i m e n t s d u r a b l e s

Centre d’études et d’expertise sur les risques, l’environnement, la mobilité et l’aménagementDirection Territoriale Méditerranée - Pôle d'activités 30 Avenue Albert Einstein - CS 70499 - 13593 AIX-EN-PROVENCE Ccedex 3 -Tél : +33 (0)4 42 24 76 76

Siège : Cité des Mobilités - 25, avenue François Mitterrand - CS 92 803 - F-69674 Bron Cedex - Tél : +33 (0)4 72 14 30 30 - www.cerema.fr

Documents

Développement d’un portail web d’indicateurs sur la voirie ...mim.cete-aix.fr/IMG/pdf/portail-voirie-chemins.pdf · 1. Introduction 1.1. Contexte Ce rapport est le résultat