View
216
Download
0
Category
Preview:
Citation preview
É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
Recommended