L`outil de visualisation dans le cadre d`un projet d

Transcription

Université de Toulouse
MASTER 2 GEOMATIQUE
« Science de l’Information Géoréférencée pour la Maîtrise de l’environnement
et l’Aménagement des territoires » (SIGMA)
http://sigma.univ-toulouse.fr
RAPPORT DE STAGE
L’outil de visualisation dans le cadre
d’un projet d’évaluation de l’adaptation
climatique en milieu urbain.
Camila LEGROUX
Centre National de Recherches Météorologiques (CNRM) – MétéoFrance
Maître de stage : Julia HIDALGO
Tuteurs-enseignants : Martin PAEGELOW et Thomas HOUET
Septembre 2012
Camila LEGROUX, Master 2 SIGMA, Université de Toulouse, 2011 / 2012
FICHE DE STAGE MASTER 2 SIGMA 2012
NOM ETUDIANT :
LEGROUX
PRENOM ETUDIANT :
Camila
E. mail
[email protected]
TITRE DU STAGE :
Développement d'outils de visualisation des impacts de différents
métabolismes urbain pour évaluer des scénarios d'urbanisme.
DATE DE DEBUT DE
STAGE :
DATE DE FIN DE
STAGE :
NOM TUTEURENSEIGNANT :
Université
05/03/2012
SOCIETE :
Adresse
CNRM - MétéoFrance Toulouse
42 Avenue Gaspard Coriolis
Code postal
Ville
Pays
Site Web
NOM DU MAITRE DE
STAGE :
Fonction
Mel
31/07/2012
Martin PAEGELOW et Thomas HOUET
Université 2 – Toulouse Le Mirail
31057
Toulouse Cedex 1
http://www.cnrm.meteo.fr/
Julia Hidalgo
Météorologue
[email protected]
MOTS-CLES :
Modélisation 2D / 3D ; Changement climatique / Indicateurs
RAPPORT
CONFIDENTIEL
OBJET (description de la
mission confiée au
stagiaire) :
Non
Identifier et développer un outil de visualisation des impacts calculés
par les modèles et des indicateurs. Cet outil de visualisation,
complémentaire du système d’indicateurs, permettront de représenter
les indicateurs spatialisés. Définir les types de visualisation possibles
pour les différents indicateurs définis.
1
RESUME / ABSTRACT
Afin d’évaluer l’évolution de la ville d’une part, et l’évolution du climat en milieu
urbain d’autre part, un système d’indicateurs cohérents et souhaitables pour l’analyse est mis
en place dans le cadre du projet Adaptation au Changement CLIMatique.de l’Agglomération
Toulousaine (ACCLIMAT). Par ailleurs, le développement d’un outil de visualisation
permettant de représenter les indicateurs cartographiquement d’une part, et graphiquement
d’autre part est préconisé. Pour cela, un logiciel SIG et des compétences en géomatique sont
nécessaires pour visualiser les données disponibles. La représentation visuelle permet
d’analyser les phénomènes climatiques et la ville au moment présent, mais aussi à l’avenir en
fonction de scénarios définis. L’outil de visualisation développé pour le projet ACCLIMAT a
pour objectif d’être un outil d’analyse ou d’aide aux diagnostics scientifiques, puis un outil
d’aide à la décision pour les politiques et les professionnels de l’urbanisme.
Le développement de cet outil de visualisation implique l’appropriation de techniques
et méthodes précises que nous présentons dans ce rapport de stage. En effet, pour cela, nous
avons dû développer des requêtes SQL et des scripts en BeanShell, dans le but de traiter les
données et de permettre une visualisation cartographique et graphique des indicateurs. Les
scripts BeanShell ont par ailleurs permis d’automatiser l’outil de visualisation et ainsi de
simplifier l’interface pour les utilisateurs.
A consistent indicator system will be set up as part of the Adaptation au Changement
CLIMatique.de l’Agglomération Toulousaine (ACCLIMAT) project, in order to assess the
evolution of a town and the climate change in an urban environment.
In addition, the development of a visualization tool is recommended to allow the graphical
and cartographical representation of the indicators. Therefore, SIG software and geomatics
skills are necessary to visualize the available data.
The Climatic phenomenon and the town can be analyzed through visual representation
at the present moment or some time later according to specific scenario.
The purpose of the visualization tool developed by the ACCCLIMAT is to be an
analytical tool or a tool to assist scientific diagnostics, and a real tool for decision support
including policies and urban planning.
In this activity report, we introduce the appropriation of techniques and specific
procedures that is required to develop this envisioning tool.
2
REMERCIEMENTS
Je souhaite adresser mes remerciements les plus sincères aux personnes qui m’ont
apporté leur aide et ont contribué à l’élaboration de ce rapport de stage.
Je tiens à remercier Julia Hidalgo pour son encadrement lors de ce stage. Sa patience
et son suivi tout au long du stage ont permis d’enrichir cette expérience professionnelle. Je la
remercie aussi, ainsi que Colette Marchadier pour leur suivi, leurs corrections et les conseils
précieux qui m’ont beaucoup aidé durant la rédaction de ce rapport de stage.
Un grand merci à toutes les personnes de l’équipe du projet qui ont contribué au bon
déroulement de mon stage et qui m’ont toujours aidé à approfondir mon travail.
Je remercie Gwendall Petit et Erwan Bocher, ainsi que toute l’équipe de développeurs
du logiciel OrbisGIS, d’avoir suivi étape par étape mon travail, et de m’avoir accordé du
temps pour répondre à mes interrogations.
Mes remerciements s’adressent également à mes tuteurs-enseignants, Martin Paegelow et
Thomas Houet, pour leur disponibilité et leur suivi pour l’élaboration de ce rapport de stage.
Je n’oublie pas mes parents et mes frères pour leurs relectures de ce rapport de stage. Mais
aussi pour leurs encouragements constants durant toutes mes études universitaires.
Enfin, je ne peux conclure cette page de remerciements sans évoquer mes amis et colocataires
de m’avoir soutenu lors de la rédaction de mon rapport de stage, toujours dans la bonnehumeur !
3
SOMMAIRE
FICHE DE STAGE MASTER 2 SIGMA 2012 ......................................................................... 1
RESUME / ABSTRACT ............................................................................................................ 2
REMERCIEMENTS .................................................................................................................. 3
SOMMAIRE .............................................................................................................................. 4
INTRODUCTION ...................................................................................................................... 6
I.
CONTEXTE DU STAGE : STRUCTURE, PROJET ET MISSION ................................. 7
1.1
Présentation de la structure d’accueil .......................................................................... 7
1.1.1.
Le Centre National de Recherches Météorologiques ........................................... 7
1.1.2.
Le Groupe de Météorologie à Moyenne Echelle.................................................. 7
1.1.3.
L’équipe TURBAU .............................................................................................. 8
1.2.
Présentation du projet ACCLIMAT ............................................................................ 9
1.2.1.
Le financeur et les partenaires du projet .............................................................. 9
1.2.2.
Les objectifs du projet ........................................................................................ 10
1.2.3.
La plateforme de simulation ACCLIMAT : Les modèles et les scénarios ........ 11
1.3.
La mission et les objectifs du stage ........................................................................... 14
1.3.1.
Les objectifs du stage ......................................................................................... 14
1.3.2.
Le déroulement du stage..................................................................................... 16
II. DEFINITION D’UN SYSTEME D’INDICATEURS ...................................................... 18
2.1.
Méthodologie de sélection et de validation des indicateurs ...................................... 18
2.2.
Analyse des données de sortie des modèles .............................................................. 20
2.3.
Proposition d’un système d’indicateurs ..................................................................... 23
III.
DEVELOPPEMENTS ET OUTIL DE VISUALISATION .......................................... 25
3.1.
Outil logiciel et environnement de développement ................................................... 25
3.1.1.
OrbisGIS, un logiciel SIG open-source.............................................................. 25
3.1.2.
L’environnement de développement .................................................................. 27
3.2.
Le développement des requêtes SQL ........................................................................ 28
3.2.1.
Pourquoi le développement de requêtes SQL a-t-il été nécessaire ?.................. 28
4
3.2.2. Les requêtes SQL développées pour traiter les données et calculer les
indicateurs ......................................................................................................................... 29
3.3.
L’outil BeanShell et le développement de scripts ..................................................... 35
3.3.1.
Qu’est-ce que l’outil BeanShell ?....................................................................... 36
3.3.2.
Le développement de scripts BeanShell pour la génération de graphiques ....... 38
3.3.3.
Des scripts BeanShell pour l’automatisation des requêtes SQL ........................ 41
IV.
RESULTATS ET RETOUR D’EXPERIENCES.......................................................... 45
4.1.
Les développements actuellement réalisés ................................................................ 45
4.1.1.
Les indicateurs disponibles aujourd’hui ............................................................. 45
4.1.2.
Les défis à relever durant le stage ...................................................................... 46
4.2.
Les compétences acquises durant le stage ................................................................. 47
4.2.1.
Les compétences techniques .............................................................................. 47
4.2.2.
L’apport du travail en équipe ............................................................................. 47
CONCLUSION ........................................................................................................................ 49
ANNEXES ............................................................................................................................... 50
Annexe 1 : Les formats des données de sortie des modèles. ................................................ 50
Annexe 2 : Tableau détaillé des indicateurs ......................................................................... 53
Annexe 3 : Les versions du logiciel OrbisGIS ..................................................................... 59
Annexe 4 : Equipe de développeurs du logiciel OrbisGIS ................................................... 60
Annexe 5 : Diagramme de Gantt .......................................................................................... 62
TABLE DES ILLUSTRATIONS ............................................................................................ 63
BIBLIOGRAPHIE / SITOGRAPHIE ...................................................................................... 64
5
INTRODUCTION
Le changement climatique est depuis des décennies au cœur des préoccupations des
environnementalistes, des urbanistes, des politiques et des scientifiques. En effet, il inquiète
notamment de par les lourdes conséquences qu’il engendre sur la ville. Le réchauffement
climatique occupe donc une place dans les stratégies de planification urbaine. C’est autour de
ces thématiques que s’est déroulé le stage au sein du projet Adaptation au Changement
CLIMatique de l’Agglomération Toulousaine (ACCLIMAT), au Centre National de
Recherches Météorologiques (CNRM).
Le projet ACCLIMAT a bénéficié d’une aide de la Fondation de Coopération Scientifique STAE
Toulouse
Ce travail a bénéficié d’une aide de l’Agence National de la Recherche portant la référence ANR-09VILL-0003
A terme, le projet doit proposer un outil de visualisation d’indicateurs en lien avec
l’évolution de la ville d’une part, et l’évolution du climat de l’autre. Il faut pouvoir visualiser
les indicateurs cartographiquement d’une part, mais aussi graphiquement d’autre part. C’est
dans cette phase finale du projet que j’ai réalisé mon stage. En effet, pour développer un outil
de visualisation des indicateurs, mes compétences en SIG ont largement été sollicitées. Mais
pas uniquement. Aussi, j’ai dû participer à la définition d’un système d’indicateurs en faisant
appel à mes connaissances et compétences en urbanisme et aménagement du territoire.
Nous commencerons par présenter la structure d’accueil qu’est le Centre National de
Recherches Météorologiques (CNRM), le projet Adaptation au Changement CLIMatique de
l’Agglomération Toulousaine (ACCLIMAT) et la mission de stage. Dans un deuxième temps,
nous expliquerons quels sont les indicateurs que nous avons retenu et quelles sont les données
disponibles et exploitables par le logiciel SIG. En troisième partie, nous détaillerons les
méthodologies, techniques et développements réalisés durant le stage pour atteindre les
objectifs fixés. Nous verrons avec cela que les compétences en SIG ont été nécessaires dans le
cadre du projet. Enfin, nous ferons un bref retour d’expériences afin de détailler les
compétences qui ont été acquises ou approfondies lors du stage, les limites et difficultés
auxquelles nous avons dû faire face.
6
I.
1.1
CONTEXTE DU STAGE : STRUCTURE, PROJET ET MISSION
Présentation de la structure d’accueil1
1.1.1.
Le Centre National de Recherches Météorologiques
Le Centre National de Recherches Météorologiques (CNRM) est une unité de recherche
associée, constituée par le Centre National de Recherches Scientifiques (CNRS) et MétéoFrance, et est composée de huit unités de recherche réparties sur plusieurs sites en France.
Les principales missions et recherches menées par le CNRM portent principalement sur la
prévision du temps et des phénomènes atmosphériques, l'étude du climat et du changement
climatique, le cycle de l'eau, l'étude des échanges océan-atmosphère, la physico-chimie
atmosphérique et la météorologie urbaine, l'assimilation et la modélisation pour la prévision
numérique du temps, et la micro-structure du manteau neigeux.
Le site de Toulouse, qui regroupe 80% du potentiel du CNRM, est composé de 5 groupes qui
développent des études et des recherches dans différents domaines. Nous insisterons ici sur la
présentation du Groupe de Météorologie à Moyenne Échelle (GMME) dans la mesure où le
stage a eu lieu au sein même de ce groupe de travail.
1.1.2.
Le Groupe de Météorologie à Moyenne Echelle
Le GMME conduit des recherches sur les phénomènes de méso-échelle et micro-échelle
dans les domaines de l'atmosphère et des surfaces continentales.
Les thématiques de ce groupe de recherches portent sur les systèmes orageux, les nuages, les
phénomènes de couche limite atmosphérique, le brouillard, la météorologie urbaine, les
évènements extrêmes, les impacts du changement climatique.
Ces travaux de recherche ont pour objectif l'amélioration de la représentation des processus à
méso-échelle dans les modèles de prévision numérique du temps et du climat, et cela
notamment à travers le développement et l'amélioration des paramétrisations physiques, de
l'assimilation de données à méso-échelle, des méthodes de prévision d'ensemble ainsi que des
modèles d'impact du changement climatique.
Le GMME est organisé en 6 équipes thématiques dont l'équipe TURBAU dans laquelle s’est
déroulé le stage.
1
http://www.cnrm-game.fr
7
1.1.3.
L’équipe TURBAU
L'équipe TURBAU est composée d'environ 10 personnes dont Valéry Masson,
responsable de l'équipe. Les principaux thèmes de recherche sont :
 le brouillard ;
 la couche limite atmosphérique ;
 le climat urbain et l’adaptation au changement climatique.
Ceux-ci sont étudiés grâce à des campagnes de mesure ainsi qu’au travers d’outils de
modélisation numérique dans le cadre de différents projets et programmes de recherche.
Figure 1 : Organigramme du projet ACCLIMAT au sein du CNRM :
Source : CNRM – Météo-France ; Réalisation : Camila Legroux, master 2 SIGMA 2011/2012
8
1.2.
Présentation du projet ACCLIMAT
1.2.1.
Le financeur et les partenaires du projet
Le projet ACCLIMAT – Adaptation au Changement CLIMatique de l'Agglomération
Toulousaine a débuté en 2010, pour une durée de 3 ans. Il est financé par le RTRA-STAE
(Réseau Thématique de Recherches Avancées – Sciences et Techniques de l'Aéronautique et
de l'Espace) à hauteur de 850 000 €.
 Le RTRA-STAE, le financeur du projet :
Le RTRA-STAE2 est une fondation de coopération scientifique qui s'appuie sur un
réseau de 25 laboratoires associés et 800 chercheurs et enseignants-chercheurs. Elle a pour
mission de développer une recherche scientifique d'excellence dans son domaine en MidiPyrénées. Pour cela, elle soutient des projets scientifiques, dont le projet ACCLIMAT.
 Les partenaires du projet :
Figure 2 : Schéma récapitulatif des partenaires du projet
Source : Plaquette du projet ACCLIMAT, disponible sur le site http://www.cnrm.meteo.fr/ville.climat/
2 http://www.fondation-stae.net/
9
1.2.2.
Les objectifs du projet
L'objectif principal du projet ACCLIMAT (Adaptation au Changement CLIMatique de
l'Agglomération Toulousaine) est d'étudier les interactions entre la ville et le changement
climatique.
Le projet ACCLIMAT se base sur les considérations suivantes.
Depuis un siècle (1906 – 2005), la température moyenne à la surface de la terre a
augmenté de 0,74°C.3 De ce réchauffement climatique progressif, découlent de nombreuses
conséquences dont la fonte des glaciers, la montée du niveau des océans, la diminution de la
biodiversité, l'augmentation du nombre de jours de canicule, etc.
Par ailleurs, le réchauffement climatique engendre de lourdes conséquences sur le milieu
urbain dans la mesure où, dans un premier temps, l'espace urbain augmente fortement dans le
monde et en France. Dans un second temps, « les villes présentent une vulnérabilité
particulière compte tenu d'une forte concentration de population et du regroupement
d'infrastructures et de biens matériels sur leur territoire, et elles sont très sensibles à toute
évolution brusque de leur environnement naturel ou socio-économique »4. Le réchauffement
climatique en ville aura particulièrement des conséquences sur les stratégies de planification
urbaine, mais aussi sur les consommations d'énergie et le confort des habitants. Le
changement climatique est donc un enjeu de taille pour l'avenir des villes et des citadins.
Effectivement, le cœur du projet ACCLIMAT est d'étudier et analyser à la fois la ville
et le climat, et plus spécifiquement le micro climat urbain, avec pour but principal de définir
les possibles adaptations au changement climatique pour le « Toulouse de demain » ou le
« Toulouse de 2100 ». En effet, le projet s'est fixé pour cette étude, une échelle d'un siècle
environ (2010 / 2100).
Pour aboutir à ces objectifs, les partenaires du projet ACCLIMAT développent une
plateforme interdisciplinaire de modélisation numérique qui permettra de simuler, à l'horizon
2100, l'évolution de l'expansion urbaine et du micro-climat urbain ; et ainsi d'évaluer les
impacts du changement climatique sur la ville. Cette plateforme renvoie des résultats
dépendant de modèles et de scénarios d'évolution de la ville et du climat, toujours dans le but
d’analyser l’efficacité des différentes stratégies d'adaptation de la ville au réchauffement
climatique.
Ainsi, il convient désormais de présenter le fonctionnement de la plateforme de
simulation.
3 http://climat.meteofrance.com/chgt_climat2/chgt_climatique/
4 Rapport « Villes et adaptation au changement climatique », ONERC, 2010. disponible sur le site :
http://www.developpement-durable.gouv.fr
10
1.2.3.
La plateforme de simulation ACCLIMAT : Les modèles et les scénarios
La plateforme de simulation ACCLIMAT est constituée de différents éléments
nécessaires: des modèles numériques de simulation et différents scénarios permettant de
modéliser et simuler l'impact du changement climatique sur la ville de Toulouse à l'horizon
2100.
Figure 3 : Schéma du fonctionnement de la plateforme ACCLIMAT
Réalisation : Marie-Pierre Moine et Camila Legroux, CNRM-GAME.
 Les modèles numériques :
Afin de simuler les impacts du changement climatique, les partenaires du projet
ACCLIMAT développent et utilisent des modèles couplés de simulation. Un modèle
d'urbanisation d'une part, et des modèles physiques de climat et de bâti d'autre part.
Des modèles de surface :

le modèle NEDUM (Gusdorf et Hallegatte 2007) : Il est conçu pour reproduire les
mécanismes d'évolution d'une agglomération sur le très long terme. Il vise à
simuler les diverses expansions possibles de l'agglomération, en fonction à la fois
de scénarios macroéconomiques et démographiques, et de scénarios
11
d'aménagement du territoire contrastés »5.
 le modèle SLEUTH (Clarke et al 1992), modifié par GEODE, et qui a « pour but
de modéliser la croissance urbaine »6 et il permet d'obtenir des informations sur
l'occupation des sols.
En couplant ces deux modèles complémentaires, il devient alors possible de visualiser les
projections d'évolution de la ville.

Le modèle GENIUS (Bonhomme et Masson 2012) est un modèle de morphologie
urbaine.

Le modèle SURFEX, ou « Surface Externalisée » est la plateforme de
modélisation de surface développée par Météo-France. 7
SURFEX (CNRM) est notamment conçu pour être couplé à des modèles atmosphériques et
hydrologiques. En effet, il inclut des modèles indépendants qui permettent de faire la relation
entre la surface et l'atmosphère. Ces modèles sont :
 ISBA qui calcule les échanges d'énergie et d'eau entre le continum sol-végétationneige et l'atmosphère ;
 TEB qui calcule les échanges entre les surfaces urbanisées et l'atmosphère. Ainsi, TEB
prend à la fois en compte tous les facteurs caractérisant l'atmosphère, mais aussi tous
les paramètres du bâti et de la morphologie de la ville.8
Le modèle SURFEX est forcé avec les données de NEDUM, GENIUS et SLEUTH.
Un modèle atmosphérique :

Le modèle Méso-NH (CNRM et Laboratoire d'Aérologie, 1998) est un modèle
météorologique atmosphérique à mésoéchelle.
 Les scénarios :
Les scénarios sont construits à partir d'une analyse des évolutions actuelles et futures, et sur
des thématiques structurantes (macro-économiques, démographiques, technologiques, etc).
Pour faire des simulations, les modèles vont très largement puiser dans ces scénarios pour
ensuite sortir des données exploitables pour le calcul d'indicateurs et la visualisation de
résultats.
Il convient désormais de présenter les traits généraux de ces scénarios.
5 VIGUIE, Simulation intégrée de la ville : Modélisation Urbaine et Stratégies d'adaptation au Changement
climatique pour Anticiper la Demande et la production Energétique (MUSCADE). La Revue. 2009
6 CALOZ Régis, COLLET Claude. Analyse spatiale de l'information géographique. Lausanne : PPUR, 2011.
400p.
7 Voir plus de détails sur http://www.cnrm.meteo.fr/surfex
8 Voir plus de détails sur http://www.cnrm.meteo.fr/spip.php?article199&lanf=fr
12
Les scénarios sont élaborés de façon progressive : à partir de plusieurs scénarios relatifs à une
thématique (Grandes Tendances, Tendances Locales, Adaptation Technologique, et
Aménagement du Territoire), on construit un scénario plus complet, qui combine un scénario
de chaque thématique pour former un récit cohérent d’évolution : c’est le scénario
« systémique ».
Les scénarios thématiques :
Les scénarios thématiques sont divisés en 4 grands thèmes : Les grandes tendances globales,
les tendances locales, l'aménagement du territoire et l'adaptation technologique.
Figure 4 : Schéma récapitulatif des scénarios thématiques
Source : Document interne au projet, Scénarios pour Toulouse 2010-2100, réalisé et validé par tous les
partenaires en 2011.
Réalisation : Camila Legroux, Master 2 SIGMA – Université de Toulouse II – Le Mirail, 2011 / 2012.
13
Les scénarii systémiques :
Les scénarii systémiques sont réalisés à partir des scénarii thématiques. En effet, en
combinant les différentes hypothèses des scénarii thématiques, plusieurs scénarii systémiques
ou prospectifs ont été définis entre les partenaires du projet. 6 scénarios ont été élaborés. Nous
proposons l’exemple du scénario n°1, dit scénario « Réactif ».
Scénario systémique n°1 : Réactif:
Le choc pétrolier provoque brutalement une crise économique dans la ville dont
l'activité est centrée autour d'un unique pôle d'excellence. En parallèle, aucune politique
climatique volontariste mondiale n'est mise en place. Pour faire face à la nouvelle donne
économique, des actions curatives sont entreprises au niveau local : l'urbanisation de la
mégalopole est dès lors contrôlée, les nouvelles technologies favorisant les économies
d'énergie sont développées à la hâte. Il n'y a cependant pas de véritable réflexion globale et on
constate un manque de recul quant à la mise en place d'un développement urbain durable.
1.3.
La mission et les objectifs du stage
L’objectif du projet ACCLIMAT est donc d'évaluer les effets du changement climatique
en milieu urbain, à long terme (2100). Pour cela, une des étapes essentielles en fin de projet
est la visualisation des résultats. C'est dans ce cadre qu'a eu lieu mon stage de Master 2, et
cela en très forte interaction avec l'objet d'un autre stage sur le même projet. En effet, j'ai
travaillé en binôme avec Geoffray Blanc, étudiant en master 2 Géographie de
l'Environnement et du Paysage, à l'Université de Toulouse II – Le Mirail, notamment durant
les deux premiers mois de stage.
1.3.1.
Les objectifs du stage
Durant le stage, principalement deux objectifs étaient à atteindre.
Dans un premier temps, il a fallu définir un système d'indicateurs transversaux et
« souhaitables » permettant de traduire les impacts calculés par les différents modèles de
simulation.
Dans un second temps, après validation d'une liste d'indicateurs, l'objectif était la
visualisation de ceux-ci. Ce deuxième objectif a dominé ma mission de stage qui a consisté à
développer un outil de visualisation des impacts d'évolutions possibles de la ville et du climat
(voir figure 5).
14
Figure 5 : Schéma représentant l’organisation de l’environnement de développement
Réalisation : Camila Legroux, master 2 SIGMA 2011/2012
15
Une optimisation de la visualisation trouve tout son intérêt dans ce projet dans la
mesure où elle permet une interprétation plus facile des résultats. Mais aussi, elle facilite
l’analyse comparative et évolutive des résultats en fonction des scénarios.
1.3.2.
Le déroulement du stage
Pour atteindre les objectifs fixés, un plan de travail détaillant brièvement les étapes
principales du stage a été défini en début de stage.
Figure 6 : Grandes étapes prévues pour le stage
Source : Julia Hidalgo (encadrante du stage), Colette Marchadier et Valéry Masson ;
Réalisation : Camila Legroux, Master 2 SIGMA – Université de Toulouse II – Le Mirail, 2011 / 2012
Afin de visualiser les indicateurs sélectionnés, il a fallu tout d'abord définir les types de
visualisation possibles pour chaque indicateur :
 spatiale : cartes thématiques ;
 temporelle : courbes d'évolution ;
Mais aussi, les échelles de représentation :
 mailles de 500 x 500 m ;
 ensemble de l'agglomération toulousaine;
 etc...
16
Une fois le choix des représentations établi, de nombreux traitements sur les données ont été
effectués sur le lociciel SIG OrbisGis dans le but de pouvoir visualiser les résultats par la
suite.
Alors qu’un des objectifs de ma mission de stage était le développement d’un outil de
visualisation des résultats, Geoffray Blanc, mon binôme pour ce stage, étudiant en master 2
« Environnement et Paysage », a lui travaillé sur les indicateurs durant les 5 mois. Il a pu
proposer ainsi une analyse fine de chaque indicateur.
Par ailleurs, la présence et l'encadrement des personnes ressources du projet tout au long du
stage ont permis l'atteinte des objectifs fixés.
Figure 7 : Les personnes ressources du stage
Les structures de recherche
Personnes ressources
Leurs rôles
Colette Marchadier
Coordinatrice du projet
Valéry Masson
Responsable
projet
scientifique
du
Julia Hidalgo (encadrante du Développement des scénarios
stage)
climatiques
Centre National de Recherches
Grégoire Pigeon
Météorologiques (CNRM)
Anne-Lise Beaulant
Aude Lemonsu
CERFACS9 + CNRM
Etudes sur les indicateurs de
confort
(UTCI=Universal
Thermal Climate Indice) et les
indicateurs de consommations
énergétiques.
Delphine Chouillou
Ingénieur en bâtiments.
Marie-Pierre Moine
Développement de la plateforme
de simulation ACCLIMAT
Source : Geoffray Blanc et Camila Legroux, 2012.
Après avoir fait le point sur le contexte du stage : la structure d'accueil d'une part, les
objectifs du projet d'autre part et, plus spécifiquement les objectifs de la mission de stage, il
convient désormais de présenter (de manière non exhaustive ici) les données de sortie des
modèles à notre disposition, et qui nous permettront de définir des indicateurs. Enfin, après un
bref état de l'art des indicateurs existants en matière de changement climatique, d'évolution de
la ville, de consommation énergétique, etc..., nous serons en mesure de présenter les
indicateurs retenus et validés dans le cadre du projet ACCLIMAT, et qui découlent des
données de sortie des modèles disponibles.
9 Centre Européen de Recherche et de Formation Avancée en Calcul Scientifique
17
II.
2.1.
DEFINITION D’UN SYSTEME D’INDICATEURS
Méthodologie de sélection et de validation des indicateurs
Afin de proposer un système d’indicateurs, nous avons opté pour une méthodologie
combinant à la fois une approche descendante (Bottom-up) et une approche ascendante (Topdown)
« Les impacts évalués par les différents modèles de la plateforme seront traduits sous
forme de systèmes d’indicateurs, identifiés grâce au croisement d’une approche descendante
partant des objectifs des décideurs (« backcasting ») et d’une approche montante dont le point
de départ est liés aux contraintes d’opérationnalité) ».10
Dans un premier temps, nous avons privilégié l’approche descendante ou Bottom-up.
Celle-ci a consisté à partir des données de sortie des modèles disponibles ou accessibles, à les
analyser et examiner comment il est possible de les exploiter, cela dans le but de remonter aux
problématiques fondamentales et de proposer et définir des indicateurs permettant d’évaluer
les impacts du changement climatique sur la ville. Cette étape initiale nous a permis de
produire une première ébauche de système d’indicateurs.
Puis dans un second temps, nous avons intégré l’approche ascendante à notre démarche.
Celle-ci consiste à analyser et relever les pratiques déjà existantes en la matière pour faire
émerger des indicateurs. Pour cela, nous avons d’une part fait de nombreuses recherches
bibliographiques : des documents théoriques et opérationnels sur les indicateurs existants, le
changement climatique, la prospective territoriale, mais aussi des documents de projets
similaires déjà existants. D’autre part, nous avons été en contact avec des professionnels de
l’urbanisme et de l’environnement, et des chercheurs en météorologie/climatologie,
architecture, etc. Ces échanges avec ces professionnels nous ont permis d’une part de prendre
connaissance de leurs préoccupations et de leurs besoins, et d’autre part, de relever quels sont
les indicateurs les plus souvent exploités dans les démarches de ces professionnels. Par
ailleurs, en leur faisant prendre connaissance de notre première liste d’indicateurs issue de
l’analyse des données de sortie des modèles, nous avons pu repérer quels sont, parmi ces
indicateurs, ceux qui ont le plus retenu leur attention.
10
Luc Adolphe, Laboratoire de Recherches en Architecture.
18
Figure 8 : Tableau récapitulatif des structures professionnelles rencontrées.
Structures professionnelles
Personnes ressources
Agence d’Urbanisme et Geneviève BRETAGNE
d’Aménagement
du
Territoire Toulouse Aire
urbaine (AUAT)
Bureau d’étude Urbains
Pierre MADIGNER
Bureau d’étude e2d
Marie-Françoise MENDEZ
Direction
Départementale Adeline COURREGES
des Territoires (DDT) de
Rodez
Bureau d’étude Adéquation Mathieu LEPOIVRE
Environnement d’Aurillac
Groupe
de
recherches
GEOgraphie
De
l’Environnement (GEODE UTM)
Laboratoire de Recherches
en Architecture
Direction du Développement
Social (DDS) – Mairie de
Toulouse
Service du Développement
Durable – CU du Grand
Toulouse
Léa SEBASTIEN
Intérêts / Apports pour la
sélection et la validation des
indicateurs
Mise en commun des
indicateurs de l’AUAT et du
CNRM
Intérêt pour les indicateurs de
performance énergétique
Mise
en
relation
des
indicateurs proposés avec les
indicateurs
usuellement
utilisés pour l’élaboration
d’Agendas 21
Intérêt pour les indicateurs en
relation avec l’aménagement
urbain
Vision du professionnel sur
les outils d’aide à la décision
et sur les indicateurs
proposés par le projet
Réflexions sur la cohérence
dans la sélection des
indicateurs
Marion BONHOMME et Travail sur les indicateurs de
Luc ADOLPHE
morphologie urbaine
Florent WAEGHEMAEKER Travail sur le développement
social des quartiers et intérêt
pour la prospective
Christelle Piechtra
Intérêt pour la prospective
territoriale et pour l’analyse
des impacts des décisions
actuelles sur le futur.
Source : Geoffray Blanc et Camila Legroux, 2012.
Ainsi, dans notre démarche globale, nous avons croisé ces deux approches : nous avons fait le
lien entre notre première liste d’indicateurs et les préconisations et intérêts des personnes
rencontrées, dans le but de proposer un système d’indicateurs cohérent et utilisable par le plus
grand nombre de professionnels, décideurs politiques et chercheurs.
19
Figure 9 : Schéma récapitulatif de l’approche Top-down et Buttom-up
Réalisation : Geoffray Blanc, Master 2 Villes et Environnement – Université de Toulouse II – Le Mirail, 2011 /
2012
La combinaison de ces deux approches dans notre méthodologie a permis de valider
les indicateurs à retenir dans le cadre du projet. Pour cela, de nombreuses réunions de travail
avec les personnes ressources du projet ont été nécessaires.
Lors de l’étape de validation des indicateurs, l’objectif était de produire un système
d’indicateurs qui soit à la fois un outil d’analyse ou d’aide au diagnostic scientifique, et un
outil d’aide à la décision pour les décideurs politiques, les professionnels de l’urbanisme et les
chercheurs.
En effet, le système d’indicateurs proposé doit être un outil permettant d’effectuer, valider,
justifier, évaluer ou corriger des décisions.
Après avoir expliqué notre méthodologie de sélection et de validation des indicateurs et
son intérêt, il convient désormais de présenter les données de sortie des modèles dont nous
disposons et le système d’indicateurs retenu.
2.2.
Analyse des données de sortie des modèles
Nous disposons des données de sortie des trois principaux modèles : SLEDUM
(NEDUM couplé avec SLEUTH), SURFEX, et GENIUS.
Dans un souci de clarté, le choix a été fait de présenter de manière non exhaustive les données
de sortie. C’est-à-dire que nous ferons ici seulement un récapitulatif des principales sorties, en
insistant notamment sur celles qui nous intéresserons par la suite.
20
Figure 10 : Les principales données de sortie du modèle SURFEX
DONNEES DE SORTIE
Température à 2 mètres
UNITE
DEFINITION
°C
Température moyenne par maille de
500x500m, à un jour et une heure précise,
et à 2 mètres au-dessus du sol. Donnée
disponible par pas de 3 heures
Humidité relative
%
Humidité relative par maille de 500x500m
à un jour et une heure précise, et à 2 mètres
au-dessus du sol. Donnée disponible par
pas de 3 heures
Force du vent
m/sec
Force du vent par maille de 500x500m à un
jour et une heure précise. Donnée
disponible par pas de 3 heures. Choix de la
hauteur à laquelle on nécessite la donnée : à
hauteur d'homme donc à 2m, sinon à 2m au
dessus des bâtiments pour évaluer le
potentiel d’éolienne urbaine
UTCI
(Urban
Thermal Seuils pré-définis
Le calcul de l’UTCI permet de représenter
Comfort Indicator)
de
confort la température ressentie par une personne.
(température
Il prend en compte plusieurs facteurs :
ressentie d'UTCI)
–
température de l'air par maille
température de l’environnement
–
niveau d'activité
–
humidité de l’air
–
rayonnement
–
force du vent
Il existe plusieurs calculs d’UTCI en
fonction des profils d’individu et de leur
situation :
- UTCI IN : température ressentie
par une personne à l’intérieur d’un
bâtiment ;
- UTCI OUT-SUN : température
ressentie par une personne à
l’extérieur au soleil ;
- UTIC OUT-SHAD : température
ressentie par une personne à
l’extérieur à l’ombre.
Température minimale
°C
Température minimale par maille sur une
période pré-définie
Température maximale
°C
Température maximale par maille sur une
période pré-définie
Consommation
énergétique KWhef/an
Consommation énergétique pour le
pour le chauffage
chauffage par maille de 2000x2000m (pour
l’instant) par an
Consommation
énergétique KWhef/an
Consommation énergétique pour la
pour la climatisation
climatisation par maille de 2000x2000m
(pour l’instant) par an
Source : Delphine Chouillou, Geoffray Blanc et Camila Legroux, CNRM, 2012.
21
Figure 11 : Les principales données de sortie du modèle NEDUM couplé à SLEUTH
DONNEES DE SORTIE
Densité de population
Densité de bâti
Coûts des loyers
UNITE
Hab / maille
m² / maille
Euros / m² ou
par habitant
min / jour /
habitant / trajet
DEFINITION
Densité de population par maille de 500x500m
Densité de bâti par maille de 500x500m
Coût moyen des loyers par maille de
500x500m
Temps de transports en voiture
Temps moyen de transports en voiture par
maille de 500x500m, par jour et par habitant,
par trajet (à multiplier par 2 pour avoir aller
retour)
Temps de transport en commun min / jour / Temps moyen de transports en TC par maille
habitant / trajet de 500x500m, par jour et par habitant, par
trajet (à multiplier par 2 pour avoir aller
retour)
Nombre de personnes utilisant Personnes / jour Nombre moyen de personnes utilisant les
les transports en commun
transports en commun par maille de
500x500m et par jour
Distance parcourue en voiture km / jour / Distance moyenne parcourue en voiture par
par habitant
habitant / trajet habitant, par maille de 500x500m et par jour,
par trajet (à multiplier par 2 pour avoir aller
retour)
Figure 12 : Les principales données de sortie du modèle GENIUS
DONNEES DE SORTIE
Nombre d’habitants
Type d’usage
UNITE
Habitants
maille
Surface de plancher
Type d’îlots
m² / maille
Nombre de ménages
Ménages
maille
m² / maille
m² / maille
m² / maille
Surface de routes
Surfaces végétales
Surface totale bâtie
Age moyen des bâtiments
Type de bâtiments
Type de chauffage
Hauteur des bâtiments
DEFINITION
/ Nombre d’habitants par maille de 250x250m
Type majoritaire d’usage des bâtiments par maille
de 250x250m : Résidentiel, bureau, commercial
Surface de plancher par maille de 250x250m
7 types d’îlots définis : Logement individuel,
collectif, immeuble de grande hauteur, …
/ Nombre de ménages par maille de 250x250m
Surface de routes par maille de 250x250m
Surfaces végétales par maille de 250x250m
Surface totale bâtie au sol par maille de
250x250m
Année
de Age moyen des bâtiments par maille de
construction
250x250m
Type majoritaire de bâtiments par maille de
250x250m : Collectif / individuel
Type de chauffage majoritaire par maille de
250x250m : Collectif / individuel / électrique /
etc…
m
Hauteur moyenne des bâtiments par maille
22
Ces principales données de sortie des modèles à notre disposition vont nous permettre
de définir des indicateurs. Certaines de ces variables seront directement exploitables en tant
qu’indicateurs, tandis que d’autres devront être combinées et/ou faire l’objet de calculs.
Par ailleurs, les données de sortie, étant issues de différents modèles, sont contenues
dans des fichiers de formats différents. Nous avons à notre disposition d’une part, des fichiers
de données raster, et d’autre part, des fichiers au format vecteur, ces deux types de fichiers
étant exploitables et visualisables avec des logiciels SIG11.
Après avoir fait le point sur les données de sortie des modèles, il convient désormais de
présenter le système d’indicateurs que nous avons retenu.
2.3.
Proposition d’un système d’indicateurs
Le système d’indicateurs que nous proposons et qui a été validé est composé de 6 grandes
thématiques : le climat, le confort de l’habitant, la socio-économie, l’énergie,
l’environnement, et l’aménagement du territoire.
Chacune de ses thématiques contient plusieurs indicateurs12.
11
12
Voir plus de détails sur les formats de sortie des modèles en annexe n°1
Voir détail des indicateurs en Annexe n°2
23
Figure 13 : Schéma récapitulatif du système d’indicateurs pour le projet ACCLIMAT
Réalisation : Camila Legroux et Geoffray Blanc, Université de Toulouse, 2011/2012
24
III.
3.1.
DEVELOPPEMENTS ET OUTIL DE VISUALISATION
Outil logiciel et environnement de développement
Pour la visualisation des résultats dans le cadre du projet ACCLIMAT, le logiciel SIG
choisi par l’équipe est OrbisGIS. Nous proposons de présenter ce logiciel puis de voir quelle
est sa place dans l’environnement de développement.
3.1.1.
OrbisGIS, un logiciel SIG open-source
OrbisGIS est un Système d'Information Géographique (SIG) libre, et disponible sur
internet à l'adresse suivante : http://www.orbisgis.org/download:index .
Ce SIG est orienté pour la modélisation scientifique.
Comme tous les SIG, OrbisGIS permet la création, la mise à jour, la modification, le
traitement, le partage et la représentation de données spatiales. Par ailleurs, ce logiciel peut
aussi bien lire et visualiser des fichiers vectoriels que des fichiers raster.
L’interface du logiciel OrbisGIS a l’avantage d’être modulaire, ce qui permet à chaque
utilisateur d’agencer ou « construire » son espace de travail comme il le souhaite. En effet, les
différents modules peuvent être placés à n’importe quel endroit dans l’interface.
Figure 14 : Interface du logiciel OrbisGIS (version 4.0)
Conception : Camila Legroux, master 2 SIGMA 2011/2012 (Capture d’écran : Août 2012)
25
Par ailleurs, les différents modules sont affichables ou non. Pour cela, il suffit de
cocher ou décocher les cases dans le menu « Vue ». (Voir figure 15)
Figure 15 : Les modules de l’interface d’OrbisGIS
Conception : Camila Legroux, master 2 SIGMA 2011/2012 (Capture d’écran : Août 2012)
Ce logiciel est développé par l’IRSTV (Institut de Recherche en Sciences et Techniques de la
Ville) basé à Nantes. Depuis 2007, une équipe de l’IRSTV se charge de développer ce
logiciel, entièrement en java. En 5 ans, 11 versions du logiciel 13 ont vu le jour. En effet,
l’équipe de développement, principalement composée de géomaticiens et d’informaticiens 14,
cherche sans cesse à développer et optimiser les fonctionnalités de ce logiciel.
Ainsi, au début du stage, nous avons pris en main et commencé à travailler sur la
version stable 3.0.2 – Barcelona. Puis au cours du stage et en discussion avec l’équipe
d’OrbisGIS, le choix a été fait de travailler avec la version beta 4.0 – La Rochelle – qui est
actuellement en cours de développement et d’évolution, mais qui est tout de même stable.
Néanmoins, certaines fonctionnalités ont été modifiées entre les deux versions, notamment en
ce qui concerne l’écriture de requêtes SQL. Ainsi, une phase supplémentaire non prévue dans
le calendrier initial a été nécessaire pour « traduire » les requêtes SQL codées pour la version
3.0.2 afin qu’elles soient exploitables sur la version 4.0.
Avec l’exemple ci-dessous, nous pouvons constater qu’entre la version 3.0.2 et la
version 4.0, les requêtes SQL ne sont pas les mêmes. Il a donc fallu réécrire toutes les
requêtes SQL afin de pouvoir travailler avec la version 4.0.
13
14
Voir annexe n° 3
Voir annexe n° 4
26
Figure 16 : Traduction de requêtes SQL pour vectoriser des fichiers raster, de la version 3.0.2 à la version
4.0.
Conception et Réalisation : Camila Legroux, master 2 SIGMA 2011/2012 (Capture d’écran : Août 2012)
Après avoir présenté l’outil SIG utilisé dans le cadre du projet, nous expliquerons
désormais l’environnement de développement et la place qu’occupe l’interface de
visualisation avec OrbisGIS dans celui-ci.
3.1.2.
L’environnement de développement
L’outil de visualisation s’intègre dans un environnement de développement composé de 3
éléments. 15
En effet, dans un premier temps, la plateforme de simulation via son interface permet à
un utilisateur de choisir des paramètres de simulation tels que les scénarios, les dates de
résultats souhaitées, etc.
Dans un deuxième temps, une fois les calculs de simulation faits, les fichiers de
données de sortie vont être stockés dans une arborescence bien précise.
Enfin, ces fichiers de données de sortie vont pouvoir être exploités par le SIG
OrbisGis pour visualiser les résultats. C’est dans cette troisième étape que le travail technique
de mon stage est inclus.
Après une brève explication de l’organisation de l’environnement de développement,
il convient désormais de présenter les développements qui ont été effectués sur le logiciel
OrbisGIS dans le but de traiter les données et calculer les indicateurs, puis de les visualiser.
15
Voir figure n° 5.
27
3.2.
Le développement des requêtes SQL
Afin de visualiser les indicateurs, la génération de requêtes SQL a été nécessaire. Nous
nous proposons donc ici d’expliquer pourquoi, mais aussi de donner un exemple.
3.2.1.
Pourquoi le développement de requêtes SQL a-t-il été nécessaire ?
OrbisGIS est un logiciel SIG qui propose très peu de « clic bouton ». C’est-à-dire qu’il
y a peu de fonctionnalités automatisées, où il suffirait de cliquer sur un bouton pour engendrer
une action sur des données ou des fichiers. Ainsi, pour réaliser des traitements sur des
données, nous avons dû développer des requêtes SQL.
Le SQL (Structured Query Language ou « Langage de requêtes structurées ») est un
langage de base permettant de créer des bases et tables de données, d’interroger et de mettre à
jour des données, etc…
Par exemple, pour vectoriser un fichier ASCII de manière à avoir une table avec d’une
part un objet géométrique pour chaque cellule, et d’autre part la valeur de chaque objet, il
n‘existe pas de fonction automatisée « vectoriser ». Ainsi, pour réaliser cette fonction, la
génération d’une requête SQL est nécessaire.
Figure 17 : OrbisGIS, un logiciel doté d‘une console SQL
28
Comme nous pouvons le constater sur l’image ci-dessus, le logiciel OrbisGIS offre la
possibilité d’ouvrir dans son interface une console SQL afin de générer des requêtes. Par
ailleurs, de nombreuses fonctions spatiales sont développées par l’équipe OrbisGIS et
permettent de nombreuses actions sur les données.16
La console SQL d’OrbisGIS a donc été un outil omniprésent dans ma mission de stage. Pour
illustrer l’importance de celui-ci dans mon travail, nous étudierons l’exemple des traitements
effectués pour les données de densité de population issues du modèle NEDUM.
3.2.2. Les requêtes SQL développées pour traiter les données et calculer les indicateurs
Dans un premier temps, comme nous l’avons mentionné auparavant, nous disposons
de fichiers raster ASCII GRID, issus des modèles NEDUM et SURFEX. Malgré la possibilité
de visualiser ces fichiers sur OrbisGIS, nous n’avons pas la possibilité de consulter les
données contenues dans ces fichiers, tel que c’est le cas pour des fichiers vecteurs.
Figure 18 : Exemple de visualisation d’un fichier ASCII GRID : la densité de population en 2027 (modèle
NEDUM)
Par ailleurs, comme il est possible de le constater sur l’image ci-dessus, la
visualisation de ce type de fichiers reste assez sommaire sur OrbisGIS, et nous n’avons pas
d’informations sur les valeurs traduisant le dégradé de couleurs.
16
Voir le détail des fonctions spatiales d’OrbisGIS en annexe n°
29
C’est notamment pour ces raisons que le choix a été fait de vectoriser les fichiers ASCII. Cela
dans le but d’obtenir des tables avec un champ « the_geom », qui contient les informations
relatives à chaque cellule, et un autre champ contenant les valeurs de chaque objet
géométrique nouvellement créé.
Pour cela, la génération de requêtes SQL a été nécessaire. Nous nous proposons d’illustrer ces
requêtes SQL via l’exemple de l’indicateur « densité de population »17, qui est une donnée de
sortie en fichiers ASCII du modèle NEDUM.
Figure 19 : Requête SQL pour vectoriser des fichiers ASCII GRID
Cette routine SQL se décompose en 4 phases :
-
-
17
La première phase permet d’ouvrir le ou les fichiers dans OrbisGIS sans avoir à passer
par l’interface (clic droit > open file). Cela est possible grâce à la fonction REGISTER
en indiquant ensuite le chemin du ou des fichiers, ici le fichier
« densite_de_population_2027.asc ».
Dans un second temps, nous vectorisons le fichier ASCII GRID (.asc) en créant une
nouvelle table (ici, « vecto ») qui contiendra les données du raster, en appelant la
fonction ST_RASTERTOPOLYGONS. Néanmoins, nous ne pouvons nous arrêter à
cette étape dans la mesure où si plusieurs pixels accolés ont la même valeur, ceux-ci
vont être fusionnés et ne former qu’un seul polygone. Ainsi, la table créée n’a pas le
même nombre de polygones que le nombre de maille du fichier ACSII.
Voir plus de détails avec le tableau des indicateurs en annexe n°2
30
Figure 20 : Exemple de visualisation d’un fichier ASCII GRID, avec un échantillon de données de densité
de population
-
Cela pose problème dans le cas où nous voudrions par la suite faire une jointure entre
deux tables de la densité de population mais à des années différentes, puisque les
valeurs peuvent changer entre deux dates et les polygones ne seraient alors pas
identiques. Nous devons donc poursuivre la routine SQL dans le but d’obtenir à
chaque fois des tables de même taille et avec des polygones de même taille que pour
les fichiers raster dont nous disposons.
La troisième étape consiste donc à créer une grille de même taille que la table
« vecto » précédemment créée et avec des géométries de 500 x 500 mètres, pour
obtenir le même nombre de polygones que de mailles du fichier raster. Pour cela, nous
faisons appel à la fonction ST_CREATEGRID avec laquelle nous spécifions nos
paramètres, à savoir la taille de la grille et la taille des cellules.
La dernière étape va être de créer une nouvelle table dans laquelle nous voulons toutes les
géométries de la grille créée. Pour cette nouvelle table, nous voulons affecter la valeur des
pixels du raster (avec la fonction ST_PIXELVALUE) au centroïde de chaque polygone de la
grille. Cette étape revient en quelque sorte à superposer la grille et le raster, et de créer une
nouvelle table en « piochant » les informations de chaque fichier que nous souhaitons : la
géométrie et l’identifiant de la grille, et les valeurs du fichier raster.
31
Figure 21 : Comparaison de la visualisation d’un fichier ASCII GRID et d’un fichier vecteur
Comme nous pouvons le voir sur l’image ci-dessus, avec à gauche la carte de la
densité de population issue des données de la table que nous avons créer en vectorisant le
fichier ASCII, et à droite, la carte de la densité de population du fichier ASCII GRID, la
représentation visuelle d’un fichier vecteur est plus aisée et détaillée. Par ailleurs, il est
désormais possible de choisir le mode de représentation que nous souhaitons. Ici, nous avons
fait le choix de représenter les données de densité de population en 14 classes d’intervalles.
Pour une visualisation plus détaillée, nous pouvons aussi superposer sur la carte de la densité,
les limites communales et les principaux cours d’eau. Cela permet de mieux situer les
résultats.
32
Figure 22 : Visualisation de la densité de population en 2027
Conception et Réalisation : Camila Legroux, master 2 SIGMA 2011/2012
Dans un second temps, la vectorisation permet aussi en fonction des besoins, de
réaliser des traitements qui sont impossibles avec des fichiers ASCII sur OrbisGIS, à savoir
par exemple des jointures de tables, des calculs, etc … Nous proposons d’illustrer cela via
l’exemple de la densité moyenne de la population sur toute l’aire urbaine toulousaine, pour
une année donnée (nous resterons sur l’année 2027 pour cet exemple). Grâce à la
vectorisation, nous disposons désormais d’une table avec la densité de population par cellule
de 500 x 500 mètres.
33
Figure 23 : Echantillon de la table de densité de population créée :
Nous souhaitons désormais obtenir une seule valeur qui soit la moyenne de toutes ces
données, afin d’avoir la densité moyenne de la population sur toute l’aire urbaine toulousaine
en 2027. Cela nous permet ensuite de pouvoir visualiser l’évolution de la densité moyenne de
la population sur plusieurs années. Par souci de clarté dans l’explication du calcul de la
moyenne, nous l’illustrerons uniquement avec les données de la densité de population en
2027.
Figure 24 : Requêtes SQL pour créer une nouvelle intégrant le calcul d’une moyenne
Dans une première phase, nous créons une nouvelle table dans laquelle nous « stockerons » la
moyenne que nous allons calculer. Dans cette table, nous créons 2 colonnes, une appelée
« année » où nous aurons l’année des données (ici, 2027), et la deuxième appelée
« avg_densite » où nous aurons la moyenne de la densité de population. Bien sûr, nous
donnons ici un exemple uniquement avec la moyenne, mais nous aurions pu aussi créer
plusieurs colonnes, pour par exemple avoir aussi la valeur maximale, minimale, la médiane,
etc.
Puis, dans une seconde phase, nous mettons à jour les colonnes, avec la fonction SQL
« INSERT INTO », où nous y affectons des valeurs. Pour la première colonne, nous y
ajoutons manuellement la valeur « 2027 », puis dans la seconde colonne, nous spécifions que
nous
voulons
la
moyenne
du
champ
« densite_2027 »
de
la
table
« densite_population_2027 ». Pour cela, nous faisons appel à la fonction AVG.
A l’issue de cette requête SQL, nous obtenons la table illustrée à la figure n° 26.
34
Figure 25 : Table de densité moyenne de population de l’aire urbaine toulousaine en 2027.
Dans cette table, nous n’avons qu’un enregistrement dans la mesure où pour cet exemple,
nous avons fait le choix de ne calculer que la moyenne de la densité pour l’année 2027. Mais,
par exemple, nous disposons de 3 fichiers ASCII GRID de densité de population en 2027, en
2047 puis en 2067. Nous pouvons vectoriser ces trois fichiers. Puis, répéter 3 fois la mise à
jour de la table « avg_densite_de_population » (INSERT INTO…) de manière à avoir 3
enregistrements dans cette table : un pour 2027, un 2047 et enfin un pour 2067.
Figure 26 : Table des densités moyennes de population de l’aire urbaine toulousaine en 2027, 2047 et 2067
Avec cette nouvelle table créée et issue de calculs, il est possible de générer des graphiques
d’évolution. Nous présenterons cela dans la sous-partie suivante.
Ainsi, comme nous avons pu le voir avec ces quelques exemples représentatifs, la
génération de requêtes SQL a été une phase nécessaire.
Nous nous proposons désormais de présenter un autre outil qui nous a été utile dans la
mission de stage : l’outil Beanshell.
3.3.
L’outil BeanShell et le développement de scripts
La console SQL d’OrbisGIS permet la génération de requêtes SQL pour interroger des
tables et bases de données. Néanmoins, celle-ci ne nous permet pas, par exemple, de déclarer
des variables, de programmer des structures de contrôles permettant d’automatiser les
35
traitements. Or l’outil de visualisation du projet ACCLIMAT doit pouvoir être utilisable par
un utilisateur néophyte et qui n’a par exemple pas de compétences en développement de
requêtes SQL. Par ailleurs, il y a un nombre important de fichiers de données de sortie de la
plateforme de simulation. Il serait donc long et fastidieux de s’atteler à générer des requêtes
SQL pour tous les fichiers. Ainsi, c’est pour ces deux raisons que le développement de scripts
Beanshell a été nécessaire pour automatiser les requêtes SQL et ainsi, simplifier l’utilisation
de l’outil de visualisation pour les utilisateurs.
En outre, le logiciel OrbisGIS et les requêtes SQL ne proposent pas de fonctionnalités
permettant de dessiner des graphiques. Or, visualiser cartographiquement d’une part, et
graphiquement d’autre part était un des objectifs de la mission de stage. Ainsi, pour pouvoir
générer des graphiques, nous avons aussi dû développer des scripts BeanShell.
Dans un premier temps, nous présenterons ce qu’est l’outil Beanshell. Dans un second
temps, nous verrons son utilité dans la génération de graphiques. Puis, nous étudierons ensuite
comment l’outil BeanShell nous a permis d’automatiser les requêtes SQL déjà définies.
3.3.1.
Qu’est-ce que l’outil BeanShell ?
BeanShell est un interpréteur Java qu’il est possible d’intégrer dans des applications.
Au cours du stage, cet outil a été pris en main et largement utilisé dans la mesure où OrbisGIS
dispose d’une console BeanShell.
Figure 27 : OrbisGIS, un logiciel doté d‘une console BeanShell
36
Via le BeanShell, il est possible d’écrire des applications en Java. Il convient ici de présenter
brièvement le langage Java.
Le langage Java est un langage de programmation informatique orienté objet. « Un objet est
avant tout une structure de données. Autrement, il s’agit d’une entité chargée de gérer des
données, de les classer, et de les stocker sous une certaine forme. […] Un objet regroupe les
données et les moyens de traitement de ces données. »18
L’objet rassemble deux éléments :
-
Les champs ou variables qui ont en charge les données à gérer. Ils peuvent posséder
un type défini au préalable : nombre entier, réel, caractère, etc…
Les méthodes sont les éléments de l’objet qui servent d’intermédiaire entre les
données et le programme ou l’application. Plus simplement, ce sont les procédures ou
fonctions destinées à traiter les données.
Pour manipuler des objets, il est nécessaire de définir ou faire appel à des classes, c’est-à-dire
définir la structure de la classe : les données ou variables, et les méthodes. Java propose
d’ailleurs toute une série de classes prédéfinies, organisée en packages.
Les packages permettent la concaténation de plusieurs classes.
Figure 28 : Tableau des principaux packages Java
Nom
java.lang
java.util
java.io
javax.swing
Java.sql
Descriptif
Ce package fournit des classes qui sont
fondamentales pour la conception du langage
Java. Il contient les classes de base.
Il contient des structures de données. (la
classe Date par exemple)
Il fournit des classes pour manipuler et gérer
des flux de données
Il contient tout ce qui a trait aux composants
graphiques tels que les boutons, les listes
déroulantes, boîtes de dialogue, etc…
Ce package permet l’accès, la connexion et le
traitement de bases de données relationnelles
en SQL.
Source : docs.oracle.com ; Réalisation : Camila Legroux, master 2 SIGMA 2011/2012
Ainsi, BeanShell est un outil qui permet de créer des applications en appelant des
classes, en déclarant des variables, en utilisant des boucles, etc…
18
« Introduction à la Programmation Orientée Objet, Eric Ségoillot, publié en 2004 et mis à jour en 2011.
37
3.3.2. Le développement de scripts BeanShell pour la génération de graphiques
Pour la génération de graphiques nous avons utilisé la bibliothèque JFreeChart.
JFreeChart est une bibliothèque Java open-source qui permet d’afficher des données
sous forme de graphiques. Elle possède de nombreux avantages :
- Cette bibliothèque est gratuite.
- C’est une API (Application Programming Interface) qui supporte de nombreux types
de graphiques (barres, lignes, courbes, camembert…)
- Une documentation conséquente (mais toutefois payante)
- Plusieurs types d’exports des graphiques (PDF, EPS, SVG, PNG, JPEG, …)
Pour utiliser cette bibliothèque, il faut la télécharger. Elle est disponible sur le site
http://www.jfree.org/jfreechart/ .
La présentation d’un exemple de script développé pour obtenir des graphiques
s’impose. Pour cela, nous resterons sur l’exemple des données de la densité de population
issues de NEDUM. L’objectif est de créer des graphiques d’évolution, à savoir des graphiques
représentant des données à des dates différentes.
Nous disposons de fichiers ASCII GRID de densité de population pour les années
2027, 2047 et 2067.
Après avoir effectué les requêtes SQL présentées précédemment : la vectorisation puis la
création d’une table avec toutes les moyennes de densité de population à des dates différentes
(voir figure 26) le développement d’un script BeanShell permet la création d’un graphique
sous forme de courbe d’évolution.
Figure 29 : Première étape du script BeanShell pour générer des graphiques
Dans un premier temps, il convient de charger la bibliothèque JFreeChart avec la
fonction « AddJAR » pour pouvoir disposer de toutes ses classes nécessaires à la génération
de graphiques. Puis grâce à la fonction « import », il faut importer les classes Java standard,
38
les classes d’OrbisGIS et les classes de la bibliothèque JFreeChart qui seront nécessaires par
la suite.
Figure 30 : Deuxième étape du script BeanShell pour générer des graphiques
Dans un second temps, nous appelons des classes propres à OrbisGIS qui permettent la
gestion de données. Ainsi, nous spécifions que nous voulons avoir accès aux données de la
table « avg_densite_population » (voir figure n°26).
Figure 31 : Troisième étape du script BeanShell pour générer des graphiques
Ensuite, nous appelons la classe Iterator du package java.util qui contient des classes
en lien avec les structures des données. Avec la méthode « hasNext » de la classe Iterator,
nous réalisons une boucle « While » dans laquelle nous spécifions que tant qu’il y a un
enregistrement ou une ligne dans la table de données, nous voulons récupérer les valeurs x et
y. Le [0] correspond à la première colonne qui est dans notre cas l’année, et le [1] à la
deuxième colonne de ma table qui est relatif à la densité moyenne. Puis nous ajoutons les x et
y récupérés par la boucle dans le « XYSeries » qui est la courbe. Dans cet exemple, nous
souhaitons l’affichage d’une seule courbe, ainsi nous avons défini un seul « XYSeries ».
Néanmoins, il est possible de définir plusieurs « XYSeries ». Cela est notamment intéressant
dans les cas où il est souhaitable, dans un même graphique, de représenter plusieurs courbes
représentant l’évolution de la densité moyenne de population sur l’aire urbaine toulousaine,
mais en fonction de différents scénarios.
39
Figure 32 : Quatrième étape du script BeanShell pour générer des graphiques
Enfin, dans un dernier temps, il convient de spécifier les paramètres du graphique : la légende,
le titre, la couleur du fond, etc… Mais aussi, la fenêtre dans laquelle s’affiche le graphique
avec la taille notamment.
Ce script BeanShell permet donc la génération d’un graphique contenant les données de la
table « avg_densite_population » avec en x, les années et en y, la densité moyenne de
population.
Figure 33 : la génération d’un graphique d’évolution de la densité moyenne de la population
Source : Données NEDUM ; Conception et Réalisation : Camila Legroux, master 2 SIGMA 2011/2012 (Capture
d’écran : Août 2012)
40
Néanmoins, nous pouvons constater quelques manques à la visualisation de ce
graphique. En effet, les années s’affichent en nombre entier, alors qu’il serait souhaitable que
celles-ci soient en format « date ». D’après mes recherches, cela est possible en travaillant
avec les classes DateAxis et TimeSeries de la bibliothèque JFreeChart. Par ailleurs, les
ordonnées commencent à la valeur 0, alors qu’il serait plus visuellement esthétique d’avoir un
graphique, qui zoomerait sur les valeurs de la courbe, ainsi il conviendrait de modifier les
paramètres du graphique.
Ces manques sont dus à plusieurs raisons. D’une part, par un manque de temps dans la
mission de stage pour développer ces scripts. En effet, avant de pouvoir développer, il a fallu
prendre en main l’outil BeanShell et le langage Java mais aussi la bibliothèque JFreeChart.
Les recherches et les tests réalisés pour comprendre le fonctionnement de ces outils sont des
étapes assez longues. D’autre part, je n’ai pas eu la documentation et les tutoriels (documents
payants) de la bibliothèque JFreeChart durant mon stage, ainsi il m’a été difficile de
« creuser » toutes les possibilités et fonctions de celle-ci. Par ailleurs, la documentation
gratuite sur internet, via les forums par exemple, est peu présente.
3.3.3. Des scripts BeanShell pour l’automatisation des requêtes SQL
Les requêtes SQL permettent d’interroger et de faire des traitements sur des bases ou
tables de données. Pour cela, il faut écrire manuellement le nom des tables, des champs, etc.
Or, nous souhaitons faire en sorte que l’utilisateur ait le moins d’actions possible à
réaliser pour le traitement des données. En effet, pour un utilisateur novice en SIG et en
requêtes SQL, il s’avèrerait relativement difficile de pouvoir réaliser des traitements sur les
données.
Ainsi, pour simplifier l’utilisation, nous avons fait le choix de combiner un script
BeanShell avec les requêtes SQL déjà développées. En effet, l’objectif ici est d’automatiser
les traitements des fichiers et des données. A travers l’exemple de la densité de la population
toujours, nous pourrons illustrer la manière dont nous procédons pour l’automatisation.
Grâce au BeanShell, nous pouvons déclarer des variables et faire des boucles de manière à ce
que les instructions données soient exécutées si les conditions explicitées sont respectées.
41
Figure 34 : Première étape du script BeanShell pour automatiser les requêtes SQL
Dans un premier temps, nous déclarons la variable « pathinfonds » qui est de type
caractère. Celle-ci nous permet d’avoir le chemin où sont stockés les fonds de carte qui nous
serviront pour la visualisation, à savoir les limites communales et les cours d’eau principaux.
Le principe consiste ensuite à exécuter une requête SQL, en écrivant
SQL(« la requête à exécuter ; ») ;
Cette fonction permettant d’appeler des requêtes SQL via le BeanShell sera utilisée tout au
long du script, pour réaliser les différentes requêtes nécessaires.
Le fait de déclarer une variable pour le chemin du dossier contenant les fichiers
nécessaires permet de ne pas avoir à recopier manuellement ce chemin dans le script. Pour
faire appel à cette variable, nous concaténons donc les actions que nous voulons réaliser avec
cette variable, grâce au symbole de concaténation qui est : + variable +.
Nous déclarons deux autres variables de ce même type pour avoir les chemins des dossiers
dans lesquels sont stockées les fichiers de données de sorties (voir l’arborescence figure 5).
Nous en déclarons deux même si ce sont les mêmes chemins. La différence se trouve dans le
fait où une variable (« pathin ») sera utilisée par les requêtes SQL, tandis que l’autre
(« pathin2 ») sera exploitée par la classe Java File du package java.io. En effet, pour faire
appel à des chemins dans les requêtes SQL, il faut les encadrer par des apostrophes
(‘chemin’), alors qu’en Java, le chemin doit s’écrire tel quel.
Figure 35 : Deuxième étape du script BeanShell pour automatiser les requêtes SQL
42
Dans un second temps, nous déclarons une variable « year » de type entier. Celle-ci
contiendra les années, qui sont une des composantes des noms de fichiers de densité de
population. En effet, ceux-ci prennent la forme suivante : name_year.asc, soit ici,
densite_de_population_year.asc. Ainsi, seule l’année change dans le nom du titre.
L’objectif ici est de pouvoir exécuter les requêtes SQL précédemment expliquées sans que
l’utilisateur soit obligé d’entrer manuellement les années. Pour cela, nous initialisons la
variable « year » à 2000. Puis, nous créons une boucle « While » dans laquelle nous
spécifions que la variable « year » doit être inférieure ou égale à 2100. A la fin de cette
boucle, nous réinitialisons la variable year telle que « year = year +1 ». Cela permet de
balayer toutes les années entre 2000 et 2100 disponibles dans le répertoire spécifié. Puis, dans
cette boucle « While », nous faisons appel à la classe File, et nous donnons l’instruction que,
si le fichier existe dans le répertoire, les requêtes SQL qui suivent soient exécutées. Si le
fichier n’existe pas, alors aucune action n’a lieu.
Figure 36 : Troisième étape du script BeanShell pour automatiser les requêtes SQL
Les requêtes SQL à exécuter sont toutes celles que nous avons expliquées précédemment.
Dans notre cas, dans le répertoire spécifié par le chemin (via la variable « pathin »), nous
avons 3 fichiers :
-
densite_de_population_2027.asc
Ainsi, la boucle va commencer à 2000 puis augmenter à chaque fois d’une année, elle va
permettre d’exécuter les requêtes SQL pour ces trois fichiers puisque ce sont les seuls
existants dans le répertoire.
Suite à cela, nous obtenons donc les mêmes fichiers que nous avions en écrivant les
requêtes SQL, mais cette fois, nous n’avons pas eu besoin d’écrire manuellement le nom des
fichiers. Cette automatisation est intéressante dans la mesure où l’utilisateur n’a même pas à
se soucier des fichiers présents dans le répertoire. Le script BeanShell va balayer tout le
répertoire et réaliser les traitements demandés en fonction de la présence des fichiers.
43
Ainsi, en expliquant dans un premier temps les outils logiciels utilisés et l’environnement de
développement, puis dans un second temps les outils de développement qui ont permis de
répondre aux objectifs du stage, nous avons pu avoir un aperçu des méthodes et techniques
employées lors de ce stage.
Il convient maintenant de faire un retour d’expériences sur toutes les connaissances, et
compétences acquises lors de ce stage ainsi que les limites et difficultés rencontrées tant au
niveau technique que scientifique
44
IV.
4.1.
RESULTATS ET RETOUR D’EXPERIENCES
Les développements actuellement réalisés
Comme nous l’avons vu dans la partie précédente, pour proposer un outil de visualisation
des indicateurs pour le projet ACCLIMAT qui puisse à la fois permettre une représentation
cartographique et graphique, et qui permette à des utilisateurs, même débutants en SIG, de
pouvoir utiliser cet outil, nous avons dû développer des requêtes SQL et des scripts
BeanShell. Dans un premier temps, nous nous proposons de présenter brièvement les
indicateurs développés et disponibles actuellement. Malgré cela, nous avons été confrontés à
certaines limites dans le processus de visualisation des indicateurs, c’est ce que nous listerons
dans un deuxième temps.
4.1.1.
Les indicateurs disponibles aujourd’hui
A l’heure actuelle, plusieurs développements ont été réalisés dans le but de visualiser les
indicateurs définis. Certains indicateurs ne nécessitent pas de calcul et sont des données de
sortie de modèles que nous exploitons directement. C’est le cas de l’exemple présenté en
troisième partie avec la densité de population : les données peuvent être visualisées
directement après l’étape de vectorisation.
Ces indicateurs sont au nombre de 8 (dont la densité de population) :
-
Le confort thermique (UTCI) et le coût des loyers sont au format ASCII et font donc
l’objet des mêmes requêtes et développements que la densité de population.
La répartition des secteurs d’activités, l’âge des bâtiments, le type d’îlots, le type
de chauffage et la hauteur des bâtiments sont des données de sortie de GENIUS, et
sont des indicateurs directement visualisables par OrbisGIS. Cependant, ces données
étant stockées dans des fichiers vecteur, l’étape de vectorisation n’est pas nécessaire.
Si nous souhaitons visualiser ces indicateurs en courbe d’évolution selon plusieurs
dates, le script BeanShell à développer est le même que pour la densité de population.
Il faut créer une nouvelle table qui contiendra la moyenne des valeurs pour chaque
année.
Les autres indicateurs nécessitent des calculs qui sont développés dans les requêtes SQL.
Beaucoup de ces indicateurs se calculent en croisant des champs de données du modèle
GENIUS. Les données de ce modèle étant en fichier vecteur, l’étape de vectorisation n’est pas
nécessaire. Ainsi, pour ces calculs d’indicateurs, il faut via des requêtes SQL, créer de
nouvelles tables avec les champs qui contiendront les valeurs des calculs. Les requêtes SQL
pour le calcul de la plupart de ces indicateurs sont déjà développées.
D’autres indicateurs nécessitant des calculs se basent sur des fichiers ASCII, et ne sont pas
un simple croisement de données. C’est le cas du calcul des 10 et 90 percentiles pour calculer
les températures extrêmes sur une période par exemple. Pour ces indicateurs, la phase
45
préalable de vectorisation est nécessaire. Les requêtes SQL pour calculer les percentiles sont
déjà développées.
Comme nous l’avons vu, pour la visualisation des indicateurs, 3 types de développements
sont nécessaires selon l’indicateur.
- Les indicateurs qui sont des données de sortie des modèles sont visualisables
directement. Si ces données sont au format ASCII, il convient de vectoriser via
l’utilisation d’une requête SQL. Et pour générer des graphiques, le script BeanShell
est à mettre à jour en fonction de l’indicateur sélectionné. Ces développements sont
finis. Ainsi, tous les indicateurs de ce type peuvent être visualisés.
- Les indicateurs qui nécessitent un calcul : soit un calcul entre deux champs de
la table, soit le calcul des percentiles, sont aussi à l’heure actuelle développés. Les
indicateurs de ce type peuvent donc être visualisés.
Néanmoins, au cours du stage j’ai été confrontée à des défis de type technique.
4.1.2.
Les défis à relever durant le stage
Un des premiers défis à relever a été d’acquérir des compétences en autonomie surtout
pour le BeanShell et le langage Java. En effet, au sein de l’équipe, il y avait un manque de
compétences en ce qui concerne le logiciel OrbisGIS, les requêtes SQL et le BeanShell. Cela
est dû par le départ d’un de mes maîtres de stage en début de mission. Celui-ci était
informaticien et devait être mon encadrant principal. Suite à son départ, mon défi a donc été
de chercher par moi-même les solutions possibles pour atteindre les objectifs fixés dans la
mission, et cela grâce aux nombreux échanges et réunions de travail avec les personnes de
l’équipe du projet.
Malgré le développement de nombreuses requêtes SQL et de scripts BeanShell, la
visualisation des résultats n’a pas été toujours possible. Et cela pour une raison
principalement : durant le stage, tous les fichiers de données de sortie des modèles n’étaient
pas disponibles. Ainsi, pour certains indicateurs, nous sommes toujours en attente de fichiers
de données de sortie, pour pouvoir les visualiser. Néanmoins, l’objectif du stage n’était pas de
visualiser tous les indicateurs mais plutôt de développer les outils nécessaires pour la
visualisation des indicateurs dont les données arriveront dans un second temps. Ainsi, les
requêtes SQL et les développements en BeanShell étant déjà fortement avancés, il sera aisé de
visualiser ces indicateurs une fois toutes les données de sortie des modèles disponibles.
Malgré ces quelques difficultés rencontrées, le stage a été une expérience professionnelle
formatrice dans laquelle de nombreuses compétences ont été approfondies ou acquises.
46
4.2.
Les compétences acquises durant le stage
Durant ce stage de 5 mois, de nombreuses compétences techniques ont pu être
approfondies, mais aussi de nouvelles compétences ont été acquises. Par ailleurs, le fait de
travailler dans une structure de recherche d’une part, et d’être intégrée au sein d’une équipe
d’autre part, a aussi été source d’enrichissement professionnel.
4.2.1.
Les compétences techniques
Après une prise de recul sur tout ce qui a été réalisé tout au long de ce stage, il est évident que
de nombreuses compétences ont été acquises.
En effet, dans un premier temps, pour développer l’outil de visualisation, il fallait développer
des requêtes SQL mais aussi des scripts en BeanShell.
Durant ma formation en Master 2, j’avais déjà acquis les bases en langage SQL. Mais les
traitements effectués en stage ont réellement permis d’approfondir mes connaissances dans ce
domaine.
Par contre ce n’est pas le cas de l’outil BeanShell que j’ai totalement découvert au cours du
stage. En effet, cet outil m’était inconnu. Par ailleurs, bien que je connaissais les principes de
la Programmation Orientée Objet et du langage Java, je n’avais jamais eu affaire à celui-ci
auparavant. Ainsi, l’outil BeanShell a dû être pris en main. Et il est devenu une nouvelle
compétence à mon actif.
Dans un second temps, durant l’étape de réflexion sur les indicateurs, de nombreuses
thématiques, inconnues ou presque, ont été abordé. Il a fallu s’approprier celles-ci. Ainsi, j’ai
pu apprendre beaucoup de matière dans le domaine de la climatologie et la météorologie,
grâce notamment aux nombreuses discussions avec toute l’équipe du projet, principalement
composée de météorologues. Par ailleurs, de nombreux apprentissages m’ont été transmis
dans le domaine du bâtiment, et notamment en ce qui concerne les consommations
énergétiques des bâtiments grâce à l’arrivée de Delphine Chouillou dans l’équipe.
4.2.2. L’apport du travail en équipe
Le fait de travailler au sein d’une équipe, et cela dans une structure de recherche, a aussi
participé à enrichir cette expérience professionnelle de fin d’étude.
En effet, durant ma mission de stage, j’ai dû rechercher et analyser les solutions
envisageables pour répondre aux objectifs fixés. Ainsi, être force de proposition a été un
aspect essentiel de mon stage. De plus, être intégrée au sein d’une équipe impliquait que je
doive présenter et expliquer les avantages et inconvénients des solutions envisagées, dans le
47
but de faire des choix de méthodologie à adopter. De nombreuses réunions de travail ont donc
eu lieu durant le stage, dans lesquelles mes prises de paroles ont été importantes pour pouvoir
présenter mes avancées. C’est ainsi que j’ai pu progresser en expression orale, en prenant la
parole, mais surtout en présentant des techniques et méthodes inconnues parfois par les autres
personnes de l’équipe.
Par ailleurs, le fait de travailler sur un logiciel SIG encore en développement m’a permis
d’être en contact très régulièrement avec les développeurs du logiciel. J’ai même pu les
rencontrer une fois en me déplaçant à Nantes avec certaines personnes de l’équipe. Ces
échanges avec les développeurs ont été très enrichissants.
48
CONCLUSION
Dans le cadre du projet Adaptation au Changement CLIMatique de l’Agglomération
Toulousaine (ACCLIMAT), un système d’indicateurs a été défini pour évaluer l’évolution du
climat, mais aussi l’évolution de la ville et l’adaptation du milieu urbain au changement
climatique. Celui-ci permet de synthétiser l’information de manière cohérente et d’offrir un
outil d’analyse et d’aide à la décision. Pour optimiser la diffusion des informations résultant
des indicateurs, un outil de visualisation des indicateurs a été développé. Pour cela, mes
compétences en géomatique et cartographie, mais aussi en urbanisme et aménagement du
territoire ont largement été requises mais aussi approfondies durant ce stage.
Comme nous avons pu le voir tout au long du rapport de stage, de nombreux
développements ont dû avoir lieu pour la création de cet outil de visualisation.
Avant même le développement de l’outil de visualisation, de nombreuses recherches
sur les solutions envisageables ont ponctué les premières semaines de mon stage. Puis une
fois, les choix faits en matière de méthodologies à adopter, nous avons commencé les
développements principalement via des requêtes SQL mais aussi des scripts en BeanShell. La
combinaison des deux permet de représenter les indicateurs cartographiquement d’une part,
puis graphiquement d’autre part. Ainsi, nous pouvons désormais visualiser les indicateurs
sous forme de cartes mais aussi avec des graphiques d’évolution ou de comparaisons.
Pour compléter et optimiser cet outil de visualisation, mon stage va se poursuivre avec
un emploi d’une durée de trois mois en sein du CNRM.
49
ANNEXES
Annexe 1 : Les formats des données de sortie des modèles.
Un raster est une matrice ou une grille de cellules ou pixels organisées en lignes et en
colonnes. Chaque cellule contient une valeur représentant des informations : la température
par exemple. Les rasters peuvent être des photographies aériennes numériques, des images
satellite, ou encore des images numériques. 19 La résolution du raster dépend de la taille des
cellules.
Le type vecteur est un mode de représentation géométrique sous plusieurs formes : des
points, des polygones et des lignes. Chacun de ses objets est associé à des attributs ou
informations contenus dans une table attributaire.
Figure 37 : Schéma de comparaison entre le type raster et le type vecteur
Source : www.notre-planete.info
Dans le cadre du projet ACCLIMAT, les fichiers de type raster sont au format ASCII,
et les fichiers vecteur au format SHP (shapefile). Il convient de présenter les caractéristiques
de ces deux types de format.
Le format ASCII, « American Standard Code for Information Interchange » (Code
américain normalisé pour l’échange d’information), est un code qui permet de conserver des
données sous forme numérique. Dans le cadre de la mission, des fichiers ASCII GRID sont à
19
www.arcgis.com, site consulté en juillet 2012.
50
notre disposition.
Les ASCII GRID sont des fichiers qui permettent de coder des données raster en ASCII. Ce
type de fichier est composé d’un en-tête spécifiant le domaine géographique, la résolution, et
les coordonnées géographiques, suivi des valeurs de chaque cellule de la grille. L’extension de
ces fichiers est .asc.
Figure 38 : Schéma récapitulatif des caractéristiques des fichiers au format ASCII GRID avec un
échantillon de données de densité de population issues du modèle NEDUM
Réalisation : Camila Legroux, Master 2 SIGMA – Université de Toulouse II – Le Mirail, 2011 / 2012
Les fichiers ASCII GRID sont exploitables avec des logiciels SIG uniquement si ils ne
contiennent qu’une seule donnée par cellule ou maille. En effet, dans le cas contraire, le
logiciel SIG ne pourrait lire le fichier dans la mesure où il y aurait plus de données que de
cellules (nombre de colonnes x nombre de lignes).
En ce qui concerne les fichiers vecteur dont nous disposons dans le cadre du projet, ils
sont au format Shapefile (.shp) ou « fichier de formes ».
Ce format a été initialement développé par ESRI mais il est désormais devenu un format
standard et utilisé par de nombreux logiciels SIG commerciaux ou libres. Comme nous
l’avons mentionné antérieurement, le format shapefile contient les informations liées à la
géométrie (ponctuelle, linéaire et surfacique). Néanmoins, pour être lu, un fichier au format
shapefile doit être accompagné de deux autres fichiers ayant le même nom. D’une part, un
fichier DBF, ou Data Base File, qui contient toutes les données attributaires relatives aux
objets géométriques contenus dans le shapefile. D’autre part, un fichier SHX qui stocke
l’index des géométries.
L’avantage avec ces fichiers est que nous pouvons disposer de plusieurs informations ou
données par géométrie.
51
Figure 39 : Exemple de la table de données issues du modèle GENIUS.
Ici, le champ PAGENUMBER correspond au numéro ou identifiant de chaque
géométrie. Puis, pour chaque géométrie, plusieurs informations ou données sont disponibles
(plusieurs champs).
En visualisant un shapefile issu du modèle GENIUS, nous constatons que les géométries
prennent la même forme que les mailles ou cellules d’un fichier ASCII GRID. En effet, le
modèle GENIUS se base sur une grille composée de cellules de 250 x 250 mètres. L’avantage
d’avoir les données de sortie du modèle GENIUS sous forme de fichier Shapefile est que pour
chaque maille, nous disposons de plusieurs données. Cela facilite notamment le calcul
d’indicateurs, par exemple.
52
Annexe 2 : Tableau détaillé des indicateurs
Nom de l’indicateur
Calcul de l’indicateur
Variables nécessaires
CLIMAT
Températures extrêmes
Ilots de chaleur urbains
Force du vent
10
percentiles
des
températures moyennes sur
la ville, sur les 90 jours
d’hiver ;
T2M (température à 2
mètres) journalière, pour 90
90
percentiles
des
jours. – SURFEX
températures moyennes sur
la ville, sur les 90 jours d’été.
T2M moyenne en ville entre
T2M moyennes entre 22h et
22h et 2h – T2M moyenne à
2h – SURFEX
la campagne entre 22h et 2h
Force du vent journalier par
par maille à 10 mètres au dessus
du sol, puis à 1.4 mètre au
- 90 percentiles sur l’année dessus des bâtiments. –
SURFEX
- Moyenne
maille ;
annuelle
CONFORT DE L’HABITANT
Confort thermique
Pas de calcul : les données de UTCI
(Urban
thermal
sortie
sont
exploitables comfort
Indicator)
–
directement.
SURFEX
- Nombre d’habitants par
maille ;
Surface de logement
m² de plancher où l’usage est
de
type - Type d’usage par maille ;
résidentiel/habitant/maille
- m² de plancher par maille
GENIUS
- Nombre d’habitants
Nombre d’habitants / maille maille ;
Habitant ayant un jardin où l’îlot est « pavillon
privatif
continu » ou « discontinu » / - Type d’îlot
Nombre d’habitant total
GENIUS
/
Temps de transport en - Temps de transport en
- Temps de transport en
voiture et de transport en voiture par maille * 2 (pour
voiture par maille ;
commun
avoir
des
allers-retours
53
domicile/travail)
- Temps moyen de transport - Temps de transport en
en voiture sur toute la ville * commun par maille
2
NEDUM
- Temps de transport en
commun par maille * 2 (pour
avoir
des
allers-retours
domicile/travail)
- Temps moyen de transport
en commun sur toute la ville
*2
- (Nombre de personnes
utilisant les transports en - Nombre de personnes
Fréquentation des transports
commun par maille/ Nombre utilisant les transports en
en commun
d’habitants de la maille) * commun par maille ;
(en cours d’étude de 100
NEDUM
faisabilité en fonction des
(Nombre de personnes
données
de
sortie
Nombre d’habitants par
utilisant les transports en
disponibles, questionnement
maille ;
commun dans la ville /
sur l’existence des données)
Nombre d’habitants total de GENIUS
la ville) * 100
SOCIO ECONOMIE
Densité de population
Pas de calcul : Les données Densité de population par
de sortie sont directement maille
exploitables
NEDUM
Densité de bâti
m² de plancher / ha
m² de plancher par maille
GENIUS
coût
NEDUM ;
Coûts des loyers
des
loyers
–
Coût des loyers en € par m²
de plancher où le type - type d’usage par maille ;
d’usage est résidentiel
- m² de plancher ;
GENIUS
maille ;
Taille des ménages
Nombre
d’habitants
Nombre de ménages
/
- Nombre de ménages par
maille
GENIUS
54
Répartition
d’activités
des
secteurs Pas de calcul : Les données Type d’usage par maille
sont directement exploitables GENIUS
Coût des transports
- Coût annuel des transports
voiture :
distance
(en cours d’étude de en
parcourue
en
voiture
en km *
faisabilité car le calcul devra
se faire directement en sortie prix de l’essence moyen pour
un kilomètre
de plateforme)
Coût du loyer moyen
mensuel / maille /habitant ;
Coût de la vie
Coût du transport en
voiture / maille / habitant ;
(en cours d’étude de
faisabilité en fonction des (coût du loyer + coût du
Revenu moyen / maille
données
de
sortie transports) / revenu moyen
/ habitant (questionnement
sur l’existence de cette
donnée).
NEDUM
ENERGIE
- Consommation énergétique
pour la climatisation par
maille de 2000x2000m (pour
Consommation énergétique l’instant) par an ;
Consommation énergétique
pour la climatisation en
pour la climatisation
SURFEX
kWep / m² de plancher / an
GENIUS
- Consommation énergétique
pour le chauffage par maille
de
2000x2000m
(pour
l’instant)
par
an
;
pour le chauffage en kWep /
pour le chauffage
SURFEX
m² de plancher / an
GENIUS
- m² de plancher par maille ;
Bâtiment climatisé
type d’îlots (nous
Surface de plancher climatisé considérons que les mailles
/ surface de plancher totale
de
« bureau »
sont
climatisées) ;
55
GENIUS
- Consommation annuelle
pour le chauffage ;
Consommation
totale
- Consommation annuelle
énergétique kWep climatisation + kWep pour la climatisation ;
chauffage / m² / an
SURFEX
- m² de plancher
GENIUS
- Production énergétique
photovoltaïque par maille ;
Potentiel
de
production
énergétique photovoltaïque
- m² de plancher
(en cours d’étude de Production énergétique en
faisabilité car certaines kWep/m²/an
données de sortie nécessaires
GENIUS (mais production
au calcul sont actuellement
énergétique PV n’existe pas
inexistantes.)
encore)
Secteur à énergie positive
faisabilité car certaines
données de sortie nécessaires
au calcul sont actuellement
inexistantes.)
- Production énergétique
photovoltaïque par maille ;
Production
énergétique - Consommation énergétique
photovoltaïque
– totale par maille ;
consommation énergétique
totale (énergie positive si le
résultat est supérieur à 0)
GENIUS (mais production
énergétique PV n’existe pas
encore)
ENVIRONNEMENT
Jardin privatif
Surface totale de la maille – - Surface totale bâtie ;
(surface totale bâtie + surface
de
routes
+
surfaces - Surface de routes ;
végétales)
- Surfaces végétales
Surfaces végétales = surfaces
végétales publiques : jardins
publics, parcs urbains…
GENIUS
Surface d’espace
public par habitant
- Surfaces végétales par
Surfaces végétales par maille maille ;
végétal
/ nombre d’habitants par
maille
maille
56
GENIUS
Consommation d’eau
annuelle
faisabilité en fonction des Consommation
données
de
sortie totale d’eau sur toute la ville
- Surface toiture végétalisée
par maille ;
Toiture végétalisée
(en cours d’étude de Surface toiture végétalisée / - Surface totale bâtie par
faisabilité en fonction des Surface totale bâtie par maille
données
de
sortie maille
GENIUS
- m² de plancher par maille ;
- captation de CO2 par la
végétation par maille ;
Rejet CO2
- rejet de CO2 climatisation
et chauffage (à calculer avec
un ratio en fonction de la
faisabilité en fonction des Rejet de CO2 en kg / an / consommation énergétique
données
de
sortie surface de plancher
kWh) ;
- rejet de CO2 transports par
maille
GENIUS
AMENAGEMENT DU TERRITOIRE
Age des bâtiments
Pas de calcul : Les données Age des bâtiments par maille
Type d’îlots
Pas de calcul : Les données Type d’îlots par maille
Type de chauffage
Pas de calcul : Les données Type de chauffage par maille
Hauteur des bâtiments
Pas de calcul : Les données Hauteur des bâtiments par
sont directement exploitables maille
57
GENIUS
Surface artificialisée
Surface totale bâtie / surface Surface totale bâtie
totale
GENIUS
- Surface totale bâtie par
maille ;
Surface consommée par
Surface totale bâtie / Nombre
l’arrivée
de
nouveaux
d’habitants
arrivants
maille
GENIUS
Taux de renouvellement du Pourcentage de changement Type d’îlots par maille
parc urbain
de type d’îlots
GENIUS
58
Annexe 3 : Les versions du logiciel OrbisGIS
Versions : numéros et noms
Dates
4.0 beta – La Rochelle
En cours de développement
3.0.2 – Barcelona
Novembre 2011
3.0.1 – Barcelona
Avril 2011
3.0 – Barcelona
Janvier 2011
3.0 beta – Barcelona
Juillet 2010
2.2.0 – Paris
Décembre 2009
2.1.0 – Vienne
Juin 2009
2.0.0 – Ostrava
Janvier 2009
1.2.0 – Naoned
Août 2008
1.1.0 – Boston
Juillet 2008
1.0.0 – Girona
Juin 2008
Source : http://www.orbisgis.org
59
Annexe 4 : Equipe de développeurs du logiciel OrbisGIS
Nom
Statut
Titre
Fonction
l’équipe
dans
EQUIPE PERMANENTE
Erwan BOCHER
Ingénieur
Recherche
l'IRSTV-CNRS
Ecole Centrale
Nantes
Gwendall PETIT
Ingénieur d'étude à Ingénieur
l'IRSTV-CNRSgéomatique
Ecole Centrale de
Nantes
en Responsable
formation et support
autour d’OrbisGIS
Jean-Yves MARTIN
Maître de conférence Docteur
à l'Ecole Centrale de informatique
Nantes
en Expert scientifique
Alexis GUEGANNO
Ingénieur d'étude à
l'IRSTV-CNRS
Ecole Centrale de
Nantes
Assistant ingénieur à
l'IRSTV-CNRS
Ecole Centrale de
Nantes
en Cartographie
et
traitement d’image
Nicolas FORTIN
Antoine GOURLAY
de Docteur
à géographie
- géomatique
de
Ingénieur
informatique
et
en Responsable
de
en l'atelier
SIG
de
l'IRSTV et du projet
OrbisGIS
Assistant ingénieur Interface utilisateur
en informatique
et calcul scientifique
Étudiant à l’École Étudiant
Centrale de Nantes
informatique
en GDMS core (20102012)
CONTRIBUTEURS
Michaël MICHAUD
Ingénieur
production
Paris
Maxence LAURENT
Ingénieur à la Haute Ingénieur
Ecole d’Ingénierie et informatique
de Gestion – Suisse
en Cartographie
thématique et Open
Geospatial
Consortium
Olivier ERTZ
Professeur à la Haute Ingénieur
Ecole d’Ingénierie et informatique
de Gestion – Suisse
en Cartographie
thématique et Open
Geospatial
Consortium
IGN
de Ingénieur
–
60
Responsable
du
développement de la
librairie de projection
pour
le
projet
OrbisGIS
Arnaud LEPETIT
Ingénieur d’étud au Ingénieur
laboratoire ESO de géomatique
l’Université
de
Rennes 2
en Cartographie
thématique et base de
données
spatiotemporelles
ANCIENS DEVELOPPEURS
Adelin PIAU
Technicien supérieur Fonction
dans
en informatique
l’équipe
de
septembre 2010 à
décembre 2010
Pierre-Yves FADET
Ingénieur
informatique
en Fonction
dans
l’équipe
d’octobre
2009 à juin 2010
Thomas LEDUC
Docteur
informatique
en Fonction
dans
l’équipe d’avril 2007
à décembre 2008
Fernando
GONZALEZCORTES
Ingénieur
informatique
en Fonction
dans
l’équipe d’avril 2007
à décembre 2008
Source : http://www.orbisgis.org
61
Annexe 5 : Diagramme de Gantt
62
TABLE DES ILLUSTRATIONS
Figure 1 : Organigramme du projet ACCLIMAT au sein du CNRM : ...................................... 8
Figure 2 : Schéma récapitulatif des partenaires du projet ........................................................ 9
Figure 3 : Schéma du fonctionnement de la plateforme ACCLIMAT ...................................... 11
Figure 4 : Schéma récapitulatif des scénarios thématiques..................................................... 13
Figure 5 : Schéma représentant l’organisation de l’environnement de développement ......... 15
Figure 6 : Grandes étapes prévues pour le stage .................................................................... 16
Figure 7 : Les personnes ressources du stage ......................................................................... 17
Figure 8 : Tableau récapitulatif des structures professionnelles rencontrées. ........................ 19
Figure 9 : Schéma récapitulatif de l’approche Top-down et Buttom-up ................................. 20
Figure 10 : Les principales données de sortie du modèle SURFEX ........................................ 21
Figure 11 : Les principales données de sortie du modèle NEDUM couplé à SLEUTH .......... 22
Figure 12 : Les principales données de sortie du modèle GENIUS ........................................ 22
Figure 13 : Schéma récapitulatif du système d’indicateurs pour le projet ACCLIMAT ......... 24
Figure 14 : Interface du logiciel OrbisGIS (version 4.0) ........................................................ 25
Figure 15 : Les modules de l’interface d’OrbisGIS ................................................................. 26
Figure 16 : Traduction de requêtes SQL pour vectoriser des fichiers raster, de la version
3.0.2 à la version 4.0. ............................................................................................................... 27
Figure 17 : OrbisGIS, un logiciel doté d‘une console SQL ..................................................... 28
Figure 18 : Exemple de visualisation d’un fichier ASCII GRID : la densité de population en
2027 (modèle NEDUM) ........................................................................................................... 29
Figure 19 : Requête SQL pour vectoriser des fichiers ASCII GRID........................................ 30
Figure 20 : Exemple de visualisation d’un fichier ASCII GRID, avec un échantillon de
données de densité de population............................................................................................. 31
Figure 21 : Comparaison de la visualisation d’un fichier ASCII GRID et d’un fichier vecteur
.................................................................................................................................................. 32
Figure 22 : Visualisation de la densité de population en 2027 ............................................... 33
Figure 23 : Echantillon de la table de densité de population créée : ...................................... 34
Figure 24 : Requêtes SQL pour créer une nouvelle intégrant le calcul d’une moyenne ......... 34
Figure 25 : Table de densité moyenne de population de l’aire urbaine toulousaine en 2027. 35
Figure 26 : Table des densités moyennes de population de l’aire urbaine toulousaine en 2027,
2047 et 2067 ............................................................................................................................. 35
Figure 27 : OrbisGIS, un logiciel doté d‘une console BeanShell ............................................ 36
Figure 28 : Tableau des principaux packages Java................................................................. 37
Figure 29 : Première étape du script BeanShell pour générer des graphiques....................... 38
Figure 30 : Deuxième étape du script BeanShell pour générer des graphiques ..................... 39
Figure 31 : Troisième étape du script BeanShell pour générer des graphiques ..................... 39
Figure 32 : Quatrième étape du script BeanShell pour générer des graphiques .................... 40
Figure 33 : la génération d’un graphique d’évolution de la densité moyenne de la population
.................................................................................................................................................. 40
Figure 34 : Première étape du script BeanShell pour automatiser les requêtes SQL ............. 42
Figure 35 : Deuxième étape du script BeanShell pour automatiser les requêtes SQL ............ 42
Figure 36 : Troisième étape du script BeanShell pour automatiser les requêtes SQL ............ 43
Figure 37 : Schéma de comparaison entre le type raster et le type vecteur ............................ 50
Figure 38 : Schéma récapitulatif des caractéristiques des fichiers au format ASCII GRID avec
un échantillon de données de densité de population issues du modèle NEDUM..................... 51
Figure 39 : Exemple de la table de données issues du modèle GENIUS. ................................ 52
63
BIBLIOGRAPHIE / SITOGRAPHIE
-
ATHAMENA Khaled, mémoire de Master 2 Sciences et Techniques des
Environnements Urbains : Indicateurs pour l’analyse de la contribution d’un projet
urbain à ilot de chaleur. Dirigé par Marjorie MUSY, Ecole Nationale Supérieure
d’Architecture de Nantes, 2008.
-
BOUTAUD Aurélien, thèse de Doctorat Science et Génie de l’Environnement : Le
développement durable : penser le changement ou changer le pansement ? Bilan et
analyse des outils d’évaluation des politiques publiques locales en matière de
développement durable en France : de l’émergence d’un changement dans les modes
de faire au défi d’un changement dans les modes de penser. Dirigée par Christian
BRODHAG, Ecole nationale supérieure des mines et Université Jean Monnet à SaintEtienne. Février 2005.
-
Agenda 21 de la ville de Toulouse, Mairie de Toulouse.
-
Etat de l’art des indicateurs et des outils de calcul de consommation énergétique et de
gaz à effet de serre – de l’échelle du quartier à celle de l’agglomération, ADEME,
2011.
-
Le développement durable en Midi-Pyrénées. Synthèse et enjeux. Les Dossiers de
l’Insee n°153, INSEE, Région Midi-Pyrénées et ARPE Midi-Pyrénées, 2011.
-
Les indicateurs synthétiques, Séminaire de l’observation urbaine, Jean-Michel
FLOCH, 2007.
-
Le Grand Pari(s) du changement climatique ? Villes, métropoles, et nouveaux défis de
la météorologie urbaine. Conférence internationale « Faire la ville durable. Inventer
une nouvelle urbanité. » Julien Desplat, Valéry Masson, Grégoire Pigeon, Cécile
Demunck. 20 et 21 janvier 2011.
-
Evaluation des impacts du changement climatique sur l’estuaire de la Gironde et
prospective à moyen terme. SAGE Estuaire de la Gironde et Milieux associés. 2009.
64
-
Les indicateurs de la stratégie nationale de développement durable 2010-2013.
INSEE et le Ministère de l’écologie, du développement durable et de l’énergie. Juillet
2010.
-
Analyse de la vulnérabilité et des opportunités d’un territoire face au changement
climatique. Document de travail du bureau d’étude RHONALPENERGIE
Environnement. 2011.
-
Confort thermique ressenti, Analyse des campagnes expérimentales 2005 – 2006,
Fabrice De Oliveira et Sophie Moreau, Centre Scientifique et Technique du Bâtiment
(CSTB), 2007.
-
Le confort thermique, dossier disponible sur http://www.energieplus-lesite.be/, 2012.
-
Redéfinir la notion de confort thermique, Guide pratique pour la construction et la
rénovation durables de petits bâtiments, février 2007.
-
http://www.territoires-durables.fr
-
http://www.ville-echirolles.fr/developpement-durable/
-
http://www.citergie.ademe.fr/
-
http://hdr.undp.org/fr/statistiques
-
http://climcity.cap-sciences.net
-
http://www.ecosociosystemes.fr/vulnerabilite
-
http://www.amica-climate.net/
65

L`outil de visualisation dans le cadre d`un projet d

Transcription

Documents pareils

Sigma 9 HD Data Sheet_FRA

Antenne UHF - SERIE SIGMA SIGMA 6HD

Sigma lance le nouvel objectif zoom haute performance APO 120

Imprimer - Omega Immobilier

Grillage Triple Torsion Galvanisé - jts

Maison à vendre Plaisance-du-Touch TOULOUSE IMMOBILIER GPB

datasheet SIGMA Portenseigne ver. 1_FRA

TOULOUSE PRADETTES Maison 4 Pièce(s) 100 m² à vendre

Grillage triple torsion

Sigma annonce une réorganisation de la gamme d`objectifs, de