conception d’un dÉmonstrateur d’analyse … · Écoles d’officiers de l’armÉe de l’air...

80
ÉCOLES D’OFFICIERS DE L’ARMÉE DE L’AIR CONCEPTION D’UN DÉMONSTRATEUR D’ANALYSE GÉOGRAPHIQUE DES RÉSEAUX DE VOIRIE ET TRANSPORT COLLECTIF D’AIX-EN- PROVENCE Mémoire rédigé dans le cadre de l’enseignement par la recherche par ASPIRANT COQUEL ASPIRANT MAZERAN sous la direction de Monsieur Patrick GENDRE Salon de Provence, juin 2010

Upload: doannhan

Post on 13-Sep-2018

216 views

Category:

Documents


0 download

TRANSCRIPT

ÉCOLES D’OFFICIERS DE L’ARMÉE DE L’AIR

CONCEPTION D’UN DÉMONSTRATEUR

D’ANALYSE GÉOGRAPHIQUE DES RÉSEAUX DE

VOIRIE ET TRANSPORT COLLECTIF D’AIX-EN-

PROVENCE

Mémoire rédigé dans le cadre de l’enseignement par la recherche

par

ASPIRANT COQUEL

ASPIRANT MAZERAN

sous la direction de Monsieur Patrick GENDRE

Salon de Provence, juin 2010

2

REMERCIEMENTS

À Monsieur Patrick GENDRE :

Chef du service DCEDI/TIM

Veuillez accepter nos plus sincères remerciements pour d’une part, l’intérêt du

stage que vous nous avez proposé, mais aussi pour l’aide précieuse que vous nous avez

apportée tout au long du projet.

Aux équipes des services TIM et EGT :

Veuillez accepter nos plus chaleureux remerciements pour l’intérêt, l’accueil et

la bonne humeur dont vous avez fait preuve à notre égard.

Au capitaine CHARLIER Gildas :

Nous vous remercions vivement de l’aide, des conseils et de la documentation

que vous nous avez procurés tout au long de notre EPR. Cela nous a permis de bien

appréhender le sujet et d’enrichir notre travail.

À l’adjudant MONDOU :

Nous vous remercions particulièrement pour l’aide précieuse et le temps que

vous nous avez consacrés. Votre enseignement nous a été d’une grande importance dans

la compréhension et l’élaboration du projet.

3

« Le ministère de la Défense et le ministère de l’Écologie, de l’Énergie, du

Développement durable et de la Mer n'entendent donner ni approbation ni improbation

aux idées émises dans les mémoires et autres documents soutenus en vue de l'obtention

de grades universitaires ou diplômes. Ces opinions doivent être considérées comme

propres à leurs auteurs et n'expriment en rien la position des institutions auxquelles ils

appartiennent. »

4

SOMMAIRE

ABSTRACT / RÉSUMÉ ............................................................................................................ 7

1. INTRODUCTION ............................................................................................................... 8

1.1. Le CETE Méditerranée .............................................................................................................. 8

1.2. Le projet CALIFE ........................................................................................................................ 8

1.3. Objectifs d’étude .....................................................................................................................10

2. ENVIRONNEMENT TECHNIQUE ............................................................................... 11

2.1. Les données .............................................................................................................................11

2.1.1. Open Street Map .................................................................................................................. 11

2.1.2. Base de données TOPO IGN ................................................................................................. 11

2.1.3. Base de données IRIS-2000 de l’INSEE ................................................................................. 12

2.1.4. Transport collectif et points d’intérêt .................................................................................. 12

2.1.5. Démonstrateur SIG libre Toulouse ....................................................................................... 12

2.2. Les outils .................................................................................................................................13

2.2.1. PostgreSQL et PostGIS .......................................................................................................... 13

2.2.2. Quantum Gis......................................................................................................................... 14

2.2.3. PgRouting ............................................................................................................................. 14

2.2.4. Sun xVM VirtualBox .............................................................................................................. 15

3. ACCESSIBILITÉ DES RÉSEAUX ROUTIERS AUX MODES DE DÉPLACEMENT DOUX ........................................................................................................................................ 16

3.1. Création d’une base de données..............................................................................................16

3.2. Le réseau routier de l’agglomération d’Aix-en-Provence .........................................................17

3.2.1. Création de la couche OSM d’Aix-en-Provence .................................................................... 18

3.2.2. Création de la couche IGN d’Aix-en-Provence ..................................................................... 19

3.3. Mailles et impasses .................................................................................................................20

3.3.1. Détection des mailles et calcul du périmètre ....................................................................... 20

3.3.2. Détection des impasses ........................................................................................................ 23

3.4. Temps de parcours d’une maille ..............................................................................................25

3.4.1. Marche à pied ....................................................................................................................... 26

3.4.2. Parcours à vélo ..................................................................................................................... 27

3.5. Création de la couche réseau transport collectif ......................................................................28

3.6. Présentation cartographique ...................................................................................................29

5

4. CARTOGRAPHIE DES VITESSES DE CIRCULATION ........................................... 31

4.1. Affectation de la vitesse moyenne en fonction du type de route ............................................31

4.2. Prise en compte des données du recensement INSEE ............................................................33

4.2.1. Acquisition d’une base de données adaptée ......................................................................... 33

4.2.2. Calcul de densité de population par IRIS ............................................................................. 35

4.3. Réévaluation des vitesses moyennes en heure de pointe ........................................................36

4.3.1. Ralentissements en zones de forte densité de population .................................................. 36

4.3.2. Affectation des nouvelles vitesses ....................................................................................... 37

4.4. Présentation cartographique ..................................................................................................39

5. INDICATEURS DE PROXIMITÉ ................................................................................. 42

5.1. Installation et test de PgRouting ..............................................................................................42

5.2. Adaptation de la table de voirie IGN aux fonctions de PgRouting ............................................44

5.3. Calcul d’isochrones pour différents modes de déplacement ....................................................46

5.3.1. Nouvelles entrées pour la fonction driving_distance ........................................................... 46

5.3.2. Polygones isochrones ........................................................................................................... 47

5.3.3. Temps de parcours depuis un lieu choisi ............................................................................. 47

5.3.4. Présentation cartographique ............................................................................................... 47

5.4. Calcul de scores .......................................................................................................................49

6. UTILISATION ET GÉNÉRALISATION DES PROCÉDURES ................................. 53

6.1. Installation des logiciels ...........................................................................................................53

6.1.1. PostgreSQL ........................................................................................................................... 53

6.1.2. Postgis .................................................................................................................................. 54

6.2. Accès aux données ..................................................................................................................55

6.3. Conversion des données dans les formats adaptés ..................................................................55

6.4. Création de la base de données ...............................................................................................56

6.5. Import des données vers la BD et vérification .........................................................................57

6.6. Ajout des colonnes et des tables nécessaires...........................................................................58

6.7. Création et exécution des fonctions ........................................................................................58

6.8. Calcul d’indicateurs .................................................................................................................59

CONCLUSION ......................................................................................................................... 60

ANNEXE 1 ............................................................................................................................... 63

6

ANNEXE 2 ............................................................................................................................... 64

ANNEXE 3 ............................................................................................................................... 67

ANNEXE 4 ............................................................................................................................... 71

BIBLIOGRAPHIE ................................................................................................................... 76

GLOSSAIRE ............................................................................................................................. 77

TABLE DES ILLUSTRATIONS ............................................................................................ 79

7

ABSTRACT / RÉSUMÉ

The 'CETE Méditerranée' -Department responsible for road maintenance Technical

Study Center- participates in a research programme in which our study takes place: the

CALIFE project aims at producing open-source tools, data and indicators about

multimodal journey times, congestion, accessibility maps for the whole of France and at

evaluating how the results can be used in transport and network management studies.

This project, which is still in the proposal phase, is waiting for a financing decision.

Our goal in this internship is to progress in the direction of the project. We applied

and adapted existing tools to the pilot site of the commune of Aix-en-Provence, and

designed and tested data processing scripts producing accessibility maps and indicators

for cars, bicycles and pedestrians, such as dead-ends, average speeds and using

population census data and the reference road network, both from the national

geographic institute IGN and from OpenStreetMap. The results are packaged and

documented so as to be reused for other geographic areas. Finally, we propose some

improvements to be made both source data, indicators and software.

Notre étude s’insère dans un programme de recherche auquel participe le CETE

Méditerranée (Centre d’Études Techniques de l’Équipement) : le projet CALIFE

(données et Cartes d'Accessibilité multimodale et de congestion récurrente LIbrement

diffusées pour la France Entière). Ce projet, encore en attente de financement, vise à

produire une plate-forme libre et ouverte de données sur les temps de parcours et la

congestion récurrente, avec une couverture nationale, extensible au domaine du

transport collectif, et à évaluer les perspectives d’utilisation des outils et données pour

des besoins d’étude ou de gestion des réseaux.

Dans cette optique, nous nous plaçons dans le cadre plus restreint de la commune

d’Aix-en-Provence, afin de démontrer la faisabilité du projet. Ainsi nous utilisons et

adaptons des outils préexistants pour produire des cartes d’accessibilité et des

indicateurs tels que les temps de parcours ou la proximité des arrêts de transport

collectif, pour les modes de déplacement piéton, cycliste ou motorisé. Les réseaux de

voirie exploités sont issus soit des données de l’Institut Géographique National IGN,

soit d’OpenStreetMap. Les résultats seront finalement regroupés et généralisés dans une

documentation adaptable à d’autres données.

8

1. INTRODUCTION

1.1. Le CETE Méditerranée

Le Centre d'Études Techniques de l'Équipement Méditerranée (CETE) est un bureau

public d'études et d'ingénierie pour tous les acteurs de l'aménagement, à savoir les

collectivités locales ou les organismes parapublics ou privés. Le CETE concourt, par sa

capacité d'étude et d'expertise, à l'éclairage des choix et des décisions publiques mises

en œuvre et à l'évaluation des politiques publiques. Il est dans le secteur public un appui

considérable grâce à sa connaissance fine du territoire et à sa maitrise des techniques.

Ses domaines d'activités sont très larges. En effet, les compétences du CETE couvrent

les domaines de la gestion des risques, les transports et déplacements, les infrastructures

et ouvrages d'art ainsi que la géotechnologie. Le CETE Méditerranée est un service

déconcentré du ministère de l’Écologie, de l’Énergie, du Développement durable et de

la Mer, et fait partie du Réseau Scientifique et Technique de l'équipement qui comprend

7 centres CETE et plusieurs services techniques.

Le stage se déroule au sein du service des « Trafic et Information Multimodale»

(TIM) du « Département Conception et Exploitation Durables des Infrastructures »

(DCEDI), dont le domaine technique est l'ingénierie du trafic, l'exploitation routière,

l'information aux usagers et plus largement les systèmes de transports intelligents.

1.2. Le projet CALIFE

Notre étude s’inscrit dans un projet de recherche auquel participe le CETE

Méditerranée : le projet CALIFE (données et Cartes d'Accessibilité multimodale et de

congestion récurrente LI brement diffusées pour la France Entière). Ce projet, encore au

stade de proposition, est en attente d’une éventuelle décision de financement dans le

cadre d’un appel d’offres du PREDIT, le programme français de recherche sur les

transports.

Ce projet a émergé de trois constats : le manque d’information sur la congestion

récurrente, l’intérêt des outils géographiques pour analyser l’offre de transport et

l’accessibilité, ainsi que l’existence d’une base de données cartographique librement

DCEDI / TIMDCEDI / TIMDCEDI / TIMDCEDI / TIM

9

disponible (OpenStreetMap) sur la France entière qui permet de créer une plate-forme

de travail mise à la disposition de la communauté.

En effet, l’information routière et multimodale connaît ces dernières années un

développement considérable et un usage en forte croissance par le grand public de

nouveaux services (sites Internet, applications sur mobiles ou navigateurs GPS),

notamment en termes de calcul d’itinéraires. Cependant, ces outils et services présentent

plusieurs inconvénients :

- l’information théorique disponible sur l’ensemble des réseaux routiers se base

sur une situation en heures creuses, et certaines hypothèses concernant les temps

de parcours ou vitesses moyennes peuvent différer d’un service ou d’un système

à l’autre et sont rarement explicitées,

- l’information en temps réel n’est disponible que pour une partie limitée du

réseau (essentiellement les autoroutes), et éventuellement pour un nombre

restreint d’usagers (notamment pour les services « premium » auxquels il faut

être abonné).

Les outils d’analyse cartographique, et notamment les cartes d’accessibilité, que l’on

peut regrouper autour de l’expression « SIG (Système d’Information Géographique)

transport », permettent de représenter les informations en temps réel et de les

communiquer.

Le projet CALIFE vise à produire une plate-forme libre et ouverte de données sur

les temps de parcours et la congestion récurrente, avec une couverture nationale,

extensible au domaine du Transport Collectif (TC), et à évaluer les perspectives

d’utilisation des outils et données pour des besoins d’étude ou de gestion des réseaux.

Les objectifs du projet CALIFE sont de fournir via le Web à la communauté des

utilisateurs les résultats suivants :

- Une représentation, estimée suffisante et couvrant tout le territoire métropolitain,

de l’accessibilité en situation de congestion,

- Une comparaison de l’accessibilité entre les heures creuses, heures de pointe, et

éventuellement en intégrant les modes doux (vélo/marche à pied),

- Une libre diffusion de la base de données correspondante ainsi que le mode de

calcul des temps de parcours ou des vitesses moyennes. Ces informations

permettront la réalisation d’études et le développement d’outils (tels que des

indicateurs) pour les professionnels (chercheurs, bureaux d’études, collectivités

et autres organismes publics, opérateurs de service...),

10

- de voir comment ces estimations pourraient être améliorées, notamment dans le

cadre collaboratif d’OpenStreetMap.

Le projet CALIFE s’inscrit dans le cadre de travaux précédents sur les logiciels

libres SIG* transport (projet POTIMART) qui ont abouti à la production de

démonstrateurs qui seront les points de départ de notre travail.

1.3. Objectifs d’étude

Notre travail a pour but d’avancer dans la direction proposée par le projet CALIFE.

Pour ce faire, nous travaillons sur un territoire de test limité à la commune d’Aix-en-

Provence, tout en gardant à l’esprit l’idée de produire des outils simples et documentés

généralisables à d’autres périmètres d’étude.

Après une présentation de l’environnement technique à notre disposition, nous nous

concentrerons sur le développement des fonctions suivantes :

- étude de l’accessibilité au réseau routier en mode de transport doux (marche à

pied/vélo),

- cartographie des vitesses moyennes de circulation en heures creuses et heures de

pointe,

- indicateurs de proximité.

Nous terminerons par une généralisation des procédures en vue d’une adaptation à

d’autres données.

2. ENVIRONNEMENT TECHNIQUE

2.1. Les données

2.1.1. Open Street Map

OpenStreetMap

cartographie vectorielle en libre

Partie d’Angleterre, OSM a désormais largement franchi les frontières et l

données OSM s’améliore

informatiques basés sur Internet permet l'intervention et la collaboration de tout

utilisateur volontaire.

saisie très évolués (et open source) et à l’effort des bénévoles, les d

en France, notamment autour des principales agglomérations, sont désormais assez

complètes.

Les données sont échangées sous format XML mais il existe des sites où les

données OSM sont disponibles au format

logiciel SIG*.

Il est possible de télécharger

française. Les données routières de la région PACA

2.1.2. Base de données

Le CETE a acquis une licence d’utilisation de la base de données (BD)

topographique de l’IGN. La BD Topo IGN présente plusieurs intérêts

couverture nationale, le fait que beaucoup de collectivités et de services de l’état ont la

licence d’utilisation.

Les données nous ont été fournies sous forme d’une seule table rassemblant les

chemins et les routes, au format Mapinfo «

ENVIRONNEMENT TECHNIQUE

Open Street Map

OpenStreetMap est une initiative privée à but non lucratif visant à produire

cartographie vectorielle en libre-diffusion du monde et en particulier du réseau routier.

Partie d’Angleterre, OSM a désormais largement franchi les frontières et l

données OSM s’améliore de manière spectaculaire depuis 2008. L'utilisatio

informatiques basés sur Internet permet l'intervention et la collaboration de tout

utilisateur volontaire. Ces données sont librement redistribuables.

saisie très évolués (et open source) et à l’effort des bénévoles, les d

en France, notamment autour des principales agglomérations, sont désormais assez

Les données sont échangées sous format XML mais il existe des sites où les

données OSM sont disponibles au format « shapefile* », directement

l est possible de télécharger sur Internet les données routières de chaque région

çaise. Les données routières de la région PACA ont ainsi été téléchargées.

Base de données TOPO IGN

Le CETE a acquis une licence d’utilisation de la base de données (BD)

topographique de l’IGN. La BD Topo IGN présente plusieurs intérêts

couverture nationale, le fait que beaucoup de collectivités et de services de l’état ont la

Les données nous ont été fournies sous forme d’une seule table rassemblant les

chemins et les routes, au format Mapinfo « .tab » en Lambert2 Carto.

11

ENVIRONNEMENT TECHNIQUE

une initiative privée à but non lucratif visant à produire une

diffusion du monde et en particulier du réseau routier.

Partie d’Angleterre, OSM a désormais largement franchi les frontières et la qualité des

L'utilisation de moyens

informatiques basés sur Internet permet l'intervention et la collaboration de tout

Ces données sont librement redistribuables. Grâce à des outils de

saisie très évolués (et open source) et à l’effort des bénévoles, les données disponibles

en France, notamment autour des principales agglomérations, sont désormais assez

Les données sont échangées sous format XML mais il existe des sites où les

, directement utilisable dans un

les données routières de chaque région

ont ainsi été téléchargées.

Le CETE a acquis une licence d’utilisation de la base de données (BD)

topographique de l’IGN. La BD Topo 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 ont la

Les données nous ont été fournies sous forme d’une seule table rassemblant les

Lambert2 Carto.

12

Il est à noter que la licence d’utilisation de la BD Topo IGN fait l’objet de

limitations qui compliquent sa diffusion (mais l’objectif de notre stage n’était pas de

produire un démonstrateur librement diffusable).

2.1.3. Base de données IRIS-2000 de l’INSEE

Pour les communes de plus de 5000 habitants, l'IRIS-2000 est la zone

géographique minimale, d'un seul tenant d'environ 2000 habitants, définie par l'INSEE,

pour la diffusion à tous publics des comptages, listes et tableaux.

La base de données associée fournit les fonds cartographiques IRIS* pour toutes

les communes urbaines découpées en IRIS-2000, ainsi que toutes les autres communes

non découpées. Elle constitue ainsi un maillage complet du territoire à un niveau fin.

Cette base contient 14637 IRIS pour 1 800 communes découpées environ, auxquels

s’ajoutent les 35 000 communes non découpées.

Nous avons à notre disposition les données des contours IRIS des Bouches du

Rhône au format « .shp » (shapefile) ainsi que des fichiers Excel rassemblant les

données statistiques de recensement (par exemple : classement par catégorie

socioprofessionnelle). Le Pôle Géomatique du CETE Méditerranée a fusionné ces

données INSEE pour qu’elles soient directement exploitables au format shapefile.

2.1.4. Transport collectif et points d’intérêt

Les positions des arrêts de transport collectif (TC) et les points d’intérêt (POI)

de la région PACA sont disponibles sur OpenStreetMap au format « .osm ».

2.1.5. Démonstrateur SIG libre Toulouse

Le développement de ce démonstrateur a été confié à la société MOBIGIS par le

CETE Méditerranée fin 2008, dans le prolongement du projet de recherche POTIMART

sur les SIG transport « open source* ».

Le démonstrateur, diffusable librement, comprend un environnement complet sous

linux (postgis, GQis

permettant de produire des

piétonne des réseaux routiers (calculs d’impasses et de mailles), d’autre part à la

fréquence et la vitesse des lignes d’un réseau TC.

Il fonctionne avec des données réelles provenant du résea

Toulouse, partenaire du projet. La donnée de voirie provient de la base Open Street Map.

La démonstration est destinée aux techniciens des services Transport des

collectivités, et plus généralement aux organismes et prestataires de service tr

sur des études des réseaux de transport.

A terme, l’objectif est de valider l'intérêt des utilisateurs potentiels (collectivités

autorités de transport et autres organismes publics, bureaux d'études) pour une solution

open source SIG (système d’

transport, et de mieux comprendre leurs besoins.

Ce démonstrateur nous

Il nous a fourni une base de travail à adapter à la ville d’

donné un aperçu du résultat final attendu.

Il existe deux versions du démonstrateur, la deuxième étant plus particulièrement

centrée sur OSM.

2.2. Les outils

2.2.1. PostgreSQL

PostgreSQL est le principal système de gestion de base de données relationnelle

et objet (SGBDRO) open source. Ce système est concurrent d’autres

gestion de bases de données, qu’ils soient libres (comme MySQL et Firebird) ou

propriétaires (comme Oracle,

de nombreux services

PostgreSQL nous employons une interface utilisateur appelée

nstrateur, diffusable librement, comprend un environnement complet sous

linux (postgis, GQis : cf. ci-dessous), des données et des requêtes ou scripts SQL*

permettant de produire des indicateurs et des cartes relatifs d’une part à l’accessibilité

piétonne des réseaux routiers (calculs d’impasses et de mailles), d’autre part à la

fréquence et la vitesse des lignes d’un réseau TC.

fonctionne avec des données réelles provenant du résea

Toulouse, partenaire du projet. La donnée de voirie provient de la base Open Street Map.

La démonstration est destinée aux techniciens des services Transport des

collectivités, et plus généralement aux organismes et prestataires de service tr

sur des études des réseaux de transport.

A terme, l’objectif est de valider l'intérêt des utilisateurs potentiels (collectivités

autorités de transport et autres organismes publics, bureaux d'études) pour une solution

(système d’information géographique) d’analyse de réseaux de

transport, et de mieux comprendre leurs besoins.

Ce démonstrateur nous a permis de comprendre rapidement l’objectif de notre projet.

Il nous a fourni une base de travail à adapter à la ville d’Aix-en

donné un aperçu du résultat final attendu.

Il existe deux versions du démonstrateur, la deuxième étant plus particulièrement

PostgreSQL et PostGIS

est le principal système de gestion de base de données relationnelle

et objet (SGBDRO) open source. Ce système est concurrent d’autres

gestion de bases de données, qu’ils soient libres (comme MySQL et Firebird) ou

propriétaires (comme Oracle, Sybase, DB2 et Microsoft SQL Server).

de nombreux services du ministère du développement durable.

nous employons une interface utilisateur appelée PgAdmin

13

nstrateur, diffusable librement, comprend un environnement complet sous

dessous), des données et des requêtes ou scripts SQL*

indicateurs et des cartes relatifs d’une part à l’accessibilité

piétonne des réseaux routiers (calculs d’impasses et de mailles), d’autre part à la

fonctionne avec des données réelles provenant du réseau TC Tisseo à

Toulouse, partenaire du projet. La donnée de voirie provient de la base Open Street Map.

La démonstration est destinée aux techniciens des services Transport des

collectivités, et plus généralement aux organismes et prestataires de service travaillant

A terme, l’objectif est de valider l'intérêt des utilisateurs potentiels (collectivités

autorités de transport et autres organismes publics, bureaux d'études) pour une solution

d’analyse de réseaux de

a permis de comprendre rapidement l’objectif de notre projet.

en-Provence et nous a

Il existe deux versions du démonstrateur, la deuxième étant plus particulièrement

est le principal système de gestion de base de données relationnelle

et objet (SGBDRO) open source. Ce système est concurrent d’autres systèmes de

gestion de bases de données, qu’ils soient libres (comme MySQL et Firebird) ou

Sybase, DB2 et Microsoft SQL Server). Il est utilisé par

Afin de travailler sur

PgAdmin III .

14

PostgreSQL dispose d'une extension géographique Postgis, qui a pratiquement le

monopole dans le domaine open source. Cette extension permet le traitement d’objets

spatiaux dans les serveurs PostgreSQL (description de la géométrie d’objets gérés dans

des 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.).

Dans notre étude, nous avons utilisé la version 8.3 de PostgreSQL avec la

version 1.10.2 de PgAdmin III, ainsi que la version 1.3.5 de PostGIS.

2.2.2. Quantum Gis

Qgis ou Quantum GIS de son nom complet, est un SIG libre (open source) qui

sert d’interface graphique simple à PostgreSQL. C'est l'un des projets officiels de la

Fondation Geospatiale Open Source (OSGeo). Il permet de visualiser les objets

géométriques créés dans une base de données en les affichant sous forme de « couches »

superposables.

Nous employons ici la version 1.4.0 « Enceladus » de Qgis.

2.2.3. PgRouting

Comme PostGis, PgRouting est une librairie de fonctions SQL qui constitue une

extension de PostgreSQL. Cette librairie contient l'implémentation des algorithmes

suivants :

- Algorithme Dijkstra : algorithme de recherche de plus court chemin, nommé

ainsi en l'honneur du professeur Dr. Edsger Wybe.

15

- Algorithme A-star (A*) : une heuristique basée sur l'algorithme de plus court

chemin.

- Shooting-star (Shooting*) : algorithme de plus court chemin pour les réseaux

routiers réels avec prise en charge du sens giratoire, des feux et des routes en

sens unique.

- Distance de conduite : indique, pour chaque arc et chaque nœud du graphe, s’il

peut être atteint en moins d’un temps donné, à partir d’un point (nœud) donné.

- TSP : solution au problème du voyageur de commerce.

Cette librairie travaille sur des graphes de réseaux qui doivent être créés au préalable

à partir des données de description de la voirie.

PgRouting est disponible en téléchargement gratuit sur Internet

(http://PgRouting.postlbs.org/wiki/PgRoutingDownload#WindowsBinaries). La version

de PgRouting utilisée sur Windows dans notre étude sera la 1.02.

2.2.4. Sun xVM VirtualBox

Afin de simplifier l’installation et la consultation des données du démonstrateur

SIG libre Toulouse, la solution VirtualBox est mise en oeuvre. VirtualBox est un

logiciel permettant de créer des ordinateurs virtuels, pour ensuite installer des systèmes

d'exploitation invités qui fonctionnent dans le système d'exploitation réel de l’ordinateur.

L’utilisateur doit simplement installer le logiciel VirtualBox sur son poste qui va

utiliser un fichier de données unique fourni avec le démonstrateur, qui contient

l’ensemble des éléments nécessaires à la démonstration (base de données, logiciels,

documents,…), ce qui évite donc d’avoir à tout installer.

16

3. ACCESSIBILITÉ DES RÉSEAUX ROUTIERS AUX

MODES DE DÉPLACEMENT DOUX

L’objectif de cette partie est de mesurer et représenter la facilité pour un piéton ou

un cycliste d’accéder aux réseaux de transport collectif. Pour cela nous nous basons sur

l’idée que plus un îlot* est grand, plus il est long de le contourner à pied ou à vélo et

donc plus il est contraignant d’accéder à un arrêt de bus. L’indicateur est donc le temps

de contournement des îlots ou « pâtés de maisons ». Pour produire des cartes avec cet

indicateur, nous suivrons les étapes suivantes :

- acquisition du réseau de voirie dans une base de données,

- création d’une fonction qui détecte et répertorie les îlots,

- création d’une fonction qui détecte et répertorie les impasses,

- évaluation de la durée de contournement d’un îlot en fonction de son périmètre,

- acquisition du réseau de transport collectif,

- représentation cartographique de l’accessibilité piétonne et cycliste aux réseaux

routiers.

3.1. Création d’une base de données

La conception d’une base de données est l’étape préalable à l’acquisition de données

et à l’exécution de requêtes spatiales. Cette opération ne pose pas de problème majeur, il

faut toute fois prendre soin de bien renseigner les caractéristiques de la base de données

(nom, utilisateur de la base, codage du serveur).

Le chemin de création d’une base de données est le suivant :

PgAdmin III Serveurs PostgreSQL Database Server Bases de données

Ajouter une base de données.

Les données sont en général disponibles au format « .shp » directement

importable en tant que « couche » dans un SIG.

17

Figure 1 : création d’une base de données.

Une fois la base de données créée, nous pouvons transférer nos données dans la base et

commencer le traitement des requêtes spatiales avec PgAdmin.

3.2. Le réseau routier de l’agglomération d’Aix-en-Provence

Deux sources de données de voirie sont à notre disposition. Les données OSM qui

sont intéressantes car modifiables et distribuables librement, et les données IGN, plus

complètes mais non diffusables à l’extérieur.

La première étape consiste à importer la couche de voirie dans une base de données

PostgreSQL afin de pouvoir l’exploiter. Qgis possède un module SPIT « importer des

shapefiles dans PostgreSQL » qui permet sur simple clic de réaliser cette opération.

Cependant la conversion peut être effectuée manuellement à partir d’une ligne de

commande MS-DOS1 via la fonction ogr2ogr2.

Qgis : « ajouter une couche vecteur » sélection des données shapefile

Extension Spit : « Importer des shapes dans PostgreSQL » connexion à la BD

Ajout Table de données PostgreSQL.

Ou bien :

Données shapefiles MS-DOS / ogr2ogr table de données PostgreSQL

1 En réalité SPIT utilise le même logiciel ogr2ogr pour fonctionner. 2 La ligne de commandes est disponible en annexe 1.

18

Figure 2 : fenêtre d’utilisation du module SPIT sur Qgis

Pour une analyse du mode piéton nous utilisons l’ensemble du réseau (routes et

chemins). Le réseau piéton n’étant pas forcément confondu avec le réseau routier

accessible aux voitures, une analyse plus fine impliquerait de supprimer entre autres la

les tronçons autoroutiers du réseau.

3.2.1. Création de la couche OSM d’Aix-en-Provence

La couche voirie d’Aix-en-Provence issue d’OpenStreetMap (OSM) est

disponible au format shapefile (.shp), lisible sur Qgis. Nous avons tout d’abord tenté

d’utiliser le module SPIT pour effectuer la conversion. Cependant un bug dans le

lancement de SPIT (fermeture du programme) nous a contraints à effectuer (avec

ogr2ogr) manuellement la conversion du fichier shapefile en une table de données

« aix ».

Les données correspondent à un petit périmètre sélectionné à la main autour du

centre d’Aix-en-Provence à partir de la couche de la région PACA.

19

Figure 3 : visualisation sur Qgis de la couche du réseau routier d’Aix-en-Provence produit par OSM.

3.2.2. Création de la couche IGN d’Aix-en-Provence

Les données Topo IGN d’Aix-en-Provence sont disponibles au format « .tab »

(Mapinfo) accessible sur Qgis. Nous avons cependant eu besoin de les convertir au

format «.shp » (shapefile) afin de les transférer sur une base de données PostgreSQL

sous forme de table. Pour cela, il suffit d’ouvrir le fichier « .tab » dans Qgis et de le

réenregistrer au format « .shp ».

Les données de l’IGN sont bien plus complètes et précises que celles

d’OpenStreetMap.

Nous avons effectué le transfert vers PostgreSQL via le module SPIT, qui a

correctement fonctionné, après réinstallation des logiciels. La table obtenue sera

nommée « aix_ign » afin de ne pas la confondre avec la table « aix » issue d’OSM.

20

Figure 4 : visualisation sur Qgis de la couche du réseau routier d’Aix-en-Provence produit par l’IGN.

3.3. Mailles et impasses

Par définition, une maille est une liste chaînée d’arcs en boucle, qui part et

aboutit au même nœud. Concrètement, cela pourrait représenter un îlot. La connaissance

du périmètre des mailles est un indicateur important dans notre travail. Elle permet

notamment de se représenter la facilité d’accéder à un arrêt de bus à pied.

3.3.1. Détection des mailles et calcul du périmètre

La requête de création de la couche des mailles s’appuie sur la fonction PostGis

polygonize, qui utilise la couche des routes pour détecter les mailles. Pour le calcul de la

surface et du périmètre nous exécutons les fonctions PostGis area et perimeter3.

Dans un premier temps nous créons une table « maille », comportant les

colonnes « gid » et « géom » permettant d’identifier la maille et d’en définir les

coordonnées, ainsi que les colonnes « surface » et « périmètre » destinées à contenir les

données de surface et de périmètre de chaque maille4.

3 Le script des fonctions est détaillé en annexe 2.II. 4 Le script de la est détaillé en annexe 2.I.

Figure 5

Nous avons tout d’a

mailles (à peine 36) ont été

Provence, rendant inexploitables les données OSM. Cela s’explique par le caractère

« artisanal » du tracé, où les nœuds routiers ne sont pas clairement définis en tant que

tels, et ne sont donc pas reconnus par le programme (cf. la définition d’une maille).

Un « nettoyage

intersections et redéfinition des tronçons. Nous avons testé des requêtes SQL dans ce

but, mais elles n’ont pas pu aboutir. Nous y sommes revenus en fin de stage, avec

succès, mais il était trop tard pour exploiter ces données.

découper tous les tronçons de voirie de sorte que leurs extrémités soient des nœuds du

réseau. Un traitement SQL permet de le faire, mais certains cas particuliers de

configuration géométriq

qualité professionnelle, ne présentent pas ce défaut.

5 : diagramme d’activités de la fonction de recherche des mailles.

Nous avons tout d’abord travaillé avec les données OSM. Cependant, très peu de

ont été matérialisées sur la couche OSM du réseau routier d’

, rendant inexploitables les données OSM. Cela s’explique par le caractère

» du tracé, où les nœuds routiers ne sont pas clairement définis en tant que

tels, et ne sont donc pas reconnus par le programme (cf. la définition d’une maille).

nettoyage » des données doit être fait au préalable

intersections et redéfinition des tronçons. Nous avons testé des requêtes SQL dans ce

mais elles n’ont pas pu aboutir. Nous y sommes revenus en fin de stage, avec

t trop tard pour exploiter ces données. En fait, il s’agissait de

découper tous les tronçons de voirie de sorte que leurs extrémités soient des nœuds du

réseau. Un traitement SQL permet de le faire, mais certains cas particuliers de

configuration géométrique restent toujours à corriger à la main. Les données IGN, de

qualité professionnelle, ne présentent pas ce défaut.

21

: diagramme d’activités de la fonction de recherche des mailles.

Cependant, très peu de

matérialisées sur la couche OSM du réseau routier d’Aix-en-

, rendant inexploitables les données OSM. Cela s’explique par le caractère

» du tracé, où les nœuds routiers ne sont pas clairement définis en tant que

tels, et ne sont donc pas reconnus par le programme (cf. la définition d’une maille).

» des données doit être fait au préalable : recherche des

intersections et redéfinition des tronçons. Nous avons testé des requêtes SQL dans ce

mais elles n’ont pas pu aboutir. Nous y sommes revenus en fin de stage, avec

En fait, il s’agissait de

découper tous les tronçons de voirie de sorte que leurs extrémités soient des nœuds du

réseau. Un traitement SQL permet de le faire, mais certains cas particuliers de

ue restent toujours à corriger à la main. Les données IGN, de

22

Figure 6 : visualisation des mailles (et impasses) d’après les données OSM d’Aix-en-Provence.

Cette opération a donc été reproduite avec les données IGN (finalement utilisées

tout au long des pages qui suivent). Après un calcul de trois minutes, nous obtenons

3403 mailles. Sur Qgis, nous ajustons les propriétés de la couche afin de classer

visuellement les mailles en fonction de leur périmètre (les plus claires correspondant au

plus grandes).

Figure 7 : classement des mailles par quantiles en fonction de leur périmètre, sur Qgis.

23

Le résultat obtenu est bien plus pertinent que le précédent. On en notera la

cohérence : de petites mailles en centre ville contre de grandes surfaces en périphérie.

Figure 8 : aperçu de la couche des mailles issue des données IGN.

3.3.2. Détection des impasses

La recherche des mailles effectuée, il est alors possible de détecter les impasses.

En effet, nous pouvons nous appuyer sur le fait qu’une impasse n’appartient pas au

contour d’une maille. Nous recherchons donc les tronçons ne faisant pas partie des

mailles. Contrairement aux mailles, les impasses ne constituent pas une nouvelle couche,

mais sont un nouvel attribut de la couche voirie.

Pour ce faire, nous insérons une colonne « deadendflags » dans la table de voirie.

Cette colonne doit contenir une donnée booléenne : « true » si le segment concerné est

une impasse, « false » sinon. Nous créons ensuite une fonction de recherche d’impasses

qui remplira cette colonne. Elle sélectionne tour à tour les segments de route et évalue

leur appartenance aux contours des mailles5.

5 La fonction est détaillée en annexe 2.III

Figure 9

Nous remarquerons quelques erreurs dans la couche «

résultat demeure tout à fait satisfaisant.

Figure 10 : détail du centre ville d’

9 : diagramme d’activités de la fonction de recherche d’impasses.

Nous remarquerons quelques erreurs dans la couche « impasses

résultat demeure tout à fait satisfaisant.

: détail du centre ville d’Aix-en-Provence avec les impasses (en rouge) et les voies (en vert).

24

: diagramme d’activités de la fonction de recherche d’impasses.

impasses », cependant le

avec les impasses (en rouge) et les voies (en vert).

3.4. Temps de parcours d’une maille

Figure 11 : superposition des mailles et des impasses dans

A partir de ces éléments,

impasses, sur un territoire donné (par exemple sur une commune, ou sur les zones IRIS

de l’Insee). Par exemple

- taux d’impasses en %

impasses peuvent être pertinentes pour limiter le trafic automobile, elles nuisent

en revanche à la marche à pied)

- valeur minimale, maximale, moyenne, médiane du périmètre des mailles

Ces indicateurs seront calculés sur Excel après importation des tables de notre base de

données.

Il est également possible de créer des indicateurs sur un SIG, en les visualisant sur

des cartes thématiques

- temps nécessaire pour effectuer le tour d’une maille

- temps nécessaire pour effectuer le tour d’une maille à vélo,

- etc…

Temps de parcours d’une maille

: superposition des mailles et des impasses dans l’agglomération d’

A partir de ces éléments, nous pouvons 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). Par exemple :

taux d’impasses en % (plus il y a d’impasses moins l’accessibilité est bonne. Les

impasses peuvent être pertinentes pour limiter le trafic automobile, elles nuisent

en revanche à la marche à pied),

valeur minimale, maximale, moyenne, médiane du périmètre des mailles

cateurs seront calculés sur Excel après importation des tables de notre base de

Il est également possible de créer des indicateurs sur un SIG, en les visualisant sur

des cartes thématiques :

temps nécessaire pour effectuer le tour d’une maille à pied,

temps nécessaire pour effectuer le tour d’une maille à vélo,

25

l’agglomération d’Aix-en-Provence.

calculer des indicateurs sur les mailles et

impasses, sur un territoire donné (par exemple sur une commune, ou sur les zones IRIS

(plus il y a d’impasses moins l’accessibilité est bonne. Les

impasses peuvent être pertinentes pour limiter le trafic automobile, elles nuisent

valeur minimale, maximale, moyenne, médiane du périmètre des mailles.

cateurs seront calculés sur Excel après importation des tables de notre base de

Il est également possible de créer des indicateurs sur un SIG, en les visualisant sur

ied,

temps nécessaire pour effectuer le tour d’une maille à vélo,

3.4.1. Marche à pied

Nous avons ainsi réalisé une

parcours d’un piéton pour faire le tour d’une maille. Cela permet de voir rapidement la

faculté d’accès à un arrêt de bus par exemple. Pour réaliser cette carte, nous avons

utilisé la relation empirique de

Figure 12 : temps de parcours d’un piéton pour effectuer le tour d’une maille

Au-delà de 15 minutes de parcours (mailles en gris), l’accessibilité au réseau de

transport collectif est médiocre.

l’utilisation des transports en commun se situent en grande majorité dans le centre ville

d’Aix-en-Provence. Cette carte constitue donc un bon indicateur pour le développement

de réseaux de transport collectif.

intégrant les données de recensement INSEE

pénalisantes si elles contiennent beaucoup d’habitants ou d’activités

Marche à pied

Nous avons ainsi réalisé une cartographie des mailles représentant le

parcours d’un piéton pour faire le tour d’une maille. Cela permet de voir rapidement la

d’accès à un arrêt de bus par exemple. Pour réaliser cette carte, nous avons

utilisé la relation empirique de 5 minutes pour parcourir 350 mètres

: temps de parcours d’un piéton pour effectuer le tour d’une maille

delà de 15 minutes de parcours (mailles en gris), l’accessibilité au réseau de

transport collectif est médiocre. Nous remarquons que les zones favorables à

l’utilisation des transports en commun se situent en grande majorité dans le centre ville

Cette carte constitue donc un bon indicateur pour le développement

de réseaux de transport collectif. Nous pourrons par la suite affiner cet indicateur en y

intégrant les données de recensement INSEE, en effet les grandes mailles sont surtout

pénalisantes si elles contiennent beaucoup d’habitants ou d’activités

26

représentant le temps de

parcours d’un piéton pour faire le tour d’une maille. Cela permet de voir rapidement la

d’accès à un arrêt de bus par exemple. Pour réaliser cette carte, nous avons

5 minutes pour parcourir 350 mètres (4 km/h).

(détail du centre-ville).

delà de 15 minutes de parcours (mailles en gris), l’accessibilité au réseau de

Nous remarquons que les zones favorables à

l’utilisation des transports en commun se situent en grande majorité dans le centre ville

Cette carte constitue donc un bon indicateur pour le développement

Nous pourrons par la suite affiner cet indicateur en y

, en effet les grandes mailles sont surtout

pénalisantes si elles contiennent beaucoup d’habitants ou d’activités.

3.4.2. Parcours à vélo

Pour les temps de parco

centre ville et campagne. En effet, la Mairie de Paris annonce une vitesse de circulation

d’environ 15 km/h en ville, contre 25 km/h hors agg

donc la relation de 5 minutes pour parcourir 1700 m

Figure 13 : temps de parcours d’un cycliste pour effectuer le tour d’une maille.

Nous remarquons la cohérence de notre carte

d’utilisation d’un vélo. En effet,

inférieurs à 15 minutes.

Cette carte peut servir à l’amélioration du réseau de transport en commun, on voit

notamment qu’il serait intéressant de disposer de parkings à vélo près des arrêts de bus

dans les zones excentrées.

Après exploitation de la carte, on s’aperçoit qu’il serait plus réaliste d’utiliser une

vitesse moyenne de 15 km/h pour les déplacements à vélo.

de tenir compte de la pente, facteur important à Aix

possible avec les données de la BD Topo IGN qui contiennent un attribut «

Parcours à vélo

Pour les temps de parcours à vélo, nous avons choisi une moyenne de 20 km/h entre

centre ville et campagne. En effet, la Mairie de Paris annonce une vitesse de circulation

d’environ 15 km/h en ville, contre 25 km/h hors agglomération (estimé). Nous adoptons

minutes pour parcourir 1700 m.

: temps de parcours d’un cycliste pour effectuer le tour d’une maille.

Nous remarquons la cohérence de notre carte : l’accessibilité s’améliore en cas

d’utilisation d’un vélo. En effet, plus de mailles correspondent à de temps de parcours

inférieurs à 15 minutes.

Cette carte peut servir à l’amélioration du réseau de transport en commun, on voit

notamment qu’il serait intéressant de disposer de parkings à vélo près des arrêts de bus

les zones excentrées.

Après exploitation de la carte, on s’aperçoit qu’il serait plus réaliste d’utiliser une

vitesse moyenne de 15 km/h pour les déplacements à vélo. Il serait également possible

de tenir compte de la pente, facteur important à Aix-en-Provence, ce qui aurait été

possible avec les données de la BD Topo IGN qui contiennent un attribut «

27

urs à vélo, nous avons choisi une moyenne de 20 km/h entre

centre ville et campagne. En effet, la Mairie de Paris annonce une vitesse de circulation

lomération (estimé). Nous adoptons

: temps de parcours d’un cycliste pour effectuer le tour d’une maille.

: l’accessibilité s’améliore en cas

plus de mailles correspondent à de temps de parcours

Cette carte peut servir à l’amélioration du réseau de transport en commun, on voit

notamment qu’il serait intéressant de disposer de parkings à vélo près des arrêts de bus

Après exploitation de la carte, on s’aperçoit qu’il serait plus réaliste d’utiliser une

Il serait également possible

vence, ce qui aurait été

possible avec les données de la BD Topo IGN qui contiennent un attribut « Z ».

28

3.5. Création de la couche réseau transport collectif

Afin de compléter cette étude, nous avons créé une couche des stations et arrêts de

bus à partir d’OSM. Les données disponibles concernant l’ensemble de la région PACA,

il est tout d’abord nécessaire de ne sélectionner que les données utiles. Deux méthodes

peuvent être envisagées : soit la table des arrêts de bus contient un attribut de lieu, dans

ce cas on supprime les lignes ne concernant pas l’agglomération d’Aix-en-Provence (sur

PgAdmin) ; soit on ouvre le fichier des données sur Qgis et on sauvegarde visuellement

la sélection des arrêts intéressants.

L’absence d’un attribut de lieu exploitable nous a orienté vers la seconde méthode.

Nous avons ensuite superposé les couches voirie et transport collectif sur

l’agglomération d’Aix-en-Provence.

Figure 14 : visualisation des arrêts et stations de bus.

Les données OSM sont toutefois incomplètes, car saisies par des bénévoles. Nous

avons également sollicité le Syndicat Mixte des Transports des Bouches-du-Rhône, qui

gère le site d’information www.lepilote.com, qui nous a très gentiment transmis la

couche des points d’arrêts de sont SIG. Malheureusement, elle ne contient pas encore

les arrêts du réseau Aix-en-Provence en bus, mais seulement les arrêts du réseau

d’autocars Cartreize et TER. On pourrait toutefois superposer les deux sources.

29

3.6. Présentation cartographique

Pour concrétiser l’analyse, il est judicieux de superposer les cartes des temps de

parcours à pieds et à vélo à celle des arrêts de transport collectif. Cela fournit un

aperçu de l’accessibilité des réseaux de transport collectif aux modes de

déplacement doux (vélo, marche à pied).

Dans le cas de l’agglomération d’Aix-en-Provence, il apparaît que certains arrêts

de bus ne sont à proximité que de mailles pour lesquelles la durée de contournement

à pieds est supérieure à 15 minutes. Ces arrêts deviennent néanmoins accessibles à

vélo en moins de 15 minutes, ce qui confirme par exemple l’intérêt de disposer de

parkings à vélo près des arrêts.

Dans le but d’affiner cette recherche on pourrait prendre en compte les données

de recensement. Nous aborderons cela par la suite.

Figure 15 : superposition des cartes de temps de parcours à pied et des arrêts de bus (losanges verts).

30

Figure 16 : superposition des cartes de temps de parcours à vélo et des arrêts de bus (losanges verts).

31

4. CARTOGRAPHIE DES VITESSES DE CIRCULATION

Nous nous consacrons dans cette partie à l’accessibilité des véhicules motorisés. Le

but de l’étude est de créer une cartographie du réseau routier où les voies sont

représentées en fonction de la vitesse de circulation. Cette cartographie doit représenter

l’état du réseau en heures creuses et en heure de pointe. Les étapes clés de cette partie

seront les suivantes :

- définition des vitesses moyennes de circulation en heures creuses pour chaque

type de route,

- ajout d’un attribut « vitesses de circulation » à la table de voirie,

- acquisition des données de l’INSEE sur les densités de population,

- ajout d’un attribut « densité de population » à la table de voirie,

- définition des vitesses moyennes de circulation en heure de pointe pour chaque

type de route en fonction de la densité de population,

- ajout d’un attribut « vitesses de circulation en heure de pointe » à la table de

voirie.

4.1. Affectation de la vitesse moyenne en fonction du type de route

La table de voirie issue de la BD Topo IGN offre la possibilité d’affecter des

vitesses en fonction du type de route. En effet, elle contient une colonne « nature » qui

définit pour chaque tronçon le type de route (autoroute, nationale, départementale,

chemin, sentier).

Il s’agit tout d’abord de définir une vitesse moyenne de circulation pour chaque type

de route. Ensuite nous ajouterons ces vitesses à la table de voirie, ce qui permettra de

créer une carte du réseau routier faisant apparaître les vitesses.

Dans la pratique, nous avons commencé par faire un choix arbitraire6, mais espérons

le réaliste, des vitesses de circulation pour chaque type de route :

6 Ce choix de vitesses selon le type de route peut être rendu facilement paramétrable afin de chercher les valeurs qui donnent les résultats les plus réalistes.

TYPE DE ROUTE

Sentier ou escalier

Route empierrée

Chemin

Route à 1 chaussée, en ville

Bretelle

Route à 2 chaussées, en ville

Départementale

Nationale

Autoroute

Figure 17 : choix de la vitesse moyenne

Nous avons ensuite ajouté une colonne «

les vitesses moyennes

Cette opération terminée,

dégradé de couleurs en fonction de la vitesse offre un bon aperçu du réseau

la couleur est sombre, plus la vitesse de circulation est élevée.

Figure 18 : visualisation sur

7 Les scripts des affectations sont détaillés en annexe

TYPE DE ROUTE VITESSE MOYENNE (km/h)

Sentier ou escalier 0

Route empierrée 10

15

Route à 1 chaussée, en ville 20

40

Route à 2 chaussées, en ville 30

Départementale 50

80

100

: choix de la vitesse moyenne de circulation en fonction du type de route

Nous avons ensuite ajouté une colonne « avgspeed » à la table de voirie

s7.

Cette opération terminée, nous visualisons le résultat sur

dégradé de couleurs en fonction de la vitesse offre un bon aperçu du réseau

la couleur est sombre, plus la vitesse de circulation est élevée.

: visualisation sur Qgis de la vitesse moyenne en fonction du type de route.

Les scripts des affectations sont détaillés en annexe 3.IV. 32

MOYENNE (km/h)

en fonction du type de route.

» à la table de voirie qui contiendra

le résultat sur Qgis. Un choix de

dégradé de couleurs en fonction de la vitesse offre un bon aperçu du réseau routier : plus

de la vitesse moyenne en fonction du type de route.

33

Le choix des vitesses ne représente pas avec exactitude l’état du réseau routier

d’Aix-en-Provence. Par exemple, les routes du centre historique d’Aix-en-Provence

sont définies sur la BD Topo IGN comme des routes à une chaussée, sans mention

particulière. Nos affectations n’en tiennent donc pas compte, s’en suit un désaccord

avec la réalité : la circulation dans ce lieu étant beaucoup plus lente en réalité !

4.2. Prise en compte des données du recensement INSEE

Dans la partie précédente, nous avons produit une carte de l’état du réseau routier

dans le cas d’une circulation fluide en agglomération. Cela n’est pas suffisant pour

obtenir un bon aperçu de l’accessibilité au réseau. Pour fournir une cartographie

complète et fiable, il faut y intégrer les variations de vitesse moyenne de circulation en

fonction des heures.

Dans notre étude nous ne traiterons que deux cas : heures creuses et heure de pointe.

Le premier cas correspond au paragraphe précédent. Pour le second, nous allons nous

appuyer sur la connaissance des densités de population dans les différents IRIS de

l’agglomération. En se basant sur l’idée très simplificatrice que les ralentissements se

produisent dans les zones les plus peuplées, nous ne modifierons les vitesses que sur les

routes traversant ces zones8. Il s’agit donc maintenant de :

- obtenir les données adaptées de recensement de population,

- traiter ces données pour obtenir les densités de population et les affecter à la

table de voirie,

- redéfinir les vitesses moyennes de circulation pour chaque type de route,

- ajouter un attribut « vitesses de circulation en heure de pointe » à la table de

voirie.

4.2.1. Acquisition d’une base de données adaptée

Les fichiers de recensement INSEE diffusés sur le web proposent un large panel

de choix de données, qui concernent l’ensemble de la région PACA, divisée en IRIS.

Nous avons ainsi accès à différents classements en fonction de la population prise en

8 En fait il serait sans doute plus judicieux de considérer les densités de chaque commune voire chaque agglomération, car bien sûr une zone IRIS inhabitée (très peu dense) d’une grande ville peut être traversée par des routes encombrées. Néanmoins comme nous n’étudions qu’une seule commune, l’analyse permet de tester la mécanique des traitements.

34

compte (tranches d’âge, population active, catégorie socioprofessionnelle, etc.…). Par

ailleurs nous avons accès à la description géographique des IRIS dans des fichiers

shapefile, ce qui permet de les importer facilement sur PostgreSQL sous forme d’une

nouvelle couche. Une colonne « nom_com » renseigne sur le nom de la commune

concernée par l’IRIS, ce qui permettra par la suite de ne conserver que les données

d’Aix-en-Provence.

Pour nos besoins, nous n’utilisons que la colonne « population totale par IRIS »

dans le fichier de recensement qui répertorie les hommes et les femmes par tranche

d’âge. On pourrait cependant utiliser d’autres données, pour obtenir des indicateurs plus

fins (par exemple : nombre d’employés).

Techniquement, nous avons transféré le fichier shapefile vers une table dans

PostgreSQL grâce à une ligne de commande MS DOS (ce qui évite les bugs du module

SPIT de Qgis). Nous avons ensuite supprimé les lignes ne concernant pas Aix-en-

Provence9, ce qui nous a fourni une table exploitable pour la suite.

Figure 19 : extrait de la table contenant les données de recensement INSEE.

Remarque : la prise en compte du système de référence spatiale (SRS) lors du transfert

est importante. En effet, en vue de superposer les couches (IRIS, réseau routier, mailles,

etc…) il est nécessaire de tout définir dans le même système de coordonnées. Nous

avons choisi d’utiliser les coordonnées WGS 84, format fourni « de base » par OSM.

9 Scripts en annexe 3.I.

4.2.2. Calcul de densité de population p

Le fichier de recensement de l’INSEE

ainsi que le nombre d’habitants par IRIS. Après un calcul de surface sur les IRIS on

évalue la densité de population par IRIS. Ce résultat nous permettra par la suite

d’affecter les densités de population aux tronço

De la même manière que pour les mailles, nous

données INSEE, correspondant à la surface de chaque IRIS. La fonction

PostGis permet le calcul des surfaces

population est inséré dans la table des données INSEE. On lui affecte le résultat du

quotient du nombre total d’habitants

En affichant la couche des données de l’INSEE sur

zones de forte densité (supérieure à 450 habitants au kilomètre carré) correspondent

bien au centre ville d’

Puyricard, Luynes).

habitants à l’hectare (ou plus), les seules qui peuvent justifier des transports plus

« lourds » (tramway ou autre).

Figure 20 : IRIS représentés en fonction de leur

10 Nous travaillons dans le système WGS 84, où les coordonnées sont exprimées en degrés de longitude et latitude. Un calcul de surface simple fournit ST_Transform de PostGis permet de forcer le calcul dans un système de coordonnées métriques (en m²).11

Script détaillé en annexe 3

Calcul de densité de population par IRIS

Le fichier de recensement de l’INSEE nous fournit la géométrie de chaque IRIS

ainsi que le nombre d’habitants par IRIS. Après un calcul de surface sur les IRIS on

évalue la densité de population par IRIS. Ce résultat nous permettra par la suite

d’affecter les densités de population aux tronçons de route.

De la même manière que pour les mailles, nous ajoutons un attribut à la table des

données INSEE, correspondant à la surface de chaque IRIS. La fonction

PostGis permet le calcul des surfaces10. Un dernier attribut destiné à la densité de

population est inséré dans la table des données INSEE. On lui affecte le résultat du

nombre total d’habitants (colonne C1) par la surface de l’IRIS

En affichant la couche des données de l’INSEE sur Qgis nous constatons que les

e densité (supérieure à 450 habitants au kilomètre carré) correspondent

bien au centre ville d’Aix-en-Provence et aux villages périphériques (Les Milles,

Les zones centrales sont encore dix fois plus denses, soit 50

e (ou plus), les seules qui peuvent justifier des transports plus

» (tramway ou autre).

représentés en fonction de leur densité de population (vert : faible densité, violetélevée).

ous travaillons dans le système WGS 84, où les coordonnées sont exprimées en degrés de longitude et latitude. Un calcul de surface simple fournit un résultat dans des unités peu parlantes

de PostGis permet de forcer le calcul dans un système de coordonnées métriques (en m²).détaillé en annexe 3.I.

35

nous fournit la géométrie de chaque IRIS

ainsi que le nombre d’habitants par IRIS. Après un calcul de surface sur les IRIS on

évalue la densité de population par IRIS. Ce résultat nous permettra par la suite

ajoutons un attribut à la table des

données INSEE, correspondant à la surface de chaque IRIS. La fonction AREA de

. Un dernier attribut destiné à la densité de

population est inséré dans la table des données INSEE. On lui affecte le résultat du

(colonne C1) par la surface de l’IRIS11.

nous constatons que les

e densité (supérieure à 450 habitants au kilomètre carré) correspondent

et aux villages périphériques (Les Milles,

Les zones centrales sont encore dix fois plus denses, soit 50

e (ou plus), les seules qui peuvent justifier des transports plus

: faible densité, violet : densité

ous travaillons dans le système WGS 84, où les coordonnées sont exprimées en degrés de longitude et nités peu parlantes. La fonction

de PostGis permet de forcer le calcul dans un système de coordonnées métriques (en m²).

36

4.3. Réévaluation des vitesses moyennes en heure de pointe

A présent la table des données de l’INSEE contient les densités de population

pour chaque IRIS. L’objectif est désormais d’ajouter un attribut « vitesse de circulation

en heure de pointe » à la table de voirie, qui dépendra des données de l’INSEE. Pour

cela plusieurs étapes sont nécessaires :

- définir de nouvelles vitesses de circulation correspondant aux heures de pointe,

- évaluer, pour chaque tronçon de route, quel est l’IRIS majoritairement traversé,

- attribuer aux tronçons de nouvelles vitesses selon la densité de population de la

zone où ils se situent.

4.3.1. Ralentissements en zones de forte densité de population

Nous avons défini arbitrairement l’ampleur des ralentissements sur une route qui

appartient à un IRIS de population dense. La Figure 21 représente le choix des vitesses

moyennes de circulation en heure de pointe :

TYPE DE ROUTE VITESSE MOYENNE (km/h)

Sentier ou escalier 0

Route empierrée 10

Chemin 15

Route à 1 chaussée, en ville 10

Bretelle 20

Route à 2 chaussées, en ville 15

Départementale 25

Nationale 40

Autoroute 50

Figure 21 : choix de la vitesse moyenne en fonction du type de route en heure de pointe.

Cependant ce choix pourrait être affiné par la prise en compte d’autres

paramètres pour définir les vitesses. En effet, le classement administratif de la route ne

détermine pas à lui seul la vitesse de circulation.

4.3.2. Affectation des nouvelles vitesses

Le travail consiste

différents IRIS. Cela permettra par la suite d’affecter les nouvelles vitesses seulement

aux tronçons concernés par de fortes densités de populations.

Dans la pratique, il s’agit de comparer les

les routes et les différents îlots IRIS. Le polygone le plus grand pour une route donnée

détermine le choix de l’IRIS influ

vitesse de circulation est enregistrée.

Figure 22 : diagramme d’activités de la fonction d’affectation des densités de population aux routes.

Deux fonctions ont été envisagées

Dans la première12

table l’ensemble des IRIS

grâce à la fonction Intersection

proche. La fonction max

renvoie ensuite la surface maximale, dont on déduit l’IRIS majoritairement traversé par

la route. On affecte ensuite une vitesse de circulation amoindrie si l’IRIS

majoritairement traversé possède une densité supérieure à 450 hab

carré.

Cette opération s’avère très lourde et demanderait plus d’une journée de calculs sur

PgAdmin. A l’échelle de la France entière cette méthode est inapplicable

donc créé une nouvelle fonction

On commence par sélectionner un tronçon de route, puis on calcule la longueur de

12

L’ensemble du script est détaillé en annexe 313

L’ensemble du script est détaillé

Affectation des nouvelles vitesses

Le travail consiste ensuite à définir l’appartenance majoritaire des routes aux

Cela permettra par la suite d’affecter les nouvelles vitesses seulement

aux tronçons concernés par de fortes densités de populations.

Dans la pratique, il s’agit de comparer les longueurs des lignes

les routes et les différents îlots IRIS. Le polygone le plus grand pour une route donnée

ermine le choix de l’IRIS influent : si l’IRIS est très peuplé, une nouvelle valeur de

vitesse de circulation est enregistrée.

: diagramme d’activités de la fonction d’affectation des densités de population aux routes.

ont été envisagées :

12, on utilise la fonction Intersects de PostGis

table l’ensemble des IRIS proches de chaque route. Pour une route donnée,

Intersection la longueur commune entre la route et chaque îlot IRIS

max associée à group by (qui permet de sélectionner une seule route)

renvoie ensuite la surface maximale, dont on déduit l’IRIS majoritairement traversé par

On affecte ensuite une vitesse de circulation amoindrie si l’IRIS

majoritairement traversé possède une densité supérieure à 450 hab

Cette opération s’avère très lourde et demanderait plus d’une journée de calculs sur

. A l’échelle de la France entière cette méthode est inapplicable

donc créé une nouvelle fonction13 dans laquelle est effectuée une boucle sur les routes.

On commence par sélectionner un tronçon de route, puis on calcule la longueur de

L’ensemble du script est détaillé en annexe 3.II. L’ensemble du script est détaillé en annexe 3.III.

37

ir l’appartenance majoritaire des routes aux

Cela permettra par la suite d’affecter les nouvelles vitesses seulement

gnes d’intersection entre

les routes et les différents îlots IRIS. Le polygone le plus grand pour une route donnée

: si l’IRIS est très peuplé, une nouvelle valeur de

: diagramme d’activités de la fonction d’affectation des densités de population aux routes.

de PostGis qui fournit dans une

chaque route. Pour une route donnée, on calcule

commune entre la route et chaque îlot IRIS

ectionner une seule route)

renvoie ensuite la surface maximale, dont on déduit l’IRIS majoritairement traversé par

On affecte ensuite une vitesse de circulation amoindrie si l’IRIS

majoritairement traversé possède une densité supérieure à 450 habitants au kilomètre

Cette opération s’avère très lourde et demanderait plus d’une journée de calculs sur

. A l’échelle de la France entière cette méthode est inapplicable. Nous avons

quelle est effectuée une boucle sur les routes.

On commence par sélectionner un tronçon de route, puis on calcule la longueur de

l’intersection entre la route et les IRIS en contact. Grâce à des tables temporaires, on

stocke pour chaque surface la densité

recherche la surface maximale et on affecte la densité de population associée à la table

de voirie dans une nouvelle colonne

au tronçon suivant. Cette opérat

précédente : le résultat fut obtenu en 55 minutes

Figure 23 : représentation des routes en fonction de la densité de population de l’IRIS qu’elles traversent.

Il ne reste plus qu’à affecter les nouvelles vitesses aux tronçons concernés. Nous

ajoutons pour cela une colonne

modification de la vitesse moyenne de circulation

14 Ce calcul demeure long. Il pourrait cependant être optimisé par un spécialiste (tailles mémoire, buffer, indexes…). 15 Cela permet de superposer les cartes heures creuses et heures de pointe, en mettant en évidence les ralentissements. Les scripts des affectations sont détaillés en annexe

l’intersection entre la route et les IRIS en contact. Grâce à des tables temporaires, on

stocke pour chaque surface la densité de population de l’IRIS correspondant. Enfin on

recherche la surface maximale et on affecte la densité de population associée à la table

de voirie dans une nouvelle colonne. Après avoir vidé les tables temporaires, on passe

au tronçon suivant. Cette opération s’effectue beaucoup plus rapidement que la

: le résultat fut obtenu en 55 minutes14.

eprésentation des routes en fonction de la densité de population de l’IRIS qu’elles traversent.

qu’à affecter les nouvelles vitesses aux tronçons concernés. Nous

tons pour cela une colonne à la table de voirie que nous renseignons lorsqu’il y a

modification de la vitesse moyenne de circulation15.

long. Il pourrait cependant être optimisé par un spécialiste (tailles mémoire, buffer,

Cela permet de superposer les cartes heures creuses et heures de pointe, en mettant en évidence les s scripts des affectations sont détaillés en annexe 3.IV.

38

l’intersection entre la route et les IRIS en contact. Grâce à des tables temporaires, on

de population de l’IRIS correspondant. Enfin on

recherche la surface maximale et on affecte la densité de population associée à la table

. Après avoir vidé les tables temporaires, on passe

ion s’effectue beaucoup plus rapidement que la

eprésentation des routes en fonction de la densité de population de l’IRIS qu’elles traversent.

qu’à affecter les nouvelles vitesses aux tronçons concernés. Nous

à la table de voirie que nous renseignons lorsqu’il y a

long. Il pourrait cependant être optimisé par un spécialiste (tailles mémoire, buffer,

Cela permet de superposer les cartes heures creuses et heures de pointe, en mettant en évidence les

39

4.4. Présentation cartographique

Figure 24 : mise en évidence des zones de ralentissement en heure de pointe (en rouge).

Remarque : Il est intéressant de reporter les densités de population sur les mailles. Pour

cela le même type de calcul s’applique16.

16 Voir annexe 3.V.

A partir de ces données il devient possible d’établir une carte croisée du temps

nécessaire à un piéton pour faire le tour d’une maille et de la densité

maille. C’est un bon indicateur de la qualité piétonne d’un quartier

peuplées sont d’autant plus

d’accéder aux transports collectifs).

On pourrait améliorer cela en prenant en compte les mailles urba

d’emploi est supérieure au seuil (en effet certaines zones

n’ont pas d’habitants mais doivent être considérées comme denses). Cela permet

d’attirer l’attention sur l’ensemble des mailles «

a de nombreux déplacements de population.

n’est pas la plus parlante pour ce type d’études.

densité au sein d’une même agglomération, il n’a pas lieu de modifie

circulation. A plus grande échelle, il serait plus intéressant d’utiliser un découpage en

communes.

Figure 25 : densité de population par maille.

A partir de ces données il devient possible d’établir une carte croisée du temps

nécessaire à un piéton pour faire le tour d’une maille et de la densité

indicateur de la qualité piétonne d’un quartier

peuplées sont d’autant plus « praticables » qu’elles ont un maillage serré

d’accéder aux transports collectifs).

On pourrait améliorer cela en prenant en compte les mailles urba

supérieure au seuil (en effet certaines zones d’emploi ou de commerces

n’ont pas d’habitants mais doivent être considérées comme denses). Cela permet

d’attirer l’attention sur l’ensemble des mailles « à problème », trop gr

a de nombreux déplacements de population. Remarquons de plus que la notion d

la plus parlante pour ce type d’études. En effet, entre deux zones de forte

densité au sein d’une même agglomération, il n’a pas lieu de modifie

A plus grande échelle, il serait plus intéressant d’utiliser un découpage en

40

A partir de ces données il devient possible d’établir une carte croisée du temps

nécessaire à un piéton pour faire le tour d’une maille et de la densité de population par

indicateur de la qualité piétonne d’un quartier. Les zones fortement

qu’elles ont un maillage serré (facilité

On pourrait améliorer cela en prenant en compte les mailles urbaines dont la densité

d’emploi ou de commerces

n’ont pas d’habitants mais doivent être considérées comme denses). Cela permet

», trop grandes alors qu’il y

marquons de plus que la notion d’IRIS

En effet, entre deux zones de forte

densité au sein d’une même agglomération, il n’a pas lieu de modifier la vitesse de

A plus grande échelle, il serait plus intéressant d’utiliser un découpage en

Figure 26 : détail du centre d’

: détail du centre d’Aix-en-Provence. En rouge : mailles dont la densité de population est supérieureà 450 hab./km².

41

: mailles dont la densité de population est supérieure

42

5. INDICATEURS DE PROXIMITÉ

Nous nous consacrons maintenant aux indicateurs de proximité. Grâce aux cartes

établies dans les chapitres précédents, nous allons étudier les fonctionnalités de

PgRouting et les exploiter afin de fournir des renseignements de proximité des points

d’intérêt (POI) et des transports collectifs (TC). Ces renseignements prendront la forme

d’isochrones de 5, 10 et 15 minutes centrées sur les POI et les arrêts TC. Elles prendront

en compte le moyen de déplacement (piéton, vélo, véhicule à moteur) et la congestion

(pour les véhicules à moteur). Cela sera le résultat des phases de travail suivantes :

- installation de PgRouting et test sur un échantillon adapté,

- modification de la table des données de voirie IGN pour y appliquer les

fonctions de PgRouting,

- calcul d’isochrones de 5, 10 et 15 minutes pour comparer les différents modes

de déplacement,

- évaluation des temps de parcours sur l’ensemble du réseau de voirie, depuis un

lieu choisi,

- présentation cartographique des résultats,

- calcul de scores.

5.1. Installation et test de PgRouting

PgRouting contient toutes les fonctions qui seront nécessaires aux calculs

d’indicateurs de proximité.

Après téléchargement sur Internet, on obtient d’une part un ensemble de fichiers .dll

à insérer dans le System 32 de Windows, d’autre part les requêtes SQL qui créent les

différentes fonctions de PgRouting. Ces étapes effectuées, nous avons directement accès

aux fonctions dans PgAdmin.

Afin de tester PgRouting sans risquer d’endommager les données de la base de

données, nous créons une nouvelle base de données test. Nous y affectons un

échantillon de données constituant un schéma simple de voirie (Figure 27), fourni avec

PgRouting sur le site de téléchargement.

43

Figure 27 : extrait de réseau routier.

Les fonctions de PgRouting sont transférées dans les bases de données

(principale et test) via une commande MS-DOS17.

Pour tester le bon fonctionnement de PgRouting, nous exécutons deux fonctions

sur des échantillons :

- La fonction « shooting* » permet de calculer le plus court chemin d’un point à

l’autre en tenant compte des sens uniques et du sens de circulation dans les

ronds-points. Après avoir exécuté la fonction sur l’échantillon test, nous

obtenons une table dont le résultat est visualisable sur Qgis.

Figure 28 : visualisation du plus court chemin sur Qgis.

- La fonction « driving_distance » permet quant à elle de sélectionner l’ensemble

des intersections ou des tronçons qui se trouvent dans un périmètre choisi autour

d’un point donné. Nous l’avons exécutée sur un échantillon plus complet issu

des données de voirie OSM.

17 Les lignes de commandes MS DOS correspondantes figurent annexe 4.I.

Figure 29 : ensemble des intersections (en bleu) situés dans un périmètre d’un kilomètre autour d’un point

Figure 30 : diagramme d’activités de la fonction

5.2. Adaptation de la table de voirie IGN aux fonctions de

Afin d’assurer une continuité dans notre travail, nous avons choisi de poursuivre

l’exploitation du réseau de voirie IGN. Cependant les fonctions de

rédigées pour travailler à partir de colonnes spécifiques issues de la table de voirie

(coordonnées des intersections «

des tronçons, etc…) ainsi que d’une table répertoriant toutes les intersections (ou

nœuds).

Le programme

manquantes à la table de voirie.

: ensemble des intersections (en bleu) situés dans un périmètre d’un kilomètre autour d’un point choisi (en vert et noir).

: diagramme d’activités de la fonction driving_distance de

Adaptation de la table de voirie IGN aux fonctions de PgRouting

Afin d’assurer une continuité dans notre travail, nous avons choisi de poursuivre

xploitation du réseau de voirie IGN. Cependant les fonctions de

rédigées pour travailler à partir de colonnes spécifiques issues de la table de voirie

(coordonnées des intersections « source » et « cible » des tronçons de route, longueur

tronçons, etc…) ainsi que d’une table répertoriant toutes les intersections (ou

osm2PgRouting permet de créer directement les colonnes

manquantes à la table de voirie. Il requiert un fichier au format OpenStreetMap (.osm)

44

: ensemble des intersections (en bleu) situés dans un périmètre d’un kilomètre autour d’un point

de PgRouting.

PgRouting

Afin d’assurer une continuité dans notre travail, nous avons choisi de poursuivre

xploitation du réseau de voirie IGN. Cependant les fonctions de PgRouting sont

rédigées pour travailler à partir de colonnes spécifiques issues de la table de voirie

» des tronçons de route, longueur

tronçons, etc…) ainsi que d’une table répertoriant toutes les intersections (ou

de créer directement les colonnes

requiert un fichier au format OpenStreetMap (.osm)

45

en entrée. Nous avons donc converti le fichier de données IGN18 au format « .osm »

grâce au programme shp2osm.

Cependant, l’utilisation de osm2PgRouting se révèle infructueuse dès lors que l’on

utilise un fichier trop « lourd » et nécessitant beaucoup de mémoire. Nous n’avons pas

réussi à ajouter les colonnes voulues dans la table de voirie, via cette méthode.

Il est néanmoins possible de contourner cette difficulté en créant manuellement les

colonnes supplémentaires.

Notre objectif étant de produire des indicateurs de temps (isochrones), seule la

fonction driving_distance sera utilisée. En effet, connaissant les vitesses de circulation

et les longueurs des tronçons nous pouvons aisément évaluer les temps de parcours.

Cette fonction doit pouvoir accéder aux données de début, fin et longueur des tronçons

et intersections dans le réseau de voirie. Nous avons pour cela employé les fonctions

ST_StartPoint, ST_EndPoint et ST_Length de PostGis19.

Nous avons ensuite effectué un test de driving_distance sur les données IGN

adaptées :

Figure 31 : ensemble des intersections (en vert) se trouvant à une distance de 5 km d’un point de départ choisi

(en rose). 18 Ces données sont fournies au format « .tab » issu du logiciel MapInfo, pour les besoins de notre étude nous les avons converties préalablement au format shapefile « .shp ». 19 Détail en annexe 4.II.

46

5.3. Calcul d’isochrones pour différents modes de déplacement

Le but de cette partie est de fournir des isochrones de 5, 10 et 15 minutes,

superposées pour comparer les modes de déplacement piéton, vélo ou voiture (en

tenant compte des heures creuses et heures de pointe). Il s’agit également de fournir

des cartes pour chaque mode de déplacement, représentant les temps de parcours

vers différents points depuis un lieu donné.

Le calcul d’isochrones se base sur l’utilisation de la fonction driving_distance de

PgRouting. Pour cela nous allons utiliser une entrée temporelle à la place de l’entrée

« distance » attendue par driving_distance. Les étapes successives de notre travail

seront :

- ajout des colonnes des différents temps de parcours par tronçon en fonction de la

vitesse,

- exécution de la fonction driving_distance à partir d’un lieu choisi pour créer les

isochrones,

- création des polygones convexes représentant les isochrones,

- utilisation de la fonction driving_distance pour déterminer les temps de parcours

sur l’ensemble du réseau de voirie, depuis un lieu choisi, dans un mode de

déplacement donné,

- présentation cartographique.

5.3.1. Nouvelles entrées pour la fonction driving_distance

La fonction driving_distance est conçue à l’origine pour utiliser une entrée de

distance (longueur de tronçon) en kilomètres. Elle restitue une table contenant

l’ensemble des intersections se trouvant à une distance donnée d’un point choisi

(isodistance). Nous exploitons cette fonctionnalité pour produire des isochrones. Il suffit

pour cela de modifier l’entrée afin qu’elle représente le temps de parcours par tronçon.

Techniquement, il s’agit de créer quatre nouvelles colonnes contenant les temps

de parcours par tronçon pour chacun des quatre modes de déplacement. On affecte à ces

colonnes le rapport de la longueur du tronçon par la vitesse de déplacement sur ce

même tronçon. On exécutera ensuite driving_distance à partir de l’une de ces colonnes20.

20 Script en annexe 4.III.

47

5.3.2. Polygones isochrones

La fonction driving_distance fournit une table des nœuds (intersections)

accessibles dans un temps choisi depuis un point donné.

Il ne reste ensuite plus qu’à créer le plus petit polygone convexe contenant

l’ensemble de ces nœuds, ce que permet la fonction ST_ConvexHull de PostGis21.

5.3.3. Temps de parcours depuis un lieu choisi

Le but de ce paragraphe est de produire une carte des intersections représentant

la durée nécessaire pour y accéder depuis un lieu donné.

La fonction driving_distance crée une colonne « cost » qui contient pour chaque

nœud le temps de parcours entre celui-ci et un lieu choisi. Il suffit ensuite d’afficher les

nœuds selon la caractéristique « cost » dans Qgis.

Il est également possible de produire le même type de données concernant les

tronçons à la place des nœuds. Pour cela, on affectera au tronçon la valeur moyenne des

durées « cost » attribuées aux points début (« source ») et fin (« target ») du tronçon22.

5.3.4. Présentation cartographique

Les isochrones permettent de comparer les différents modes de déplacement

dans un lieu donné, à une heure donnée. Pour l’illustrer, nous avons pris l’exemple du

centre-ville : on voit clairement sur la carte que le déplacement en vélo en heure de

pointe est plus intéressant que le déplacement en voiture.

Remarquons que le résultat est améliorable par la prise en compte d’autres

paramètres. Il serait effectivement judicieux de moduler la vitesse de déplacement à

vélo en fonction du lieu (centre-ville, périphérie), de prendre en compte les sens uniques,

les feux tricolores, ainsi que le dénivelé23 (ce qui demande de créer un graphe

bidirectionnel).

21 Annexe 4.IV. 22 Annexe 4.V. 23 Le dénivelé est disponible dans la BD Topo IGN, sous forme d’altitude des points de début et fin des tronçons de route.

48

Figure 32 : comparaison des isochrones de 10 minutes pour les différents modes de déplacement.

Grâce aux isochrones, il est également possible de comparer les résultats pour un

mode de déplacement donné avec différents temps de parcours. Cela permettra par la

suite d’établir des « scores » renseignant sur l’accessibilité des transports collectifs et

points d’intérêt à partir de lieux choisis.

Figure 33 : isochrones 5, 10 et 15 minutes pour un déplacement en voiture en heures creuses (à gauche) et

piéton (à droite).

Les « coûts » affectés aux intersections par la fonction

le temps nécessaire pour y accéder depuis un lieu choisi.

cette donnée permet de renseigner un utilisateur sur le temps requis pour se rendre à

n’importe quel autre endroit. En croisant cette carte avec celle des POI

collectifs, l’utilisateur peut rapidement visualiser

terme de temps de parcours, selon son mode de déplacement.

Figure 34 : intersections du réseau de voirie d’Aix

5.4. Calcul de scores

À l’image du site

choisi, en fonction des POI situés autour, nous nous concentrons à présent sur

l’attribution de scores aux isochrones.

» affectés aux intersections par la fonction driving_distance

le temps nécessaire pour y accéder depuis un lieu choisi. La carte produite à partir de

cette donnée permet de renseigner un utilisateur sur le temps requis pour se rendre à

n’importe quel autre endroit. En croisant cette carte avec celle des POI

collectifs, l’utilisateur peut rapidement visualiser la proximité des sites d’intérêts en

terme de temps de parcours, selon son mode de déplacement.

intersections du réseau de voirie d’Aix-en-Provence en fonction des temps de parcours en voiture aux heures creuses depuis le centre-ville (rond vert).

de scores

À l’image du site www.walkscore.com qui fournit une note sur la qualité d’un lieu

choisi, en fonction des POI situés autour, nous nous concentrons à présent sur

l’attribution de scores aux isochrones.

49

driving_distance donnent

La carte produite à partir de

cette donnée permet de renseigner un utilisateur sur le temps requis pour se rendre à

n’importe quel autre endroit. En croisant cette carte avec celle des POI ou des transports

la proximité des sites d’intérêts en

temps de parcours en voiture

qui fournit une note sur la qualité d’un lieu

choisi, en fonction des POI situés autour, nous nous concentrons à présent sur

Figure 35 : exemple de mesure

Le but est de calculer le nombre de POI et arrêts de TC contenus dans les différents

polygones isochrones établis dans le paragraphe précédent.

En pratique nous définissons une fonction qui

avec la géométrie d’un polygone isochrone choisi. Un compteur est incrémenté à

chaque fois que le POI (respectivement l’arrêt TC) est contenu dans l’isochrone.

résultat est ensuite visible dans une table de données sur

Figure

mesure de « qualité piétonne » sur le cours Mirabeau à AixWalkscore.com.

Le but est de calculer le nombre de POI et arrêts de TC contenus dans les différents

polygones isochrones établis dans le paragraphe précédent.

En pratique nous définissons une fonction qui compare la position des POI et TC

avec la géométrie d’un polygone isochrone choisi. Un compteur est incrémenté à

chaque fois que le POI (respectivement l’arrêt TC) est contenu dans l’isochrone.

résultat est ensuite visible dans une table de données sur PostgreSQL

Figure 36 : diagramme d’activités de la fonction de calcul de scores.

50

urs Mirabeau à Aix-en-Provence, avec le site

Le but est de calculer le nombre de POI et arrêts de TC contenus dans les différents

compare la position des POI et TC

avec la géométrie d’un polygone isochrone choisi. Un compteur est incrémenté à

chaque fois que le POI (respectivement l’arrêt TC) est contenu dans l’isochrone. Le

PostgreSQL.

diagramme d’activités de la fonction de calcul de scores.

Nous avons testé la fonction sur un polygone isochrone de 5 minutes pour un

déplacement à vélo en centre ville d’Aix

et les POI ont été comptés.

Figure 37 : nombre d’arrêts de bus (avant dernière colonne) et de POI (dernière colonne) situés

La validité du résultat

polygone isochrone choisi

Figure 38 : arrêts de bus et isochrone de 5 minutes

On pourrait envisager

des arrêts TC pour visualiser la qualité des quartiers en termes de POI. Il serait

également possible de «

puisse par exemple a

Nous avons testé la fonction sur un polygone isochrone de 5 minutes pour un

déplacement à vélo en centre ville d’Aix-en-Provence. Les arrêts de t

et les POI ont été comptés.

: nombre d’arrêts de bus (avant dernière colonne) et de POI (dernière colonne) situés minutes à vélo du centre ville d’Aix-en-Provence.

La validité du résultat peut être testée en superposant la carte des arrêts de bus au

polygone isochrone choisi :

: arrêts de bus et isochrone de 5 minutes à vélo à partir du centre-ville d’Aix

On pourrait envisager à partir des fonctions établies, de créer des isochrones à partir

des arrêts TC pour visualiser la qualité des quartiers en termes de POI. Il serait

également possible de « trier » les points d’intérêt par nature pour qu’un utilisateur

puisse par exemple accéder à l’ensemble des restaurants situés autour de son lieu de

51

Nous avons testé la fonction sur un polygone isochrone de 5 minutes pour un

Provence. Les arrêts de transport collectif

: nombre d’arrêts de bus (avant dernière colonne) et de POI (dernière colonne) situés de 0 à 5

peut être testée en superposant la carte des arrêts de bus au

ville d’Aix -en-Provence.

à partir des fonctions établies, de créer des isochrones à partir

des arrêts TC pour visualiser la qualité des quartiers en termes de POI. Il serait

» les points d’intérêt par nature pour qu’un utilisateur

ccéder à l’ensemble des restaurants situés autour de son lieu de

52

travail. OpenStreetMap propose déjà dans ses données un classement par nature des POI,

qui permettrait d’affiner notre travail dans cette direction.

53

6. UTILISATION ET GÉNÉRALISATION DES

PROCÉDURES

Ce chapitre se veut un condensé des spécifications fonctionnelles et techniques

utilisées dans notre travail, adaptable à d’autres données pour l’analyse géographique

des réseaux de voirie et transport collectif. Ainsi, cette partie peut présenter une certaine

redondance dans la rédaction de ce rapport. Cependant, le but reste de créer un tutoriel

accessible à toute personne désirant réaliser le même traitement sur les données d’autres

villes.

La majorité des requêtes est présentée en annexe. La syntaxe de couleur verte est

réutilisable, il suffit de remplacer les caractères en bleu par les titres, noms et références

choisis par l’utilisateur.

Nous reprendrons les points suivants :

- installation des logiciels,

- accès aux données,

- conversion des données dans les formats adaptés,

- création de la base de données,

- import des données vers la BD et vérification,

- ajout des colonnes et des tables nécessaires,

- création et exécution des fonctions,

- calcul d’indicateurs.

6.1. Installation des logiciels

6.1.1. PostgreSQL

Manuel utilisateur : http://www.PostgreSQL.org/docs/8.3/static/index.html

Installation à partir de PostgreSQL-8.3.msi.

54

6.1.2. Postgis

Installation à l’aide du Stack Builder PostgreSQL (constructeur de la pile applicative) :

L'installation de Qgis et de PgAdmin se fait de manière tout-à-fait classique sous

Windows. Les manuels d'utilisation sont ensuite disponibles aux adresses suivantes :

- http://www.PgAdmin.org/docs/1.10/using.html

- http://www.Qgis.org/fr/documentation/manuels.html

55

Configuration de connexion entre PgAdmin et PostgreSQL :

Enfin, pour installer FWTools, il suffit de copier le dossier FWTools2.4.3 dans le

dossier Program files. Et pour toute utilisation de cet outil (notamment la fonction

ogr2ogr), il est impératif de spécifier le chemin d'accès à FWTools dans MS-DOS : path

%PATH% ;C :\Program files\FWTools2.4.3\bin

6.2. Accès aux données

Il est important de signaler que ce tutoriel n'est ré-exploitable qu'avec des

données INSEE et des données IGN, qui ont été obtenues par l'intermédiaire de licences

payantes. Cependant, il est possible d’adapter cette routine à des données IGN Géofla,

pouvant remplacer celles de l'INSEE, et à des données OSM, à la place de la BD Topo

IGN.

6.3. Conversion des données dans les formats adaptés

Les données Topo IGN d’Aix-en-Provence sont disponibles au format « .tab »

(Mapinfo) accessible sur Qgis. Il est nécessaire de les convertir au format «.shp »

(shapefile) afin de les transférer sur une base de données PostgreSQL sous forme de

table. Pour cela, il suffit d’ouvrir le fichier « .tab » dans Qgis et de le ré-enregistrer au

format « .shp ».

56

Les données INSEE des contours des IRIS sont directement fournies au format .shp.

Il faut fusionner les tables Excel du recensement (correctement choisies) avec le contour

des IRIS pour obtenir un fichier exploitable. (Remarque : l'étape 6 de ce tutoriel détaille

l’utilisation de ces données déjà fusionnées, notamment à l'aide de l'annexe 3.1)

Les données OSM comportent plusieurs fichiers .shp, dont un qui regroupe tous les

points d'intérêt de la région PACA. C'est pourquoi, sous Qgis, il est possible de ne

sélectionner que la région désirée, avant de réexporter le résultat dans un nouveau .shp.

De la même manière, on peut ne récupérer que les arrêts et stations de bus.

6.4. Création de la base de données

Sur PgAdmin : création de l’utilisateur « cete » et de la BD « CETE » :

Attention de sélectionner le bon jeu de caractères (LATIN1 ou bien UTF8 selon le cas),

pour bien gérer les accents.

57

Ajout de la composante spatiale à la base de données (conformément à

http://www.bostongis.com/PrinterFriendly.aspx?content_name=postgis_tut01) :

Dans la fenêtre d’édition des requêtes, créer le language plpgsql : « create language

plpgsql »

Cliquer sur la flèche verte

Ouvrir le fichier C:\Program Files\PostgreSQL\8.3\share\contrib\lwpostgis.sql

Cliquer sur

Ouvrir le fichier C:\Program Files\PostgreSQL\8.3\share\contrib\spatial_ref_sys.sql.

A la fin du fichier sql, supprimer la ligne VACUUM ANALYZE spatial_ref_sys;

Cliquer sur

6.5. Import des données vers la BD et vérification

Pour importer les données dans la base de données précédemment créée, il suffit

d’utiliser la ligne de commande DOS disponible en annexe 1. En effet, le plugin SPIT

de Qgis renvoie souvent des erreurs. Ainsi, en adaptant ces lignes de commande DOS

58

aux noms d’utilisateur PostgreSQL, aux noms de base de données et de fichier .shp, il

sera possible d’importer les données provenant des BD topo IGN et INSEE dans deux

nouvelles tables qui porteront automatiquement les noms respectifs des fichiers .shp.

Remarque : Si les données ne se superposent pas dans Qgis, cela peut être dû à une

différence au niveau du système spatial de référence (SRS, en anglais). Il faut donc

modifier les colonnes de type « geometry » des tables afin de tout convertir dans le

système WGS84 (GPS, EPSG : 4326). Pour ce faire, on utilise la requête suivante :

UPDATE <Votre_table> SET <Votre_colonne_géométrie> = select ST_setsrid(<Votre_colonne_géométrie>,4326);

UPDATE <Votre_table> SET <Votre_colonne_géométrie> = select ST_transform(<Votre_colonne_géométrie>,4326);

6.6. Ajout des colonnes et des tables nécessaires

La première étape consiste en la création d’une table répertoriant les mailles du

réseau de voirie et d’une colonne supplémentaire dans cette dernière indiquant si la

route correspondante est une impasse ou non. Les scripts nécessaires sont présentés en

annexe 2.

La seconde étape va permettre d’affecter une densité de population à chaque route

afin de pouvoir par la suite y associer une vitesse moyenne de circulation (en

différenciant les heures creuses et les heures de pointe). On utilisera les annexes 3.1 et

3.3.

Le moyen d’affecter les vitesses moyennes choisies pour représenter l’état du réseau

routier, en heures creuses et heures de pointe, est précisé en annexe 3.4.

Enfin, il est nécessaire d’ajouter les éléments indispensables à l’utilisation de la

fonction driving_distance de PgRouting. Les scripts sont présents en annexe 4.2 et 4.3.

Ils permettent d’utiliser la fonction sur une base de temps et non de distance.

6.7. Création et exécution des fonctions

Pour ajouter les fonctions de PgRouting à la base de données, notamment la

focntion driving_distance, il est possible d’utiliser la commande DOS présente en

annexe 4.1, après avoir copié le contenu du dossier \logiciels\PgRouting-1.02_pg-

8.3.3\PgRouting-1.02_pg-8.3.3 dans le répertoire C :\Program Files\PostgreSQL\8.3.

Enfin, un exemple de calcul d’isochrones (correspondant à un point, une durée de

parcours et un mode de déplacement) se situe en annexe 4. Ce calcul crée une table

59

contenant les points situés à un temps inférieur à la durée spécifiée du point de départ, et

une autre table contenant le plus petit polygone convexe créé à partir de ces points (le

polygone isochrone).

6.8. Calcul d’indicateurs

Le but de cette routine est de pouvoir calculer le nombre d’arrêts de bus ou de points

d’intérêt présents dans différents isochrones. Pour cela, il suffit d’ajouter une colonne

contenant ce nombre dans la table de l’isochrone correspondant. Le script nécessaire est

présent en annexe 4.6.

60

CONCLUSION

Dans le cadre de notre EPR sur l’analyse géographique de réseaux routiers, nous

nous sommes vus attribuer le programme de travail suivant : extraction des données et

mise en place des outils, calcul de la vitesse moyenne et des temps de parcours par

tronçon (en fonction du type de route et de la densité de population), création d’un

graphe pour PgRouting et calcul d’indicateurs de proximité.

Un travail à peu près similaire ayant déjà été effectué sur l’agglomération de

Toulouse, nous avions à notre disposition un tutoriel pour l’installation et l’utilisation

des différents logiciels, ainsi que quelques outils d’analyse (scripts de création de tables,

détection des impasses et mailles, calculs de périmètres). De plus, toutes les données

nécessaires concernant l’agglomération d’Aix-en-Provence (IGN, INSEE, OSM) nous

ont été fournies.

S’appuyant sur ces outils préexistants, nous avons tout d’abord mesuré et

représenté la facilité d’accès au réseau de transport collectif, pour un piéton ou un

cycliste. Ce premier travail fut réalisé au moyen de calcul de mailles, impasses et

périmètres et d’un choix arbitraire de vitesses moyennes de déplacement. Nous avons

ensuite enrichi l’étude par l’établissement d’une carte du réseau routier représentant les

vitesses moyennes de circulation en voiture, en heures creuses et en heures de pointe.

Pour cela nous avons été amenés à croiser les données de voirie et de densité de

population. Pour compléter cette étude d’accessibilité, nous avons développé un outil de

calcul de qualité du réseau ; qualité évaluée en termes de proximité des points d’intérêt

et arrêts de bus. Les fonctions de PgRouting préalablement téléchargées en ont permis la

réalisation. L’aboutissement du projet fut la production d’un tutoriel rassemblant des

scripts réutilisables et un mode d’emploi, afin de réadapter notre travail à d’autres

communes. L’accomplissement des objectifs démontre la faisabilité d’un tel projet à

l’échelle nationale.

Néanmoins nous avons utilisé des données issues de la BD Topo IGN,

disponibles uniquement sous licence. Les données OSM n’offraient effectivement pas la

possibilité d’être exploitées dans le sens de nos objectifs. Les données géographiques de

recensement INSEE (au format shapefile) sont également payantes. Parallèlement,

l’IGN propose gratuitement une base de données « Geofla » concernant les unités

administratives françaises. Le but du programme étant de fournir à terme un service

gratuit, un travail supplémentaire d’adaptation des données libres est nécessaire.

61

De plus, en raison de la contrainte temporelle (27 jours) de nombreuses

améliorations possibles n’ont pas été intégrées. En effet, nous pourrions affiner le choix

des vitesses moyennes de déplacement en voiture et à vélo. Le découpage utilisé pour

l’acquisition des données de recensement est trop fin et mériterait d’être à l’échelle de la

commune. Notons finalement qu’il serait possible de produire un graphe bidirectionnel

qui permettrait la prise en compte des sens uniques et de l’influence des pentes.

Organisation et enrichissement personnel :

Le déroulement de la réalisation de notre projet peut être décrit selon plusieurs

étapes.

Chronologiquement, la première étape est antérieure au début du stage et

consistait en une pré-acquisition de connaissances. Concrètement, nos référents d’EPR à

Salon nous ont fourni une documentation sur les bases de données et le langage SQL, et

nous ont présenté les logiciels avec lesquels nous avons travaillé (PostgreSQL et Qgis).

Durant la première semaine de stage au CETE Méditerranée nous nous sommes

familiarisés avec le sujet et l’environnement de travail, et avons pris en compte le cahier

des charges. Cela s’est fait par le biais de l’installation des logiciels et du démonstrateur

SIG de Toulouse, l’utilisation du tutoriel et des scripts préexistants pour la première

partie du projet.

Nous sommes entrés dans la phase de développement en travaillant à deux, ce

qui nous a permis de comprendre plus vite et d’acquérir les mêmes connaissances. Par

la suite nous nous sommes répartis le travail : l’un s’étant concentré sur la recherche de

scripts sur Internet et leur adaptation, l’autre sur la réalisation des cartes avec Qgis et la

rédaction du rapport. Quand il s’avérait nécessaire de créer de nouvelles requêtes SQL

(sans piste disponible sur Internet) nous revenions à un travail en binôme. À la

rencontre de points bloquants notre chef de projet participait à la réflexion, nous évitant

de perdre trop de temps.

Pour finir, nous avons consacré trois jours à la finalisation du rapport, après une

phase de test durant laquelle nous avons récapitulé l’ensemble de nos procédures avec

notre chef de projet. Suite au rendu du rapport, nous prévoyons d’employer les deux

jours restants pour la préparation de la soutenance et l’avancement de quelques pistes

d’amélioration du projet.

Notre travail s’est vu ponctué de trois corrections intermédiaires du rapport, qui

ont permis d’assurer la bonne continuité du projet.

Sur un plan plus personnel, l’EPR nous

domaine informatique et la

Notre choix de répartition de travail nous est apparu judicieux. En effet, le fait

d’avoir débuté notre travail en binôme nous a permis d’être l’un comme l’autre apte à

réfléchir sur un même problème, et donc de pouvoir travailler à deux

bloquants. Parallèlement, le fait de mener sur un même front la rédaction du rapport et

l’avancement du projet, nous a assuré la réalisation des objectifs dans le temps imparti.

Le sujet de l’EPR et l’environnement de travail dans lequel no

nous ont offert la possibilité d’acquérir des connaissances sur les bases de données, le

langage SQL et les SIG

sous Linux et MS-DOS. De plus

l’air nous a donné les bases nécessaires pour comprendre rapidement les rouages

d’autres langages de programmation.

Finalement, l’EPR nous a montré que grâce aux connaissances acquises en

classes préparatoires et à l’École de l’air, nous

rapidement à un domaine scientifique inconnu. Nous avons

capacité à chercher efficacement de l’information et à la comprendre, même

niveau technique avancé.

documentation au départ du projet.

Figure 39 : déroulement chronologique du projet.

Sur un plan plus personnel, l’EPR nous a apporté des connaissances dans le

domaine informatique et la gestion de projet.

Notre choix de répartition de travail nous est apparu judicieux. En effet, le fait

d’avoir débuté notre travail en binôme nous a permis d’être l’un comme l’autre apte à

réfléchir sur un même problème, et donc de pouvoir travailler à deux

Parallèlement, le fait de mener sur un même front la rédaction du rapport et

l’avancement du projet, nous a assuré la réalisation des objectifs dans le temps imparti.

Le sujet de l’EPR et l’environnement de travail dans lequel no

la possibilité d’acquérir des connaissances sur les bases de données, le

langage SQL et les SIG. Nous avons également approfondi nos compétences de travail

DOS. De plus, l’étude du langage C en première a

l’air nous a donné les bases nécessaires pour comprendre rapidement les rouages

d’autres langages de programmation.

Finalement, l’EPR nous a montré que grâce aux connaissances acquises en

classes préparatoires et à l’École de l’air, nous sommes capables de nous adapter

rapidement à un domaine scientifique inconnu. Nous avons pris conscience de

capacité à chercher efficacement de l’information et à la comprendre, même

niveau technique avancé. L’apprentissage fut néanmoins fav

documentation au départ du projet.

62

apporté des connaissances dans le

Notre choix de répartition de travail nous est apparu judicieux. En effet, le fait

d’avoir débuté notre travail en binôme nous a permis d’être l’un comme l’autre apte à

réfléchir sur un même problème, et donc de pouvoir travailler à deux sur des points

Parallèlement, le fait de mener sur un même front la rédaction du rapport et

l’avancement du projet, nous a assuré la réalisation des objectifs dans le temps imparti.

Le sujet de l’EPR et l’environnement de travail dans lequel nous nous trouvions

la possibilité d’acquérir des connaissances sur les bases de données, le

. Nous avons également approfondi nos compétences de travail

l’étude du langage C en première année à l’École de

l’air nous a donné les bases nécessaires pour comprendre rapidement les rouages

Finalement, l’EPR nous a montré que grâce aux connaissances acquises en

sommes capables de nous adapter

pris conscience de notre

capacité à chercher efficacement de l’information et à la comprendre, même dans un

L’apprentissage fut néanmoins favorisé par une bonne

63

ANNEXE 1

Conversion forcée d’un fichier shapefile en table de données, via la fonction

ogr2ogr sous DOS.

64

ANNEXE 2

I. Script SQL de création de la table « maille_ign » :

Requête de création d’une table. On nomme initialement la table, puis on définit les colonnes et le type d’attribut qu’elles contiennent. Ici on ajoute une contrainte sur le choix du système de coordonnées (SRID). CREATE TABLE maille_ign ( gid integer NOT NULL, -- Identifiant formation pour utilisation par un SIG comme Qgis surface double precision, perimeter double precision, geom geometry, CONSTRAINT pathlink_enforce_srid_geom CHECK (srid(geom) = 4326) -- EPSG:4326 = WGS84 ) WITHOUT OIDS; ALTER TABLE maille_ign OWNER TO cete;

II. Script SQL de la fonction de recherche de mailles « insert_mailles_ign » :

Tout d’abord il est nécessaire de créer une séquence servant à incrémenter la boucle

dans la fonction. La fonction va rechercher les routes non bouclées sur elles-mêmes et

crée les polygones formés par celles-ci.

Création d’une séquence :

CREATE SEQUENCE maille_gid_seq INCREMENT 1 MINVALUE 1 MAXVALUE

9223372036854775807 START 19868 CACHE 1; ALTER TABLE maille_gid_seq OWNER TO cete;

Création de la fonction :

CREATE OR REPLACE FUNCTION insert_mailles_ign() RETURNS text AS

$BODY$

declare geometrie RECORD; query TEXT; maille_sequence integer;

begin TRUNCATE TABLE maille_ign;

-- LOOP chemins

FOR geometrie IN SELECT (ST_Dump(foofoo.polycoll)).geom As geom. FROM (SELECT

ST_Polygonize(the_geom) As polycoll FROM (SELECT the_geom FROM "aix_ign" where

ST_IsClosed(the_geom) = false ORDER BY gid ) As foo) As foofoo

LOOP

65

query := 'select nextval(''maille_gid_seq'');';

EXECUTE query INTO maille_sequence;

INSERT INTO maille_ign (gid, geom) VALUES (maille_sequence, geometrie.geom );

END LOOP ;

RETURN 'mailles inserted ' ; end; $BODY$

LANGUAGE 'plpgsql' VOLATILE COST 100;

ALTER FUNCTION insert_mailles_ign() OWNER TO cete;

Exécution de la fonction : select insert_mailles();

Calcul de la surface et du périmètre :

update maille set surface=ST_AREA(ST_transform(geom,2154))/1000000;

update maille set perimeter=ST_PERIMETER(geom,2154);

III. Script SQL de la fonction de recherche d’impasses « insert_deadends_ign » :

La fonction suivante rassemble toutes les routes qui sont contenues dans les mailles,

et n’ont donc pas pu être bouclées avec d’autres routes pour constituer des polygones.

Elle compare tour à tour les géométries des mailles à celles des routes.

Ajout d’une colonne impasses à la table aix_ign :

ALTER TABLE "aix_ign" ADD COLUMN deadendflag boolean DEFAULT false;

Fonction de recherche des impasses :

CREATE OR REPLACE FUNCTION insert_deadends_ign() RETURNS text AS

$BODY$

declare rec_maille RECORD; current_index integer;

begin current_index=0; UPDATE "aix_ign" set deadendflag=false;

-- LOOP mailles:

FOR rec_maille IN SELECT geom FROM maille_ign LOOP -- pour chaque maille, les tronçons entièrement contenus dans la maille sont des impasses :

UPDATE "aix_ign" set deadendflag=true WHERE the_geom && rec_maille.geom AND

ST_Contains(rec_maille.geom, the_geom);

current_index = current_index+1;

if current_index % 100 = 0

THEN RAISE NOTICE 'Indice %', current_index || ' date =' || current_date;

end if;

66

END LOOP;

RETURN 'deadends inserted ' ;

end;

$BODY$

LANGUAGE 'plpgsql' VOLATILE COST 100;

ALTER FUNCTION insert_deadends_ign() OWNER TO cete;

67

ANNEXE 3

I. Détail du script de calcul de densité de population par îlot IRIS :

Ligne de commande MS DOS pour la conversion des fichiers .shp en table PostgreSQL :

Suppression des données ne concernant pas l’agglomération d’Aix-en-Provence : DELETE FROM iris WHERE "nom_com" != 'AIX-EN-PROVENCE'; ALTER TABLE "iris" ADD COLUMN dpop double precision DEFAULT 0; update iris set dpop=c1/surface; La surface est calculée comme pour les mailles, avec la fonction ST_AREA. On se place en coordonnées WGS84 avec la fonction ST_Transform :

ST_AREA (ST_transform(wkb_geometry,2154))

II. Recherche de l’IRIS majoritairement traversé par une route (premier

calcul) :

Cette requête rassemble et classe initialement l’ensemble des routes en contact avec

les IRIS. Par la suite elle compare la longueur de segment commune aux routes et aux IRIS. Ce calcul, trop fastidieux pour notre ordinateur, a été arrêté. CREATE TABLE A AS SELECT distinct iris.wkb_geometry, iris.dpop, ST_intersection(the_geom,wkb_geometry) FROM aix_ign,iris WHERE ST_intersects(the_geom, wkb_geometry); CREATE INDEX a_geom_idx ON A USING gist (wkb_geometry); CREATE TABLE B2 AS SELECT ST_length(ST_intersection(aix_ign.the_geom,A.wkb_geometry)), A.dpop, aix_ign.gid FROM A, aix_ign;

III. Recherche de l’IRIS majoritairement traversé par une route (second

calcul) :

Une seconde méthode permet de s’affranchir du calcul précédent. Il s’agit de créer

une fonction qui exécute une boucle sur les routes : elle sélectionne successivement les

routes et rassemble les IRIS en contact, puis calcule la longueur des segments

d’intersection. Le segment le plus long détermine l’IRIS qui influera sur la route en

termes de densité de population. Sa densité est ensuite affectée à la route. Pour alléger le

68

calcul on utilise des tables temporaires, qui seront automatiquement effacées à chaque

fin de boucle.

CREATE OR REPLACE FUNCTION aaa_dpop_route()

RETURNS text AS

$BODY$

declare

geom GEOMETRY;

current_index INTEGER;

begin

current_index=0;

-- tables temporaires:

CREATE TEMPORARY TABLE A ( dpop DOUBLE PRECISION, sfc_intersection GEOMETRY);

CREATE TEMPORARY TABLE B ( dpop DOUBLE PRECISION, lg_intersection DOUBLE

PRECISION);

-- Boucle sur les routes :

FOR geom IN (SELECT the_geom FROM aix_ign)

LOOP

current_index=current_index+1;

RAISE NOTICE 'tronçon %', current_index;

INSERT INTO A SELECT iris.dpop, ST_intersection(geom,wkb_geometry) FROM iris WHERE

ST_intersects(geom, iris.wkb_geometry);

INSERT INTO B SELECT dpop, ST_length(A.sfc_intersection) FROM A;

RAISE NOTICE 'taille A %', (select count (*) from A);

RAISE NOTICE 'taille B %', (select count (*) from B);

UPDATE aix_ign SET dpop=(SELECT dpop FROM B WHERE lg_intersection = (SELECT

max(lg_intersection) FROM B)) WHERE the_geom=geom. ;

-- Vidage des tables temporaires :

TRUNCATE TABLE A;

TRUNCATE TABLE B;

END LOOP;

-- Suppression des tables temporaires :

DROP TABLE A;

DROP TABLE B;

RETURN 'terminé ! ' ;

end;

69

$BODY$

LANGUAGE 'plpgsql' VOLATILE COST 100;

ALTER FUNCTION aaa_dpop_route() OWNER TO cete;

IV. Affectation des vitesses moyennes de circulation :

Ces requêtes permettent d’affecter des valeurs à une colonne créée en amont. On utilise

ici l’opérateur logique « and » qui permet de poser plusieurs conditions à l’affectation.

Vitesses de circulation en heures creuses :

ALTER TABLE "aix_ign" ADD COLUMN avgspeed integer DEFAULT 0;

UPDATE aix_ign SET avgspeed = '100' WHERE "NATURE"='Autoroute';

UPDATE aix_ign SET avgspeed = '80' WHERE "NATURE"='Route à 2 chaussées' AND

"CL_ADMIN"='Départementale';

UPDATE aix_ign SET avgspeed = '50' WHERE "NATURE"='Route à 1 chaussée' AND

"CL_ADMIN"='Départementale';

UPDATE aix_ign SET avgspeed = '30' WHERE "NATURE"='Route à 2 chaussées' AND

"CL_ADMIN"='Autre';

UPDATE aix_ign SET avgspeed = '40' WHERE "NATURE"='Bretelle';

UPDATE aix_ign SET avgspeed = '20' WHERE "NATURE"='Route à 1 chaussée' AND

"CL_ADMIN"='Autre';

UPDATE aix_ign SET avgspeed = '10' WHERE "NATURE"='Route empierrée';

UPDATE aix_ign SET avgspeed = '15' WHERE "NATURE"='Chemin';

Vitesses de circulation modifiées en heure de pointe :

ALTER TABLE "aix_ign" ADD COLUMN avgspeed_modif integer;

UPDATE aix_ign SET avgspeed_modif = '50' WHERE "NATURE"='Autoroute' AND "dpop">450.000;

UPDATE aix_ign SET avgspeed_modif = '40' WHERE "NATURE"='Route à 2 chaussées' AND

"CL_ADMIN"='Départementale' AND "dpop">450.000;

UPDATE aix_ign SET avgspeed_modif = '25' WHERE "NATURE"='Route à 1 chaussée' AND

"CL_ADMIN"='Départementale' AND "dpop">450.000;

UPDATE aix_ign SET avgspeed_modif = '15' WHERE "NATURE"='Route à 2 chaussées' AND

"CL_ADMIN"='Autre' AND "dpop">450.000;

UPDATE aix_ign SET avgspeed_modif = '20' WHERE "NATURE"='Bretelle' AND "dpop">450.000;

UPDATE aix_ign SET avgspeed_modif = '10' WHERE "NATURE"='Route à 1 chaussée' AND

"CL_ADMIN"='Autre' AND "dpop">450.000;

70

V. Affectation des densités de population aux mailles :

La méthode est similaire à celle employée ci-dessus, on remplace simplement les

routes par les mailles.

CREATE OR REPLACE FUNCTION aaa_dpop_maille()

RETURNS text AS

$BODY$

declare

geo GEOMETRY;

current_index INTEGER;

begin

current_index=0;

-- tables temporaires:

CREATE TEMPORARY TABLE C ( dpop double precision, sfc_intersection geometry);

CREATE TEMPORARY TABLE D ( dpop double precision, aire_intersection double precision);

-- Boucle sur les mailles :

FOR geo IN (SELECT geom FROM maille_ign)

LOOP

current_index=current_index+1;

RAISE NOTICE 'maille %', current_index;

INSERT INTO C SELECT iris.dpop, ST_intersection(geo,wkb_geometry) FROM iris WHERE

ST_intersects(geo, iris.wkb_geometry);

INSERT INTO D SELECT dpop, ST_AREA(C.sfc_intersection) FROM C;

RAISE NOTICE 'taille C %', (select count (*) from C);

RAISE NOTICE 'taille D %', (select count (*) from D);

UPDATE maille_ign SET dpop=(SELECT dpop FROM D WHERE aire_intersection = (SELECT

max(aire_intersection) FROM D)) WHERE geom=geo;

TRUNCATE TABLE C;

TRUNCATE TABLE D;

END LOOP;

DROP TABLE C;

DROP TABLE D;

RETURN 'terminé ! ' ;

end;

$BODY$

LANGUAGE 'plpgsql' VOLATILE COST 100;

ALTER FUNCTION aaa_dpop_maille() OWNER TO cete;

71

ANNEXE 4

I. Ajout des fonctions de PgRouting sur la base de données « aix » :

II. Ajout des éléments nécessaires à l’exécution de la fonction driving_distance

de PgRouting :

Ce script va créer tout les éléments nécessaires à l’exécutions de la fonction

driving_distance. On utilise les fonction StartPoint et EndPoint qui recherchent les

nœuds de début et fin de tronçon (source et target), et la fonction Length pour calculer la

longueur des tronçons.

72

ALTER TABLE <Votre table de voirie> ADD COLUMN source_geom geometry;

UPDATE <Votre table de voirie> SET source_geom = ST_StartPoint(<Votre colonne géométrie>)

FROM <Votre table de voirie> ;

ALTER TABLE<Votre table de voirie> ADD COLUMN target_geom geometry;

UPDATE <Votre table de voirie> SET target_geom = ST_EndPoint(<Votre colonne géométrie>) FROM

<Votre table de voirie> ;

CREATE TABLE vertices_tmp1

( geome geometry NOT NULL,)

WITH ( OIDS=FALSE);

ALTER TABLE vertices_tmp1 OWNER TO <Votre utilisateur Postgres>;

INSERT INTO vertices_tmp1(geome) SELECT DISTINCT source_geom FROM <Votre table de voirie>;

INSERT INTO vertices_tmp1(geome) SELECT DISTINCT target_geom FROM <Votre table de voirie>;

CREATE TABLE vertices_tmp

( geom geometry NOT NULL,

id serial NOT NULL)

WITH (OIDS=FALSE);

ALTER TABLE vertices_tmp OWNER TO <Votre utilisateur Postgres>;

INSERT INTO vertices_tmp(geom) SELECT DISTINCT geome FROM vertices_tmp1;

ALTER TABLE <Votre table de voirie> ADD COLUMN source integer;

UPDATE <Votre table de voirie> SET source = vertices_tmp.id FROM vertices_tmp WHERE

vertices_tmp.geom = source_geom ;

ALTER TABLE <Votre table de voirie> ADD COLUMN target integer;

UPDATE <Votre table de voirie> SET target = vertices_tmp.id FROM vertices_tmp WHERE

vertices_tmp.geom = target_geom ;

ALTER TABLE <Votre table de voirie> ADD COLUMN length double precision;

UPDATE <Votre table de voirie> SET length = ST_Length(<Votre colonne géométrie>) FROM <Votre

table de voirie> ;

III. Modification des entrées pour driving_distance :

Ajout, dans la table de voirie, des colonnes destinées à recevoir les temps de

parcours par tronçon, pour chaque mode de déplacement. Puis calcul des temps de

73

parcours par tronçon (rapport de la longueur sur la vitesse moyenne de déplacement). La

valeur -1 permet de stopper le calcul pour éviter la division par 0.

ALTER TABLE aix_ign ADD COLUMN tps_hp DOUBLE PRECISION;

ALTER TABLE aix_ign ADD COLUMN tps_hc DOUBLE PRECISION;

ALTER TABLE aix_ign ADD COLUMN tps_velo DOUBLE PRECISION;

ALTER TABLE aix_ign ADD COLUMN tps_pieton DOUBLE PRECISION;

UPDATE aix_ign SET tps_hp = length/60.0/avgspeed_hpointe WHERE avgspeed>1.0;

UPDATE aix_ign SET tps_hc = length/60.0/avgspeed WHERE avgspeed>1.0;

UPDATE aix_ign SET tps_pieton = length/60.0/avgspeed_pieton;

UPDATE aix_ign SET tps_velo = tps_pieton/60.0/avgspeed_velo;

UPDATE aix_ign SET tps_hp = -1 WHERE "avgspeed"='0';

UPDATE aix_ign SET tps_hc = -1 WHERE "avgspeed"='0';

IV. Calcul des isochrones :

Exécution de la fonction driving_distance. En entrée le choix de la colonne de temps

de parcours (contenue dans la table de voirie), l’identifiant du point de départ (11919 ici)

et le temps choisi en minutes pour l’isochrone (ici 5min).

CREATE TABLE temp_node_result_pieton_5

(

“ID” integer NOT NULL,

“THE_GEOM” Geometry

);

INSERT INTO temp_node_result_pieton_5 ( SELECT DISTINCT T1.VERTEX_ID, T2.geom FROM

( SELECT * FROM driving_distance ( 'SELECT gid AS id, source, target, tps_pieton::double precision

as cost FROM aix_ign', 11919, 5, false, false))

AS T1, vertices_tmp AS T2 WHERE T1.VERTEX_ID = T2.ID);

Création du polygone isochrone. Dans une nouvelle table on rentre la géométrie

du polygone convexe le plus petit constitué à partir des points fournis par

driving_distance.

74

CREATE TABLE polygon_pieton_5 AS SELECT DISTINCT

ST_ConvexHull(ST_Collect(temp_node_result_pieton_5.“the_geom”)) FROM

temp_node_result_pieton_5;

ALTER TABLE polygon_pieton_5 ADD COLUMN ogc_fid SERIAL NOT NULL;

V. Affectation des durées de parcours aux intersections et aux tronçons :

Requête de création d’une table dont les attributs sont les intersections du réseau de

voirie, affectés du temps nécessaire pour les atteindre depuis un lieu choisi (ici le nœud

11919) via un mode de déplacement donné (voiture en heures creuses dans ce cas). Le

terme « 40 » permet ici de s’assurer de prendre en compte l’ensemble des points du

réseau de voirie.

CREATE TABLE tp_tout_aix AS

SELECT DISTINCT T1.VERTEX_ID,T1.EDGE_ID,T1.cost, T2.geom FROM (SELECT * FROM

driving_distance('SELECT gid AS id, source, target, tps_hc::double precision AS cost FROM

aix_ign',11919, 40, false, false)) AS T1, vertices_tmp AS T2 WHERE T1.VERTEX_ID = T2.ID;

Requête de création d’une table dont les attributs sont les tronçons du réseau de

voirie, affectés du temps nécessaire pour les atteindre depuis un lieu choisi via un mode

de déplacement donné. Après exécution de la requête précédente, on attribue aux

tronçons la valeur moyenne de leurs points de début et de fin.

CREATE TABLE road_tout_aix

(

gid SERIAL NOT NULL,

"cost" DOUBLE PRECISION,

c1 DOUBLE PRECISION,

c2 DOUBLE PRECISION,

geom GEOMETRY

)

WITH (OIDS=FALSE);

ALTER TABLE road_tout_aix OWNER TO cete;

INSERT INTO road_tout_aix(geom) SELECT the_geom FROM aix_ign;

ALTER TABLE road_tout_aix ADD COLUMN source_geome GEOMETRY;

ALTER TABLE road_tout_aix ADD COLUMN target_geome GEOMETRY;

INSERT INTO road_tout_aix(source_geome) SELECT source_geom FROM aix_ign;

INSERT INTO road_tout_aix(target_geome) SELECT target_geom FROM aix_ign;

75

UPDATE road_tout_aix SET c1=tp_tout_aix.cost FROM tp_tout_aix WHERE

road_tout_aix.source_geome=tp_tout_aix.geom;

UPDATE road_tout_aix SET c2=tp_tout_aix.cost FROM tp_tout_aix WHERE

road_tout_aix.target_geome=tp_tout_aix.geom;

UPDATE road_tout_aix SET cost = 0.5*(c1+c2);

VI. Calcul de scores :

Création d’une fonction qui compare la position des POI (ou TC) avec la géométrie

d’un polygone isochrone choisi. Un compteur est incrémenté à chaque fois qu’un POI

est contenu dans l’isochrone.

CREATE OR REPLACE FUNCTION comp_poi_polygon() RETURNS text AS $BODY$ declare geom GEOMETRY; current_index INTEGER; d INTEGER; BEGIN current_index=0; d=0; FOR geom IN (SELECT wkb_geometry FROM poi_aix_ign)

LOOP current_index=current_index+1; RAISE NOTICE 'poi %', current_index; IF (select ST_Intersects(geom,polygon_pieton.st_convexhull) FROM polygon_pieton) = 'true' THEN d = d+1; END IF;

END LOOP; UPDATE polygon_pieton SET nombre_poi=d; RETURN 'terminé ! ' ; END; $BODY$ LANGUAGE 'plpgsql' VOLATILE COST 100; ALTER FUNCTION comp_poi_polygon() OWNER TO cete;

76

BIBLIOGRAPHIE

Ouvrages :

- Capitaine CHARLIER Gildas, 2009, Base de Données Relationnelles Langage

SQL, École des Officiers de l’Armées de l’air.

- DRAKE Joshua D., WORSLEY John C., 2002, Practical PostgreSQL,

Sebastopol, O’Reilly.

Sites internet :

CETE Méditerranée : http://www/cete-aix.fr et service TIM http://www/cete-aix.fr/tt13

Projet POTIMART : http://www.potimart.com

Site du Predit : http://www.predit.prd.fr

Open Street Map : http://www.openstreetmap.org

Walkscore : http://www.walkscore.com

Fondation Géospatiale Open Source : http://osgeo.org

Geoportail : http://www.geopartail.fr

IGN,Geofla : http://professionnels.ign.fr/ficheProduitCMS.do?idDoc=5323861

INSEE :

- http://www.insee.fr/fr/ppp/bases-de-donnees/donnees-

detaillees/duicq/uu.asp?reg=93&uu=00758

- http://www/recensement-1999.insee.fr/RP99/rp99/page_accueil.paccueil

- http://www/recensement.insee.fr/accesDonneesTelechargeables.action

Diers (SIG, PostgreSQL, forums…) : http://postlbs.org

Définition d‘accessibilité sur Wikipédia :

http://fr.wikipedia.org/wiki/Accessibilité#Transport

Téléchargement des logiciels :

PgRouting : http://PgRouting.portlbs.org

PostgreSQL : http://www.PostgreSQL.org/download

PgAdmin : http://www.PgAdmin.org/download

PostGIS : http ://www.postgis.fr

Qgis : http://www.Qgis.org/en/download/current-software.html

77

GLOSSAIRE

BD : base de données.

Couche : Une zone géographique peut se décortiquer en plusieurs couches thématique.

Une couche est la représentation géométrique d’une ensemble de données de même

nature (par exemple les routes, les zones de forte population...).

Îlot : Unité de base de zonage, qui correspond à un pâté de maisons. C’est la plus petite

surface limitée par des voies publiques ou privées, des obstacles naturels (rivière,

falaise), ou des obstacles artificiels (canal, voie ferrée). L’îlot s’inscrit toujours dans les

limites communales ou cantonales.

IRIS : Îlots Regroupés pour l’Information Statistique. L’IRIS-2000 est le nouveau

zonage de diffusion mis en place par l’INSEE lors du recensement de population de

1999. Le zonage s’appuis sur certains impératifs liés au terrain (morphologie urbaine),

au bâti (typologie de l’habitat), au caractère socioéconomique (zone d’activité, d’habitat

ou zone spécifique). Les zones à dominante d’habitat contiennent en moyenne 2000

habitants.

Open source : désignation s’appliquant aux logiciels dont la licence respecte les

critères de l’Open Source Initiative, c'est-à-dire la possibilité de libre redistribution, de

modification et de réexportation par d’autres développeurs.

OSM : Open Street Map. Projet destiné à réaliser une carte du monde, sous licence

Open Source. Sur le modèle de Wikipédia, tout le monde peut donc utiliser, améliorer et

distribuer les cartes OSM.

POI : Point of interest. Terme utilisé pour désigner les points d’intérêt du type

transports, monuments, alimentation, médical, divertissements, etc…

Shapefile : fichier de forme. L’extension .shp concerne des données géométriques. Un

« shapefile » contient toute l’information liée à la géométrie des objets décrits, qui

peuvent être : des points, des lignes ou des polygones.

78

SIG – GIS : acronyme (français et anglais) de Système d’Information Géographique.

C’est un système informatique permettant, à partir de diverses sources, de rassembler,

d’organiser, de gérer, d’analyser, de combiner, d’élaborer et présenter des informations

localisées géographiquement, contribuant notamment à la gestion de l’espace.

SQL : Structured Query Language. Langage de programmation relationnel : manipule

des tables (ou ensembles) par l’intermédiaire de requêtes qui produisent également des

tables.

SRS : Spatial Reference System. Système de coordonnées géographiques.

TC : transport collectif.

79

TABLE DES ILLUSTRATIONS

Figure 1 : création d’une base de données. ................................................................................. 17

Figure 2 : fenêtre d’utilisation du module SPIT sur Qgis ........................................................... 18

Figure 3 : visualisation sur Qgis de la couche du réseau routier d’Aix-en-Provence produit par OSM. ........................................................................................................................................... 19

Figure 4 : visualisation sur Qgis de la couche du réseau routier d’Aix-en-Provence produit par l’IGN. .......................................................................................................................................... 20

Figure 5 : diagramme d’activités de la fonction de recherche des mailles. ................................ 21

Figure 6 : visualisation des mailles (et impasses) d’après les données OSM d’Aix-en-Provence. .................................................................................................................................................... 22

Figure 7 : classement des mailles par quantiles en fonction de leur périmètre, sur Qgis............ 22

Figure 8 : aperçu de la couche des mailles issue des données IGN. ........................................... 23

Figure 9 : diagramme d’activités de la fonction de recherche d’impasses. ................................. 24

Figure 10 : détail du centre ville d’Aix-en-Provence avec les impasses (en rouge) et les voies (en vert). ............................................................................................................................................ 24

Figure 11 : superposition des mailles et des impasses dans l’agglomération d’Aix-en-Provence. .................................................................................................................................................... 25

Figure 12 : temps de parcours d’un piéton pour effectuer le tour d’une maille (détail du centre-ville). ........................................................................................................................................... 26

Figure 13 : temps de parcours d’un cycliste pour effectuer le tour d’une maille. ....................... 27

Figure 14 : visualisation des arrêts et stations de bus. ................................................................ 28

Figure 15 : superposition des cartes de temps de parcours à pied et des arrêts de bus (losanges verts). .......................................................................................................................................... 29

Figure 16 : superposition des cartes de temps de parcours à vélo et des arrêts de bus (losanges verts). .......................................................................................................................................... 30

Figure 17 : choix de la vitesse moyenne de circulation en fonction du type de route. ............... 32

Figure 18 : visualisation sur Qgis de la vitesse moyenne en fonction du type de route. ............ 32

Figure 19 : extrait de la table contenant les données de recensement INSEE. ........................... 34

Figure 20 : IRIS représentés en fonction de leur densité de population (vert : faible densité, violet : densité élevée). ............................................................................................................... 35

Figure 21 : choix de la vitesse moyenne en fonction du type de route en heure de pointe. ........ 36

Figure 22 : diagramme d’activités de la fonction d’affectation des densités de population aux routes. .......................................................................................................................................... 37

Figure 23 : représentation des routes en fonction de la densité de population de l’IRIS qu’elles traversent. .................................................................................................................................... 38

Figure 24 : mise en évidence des zones de ralentissement en heure de pointe (en rouge).......... 39

Figure 25 : densité de population par maille. .............................................................................. 40

Figure 26 : détail du centre d’Aix-en-Provence. En rouge : mailles dont la densité de population est supérieure à 450 hab./km²...................................................................................................... 41

Figure 27 : extrait de réseau routier. ........................................................................................... 43

Figure 28 : visualisation du plus court chemin sur Qgis. ............................................................ 43

Figure 29 : ensemble des intersections (en bleu) situés dans un périmètre d’un kilomètre autour d’un point choisi (en vert et noir)................................................................................................ 44

Figure 30 : diagramme d’activités de la fonction driving_distance de PgRouting. .................... 44

80

Figure 31 : ensemble des intersections (en vert) se trouvant à une distance de 5 km d’un point de départ choisi (en rose). ................................................................................................................ 45

Figure 32 : comparaison des isochrones de 10 minutes pour les différents modes de déplacement. .................................................................................................................................................... 48

Figure 33 : isochrones 5, 10 et 15 minutes pour un déplacement en voiture en heures creuses (à gauche) et piéton (à droite). ........................................................................................................ 48

Figure 34 : intersections du réseau de voirie d’Aix-en-Provence en fonction des temps de parcours en voiture aux heures creuses depuis le centre-ville (rond vert). ................................. 49

Figure 35 : exemple de mesure de « qualité piétonne » sur le cours Mirabeau à Aix-en-Provence, avec le site Walkscore.com. ........................................................................................................ 50

Figure 36 : diagramme d’activités de la fonction de calcul de scores. ........................................ 50

Figure 37 : nombre d’arrêts de bus (avant dernière colonne) et de POI (dernière colonne) situés de 0 à 5 minutes à vélo du centre ville d’Aix-en-Provence. ....................................................... 51

Figure 38 : arrêts de bus et isochrone de 5 minutes à vélo à partir du centre-ville d’Aix-en-Provence. ..................................................................................................................................... 51

Figure 39 : déroulement chronologique du projet. ...................................................................... 62