Développement d’un outil d’aide à l’analyse de l...

Académie de Toulouse

DIPLOME D'ETUDES SUPERIEURES SPECIALISEES

SCIENCE DE L’INFORMATION GEOREFERENCEE POUR LA MAITRISE

DE L’ENVIRONNEMENT ET L’AMENAGEMENT DES TERRITOIRES

RAPPORT DE STAGE

Développement d’un outil d’aide à l’analyse

de l’occupation du sol et de son évolution

DUC Emilie

Septembre 2004

D é v e l o p p e m e n t d ’ u n o u t i l d ’ a i d e à l ’ a n a l y s e d e l ’ o c c u p a t i o n d u s o l e t d e s o n é v o l u t i o n

2

DESS SIGMA 2004 : RESUME DU STAGE

NOM & PRENOM : DUC Emilie TITRE DU RAPPORT : « Développement d’un outil d’aide à l’analyse de l’occupation du sol

et de son évolution »

DATE DE DEBUT DE STAGE : 01/04/2004 DATE DE FIN DE STAGE : 31/08/2004 NOM TUTEUR-ENSEIGNANT : LE CORRE Sébastien et MONTEIL Claude

Universités Université du Mirail et INP/ENSAT SOCIETE : SCOT

Parc Technologique du Canal Adresse

12, Rue Hermès Code postal 31526 Ville Ramonville St-Agne Pays France

NOM DU MAITRE DE STAGE : RABAUTE Thierry Fonction Ingénieur d’études / Chef de projet Mel [email protected] Téléphone 05 61 39 46 07

MOTS-CLES : Analyse spatiale - Statistiques / ArcGis 8 - ArcObjects - VBA RESUME :

Une des missions de SCOT aujourd’hui est de participer à la gestion raisonnée de l’environnement et au développement durable.

Dans le cadre du projet Apoge (Aide à la Planification de

l'Occupation des sols et à la Gestion de la ressource en Eau et de la production agricole à l'échelle régionale), SCOT, en partenariat avec la société Astrium et le CESBIO, s’engage à développer un ensemble d’outils d’aide à la décision. Ces développements s’appuient principalement sur la valorisation des techniques spatiales d’observation de la Terre.

Destinés aux gestionnaires du territoire et de l’environnement,

ces outils mettent en évidence les impacts présents et futurs de l’occupation du sol sur l’environnement.

Développé au sein d’un logiciel SIG, un des ces outils facilite

l’analyse statistique et spatiale du territoire en renseignant sur les structures de l’occupation du sol et leurs évolutions.

RAPPORT CONFIDENTIEL NON

mailto:[email protected]


3

REMERCIEMENTS

Je remercie tout d’abord Sébastien LE CORRE et Claude MONTEIL de m’avoir soutenue au cours de cette année de troisième cycle et pour m’avoir encadré tout au long de ce stage.

Je remercie la société SCOT pour son accueil et pour m’avoir offert la possibilité de participer au

projet RTE-Apoge durant ces cinq mois. J’exprime une reconnaissance toute particulière à Thierry RABAUTE, chef de projet, pour son

encadrement et pour la confiance qu’il m’a accordée. J’ai en effet eu la possibilité de travailler en collaboration avec des personnes aux compétences

diverses autour de ce projet, me permettant ainsi d’apprécier l’importance des échanges et du travail en équipe.

Je tiens à remercier Gretti N’GUESSAN et Nicolas RIBOT pour leur disponibilité et pour l’aide qu’ils

m’ont apportée au cours de la phase de développement de l’application. Merci également à Pierre ALBERT, Rémi BREVAL, Adrien CARPENTIER et Lenaïc DEPONTALLIER

pour leur soutien et leurs conseils.


4

SOMMAIRE

RESUME DU STAGE ......................................................................................................................... 2 REMERCIEMENTS............................................................................................................................ 3 SOMMAIRE ..................................................................................................................................... 4 INTRODUCTION.............................................................................................................................. 6

LES SPECIFICATIONS ......................................................................................................... 8

1.1. Projet RTE-Apoge et finalités du stage.................................................................. 9

1.1.1. Contexte et finalités du projet..................................................................................... 9 1.1.2. Zone atelier et données.............................................................................................. 9 1.1.3. Objectifs du stage et spécifications d’ensemble.......................................................... 11 1.1.4. Méthodologie générale ............................................................................................. 12

1.2. Vers la définition des spécifications détaillées.................................................... 13

1.2.1. Analyse spatiale, définition et concepts ..................................................................... 13 1.2.2. Spécialisation........................................................................................................... 13 1.2.3. Homogénéité et régionalisation................................................................................. 16 1.2.4. Changements dans le temps..................................................................................... 18

1.3. Spécifications détaillées ...................................................................................... 21

1.3.1. Préparation des données .......................................................................................... 21 1.3.2. Exploitation des données.......................................................................................... 22

LA MISE EN ŒUVRE DES SPECIFICATIONS...................................................................... 24

2.1 Solutions technologiques...................................................................................... 25

2.1.1 Choix du logiciel SIG ................................................................................................. 25 2.1.2 Environnement de développement ............................................................................. 27

2.1.1.1 Environnement Visual Basic ................................................................................ 27 2.1.1.2 Environnement ArcObjects.................................................................................. 28

2.1.3 Composants additionnels........................................................................................... 30 2.1.3.1 Moteur graphique .............................................................................................. 30 2.1.3.2 Contrôle FlexGrid ............................................................................................... 30

2.2 Conception générale et détaillée .......................................................................... 31

2.2.1 Méthodologie de développement : l’approche classique............................................... 31 2.2.2 Architecture du programme....................................................................................... 31

2.3. Codage étape par étape....................................................................................... 34

2.3.1 Préparation des données ........................................................................................... 34 2.3.1.1 Organisation ...................................................................................................... 34 2.3.1.2 Interface ........................................................................................................... 35 2.3.1.3 Eléments clés..................................................................................................... 36

2.3.2 Exploitation des données........................................................................................... 38 2.3.2.1 Interface ........................................................................................................... 38 2.3.2.2 Gestion des sous-ensembles ............................................................................... 39 2.3.2.3 Gestion des données .......................................................................................... 40

2.3.3 Implémentation de l’outil dans l’interface d’ArcMap..................................................... 41 LES RESULTATS ................................................................................................................ 42

3.1. Tests et pérennisation ......................................................................................... 43

3.1.1 Tests........................................................................................................................ 43


5

3.1.2. Maintenance............................................................................................................ 44 3.1.3. Aide utilisateur......................................................................................................... 44

3.2. Résultats et évolutions ........................................................................................ 45

3.2.1. Résultats ................................................................................................................. 45 3.2.2. Evolutivité de l’outil.................................................................................................. 50

CONCLUSION................................................................................................................................ 51 ACRONYMES ................................................................................................................................. 52 GLOSSAIRE................................................................................................................................... 53 BIBLIOGRAPHIE ............................................................................................................................ 55 TABLES DES FIGURES ................................................................................................................... 57 TABLES DES TABLEAUX ................................................................................................................. 57 ANNEXES...................................................................................................................................... 58


6

INTRODUCTION

Ce document constitue le rapport de stage finalisant ma formation de troisième cycle, le DESS SIGMA (Science de l’Information Géoréférencée pour la Maîtrise de l’environnement et l’Aménagement des territoires). Ce stage s’est déroulé au sein de la société SCOT (Services et Conception de système en Observation de la Terre) du 1er avril au 31 août 2004.

Inscrit dans le cadre du projet RTE-Apoge(Aide à la Planification de l'Occupation des sols et à la Gestion de la ressource en Eau et de la production agricole à l'échelle régionale), ce stage a pour finalité le développement d’un outil d’aide à l’analyse de l’occupation du sol et de son évolution au sein d’un système d’information géographique (SIG).

SCOT est une compagnie privée d’une cinquantaine de personnes. Elle est spécialisée dans le développement d’applications liées à la télédétection et à l’information géographique. Créée en 1989 en tant que filiale de l’Agence Spatiale Française (aujourd’hui le CNES), cette société fournit des prestations diverses allant dans le sens d’une gestion équilibrée et raisonnée du territoire et de l’environnement.

Ces prestations reposent en général sur l’usage des différents types de données issues d’observations aériennes ou satellitaires et d’outils associés ; principalement les systèmes d’information géographique (SIG), les systèmes de gestion de bases de données (SGBD) et le GPS. SCOT mène des programmes de suivi des ressources sur tous les continents et a conduit plus de 150 projets et études concernant l’agriculture, la forêt, l’eau, l’analyse des changements et la mise en œuvre des systèmes d’information géographique. Des prestations qui répondent aussi bien aux besoins de conseils, d’études qu’à ceux de conception et d’élaboration de produits et systèmes.

Le projet Apoge s’inscrit dans le cadre du Réseau Terre et Espace (RTE). Initié en 2001 par le Ministère de la Recherche, le réseau de Recherche et d’Innovation

Technologique Terre et Espace a pour objet de développer des applications et services utilisant les infrastructures spatiales, existantes ou en préparation, en observation de la Terre, télécommunication, datation ou localisation.

Le Réseau Terre et Espace soutient des projets de coopération entre des industriels de l’espace, des sociétés de services, des établissements de recherche et des utilisateurs potentiels (administrations, collectivités locales, services déconcentrés, etc.)

Ce réseau est animé par un Comité d’Orientation. Il fonctionne par appel d’offre ouvert. Plusieurs thèmes prioritaires ont été définis. Ils sont liés à l’environnement, aux transports, à l’aménagement et à la santé.

Le projet Apoge regroupe des partenaires scientifiques (le CESBIO, l’INRA et Météo France) et des partenaires opérationnels industriels (EADS-Astrium et SCOT). Cette équipe, intégralement située à Toulouse, s'est constituée au sein du "Réseau Régional de Recherche Technologique - Espace et Applications" qui réunit des partenaires aux compétences complémentaires et couvrant un large spectre scientifique et industriel. Il a pour objectif général la conception d’un démonstrateur d’outils d’aide à la décision destiné aux professionnels en charge de la gestion territoriale et environnementale. Les travaux réalisés au cours de ce stage participent au développement de ce démonstrateur. Il est question de concevoir un outil d’aide à l’analyse statistique de l’occupation du sol et de son évolution.


7

Ce stage s’inscrit à la fois dans une démarche de recherche de méthodes et d’indicateurs d’aide à l’analyse spatiale et dans une démarche de production informatique destinée à généraliser les résultats les plus pertinents et adéquats obtenus au cours de cette phase thématique.

Afin de répondre à la demande d’informations fiables et précises sur le territoire, une première phase d’analyse des besoins des gestionnaires, de tests d’indicateurs statistiques et de définition des spécifications de l’outil a été réalisée. Une étude de cas vient illustrer cette étape.

Suite à l’approbation de ces spécifications, une deuxième phase a consisté à concevoir et développer l’outil. Cette étape peut se résumer à l’élaboration de l’architecture de l’application et à son codage au sein du logiciel SIG choisi.

Enfin, il est important d’apprécier les résultats obtenus, les apports de l’outil pour les futurs utilisateurs et d’en estimer l’évolutivité. Un bilan général du stage vient clore ce rapport.


8

Première Partie

LES SPECIFICATIONS

L e s s p é c i f i c a t i o n s

9

1.1. Projet RTE-Apoge et finalités du stage

1.1.1. Contexte et finalités du projet

Le projet Apoge (Aide à la Planification de l'Occupation des sols et à la Gestion de la ressource en Eau et de la production agricole à l'échelle régionale) a pour finalité générale l’aide à la planification de l’occupation du sol et à la gestion de la ressources en eau. Il s’inscrit dans un contexte global de gestion du territoire et de l’environnement.

En effet, la gestion de l’occupation des sols au niveau des espaces ruraux par les différents acteurs concernés prend en compte des contraintes climatiques et économiques. Elle doit également intégrer à l’heure actuelle des éléments politiques et réglementaires établis au niveau régional, national ou européen. Ces mesures sont destinées à évaluer et réguler l’impact de l’occupation des sols et de son évolution sur l’environnement, et plus particulièrement sur le comportement de celui-ci en tant que source ou puits de carbone. Cette démarche est indispensable afin de souscrire au protocole de Kyoto. Ces activités de gestion, de même que la définition des politiques de planification, ne peuvent se concevoir qu’à partir de données exhaustives et au travers d’outils d’aide à la décision adaptés aux besoins des utilisateurs tels que les collectivités. Le principal objectif du projet Apoge est donc de mettre en place un tel outil d’aide à la décision sous forme d’un démonstrateur.

Ce démonstrateur, développé au sein d’un SIG, sera basé sur l'application conjointe de données

d'observation de la terre, de données météorologiques et de modèles de simulation simplifiés et validés. Il est destiné à une utilisation à l'échelle régionale, bassin versant ou entité administrative. Son domaine d’utilisation sera spécifiquement :

- la planification de l'occupation des terres en espace rural, avec comme critères la pression sur la ressource en eau et la contribution à la séquestration ou à l'émission de carbone.

- la gestion de l'eau d'irrigation, à la fois dans une démarche de planification stratégique et tactique et dans une démarche opérationnelle "temps réel".

1.1.2. Zone atelier et données Une zone atelier a été définie pour les besoins de ce projet. Elle est située à la limite de la

Haute-Garonne et du Gers, centrée autour de la ville de Rieumes et couvre une surface d’environ 2500 km² (soit 50 x 50 km).

Le nord de cette région est caractérisé par les terrasses de la Garonne, faiblement accidentées,

et occupées principalement par de grandes parcelles de blé, maïs et tournesol, des friches, ainsi que par la forêt de Bouconne (2200 ha en feuillus et résineux). L’est, le sud et l’ouest de la zone correspondent à un paysage de coteaux, aux sommets généralement boisés. Les mollasses, acides ou carbonatées, sont présentes sur l'ensemble de ce territoire et lui confèrent une relative unité. Les rivières sont fréquemment déficitaires durant la sécheresse estivale, et leur débit n'est que partiellement soutenu par les réserves d'étiage. L'irrigation des cultures de plaine s'est de plus fortement développée durant la dernière décennie et représente environ 85 % de la consommation nette sur les rivières et les nappes libres en période d'étiage. Au total 70 à 80 % des précipitations annuelles (~700 mm) repartent vers l'atmosphère par évapotranspiration, le sol quant à lui pouvant stocker environ 200 mm d'eau durant l'hiver. Le déficit en eau sur l'ensemble du bassin Adour-Garonne est, par rapport aux besoins et en moyenne annuelle, de l'ordre de 300 millions de m3 (~10 % des besoins).


10

Figure 1 : Cadre géographique de l’étude (Source : documentation du projet Apoge)

Les limites de la zone dans le système Lambert II étendu sont : - d’ouest en est : 476 010 m à 526 990 m, - du nord au sud : 1 848 010 m à 1 803 030 m. Les données nécessaires à l’étude de cette zone et au développement du démonstrateur sont

de différents types et leur mise à disposition implique tous les partenaires. Nous présentons ici les principales.

Les données à mettre en valeur sont celles issues de la télédétection. L’occupation du sol de la zone atelier est déterminée grâce à l’acquisition et au traitement de scènes SPOT HRV en mode 20 m couleur et Landsat TM/ETM+ (résolution de 30 m) sur plusieurs années (1987, 1991, 1994, 1998 et 2002). Au cours du stage, seule la classification de l’image SPOT de 2002 sera disponible. L’outil devra traiter des classifications au format vectoriel. Ces données sont obtenues grâce aux fonctionnalités du logiciel E-Cognition.

Les données météorologiques sont indispensables pour analyser et simuler les besoins en eau et eau d’irrigation. Elles sont naturellement fournies par Météo France pour les mêmes années. Ces données et les modèles de simulations ne seront intégrés que dans les dernières versions du démonstrateur.

Les bases de données IGN permettent de localiser les communes, les cantons et les zones hydrographiques. Pour compléter la définition du territoire, nous disposons des principaux axes routiers, des réseaux hydrographiques et du modèle numérique de terrain, au pas de 100 m, fourni par l’IGN par le biais de la BD Carthage.

Nord


11

1.1.3. Objectifs du stage et spécifications d’ensemble Le cahier des charges, remis au début du stage comme base de travail, décrit le contenu d’une

première version du démonstrateur. Il prévoyait une répartition des développements entre deux partenaires. SCOT réalisait les fonctions d’analyse de l’occupation du sol et EADS-Astrium celles d’analyse des besoins en eau. L’objectif du stage était défini comme suit :

Extrait du cahier des charges du 12 février 2004 : les spécifications d’analyse de l’évolution de l’occupation du sol :

« Le lancement de cette fonction se fait grâce à une icône particulière. Cela entraîne l’apparition

de trois onglets pour permettre à l’utilisateur de choisir : - Le type d’unité spatiale sur laquelle les données d’occupation du sol vont être agrégées : limites

de canton, de commune, de petite région agricole, de zone hydrographique, - Le ou les types d’occupation du sol dont il souhaite connaître l’évolution, - Les deux dates à partir desquelles vont être calculées des différences de distribution pour les

thèmes choisis. Une fois ces choix faits, l’utilisateur utilise une autre icône, qui va permettre la visualisation des

résultats : Une boîte de dialogue demande à l’utilisateur de choisir parmi les types d’occupation du sol

sélectionnés, celui qu’il choisit comme thème de « référence ». Une nouvelle vue est constituée sur laquelle apparaît la zone atelier, découpée par les contours

des unités spatiales choisies par l’utilisateur. Chaque unité est affectée d’une couleur correspondant au niveau d’évolution du thème de « référence » entre les deux dates choisies par l’utilisateur. La gamme de couleur utilisée pour la légende doit être optimisée par rapport aux niveaux minimal et maximal de variation. L’utilisateur doit avoir la possibilité d’exporter facilement cette vue au format JPEG par l’intermédiaire d’un type de mise en page par défaut.

Lorsque l’utilisateur clique sur une unité spatiale, cela fait apparaître un graphe montrant l’évolution des types d’occupation du sol choisis par l’utilisateur sur l’ensemble des dates des cartes historiques. »

Etant donné la difficulté d’organiser la conception du démonstrateur par deux partenaires,

EADS-Astrium a proposé de prendre en charge ce développement. Ce choix ne permettait pourtant pas à SCOT de bénéficier de toutes les retombées techniques espérées dans ce projet. Le développement d’un outil d’aide à l’analyse de l’occupation du sol a donc été poursuivi en interne. Ses objectifs différaient légèrement de ceux fixés dans le cadre du projet RTE-APOGE même si les données de ce projet ont alimenté, dans un premier temps, les phases de développement et tests. Suite à ce changement, il était nécessaire de clarifier les finalités du stage.

Une grille d’analyse, comme support de concertation, a été diffusée auprès des personnes de la

société susceptibles de participer à un projet d’aménagement ou d’environnement. L’analyse des résultats a permis d’identifier principalement des besoins en matière de visualisation et de mise en page, d’analyse de l’occupation du sol, d’analyse de séries spatio-temporelles sur des données de type raster et vecteur et également des besoins d’analyse statistique de ces données. Des besoins qui sont donc généraux, divers et parfois difficilement conciliables.

A partir des spécifications d’origine et des réflexions menées, de grands objectifs se dégagent. - Fournir rapidement des éléments, des axes d’analyse et d’aide à la décision en matière

d’organisation spatiale, d’aménagement et de planification territoriale. - Faciliter l’usage des procédures et méthodes relatives à l’analyse spatiale.


12

- Effectuer des traitements identiques, donc comparables, à différents ensembles géographiques (par exemple pour l’étude menée sur les grandes agglomérations du sud-ouest européen).

- Créer de l’information géographique à jour et qui souvent n’existe pas directement à l’échelle de l’étude.

L’outil doit également permettre de répondre aux questions que peuvent se poser les

gestionnaires du territoire dans une phase de diagnostic, d’étude ou d’analyse. - Comment se répartissent les différents postes d’occupation du sol sur un territoire ? - Pourquoi ces répartitions ? - Quelles sont les zones porteuses de spécialisation et quelles sont ces spécialisations ? - Quelles sont les régions homogènes ? - Quelles sont les différences entre les unités spatiales ? Il s’agit d’un travail statistique avant tout. Les résultats seront représentés sous forme de

graphiques essentiellement et cartographiquement si cela est pertinent. Cet outil aidera donc plus spécifiquement à:

- mettre en évidence l’existence de sous-ensembles territoriaux et dégager de grands ensembles d’occupation du sol.

- rechercher, quantifier et localiser les spécialisations d’unités géographiques. - permettre de comparer les différentes unités spatiales de l’ensemble géographique étudié

grâce notamment à la génération de leur profil. 1.1.4. Méthodologie générale La méthodologie généralement adoptée dans le cadre d’un projet de développement

informatique est la suivante : - une phase d’étude préalable qui consiste à définir un cahier des charges plus précis et les

objectifs du futur système. - une phase de définition de spécifications d’ensemble puis de spécifications détaillées. Il s’agit

de formaliser les fonctionnalités globales de l’outil puis de les raffiner. (temps de travail estimé : 1 mois) - une phase de conception d’ensemble puis de conception détaillée. Il s’agit d’écrire les

fonctionnalités en terme organique, d’identifier la structure globale du système et ses composants, puis de raffiner cette conception.

- viennent ensuite les phases de codage, de tests du produit et de pérennisation du système (rédaction d’une première documentation adaptée aux utilisateurs et d’une seconde permettant aux développeurs de maintenir l’outil).

(temps de travail estimé : 3 mois)


13

1.2. Vers la définition des spécifications détaillées Afin de définir les spécifications de l’outil, il est nécessaire de rechercher dans le champ de

l’analyse spatiale et statistique les méthodes et indicateurs capables de qualifier pertinemment l’occupation du sol. A ce titre, les concepts liés à cette thématique doivent être introduits dans l’outil développé. Cette phase de recherche définira et illustrera les méthodes et techniques d’étude des répartitions des différents postes d’occupation du sol en fonction d’unités spatiales. Les études de cas illustrent les tests statistiques grâce à un échantillon de communes de la zone atelier du projet Apoge. Les tests réellement mis en place portaient sur l’ensemble de cette zone.

1.2.1. Analyse spatiale, définition et concepts Il faut entendre par analyse spatiale la mise en évidence de sous-ensembles territoriaux,

l’étude des répartitions des différents types d’occupation du sol et la détermination d’unités géographiques spécialisées ou plus généralement l’élaboration de typologies, de profils de l’ensemble, de sous-ensembles ou d’unités spatiales. L’analyse spatiale met l’accent sur les règles d’organisation de l’espace. Elle a pour objectif de décrire une disposition particulière de certains objets, leur organisation spatiale, repérer les structures, expliquer une localisation par une autre.

Il est rare que l’analyse spatiale porte sur des objets élémentaires, c’est à dire dont

l’implantation physique corresponde directement à l’implantation géographique. Les objets sont souvent des agrégats, des regroupements d’objets élémentaires. On appelle « unité spatiale » une portion de la surface terrestre à laquelle on associe des informations spatiales et sémantiques qui résument l’ensemble des objets élémentaires qui y sont localisés (par exemple des communes ou des petites régions agricoles). Cependant lorsqu’elles sont définies a priori, ces agrégations d’objets élémentaires ne forment pas toujours des entités ayant une signification géographique cohérente. Le travail d’analyse spatiale consiste aussi à chercher dans un ensemble d’unités où se situent les continuités et les ruptures.

Compte tenu de la diversité des concepts liés à l’analyse spatiale et des finalités de l’outil, nous

limiterons d’ores et déjà nos recherches à l’étude de la spécialisation, de l’homogénéité et régionalisation et aux changements dans le temps. Ces recherches portent uniquement sur le traitement de données vectorielles conformément aux spécifications d’ensemble.

1.2.2. Spécialisation

« Une unité spatiale est dite spécialisée si les unités qui constituent l’ensemble géographique auquel elle appartient répondent à un type, à une fonction, à un usage qui n’est pas celui ou celle d’une autre mais qui peut en être dépendant. » (Pumain, Saint-Julien, 2001)

La spécialisation d’une unité spatiale est à la fois ce qui individualise l’unité dans l’ensemble

géographique et ce qui contribue à la complémentarité des différentes unités qui constituent cet ensemble. La mesure de la spécialisation d’une unité suppose la définition d’un ensemble pertinent d’unités spatiales qui servira de référence.

Mesurer la spécialisation signifie repérer :

- la dominante d’une unité spatiale, soit la modalité qui a le poids relatif le plus élevé.


14

- l’absence de spécialisation donc l’équirépartition des éléments entre les différentes modalités d’un domaine observé (même poids relatif).

Chaque fois que cela est possible, on privilégie les mesures de la spécialisation qui intègrent

une référence au système géographique d’appartenance. Pour un domaine d’observation donné, le modèle de référence correspond le plus souvent au profil d’ensemble. Les mesures du degré de spécialisation les plus communément utilisées sont une évaluation de l’écart qui existe entre le profil d’une unité spatiale particulière et le profil de référence.

Nous souhaitons donc établir le profil des unités spatiales afin de dégager les dominantes. Comparer ces profils à celui de l’ensemble donne une information supplémentaire sur la spécialisation de ces dernières. Pour cela, l’information s’organise de manière quasi systématique sous la forme d’un tableau de contingence (ou tableau d’information géographique). Dans ces tableaux, une ligne correspond généralement à une unité spatiale (les individus), une colonne correspond à un attribut différent (les variables). Dans notre cas, les variables sont les différents postes d’occupation du sol et les valeurs présentées celles de surface brute.

Deux tableaux de profils dérivent ensuite de ce tableau de contingence. Le tableau de profils en

lignes contient la part relative des lignes dans les colonnes. Il caractérise chaque unité spatiale (les individus) par rapport à l’ensemble de variables défini. Le tableau de profils en colonne contient la part relative des colonnes dans les lignes. Il décrit les répartitions géographiques des variables.

Etude de cas

Afin de caractériser les spécialisations, nous étudions ici le cas de cinq communes de la zone d’étude. Nous disposons des valeurs de surface brute en hectares des différents postes d’occupation du sol pour l’année 2002.

Tableau 1 : Tableau de contingence (surfaces en hectares)

Nous en déduisons les deux tableaux de profils : Note de calcul : 9,99 = (218/2182) x 100

Tableau 2 : Tableau de profils en lignes (profils des unités spatiales)

Aurade 218 80 222 840 46 31 46 603 96 2182Cugnaux 112 497 533 78 5 14 18 13 24 1294Fonsorbes 155 354 598 406 11 18 140 82 95 1859Saiguede 281 38 317 268 60 3 140 77 81 1265Muret 813 931 1442 891 50 127 802 248 398 5702

Ensemble 1579 1900 3112 2483 172 193 1146 1023 694 12302

Céréales d'hiver

Soja EnsembleColzaCultures

printempsMaïs TournesolForets Urbain Prairies

Aurade 9,99 3,67 10,17 38,50 2,11 1,42 2,11 27,64 4,40 100,00Cugnaux 8,66 38,41 41,19 6,03 0,39 1,08 1,39 1,00 1,85 100,00Fonsorbes 8,34 19,04 32,17 21,84 0,59 0,97 7,53 4,41 5,11 100,00Saiguede 22,21 3,00 25,06 21,19 4,74 0,24 11,07 6,09 6,40 100,00Muret 14,26 16,33 25,29 15,63 0,88 2,23 14,07 4,35 6,98 100,00

Ensemble 12,84 15,44 25,30 20,18 1,40 1,57 9,32 8,32 5,64 100,00

EnsembleTournesol SojaMaïsForets Urbain PrairiesCéréales d'hiver

ColzaCultures

printemps


15

Note de calcul : 13,81 = (218/1579) x 100

Tableau 3 : Tableau de profils en colonnes (profils des postes d’occupation du sol)

Quelques conclusions : Les céréales d’hiver et le tournesol sont sur-représentés dans la commune d’Aurade (respectivement 38 %

et 27 %). Le tournesol ne représentant que 8 % dans l’ensemble des communes étudiées, nous en concluons que la commune d’Aurade est spécialisée. Elle concentre en effet les 3/5 des surfaces de ce type d’agriculture. Les espaces urbains de la commune de Cugnaux représente près de 50 % de sa surface totale. Les

espaces agricoles y sont sous-représentés. La commune de Muret a un profil proche de celui de l’ensemble. Elle représente 46 % de la surface totale

de la zone et concentre près de 50 % des espaces urbains. Le croisement des informations d’occupation du sol avec celles des réseaux routiers et hydrographiques

explique en partie ces répartitions et spécialisations. Cugnaux et Muret bénéficient également de l’attractivité de Toulouse.

0%

10%

20%

30%

40%

50%

60%

70%

80%

90%

100%

Part

Aurade Cugnaux Fonsorbes Saiguede Muret Ensemble

Communes

Répartition des postes d'occupation du sol dans les unités spatiales

Forets Urbain Prairies Céréales d'hiver Colza Cultures de printemps Maïs Tournesol Soja

Figure 2 : Représentation graphique des répartitions de chaque poste d’occupation du sol

Aurade 13,81 4,21 7,13 33,83 26,74 16,06 4,01 58,94 13,83 17,74Cugnaux 7,09 26,16 17,13 3,14 2,91 7,25 1,57 1,27 3,46 10,52Fonsorbes 9,82 18,63 19,22 16,35 6,40 9,33 12,22 8,02 13,69 15,11Saiguede 17,80 2,00 10,19 10,79 34,88 1,55 12,22 7,53 11,67 10,28Muret 51,49 49,00 46,34 35,88 29,07 65,80 69,98 24,24 57,35 46,35

Ensemble 100,00 100,00 100,00 100,00 100,00 100,00 100,00 100,00 100,00 100,00

Tournesol Soja EnsembleCéréales d'hiver

ColzaCultures

printempsMaïsForets Urbain Prairies


1- Script pca.zip disponible sur http://support.esri.com 16

1.2.3. Homogénéité et régionalisation L’homogénéité désigne l’état particulier d’une zone dont les unités spatiales élémentaires se

ressemblent. Ceci introduit également la notion de voisinage et de continuité (une zone homogène est une zone continue).

« La régionalisation revient à identifier et délimiter des organisations spatiales différentes dont

l’existence repose sur la ressemblance et/ou l’interdépendance des unités spatiales constitutives. » (Pumain, Saint-Julien, 1997)

Les mesures de l’homogénéité d’une zone sont nombreuses et passent souvent par celles du

degré de ressemblance des unités spatiales élémentaires prises deux à deux. Les contours d’une zone homogène correspondent aux limites de cette ressemblance. Les processus d’homogénéisation tendent à rendre plus semblables des objets géographiques qui l’étaient moins avant. Ils s’accompagnent donc toujours d’une modification des configurations géographiques existantes.

Un certain nombre de choix préalables à l’étude de l’homogénéité doivent être faits : - définition de l’ensemble géographique, objet de l’analyse, - définition des attributs à partir desquels peut-être posée la question de l’homogénéité.

Mesurer l’homogénéité - Première démarche : Elle consiste à classer les unités spatiales élémentaires exclusivement en fonction du degré et

de la nature de leur ressemblance. Ceci relève donc d’une procédure de classification. - Deuxième démarche : Régionalisation : On regroupe alors les unités spatiales élémentaires en tenant compte non

seulement du degré de leur ressemblance mais encore de leur contiguïté. Ne font partie d’une même région que les unités élémentaires semblables et contiguës.

Ces démarches relèvent des techniques d’analyses factorielles, comme l’analyse en composantes principales ou l’analyse factorielle de correspondances. L’analyse multivariée fait l’objet de nombreux ouvrages et développements. Pour l’étudier, nous avons essentiellement fait référence à l’ouvrage de Lena Senders (Senders, 1989) qui définit l’analyse en composantes principales comme suit : « Elle permet d’extraire le maximum d’information sous une forme simple et cohérente à partir d’un ensemble très important de données et sert à mettre en évidence les interrelations entre les variables et les ressemblances et oppositions entre les unités géographiques analysées. Ses résultats se présentent sous forme de composantes, combinaisons linéaires de variables différenciant au maximum les individus statistiques analysés et correspondant à une association de variables conceptuellement liées qui classent les unités géographiques de manière comparable et qu’il faut chercher à identifier. » L’analyse en composantes principales est terminée lorsque les principaux axes factorielles (AF) du nuage ont été mis en évidence. Chaque axe défini une coordonnée de l’individu et permet donc sa représentation sous forme de nuage de points.

Etude de cas

Nous allons estimer l’homogénéité de l’échantillon de communes étudiées dans notre première étude de cas. L’analyse en composantes principales (ACP) a été réalisée à partir du tableau de contingence et à l’aide d’une extension développée pour Arcgis 8 (1). Nous disposons après les traitements des coordonnées factorielles des unités spatiales (individus) et de celles des postes d’occupation du sol (variables). L’essentiel de la variance s’explique grâce aux deux premiers axes factoriels (respectivement 69% et 24% de la variance).


17

Les unités sont représentées dans le graphique sous la forme d’un nuage de points. Les coordonnées des variables, représentées sous forme de vecteurs, simulent la direction des individus qui auraient une très grande valeur pour cette variable. Cela permet donc d’expliquer la position de ces individus. Pour des raisons de lisibilité, seuls cinq vecteurs ont été tracés, les quatre autres tendant vers (0, -1).

Figure 3 : Représentation des résultats de la première ACP

Quelques conclusions : La commune de Muret se différencie

fortement. En conséquence, les résultats de l’analyse pour les autres communes sont peu significatifs. Le troisième axe factoriel n’apporte pas d’explications supplémentaires. Nous avons donc relancer l’ACP sans la commune de Muret. On distingue alors clairement quatre profils : Aurade est une commune agricole, Cugnaux est sans conteste une commune

urbaine, Fonsbordes est urbaine dans une moindre

mesure mais son profil tend plus vers une dominante de prairies. Saiguede à un profil agricole mais également

forestier.

Tableau 4 : Tableau des coordonnées

factorielles de la deuxième ACP

Projection des communes sur le plan factoriel

-3

-2

-1

0

1

2

-6 -5 -4 -3 -2 -1 0 1 2 3

1er axe factoriel (69% de la variance)

2eme a

xe fac

toriel

(24

% d

e la

var

ianc

e)

Aurade Cugnaux Fonsorbes Saiguede Muret

Urbain

Prairies

Céréales d'hiver

ColzaTournesol

AF1 (x) AF2 (y)Aurade -2,76 -1,97Cugnaux 3,14 -0,66Fonsorbes 1,02 0,15Saiguede -1,41 2,48

Forets -0,84 0,52Urbain 0,96 -0,28Prairies 0,88 0,09Céréales d'hiver -0,80 -0,54Colza -0,88 0,38Cultures printemps -0,29 -0,93Maïs -0,25 0,75Tournesol -0,76 -0,64Soja -0,78 0,06


18

Figure 4 : Représentation des résultats de la seconde ACP

Nous concluons que l’interprétation des résultats des analyses en composantes principales peuvent être ambiguës ou incertains. Ces résultats dépendent fortement de l’ensemble géographique étudié.

1.2.4. Changements dans le temps La prise en compte d’une dimension temporelle a toute sa place dans l’analyse spatiale. Tous

les mécanismes de spécialisations, d’homogénéité, de hiérarchisation se développent dans le temps. Le temps construit les interactions et les structures spatiales. L’étude des changements passe par plusieurs outils et méthodes.

- La caractérisation de l’évolution des unités spatiales : au cours du temps, le changement d’un

élément se manifeste par la variation d’un ou plusieurs de ses attributs. Nous nous intéresserons plus particulièrement aux changements de répartition des types d’occupation du sol dans les unités spatiales. Cette comparaison s’appuie généralement sur une mesure de la variation et suppose donc une caractérisation du changement d’un élément entre deux états successifs, entre les années prises deux à deux.

Projection des communes (sans Muret) sur le plan factoriel

-3

-2

-1

0

1

2

3

-4 -3 -2 -1 0 1 2 3 4

1er axe factoriel (57% de la variance)

2em

e ax

e fa

ctor

iel (

29%

de

la v

aria

nce)

Aurade Cugnaux Fonsorbes Saiguede

Urbain

Prairies

Céréales d'hiver

Colza

Tournesol

Forets

Maïs

Soja

Cultures printemps


19

- La comparaison dans le temps des profils des unités spatiales : de manière très simple il peut s’agir de comparer la répartition des types d’occupation du sol au cours des différentes années étudiées.

Une méthode plus élaborée introduit les analyses factorielles et permet de représenter les

unités spatiales et l’évolution de leur profil dans un même espace. Une première analyse factorielle est effectuée sur une date de référence, généralement la date initiale. Chaque unité spatiale est positionnée dans un repère dont l’origine est constituée par les axes factoriels. On projette ensuite sur ce même plan, les profils enregistrés (les résultats des analyses factorielles suivantes) pour ces mêmes unités aux dates ultérieures. A partir de ces projections, on repère les trajectoires de l’ensemble des unités, reflet des changements de profils et des tendances d’évolution.

Etude de cas

Un premier indicateur du changement dans le temps est le taux d’évolution entre deux dates. Nous reprenons ici les données pour l’année 2002 (An 1) . Ne disposant pas de données multidates, nous simulons les valeurs de surface pour une année fictive (An 2). Ces valeurs reflètent globalement la tendance d’évolution des modes d’occupation du sol en Midi-Pyrénées. Nous cherchons simplement la manière de représenter sous la forme d’un graphique ces taux d’évolution.

Tableau 5 : Tableau de contingence pour l’an 1

Tableau 6 : Tableau de contingence pour l’an 2

Note de calcul : 0,46 = ((219 – 218) / 218 ) x 100

Tableau 7 : Tableau des taux d’évolution entre l’an 1 et l’an 2


Ensemble 1579 1900 3112 2483 172 193 1146 1023 694 12302

Tournesol Soja EnsembleCéréales d'hiver

ColzaCultures

printempsMaïsAn 1 Forets Urbain Prairies


Ensemble 1581 1950 2983 2548 170 180 1161 1024 705 12302

PrairiesUrbainForetsAn 2 MaïsCultures

printempsColza

Céréales d'hiver

EnsembleSojaTournesol

Aurade 0,46 2,50 -7,66 1,67 2,17 -6,45 -2,17 0,17 1,04Cugnaux 0,89 5,03 -6,19 7,69 0,00 7,14 5,56 -7,69 0,00Fonsorbes 2,58 2,54 -7,02 6,65 0,00 -11,11 2,14 1,22 0,00Saiguede -1,07 15,79 -7,89 4,85 1,67 0,00 0,71 1,30 7,41Muret -0,12 0,86 -0,83 0,56 -8,00 -7,87 1,37 -0,40 1,01

Ensemble 0,13 2,63 -4,15 2,62 -1,16 -6,74 1,31 0,10 1,59

7 - Maïs 8 - Tournesol 9 - SojaEvolution 1 - Forets 2 - Urbain 3 - Prairies4 - Céréales

d'hiver5 - Colza

6 - Cultures printemps


20

Figure 5 : Représentation graphique des taux d’évolution

Nous avons choisi de représenter les changements sur plus de deux années comme dans la première étude de cas, soit les répartitions des postes d’occupation du sol de chaque année sous la forme d’un histogramme empilé.

Taux d'évolution entre l'An 1 et 2

-10

-8

-6

-4

-2

0

2

4

6

8

10

1 2 3 4 5 6 7 8 9

Part

en

%

Aurade Cugnaux Ensemble


21

1.3. Spécifications détaillées Nous écartons d’ores et déjà l’implémentation de fonctions d’analyses factorielles. De nombreux

outils statistiques spécifiques et complets permettant de faire ces analyses existent déjà. De plus, notre outil s’adresse à des personnes non-initiées à ces techniques. Le risque d’interprétations erronées est donc réel. De tels traitements sont difficilement généralisables. Ceci ne remet pourtant pas en cause leur pertinence, mais ils sont jugés trop complexes. L’outil doit rester abordable et convivial, d’utilisation simple. Les résultats doivent être compréhensibles et sans ambiguïté. Pour cela, le travail de développement des interfaces va être très important.

1.3.1. Préparation des données Objectif général Générer le tableau de contingence, et les deux tableaux de profils à partir d’une couche

d’occupation du sol et d’une couche d’unités spatiales. Le tableau de contingence récapitule les valeurs de surface (en hectares par exemple) des différents postes d’occupation du sol pour chaque unité spatiale.

Entrées - Une couche polygonale de l’occupation du sol au format shape d’ESRI, comportant un champ

identifiant les différents types d’occupation du sol. Ce champ peut-être de type numérique ou texte. - Une couche polygonale d’unités spatiales au format shape d’ESRI ne dépassant pas les limites

géographiques de la couche d’occupation du sol. On suppose qu’un champ distingue ces unités spatiales soit par leur nom soit par un identifiant.

Processus Objectif : Savoir à quelle unité spatiale appartient chaque polygone d’occupation du sol. - Clip : Découpe de la couche d’occupation du sol en utilisant comme emporte-pièce la couche

des unités spatiales. La couche résultante a la même structure (les mêmes attributs) que celle de l’occupation du sol. Le clip permet de ne pas surcharger les autres traitements en données non utilisées.

- Union : Faire l’union de la couche issue du clip et de la couche d’unités spatiales. La couche résultante sera la « couche de travail ». Il associe les entités et les attributs des deux couches.

Objectif : Savoir quelle est la surface de chaque polygone d’occupation du sol. - Calcul des surfaces des polygones de la couche de travail. L’unité de calcul dépend de la

projection utilisée par la couche d’occupation du sol. Objectif : Construire le tableau de contingence et en déduire les tableaux de profils. - Génération des tables à partir de requêtes et calculs effectués dans la couche de travail. Sorties - la couche de travail, - le tableau de contingence, - le tableau de profils des unités géographiques, - le tableau de profils des types d’occupation du sol.


22

1.3.2. Exploitation des données Objectifs Faciliter l’interprétation des résultats par leur mise à disposition dans une « Fiche Statistique ».

Cette interface contiendra deux modes de représentation : une fenêtre « graphique » et une fenêtre « tableau ». Des contrôles seront associés indépendamment à chaque fenêtre pour fournir des paramètres de configuration à l’utilisateur.

Entrées Des tableaux de contingence. Processus et résultats La définition des unités géographiques servant de base à l’analyse spatiale se fera par

sélection, soit directement dans la fenêtre carte d’ArcMap, soit dans la liste des unités géographiques disponible dans l’interface de visualisation.

La sélection d’un groupe d’unités pourra être mémorisée. Il sera donc possible d’en constituer plusieurs et de la comparer. Ces groupes seront appelés « sous-ensembles » et disponibles dans la liste de choix de l’interface.

Figure 6 : Prototypage de l’interface

La fenêtre « Graphique »

Les graphiques doivent fournir le plus simplement et visuellement possible la répartition des

différents types d’occupation du sol pour les unités spatiales choisies. Trois types de graphique seront disponibles.

- Etude d’une couche de l’occupation du sol : Un graphique de type histogramme empilé 100% permettant de comparer la contribution en

pourcentage de chaque valeur y par rapport au total. Les abscisses x pourront représenter soit une unité, soit un sous-ensemble d’unités, soit l’ensemble des unités. Ce graphique sera donc alimenté avec les données de la table de profils des unités géographiques.

Graph

Table

Con

trôle

s

Nom Urbain Agricole NatuelFonsbordes 354 350 598Aurade 80 830 222Cugnaux 497 75 533


23

- Etude de l’évolution de l’occupation du sol entre deux dates : Un graphique de type histogramme classique représentant les données de taux d’évolution

entre deux dates des différents types d’occupation du sol. Il sera possible de comparer les taux d’évolution de plusieurs ensembles.

- Etude de l’évolution de l’occupation du sol sur plus de deux années : Un graphique de type histogramme empilé 100% dont les années constituent les séries. Les

données utilisées sont celles des tables de profils des unités spatiales générées pour différentes dates. Format et spécifications techniques L’apparence des graphiques doit refléter celle de la légende de la couche d’occupation du sol.

La fenêtre « Tableau » Le tableau doit préciser les données utilisées par les graphiques et les enrichire selon les choix

de l’utilisateur. Les données de ce tableau doivent être les plus manipulables et paramétrables possible. Des contrôles doivent fournir des options de tris des lignes et des colonnes. L’utilisateur doit avoir le choix des données à inclure dans ce tableau. Il doit avoir la possibilité de visualiser les données pour l’ensemble. Cette fenêtre « tableau » permet d’exploiter les données dans plusieurs tableaux de contingence simultanément. Le programme calcule également à la volée les données pour qualifier les sous-ensembles et l’ensemble.


24

Deuxième Partie

LA MISE EN ŒUVRE DES SPECIFICATIONS

L a m i s e e n o e u v r e d e s s p é c i f i c a t i o n s

Les termes annotés d’une étoile sont définis dans le glossaire. 25

2.1 Solutions technologiques

Avant de concevoir le programme et son architecture, il est indispensable de connaître les logiciels et langages qui seront utilisés. Développer une application pour un logiciel signifie maîtriser le mieux possible son fonctionnement et son architecture. Nous pourrons être amenés à rechercher et tester des composants additionnels si certaines fonctionnalités du logiciel ne répondent pas aux attentes.

2.1.1 Choix du logiciel SIG En matière d’applications « Systèmes d’Information Géographique », la société dispose de

licences des produits ESRI. Le choix du logiciel SIG doit donc se faire entre les deux versions actuellement disponibles : ArcView 3 ou ArcGis 8 Desktop. (voir figure 7)

Compte-tenu des finalités de l’outil, nous nous intéressons tout d’abord à deux critères, les

possibilités offertes pour la création des diagrammes et l’esthétique générale, la qualité graphique. Comme il s’agit d’un travail de développement informatique, le choix sera également influencé par un troisième critère, le langage de programmation des macros. Plus généralement, il faut estimer la pérennité et l’évolutivité de l’application.

Les diagrammes ont un rendu presque similaire dans les deux versions. Cependant, ArcGis 8

offre un ensemble de paramètres plus complet pour la gestion des données et des options d’affichage plus nombreuses.

En matière d’esthétique et de présentation générale, ArcGis 8, plus récent, est indéniablement

plus convivial et ergonomique. Enfin, concernant les aspects liés à la programmation, les capacités des deux langages (Avenue

et Visual Basic for Application) sont satisfaisantes. L’interopérabilité est cependant plus forte en VBA. L’intérêt de ce langage interprété* est d’être

partagé par d’autres applications. L’utilisation de composants additionnels, d’extensions d’applications s’avérera plus fastidieuse sous ArcView 3. VBA couvre un large champ d’utilisateurs. C’est un atout certain pour la maintenance, la pérennisation et l’évolutivité de l’outil.

Il semble donc plus judicieux d’opter pour ArcGis 8. Ce choix s’est accompagné d’une phase de

prise en main du logiciel.

Présentation d’ArcGis 8 Desktop

La gamme SIG d’ESRI se décompose en trois « versions » aux fonctionnalités croissantes : ArcView, ArcEditor et ArcInfo (le développement de l’outil s’effectue avec ArcEditor 8.3). Chacune de ces versions fonctionne dans l’environnement « Desktop », c’est à dire avec les trois applications ArcCatalog, ArcMap et ArcToolBox.

- ArcMap est l’application à finalité cartographique. Elle propose les fonctions d’édition,

d’affichage, d’interrogation et d’analyse des données cartographiques. C’est dans cette application que sera développé l’outil


26

- ArcCatalog est l’application à finalité de gestion de base de données. Elle permet de rechercher, parcourir et administrer des données spatiales.

- ArcToolBox est l’application dédiée aux travaux de géotraitements telles que les conversions de données, les croisements de couches et les transformations de coordonnées cartographiques.

Figure 7 : Comparaison entre les deux versions d’ArcView

ArcView 3 ArcView 8 (ArcMap)

Interface à un seul documentInterface à plusieurs documents

Bloc de données

Regroupe des jeux d’entités (couches) affichés ensemble. Répertorié dans la table des matières principale et affiché dans la zone d’affichage principale.

Document ArcMap (.mxd)

Document qui stocke les cartes, tables, diagrammes, et macros.

Script Avenue

Une macro écrite à l’aide d’Avenue.

Mise en page

Disposition des vues et des éléments cartographiques sur une page. Les outils d’analyse géographique ne peuvent pas être utilisés sur une mise en page car les éléments cartographiques ne sont pas dynamiques. Plusieurs mises en page sont prises en charge.

Diagramme

Représentation graphique des informations portant sur les entités de la carte et les relations existant entre elles.

Thème

Représente un jeu d’entités du même type, telles que des cours d’eau, des lacs ou des autoroutes. Existe uniquement dans le projet parent.

Diagramme

Représentation graphique des informations portant sur les entités de la carte et les relations existant entre elles.

Vues

Regroupe des jeux d’entités (thèmes) affichés ensemble. A sa propre table des matières et zone d’affichage.

Table des matières

Répertorie les thèmes d’une vue particulière.

Projet (.apr)

Organise et stocke les informations sous forme de vues, de tables, de diagrammes, de mises en page et de scripts.

Table des matières

Répertorie les données avec les couches qu’elles affichent.

Mise en page

Disposition des blocs de données et des éléments cartographiques sur une page. Les outils d’analyse géographique peuvent être utilisés sur une mise en page car les éléments cartographiques sont dynamiques. Les mises en page peuvent être modifiées de façon dynamique, à l’aide de modèles. Seule une mise en page est prise en charge.

Couche

Représente un jeu d’entités du même type, telles que des cours d’eau, des lacs ou des autoroutes. Persiste indépendamment du bloc du données et peut-être partagé par d’autres utilisateurs.

Macro VBA

Une macro écrite à l’aide de Visual Basic for Application.


27

2.1.2 Environnement de développement

A partir d’ArcObjects, la plate-forme de développement de la famille des applications ArcGis, plusieurs types de travaux sont possibles : - Personnaliser l’environnement dans ArcMap ou ArcCatalog avec VBA, en développant des macros associées à un document ArcMap (.mxd) ou à un modèle (.mxt).

- Créer des applications ou des contrôles, en développant en Visual Basic (VB), C++, Delphi essentiellement, des DLL*, des contrôles ActiveX* ou des exécutables (.exe).

- Etendre le modèle ArcInfo grâce à VisioUML et aux outils CASE*, avec les langages C++, Delphi ou tout autre langage supportant la technologie COM (Component Object Model)*.

Nous avons choisi ArcObjects avec VBA, manière la plus simple et la plus rapide pour développer de petites applications. Le programme se présentera sous la forme d’un document ArcMap. Une description rapide de l’environnement logiciel et de ses spécificités facilite la compréhension de la mise en œuvre du développement.

2.1.1.1 Environnement Visual Basic

Un modèle événementiel Dans les applications traditionnelles dites « procédurales », les instructions commencent à la

première ligne de code et se déroulent suivant un chemin défini, appelant les procédures au fur et à mesure des besoins. Dans les applications « événementielles », le code ne suit pas un chemin prédéterminé. Différentes sections du code sont exécutées en fonction des événements qui se produisent. L’ordre des événements n’est pas prévisible, en revanche, il faut prévoir ces événements et le code doit être en mesure de les traiter.

Une notion d’objets

Un objet représente un élément d’une application (une couche, une table, une légende, etc.). Dans un code Visual Basic, nous devons identifier un objet avant de pouvoir appliquer l’une de ses méthodes* ou modifier la valeur d’une de ses propriétés*.

Un éditeur Visual Basic

Une fenêtre de projet liste tous les modules de code du document ArcMap courant. Chaque module contient un certain nombre de « macros » (ou procédures) elles-mêmes constituées d’un certain nombre de lignes de code (instructions). Il existe trois types de modules :

- Les modules standards (.bas) - Les feuilles ou UserForm (.frm) - Les modules de classe (.cls) Une feuille est une boite de dialogue créée par le développeur (l’interface graphique). Elle

contient un certain nombre de « contrôles », par exemple des boutons, des listbox, etc. A ces contrôles sont associés des événements, eux-mêmes rattachés à des procédures événementielles (par exemple l’événement « clic » va déclencher un certain traitement).

Un module regroupe les séries d’instructions sous forme de procédures ou de fonctions. Afin de

minimiser le code dans les feuilles, toutes les procédures événementielles pouvant être appelées plusieurs fois sont également placées dans les modules.

Les modules de classe permettent la création de nouveaux objets susceptibles d’être appelés

par des procédures internes de l’application. Alors qu’un module ne contient que du code, un module de classe contient à la fois du code et des données. Il est assimilable à un contrôle dépourvu de représentation physique.


28

2.1.1.2 Environnement ArcObjects ArcObjects s’appuie sur la technologie COM (Component Object Model) de Microsoft. COM n’est

pas un langage orienté objet mais une norme définissant des protocoles de connexions entre différents composants logiciels. C’est un type d’organisation des données en classes, sous-classes et interfaces. COM se définit comme un modèle de programmation dit « Interface-based programming ». Les ArcObjects OMD (Objects Model Diagrams) utilisent une modélisation UML (Unified Modeling Language) avec quelques variantes afin de pouvoir représenter les spécificités de la norme COM (ajout de symboles pour représenter les différentes propriétés et méthodes, etc.). Ces diagrammes aident à comprendre l’architecture ArcObjects.

COM et classes

Figure 8 : Diagramme de classe

On distingue donc trois types de classes dans ce diagramme : La Classe simple, la CoClasse et la Classe Abstraite.

Une Classe est dite « instantiable » mais pas « creatable ». Elle ne peut pas créer directement de nouvel objet. Un objet d’une classe peut être créé comme propriété d’une autre classe ou grâce à une méthode d’une autre classe.

Par exemple, la Classe « FeatureClass » permet d’instantier un objet « Feature » (une entité) grâce à la méthode « GetFeature ».

Une CoClasse (Component Object Class) est dite « creatable ». Un objet d’une CoClasse peut être directement créer à l’aide du mot-clé « New ».

Une Classe Abstraite définit des propriétés générales communes à plusieurs sous-classes. C’est

un regroupement de plusieurs Classes et/ou CoClasses. On ne peut pas créer d’objets avec ce type de classe.


29

Par exemple, la Classe Abstraite « Layer » définit les propriétés générales telles que le nom ou les références spatiales de la couche. Les propriétés spécifiques à chaque type de couche sont portées par les sous-classes « FeatureLayer », « TinLayer » ou encore « GroupLayer ».

COM et interface

Développer avec la norme COM implique développer en utilisant des interfaces. Une interface est un groupe logique de méthodes et propriétés. Pour communiquer avec un objet, on passe par son interface. Le principal avantage est de permettre de faire évoluer, de mettre à jour une classe en lui ajoutant une nouvelle interface. Une interface ne peut jamais être supprimé mais l’implémentation peut être modifiée.

Dans cet exemple, la classe « FeatureLayer » implémente deux interfaces « IFeatureLayer » et « IFeatureSelection ».

Figures 9 et 10 : Illustrations du principe de « Query Interface »

Lorsqu’une classe donnée possède plusieurs interfaces et que l’on dispose d’une variable

pointant sur une des interfaces, il faut donc faire une « Query Interface » (QI) pour récupérer un pointeur sur une autre interface. Ceci rend accessible les méthodes et propriétés de cette autre interface. Ce mécanisme est la base du développement avec ArcObjects.

Dim pMxDoc As IMxDocument Set pMxDoc = ThisDocument ' On dispose d’une variable pointant sur IFeatureLayer Dim pFLayer As IFeatureLayer Set pFLayer = pMxDoc.FocusMap.Layer(0) ' On déclare une deuxième variable pointant sur IFeatureSelection Dim pFeatSelect As IFeatureSelection ' Afin d’accéder aux propriétés et méthodes de IFeatureSelection, on récupère le pointeur de IFeatureLayer. On fait donc une Query Interface entre IFeatureLayer et IFeatureSelection Set pFeatSelect = pFLayer

FeatureLayerFeatureLayer

IFeatureLayer

IFeatureSelectionQI


30

2.1.3 Composants additionnels

2.1.3.1 Moteur graphique

Notre application a pour principal objectif de générer des graphiques. ArcGis offre déjà une première solution puisqu’un moteur graphique est intégré au logiciel. Une première phase de tests a donc été réalisé. Les résultats sont peu satisfaisants pour trois raisons principales :

- La manipulation, et donc la représentation, des données est trop limitée. Les graphiques sont

adaptés aux traitements des données attributaires, c’est à dire sous forme de fichier DBase. L’accès aux données n’est pas assez flexible et ces dernières ne peuvent être virtuelles.

- Le développement de ces graphiques est lourd. En conséquence d’un modèle Objet complexe,

l’accès à certaines interfaces, notamment pour définir des paramètres comme la légende et les couleurs, peut s’avérer fastidieux.

- La qualité et l’esthétique ne sont pas assez satisfaisantes. La possibilité d’utiliser des composants extérieurs a donc été envisagée. Notre choix s’est porté

sur les composants Office (Office Web Components – OWC), facilement intégrables à une application développée en Visual Basic. L’utilisateur devra posséder une application de la suite Office.

Les composants OWCCharts (les objets « graphiques ») ont des avantages certains : - Les données sources sont très manipulables. Elles peuvent être de trois types :

- des tableaux Visual Basic constitués par le programme, - des bases de données connectées, - des feuilles de calcul.

L’accès aux données étant également plus rapide, l’outil gagnera en performance.

- Le développement est facilité. - la qualité et l’esthétique sont satisfaisantes.

2.1.3.2 Contrôle FlexGrid

Dans les spécifications, il est question de présenter les données sources des graphiques dans un tableau. Peu de tests ont été nécessaires. Le choix s’est porté assez rapidement sur l’emploi du contrôle « MSHFlexGrid ». Il affiche les données sous forme de tableau en lecture seule. Il possède des fonctionnalités de mise en forme et peut trier, fusionner et mettre en forme des tableaux contenant des chaînes et des images. Ce contrôle est simple à manipuler et offre les paramètres nécessaires à l’outil.


31

2.2 Conception générale et détaillée

« Une bonne programmation est celle qui permet à un programme de vivre, c’est à dire de s’adapter. Tout logiciel (programme d’application) doit pouvoir évoluer en fonction de facteurs souvent difficiles, voire impossibles à prévoir lors de sa conception. Si l’analyse du programme a été élaborée avec soin, selon des normes précises, avant d’être traduite en programme, ce dernier pourra facilement être modifié par son concepteur ou par quelqu’un d’autre. » (ENSG, 2001)

2.2.1 Méthodologie de développement : l’approche classique

L’approche dite « classique » est axée sur la conception modulaire et la programmation structurée. Cela revient à diviser le programme en une hiérarchie de modules. Cette technique permet de distinguer les lignes directrices du programme. Nous devons déterminer ce que chaque module doit faire et comment collaborent ces modules entre eux pour exécuter une tache. Il s’agit en fait de construire l’architecture du programme. Elle doit être pensée pour répondre aux qualités attendues d’un programme en général et de l’outil en particulier.

- La fiabilité : un programme fiable est un programme intègre et pour lequel les tests ont réussi dans tous les cas.

- L’efficacité : un programme efficace économise la mémoire. Son exécution doit être rapide. - La prise en compte des aspects humains : un programme doit être facile à utiliser et

accessible. Il est accompagné d’un manuel d’aide pour l’utilisateur. - La clarté : un programme doit être structuré, concis et lisible. - La facilité d’adaptation : un programme doit être facilement modifiable et extensible. Il est

accompagné d’une documentation technique, le manuel de maintenance.

2.2.2 Architecture du programme L’architecture générale (voir figure 11) présente les principales entrées/sorties du programme. Elle décrit l’organisation des composants de l’application, leur connexion et leur dynamique afin de répondre aux besoins énoncés.

Le périmètre du projet est ArcGis (ArcMap). L’outil d’analyse statistique de l’occupation du sol est complètement intégré au logiciel. Le moteur de traitement récupère les données d’entrées (soit une couche d’occupation du sol et une couche d’unités spatiales), les travaille (données de travail) et exploite les résultats (couche d’abstraction) en les présentant sous la forme de graphes et de tableaux.

Le diagramme fonctionnel (voir figure 12) présente plus en détail l’organisation de l’application en montrant comment les modules collaborent entre eux. Le programme se décompose en deux taches distinctes mais dépendantes, la préparation des données et l’exploitation des données. La préparation des données consiste à retravailler les données d’entrées afin d’obtenir un tableau de contingence (récapitulant les surfaces de chaque type d’occupation du sol pour chaque unité spatiale). Ce processus est répété autant de fois que d’années disponibles et pour chaque type d’unités spatiales analysées. Cet ensemble de tableaux de contingence est ensuite exploité en fonction des requêtes formulées par l’utilisateur. Chaque requête entraîne le traitement des données récupérées dans cet ensemble de tables. Le résultat de ce traitement est ensuite mis en valeur, représenté sous forme de graphes et tableaux adaptés à la requête.


32

Figure 11 : Architecture générale de l’outil

Bloc de données

(jeux de couches)

VBA

Tablesvirtuelles

Graphiques

Tableaux

ArcMap

Donnéesde

travail

Architecture Générale

Moteur

Préparation

des données

Exploitation

des données


33

Figure 12 : Diagramme fonctionnel

Génération du graphique

Diagramme Fonctionnel

Ouverture du document ArcMap (.mxd)Ajout de données

mPrepaData

mFeatSelect

mData

mFlexGrid

mGraphs

mLegend

Calculs

mCalculTools

Utilisateur

Préparation des données

Exploitation des donnéesLancement de

l’interface

Peuplement destables

Géotraitements

Génération du tableau

Gestion des données(tables virtuelles)

Sélection des unitésdans la fenêtre carte

Sélection des unitéset années

Récupération des couleurs

Utilisateur

Récupération desunités sélectionnées

Oui

Non

mNewTable

Création des tables

Calculs

mCalculTools

Gestion des sous-ensembles

mIHM


34

2.3. Codage étape par étape

2.3.1 Préparation des données

2.3.1.1 Organisation

Pour faire l’étude de l’occupation du sol, les données ont besoin d’être présentées sous la forme d’un tableau de contingence, soit de façon à ce que l’on dispose des surfaces de chaque type d’occupation du sol dans les unités spatiales. Afin d’obtenir ces données de surfaces à partir d’une couche de l’occupation du sol et d’une couche d’unités spatiales, des géotraitements sont nécessaires. Il faut ensuite créer physiquement les tables statistiques et les peupler à partir de la couche résultante de ces géotraitements, « la couche de travail ». L’organigramme (voir figure 13) présente les différentes phases de la préparation des données et illustre le fonctionnement de cette partie du code.

Figure 13 : Organigramme de la préparation des données

Ajout d’un champ dans la table de la couche de travail et calcul

de la surface des polygonesCouche des

unités spatiales

Couched’occupation

du sol

Couche des unités spatiales

« TempClip »

Couche de travailUnion

Clip

Tablede la couche

de travail

Tableau de contingence Tables des profils

Requêtes, calculs et peuplement du tableau

de contingence

Calculs et peuplement des tables de profils


35

Les tables créées par ce module ont toutes la même structure : - Un champ identifiant et un champ « Nom_UG » repris dans la table attributaire de la couche

d’unités spatiales. L’ordre et les identifiants des unités sont identiques dans toutes ces tables. Ceci va permettre ensuite de retrouver les unités sélectionnées dans la fenêtre carte d’ArcMap par l’utilisateur lors du lancement de la « Fiche Statistique » (l’interface d’exploitation des données).

- Un champ ajouté par mode d’occupation du sol. Nous retrouvons donc la structure du tableau de contingence telle qu’elle a été décrite dans la

phase de mise en place des spécifications.

2.3.1.2 Interface

Afin de simplifier la conception et d’éviter certaines erreurs, cette première étape de génération des tables statistiques se fera par le biais d’une interface unique. Ce choix rigidifie quelque peu son utilisation puisqu’un changement, une modification des données d’origine (les entrées) ou une perte d’information sur les données résultats (les sorties) oblige l’utilisateur à refaire tout le processus de préparation. Cependant, dans le code, tous les traitements relatifs à cette phase sont bien distingués et autonomes. Ce choix facilite également la prise en main de l’outil et sollicite le moins possible l’utilisateur.

Figure 14 : L’interface de préparation des données

1

8

6 7

3 2

5

4


36

1 Le nom de la couche d’occupation du sol.

2 Le nom du champ de la table attributaire distinguant les types d’occupation du sol.

3 Le nom de la couche d’unités spatiales.

4 Le nom du champ renseignant sur les noms des unités spatiales

5 Un nom pour la couche de travail résultante.

6 7 Une codification des noms de tables statistiques générées.

8 Un répertoire de travail.

Tableau 8 : Liste des paramètres nécessaires à la préparation des données

2.3.1.3 Eléments clés Gestion des noms de tables

Pour simplifier la gestion des données et récupérer facilement les informations nécessaires au

fonctionnement de l’interface statistique, la personnalisation des noms des tables est restreinte. Les noms des trois tables sont fixés (« Surface », « ProfilUG » et « ProfilOS »). L’utilisateur doit alors spécifier, pour ce groupe de tables, l’année des données d’occupation du sol traitées et le type d’unités spatiales étudié (choix d’un identifiant de trois caractères). Les noms sont formés à partir de ces trois informations.

Par exemple : Les unités spatiales sont des communes. Nous choisissions de les identifier par « COM ». Les données d’occupation du sol datent de l’année 2000. Nous choisissons dans la liste

présentée dans l’interface cette même année. Les noms des tables seront les suivants : « COMSurface2000 », « COMProfilUG2000 » et

« COMProfilOS2000 ». Ce choix a été fait pour plusieurs raisons : - Un nombre important de données pouvant être créées, il est préférable de simplifier

l’administration, la gestion de ces données, pour l’utilisateur comme pour une plus grande fiabilité de l’outil. Un répertoire spécifique est créé pour chaque zone d’étude afin de stocker les données préparées. Ce dossier porte le nom de la couche d’occupation du sol.

- Ces noms identifient clairement le contenu des tables. - Le programme a besoin de récupérer ces tables. Il doit également en connaître l’origine. Ces

paramètres sont nécessaires au fonctionnement de l’interface d’exploitation des données. Disposer de ces informations dans les noms des tables évite leur stockage sur le disque dur (sous forme de fichier de configuration (.ini) ou dans la base de registre).


37

Gestion des unités de mesure Afin de garantir l’exactitude des données de surface calculées, les couches utilisées doivent

avoir un système de projection. Cette information est vérifiée avant l’exécution des traitements. La projection doit définir les unités de mesure dans le système métrique. Les valeurs de surface

calculées à partir de la couche de travail sont donc exprimées en mètre carré (m²). Ces valeurs sont converties systématiquement en hectare lors du peuplement du tableau de contingence (table « Surface »).


38

2.3.2 Exploitation des données

2.3.2.1 Interface

Figure 15 : Interface d’exploitation des données

1

2

5

4

3

L’espace graphique

Le tableau


39

Lancement de l’interface Un bouton est implémenté dans ArcMap pour accéder à la « Fiche Statistique ». Si l’utilisateur a sélectionné préalablement des unités spatiales dans la fenêtre carte, la fiche

génère directement le graphique pour la première année trouvée. Les années étant classées par ordre chronologique, c’est l’année la plus ancienne qui est utilisée par défaut.

Si l’utilisateur n’a pas sélectionné d’unités, la « Fiche Statistique » est ouverte et prête à exécuter les requêtes. Une requête contient deux paramètres, un choix d’unités et un choix d’années.

Chaque nouvelle requête est exécutée grâce au bouton . Les analyses

La façon de représenter des données dépend des choix de l’utilisateur : - Etudier l’occupation du sol d’une ou plusieurs unités sur une année (représentation des répartitions). - Etudier l’évolution de l’occupation du sol d’une seule unité sur deux années (représentation des taux d’évolution). - Etudier l’évolution de l’occupation du sol d’une seule unité sur plus de deux années (représentation des répartitions).

L’utilisateur choisit donc dans les listes de l’interface les années et les unités spatiales (12).

Ces deux paramètres suffisent à générer un graphique et un tableau.

Les paramètres optionnels - Les couleurs sont déterminées aléatoirement si l’utilisateur ne sélectionne pas dans une liste (4) la couche d’occupation du sol contenant cette information. La liste propose les couches polygonales dont la légende est de type « Valeurs uniques ». Si une légende est indiquée, les labels seront également récupérés.

- Deux manières de trier les données du tableau sont à la disposition de l’utilisateur, un tri par unité et un tri par type de données (5).

Les contrôles supplémentaires - Une zone de texte (3) indique le nombre d’unités spatiales sélectionnées dans la liste de choix des unités. Compte-tenu de la taille de cette liste et du nombre parfois important d’unités spatiales présentées, cette fonctionnalité s’avère très utile.

- Egalement, le bouton permet de tout désélectionner dans la liste.

2.3.2.2 Gestion des sous-ensembles Cette fonction rehausse les possibilités d’analyse. L’utilisateur n’est pas restreint à l’étude

d’unités spatiales « simples ». Il peut composer des unités spatiales en regroupant ces unités spatiales simples. Un sous-ensemble est ensuite considéré comme une unité spatiale à part entière. Il est donc rajouté à la liste de choix des unités. Par défaut, un sous-ensemble regroupant toutes les unités est créé (nommé <Ensemble>). L’utilisateur peut donc comparer, analyser les données à différentes échelles spatiales. Cette fonction sous-entend une mémorisation des unités composant le sous-ensemble. Ces groupes sont mis en mémoire pendant le durée d’exécution du programme, c’est à dire tant que l’utilisateur ne ferme pas l’interface de visualisation.


40

Cette fonction s’agrémente de trois contrôles : - Le bouton propose d’enregistrer les éléments sélectionnés dans la liste sous un nom choisi

par l’utilisateur. - Le bouton permet de restaurer un sous-ensemble. Une boite de dialogue demande à

l’utilisateur le nom du sous-ensemble dont il souhaite retrouver les unités spatiales simples. Ces dernières seront de nouveau sélectionnées dans la liste.

- Le bouton supprime un sous-ensemble.

2.3.2.3 Gestion des données Un des points importants du programme est la gestion des données dédiées aux graphiques et

tableaux. Ces données sont récupérées dans le tableau de contingence (les surfaces brutes) et retravaillées en fonction des requêtes de l’utilisateur. Pour cela, un module spécifique a été développé. Il contient les fonctions essentielles relatives aux traitements et à la validité des données. Etant donné l’importance de ce module pour le fonctionnement du programme et malgré sa relative complexité, une description succincte doit être faite.

Nous mettons de coté les aspects relatifs à la gestion des sous-ensembles dans ce module.

Considérons donc que nous n’avons que des unités spatiales simples. Toutes les réflexions pour développer ce module ont porté sur le fait de conserver « l’identité »

des données recherchées. En effet, il ne s’agit pas simplement de transmettre les valeurs de surface de chaque unité aux graphiques. Ces informations doivent être accompagnées du nom de l’unité, de l’année à partir de laquelle ont été calculées ces surfaces et à quel mode d’occupation du sol elles se rattachent (autrement dit les index, les identifiants des occupations du sol). Toutes ces informations sont indispensables pour certifier l’exactitude des données représentées. Pour ce faire, les données sont travaillées dans le programme avec des tableaux (des listes d’éléments), fréquemment utilisés en langage Visual Basic. Nous créons donc une table virtuelle.

Tout d’abord, les données sont retrouvées dans chaque tableau de contingence. Chaque unité

sélectionnée est recherchée. Les valeurs de surface de chaque type d’occupation du sol sont ajoutées dans un tableau. Concrètement, il s’agit donc d’une ligne du tableau de contingence. A chacune de ses valeurs est associé, dans le même tableau, l’identifiant de l’occupation du sol. Sont créés autant de tableaux « élémentaires » que de couple unité/année.

(0) Index (n) Urbain (n+1) Naturel (n+2) Agricole (1) Valeur 80 228 1666

Tableau 9 : Tableau « élémentaire » représentant les données pour une unité et pour une année

Tous ces tableaux « élémentaires » sont ensuite rangés dans un autre tableau. Ce nouveau tableau « résultats » contient donc tous les tableaux élémentaires, c’est à dire les valeurs de surface de chaque unité choisie, pour chaque année choisie. C’est un tableau de tableaux. Il est construit de manière à pouvoir retrouver l’unité voulue à l’année voulue.


41

Exemple Nous recherchons, dans le tableau « résultats », le tableau « élémentaire » de l’unité 2 pour

l’année 1 : Tableau « résultats » (i, j) = Tableau « élémentaire » de la j-ième unité pour la i-ième année Tableau « résultats » (1,2) = Tableau « élémentaire » de l’année 1 pour l’unité 2 Ce tableau « élémentaire » contient les index et valeurs pour l’unité recherchée, à l’année

recherchée : Tableau « élémentaire » (0,n) = l’index n de l’année 1 pour l’unité 2 Tableau « élémentaire » (1,n) = la valeur n de l’année 1 pour l’unité 2

Ce tableau « résultats » est systématiquement accompagné d’un second tableau contenant le

nom des unités spatiales.

Exemple Tableau de noms (j) = le nom de l’unité numéro j Tableau de noms (2) = le nom de l'unité 2

Le module de gestion des données fabrique et renvoie donc deux tableaux. Le premier contient les résultats, les données demandées par l’utilisateur. Le second renseigne sur les noms des unités spatiales choisies. Ces données sont utilisées à la fois pour construire le graphique et pour remplir le tableau l’accompagnant. La structure de ces tableaux « élémentaires » a été pensée pour faciliter le plus possible la génération, le codage de ces graphiques et tableaux.

2.3.3 Implémentation de l’outil dans l’interface d’ArcMap

Figure 16 : Barre d’outil « Analyse Occupation du sol »

1 Le bouton ouvre l’interface de préparation des données.

2 Le bouton ouvre la « Fiche Statistique ». 3 L’analyse porte sur un type d’unités spatiales. C’est « l’identifiant » sélectionné dans cette

liste qui permet de définir les unités étudiées dans la « Fiche Statistique ». 4 Il s’agit de spécifier la couche d’unités spatiales qui a été utilisée lors de la phase de

préparation des données. La liste propose toutes les couches polygonales de la fenêtre carte active. Cette information sert à ouvrir la fiche à partir d’unités sélectionnées dans cette couche, directement dans la fenêtre carte. C’est un paramètre optionnel.

2 1 4 3


42

Troisième Partie

LES RESULTATS

L e s r é s u l t a t s

43

3.1. Tests et pérennisation

La phase de codage achevée, il faut tester l’application avec des jeux de données suffisamment significatifs et diversifiés pour détecter le maximum d’anomalies. Une fois les corrections apportées, l’outil est prêt à être tester par des utilisateurs potentiels. Afin de pérenniser l’application, deux documents essentiels ont été rédigés, les manuels de maintenance et d’aide pour les utilisateurs.

3.1.1 Tests Les jeux de données testés Le jeu de données du projet Apoge (données du projet) La couche vectorielle de l’occupation du sol porte une information détaillée.

La nomenclature est riche (15 classes d’occupation du sol) et essentiellement ciblée sur les espaces agricoles. Les unités spatiales principalement testées sont les communes de la zone d’étude (75 unités). Le jeu de données de Bordeaux

Ces données, comme celles du projet Apoge, sont issues du traitement d’images satellites. La couche vectorielle est donc également très riche compte tenu de la précision que peuvent avoir les classifications.

La nomenclature est plus simple (9 classes d’occupation du sol) et révèle un territoire a caractère urbain. Les unités spatiales étudiées sont les communes de l’agglomération (32 communes). Le jeu de données de la Communauté d’agglomération de Castres-Mazamet Ces données sont celles de la BDCarto (1999).

La nomenclature est simple (6 classes). Les unités spatiales étudiées sont les communes (16 unités).

Ces tests ont permis de révéler les erreurs possibles du logiciel lors du clip ou de l’union. Par exemple, des polygones ne contenant aucune information sont parfois créés. ArcMap attribue donc une valeur nulle au champ de type numérique, et donc potentiellement à celui identifiant les modes d’occupation du sol. La valeur nulle étant zéro, l’outil a été modifié pour ne pas prendre en compte les classes d’occupation du sol qui seront identifiées par un zéro. Toutes ces restrictions sont spécifiées dans le manuel d’aide.

Les tests ont également permis d’estimer le temps moyen de préparation des données. La

durée des traitements dépend essentiellement de la densité de la couche vectorielle d’occupation du sol et de la richesse de la nomenclature utilisée. La phase de préparation des données prend alors entre deux et dix minutes.

Quelques préconisations semblent importantes. Pour une utilisation optimale de l’outil, un

travail préalable sur les données d’occupation du sol peut être nécessaire. Il est par exemple conseillé d’identifier les classes d’occupation du sol par un code numérique plutôt que par un nom. Il est préférable d’adapter la nomenclature aux éléments étudiés, de ne pas la surcharger inutilement, ou encore de regrouper les classes peu significatives dans une seule. Les données vectorielles issues de la télédétection peuvent être très riches. Il peut être bénéfique pour l’analyse de les simplifier, d’éviter de travailler avec une information trop dense si cela ne porte pas atteinte aux résultats. L’outil est en


44

mesure de traiter tous ces cas. Il s’agit simplement d’optimiser le temps de préparation des données et de rendre plus cohérente et plus fructueuse l’analyse statistique.

Les tests avec les utilisateurs potentiels

Ces tests portent essentiellement sur l’interface d’exploitation des données (la fiche statistique). Nous avons sollicités des personnes au sein de l’entreprise (ingénieurs informaticiens, chercheurs et chefs de projets ayant des compétences en aménagement et analyse territoriale). Ces personnes sont satisfaites de l’ergonomie et de la facilité d’utilisation de l’interface. Les remarques formulées sont plus d’ordre esthétique. La fonctionnalité de création/gestion de sous-ensembles est appréciée. Apres ces tests, peu de modifications ont été nécessaires.

3.1.2. Maintenance

Un manuel de maintenance accompagne l’outil. Ce document est destiné aux personnes qui auront à modifier et à maintenir l’application. Il est rédigé dans le but de fournir une vision de l’ensemble du programme, avant même de lire le code. Il décrit le rôle et l’organisation des modules. La personne doit retrouver facilement l’endroit où une erreur s’est produite, l’endroit où sont définis les paramètres qu’elle souhaite changer. On y retrouve donc l’architecture générale et détaillée de l’application.

Le code a été commenté de manière à minimiser les explications dans le manuel de maintenance. Un travail important d’explications a été fourni. Les commentaires permettent de dégager l’algorithme général de chaque procédure et fonction. Sont également expliquées les particularités et les contraintes liées à Visual Basic, ArcObjects ou aux composants utilisés. Le vocabulaire utilisé est toujours le même et les noms de variable sont significatifs.

3.1.3. Aide utilisateur

Un document d’aide, destiné aux utilisateurs, a été rédigé afin d’expliquer le fonctionnement de l’outil et de permettre une utilisation optimale. Il récapitule les objectifs de l’outil et résume les éléments importants liés à l’analyse spatiale pour une meilleure compréhension des données étudiées. Il explique en détail comment s’organisent et s’effectuent les traitements et quelles en sont leurs finalités. Les conseils et restrictions sont clairement formulés afin de lever toute ambiguïté.


45

3.2. Résultats et évolutions

3.2.1. Résultats

Figure 17 : Interface résultat (1 année étudiée, tri par données)


46

Figure 18 : Interface résultat (1 année étudiée, tri par unité)

Dans ces deux illustrations, une même requête a été effectuée. Nous étudions le profil de quatre unités (trois communes et l’ensemble) pour l’année 2000. Dans la première, le tableau trie par type de données et dans le second, par unité. Nous avons également spécifié le nom de la couche contenant la légende de l’occupation du sol. Les couleurs de chaque mode sont répercutées dans le graphique et les noms sont associés à l’index dans le tableau.


47

Figure 19 : Interface résultat (2 années étudiées)

Dans cette illustration, nous étudions les taux d’évolution des modes d’occupation du sol entre 2000 et 2002 pour un sous-ensemble créé. Les données représentées dans le tableau précisent ces taux et informent sur la répartition de chaque mode pour les deux années.


48

Figure 20 : Interface résultat (3 années étudiées)

Cette dernière illustration montre la répartition des modes d’occupation du sol sur plusieurs années. Nous avons garder le même sous-ensemble. Les données exactes sont indiquées dans le tableau.


49

Appréciation des résultats L’apport des réflexions menées pour redéfinir les objectifs et finalités de l’outil est

incontestable. Il en résulte un outil cohérent permettant une première analyse des répartitions des modes d’occupation du sol et de leur évolution.

Un des objectifs était de montrer la faisabilité technique d’un outil d’aide à l’analyse de

l’occupation du sol et de son évolution, ainsi que d’illustrer les possibilités de développement de solutions et méthodes d’analyse spatiale. Sur ce point, il est indéniable que le traitement statistique d’un nombre important de variables est appréciable lorsqu’il est automatisé.

L’effort technique s’est attaché en grande partie à la conception d’une architecture saine et évolutive, facilitant l’implémentation de nouvelles fonctionnalités ou types de représentation. Les résultats sont fiables et les requêtes s’effectuent instantanément. Le système de gestion des données, comme il a été conçu, garantit l’exactitude et la cohérence des données représentées.

Les spécifications établies ont été réalisées. L’utilisateur a rapidement et facilement accès à l’étude statistique des répartitions des modes d’occupation du sol et de leur évolution. L’outil s’intègre bien dans une analyse, un diagnostic territorial. Il facilite une première description et révèle la structure et les occupations dominantes d’une zone d’étude. Néanmoins, une solution pour comparer plusieurs unités spatiales, lors d’une analyse entre deux dates et plus, n’a pu être développée. Techniquement, la difficulté tient notamment aux limites de représentation graphique.

L’étude d’un territoire doit cependant prendre en compte un nombre plus important de variables et de facteurs pour être satisfaisante. L’expérience et les capacités d’interprétation des utilisateurs restent les outils d’analyse les plus précieux. Cet outil n’a en effet pas la prétention de faire à lui seul une analyse suffisante du territoire. Il est indispensable, pour être complet, d’y associer d’autres indicateurs, des croisements de données permettant d’expliquer les localisations et d’autres outils d’analyse. Il faut de plus rester prudent avec la manipulation des statistiques. L’interprétation dépend souvent de l’utilisateur, des conclusions qu’il souhaite mettre en avant. Organisation du temps

Le premier mois de stage a été marqué par quelques aléas dans la répartition des

développements du démonstrateur entre les différents partenaires, situation évoquée au début de ce document. Durant cette période, les réflexions et travaux n’ont pas porté directement sur l’outil statistique. C’est seulement au début du second mois que les objectifs du stage ont été réellement fixés.

La mise en place des spécifications a duré près d’un mois, temps nécessaire à la fois aux recherches bibliographiques, aux tests des différents indicateurs et à la définition des fonctionnalités. Compte-tenu de la relative nouveauté de mes compétences en développement informatique, il a été difficile d’estimer précisément le temps de mise en œuvre des spécifications. Les travaux allant de la conception de l’architecture aux tests de l’application auront finalement nécessité un peu plus de deux mois et demi. Nous avions cependant une idée globale du temps à consacrer à chacune des phases de développement afin de respecter les délais.


50

3.2.2. Evolutivité de l’outil

Compte-tenu de la durée du stage, nous nous sommes limités aux fonctions répondant directement aux besoins exprimés. En ce sens, cette application reste une première version d’un outil démontrant les capacités de développement d’extensions en VBA pour ArcGis 8 et les capacités de traitements de données et d’indicateurs d’analyse spatiale.

Cette application est donc une base de travail contenant les éléments les plus importants (gestion et manipulation des données et génération de graphiques) permettant de répondre aux spécifications établies, aux attentes des utilisateurs et de l’entreprise.

A partir de cette base, beaucoup de fonctionnalités complémentaires peuvent être

implémentées. Nous pensons notamment :

A de plus grandes capacités de comparaisons de l’évolution des répartitions des modes d’occupation du sol. A la possibilité de manipuler les modes d’occupation du sol étudiés directement dans l’outil. Il peut s’agir, comme pour la gestion des sous-ensemble d’unités spatiales, de fusionner des champs d’occupation du sol pour le temps de l’analyse. Ceci n’engendre pas pour autant une perte d’informations puisque ces regroupements sont « virtuels » et provisoires. Un nouveau type d’occupation sera donc créé et ajouté comme élément dans une liste. A la possibilité de générer d’autres types de représentation graphique et de laisser plus de choix à l’utilisateur. Cela peut s’accompagner d’une plus grande flexibilité et liberté de paramétrages (choix d’une légende particulière, choix d’affichage de certaines données, de certains champs dans le graphique comme dans le tableau, etc.) A la génération de nouvelles tables statistiques. Dans la phase de définition des spécifications, nous avons été amenés à tester une nombre important d’indicateurs. Certains, par leur relative complexité d’interprétation, ne répondaient pas directement aux besoins de l’entreprise (comme les indicateurs de taux de liaison, de Khi-Deux, etc.). Ils peuvent cependant être intégrés à l’outil si une démarche explicite d’aide à l’analyse les accompagne, le principal frein à leur développement étant bien le risque de confusion et de mauvaise interprétation des résultats.

Techniquement, il est également concevable de basculer les développements sous ArcGis 9, la gamme « SIG » la plus récente D’ESRI.

Nous avons également pensé aux possibilités de développer d’autres outils distincts et permettant de compléter autant que faire se peut l’analyse statistique et spatiale. Il n’est en effet pas pertinent de surcharger l’application afin qu’elle ne perde pas de sa cohérence et sa facilité de prise en main.

Nous aurions notamment souhaité développer un outil d’aide à l’analyse multivariée (Analyse en Composantes Principales (ACP) et classification ascendante hiérarchique) qui aurait permis d’apprécier la position des unités spatiales les unes par rapport aux autres et donc de comparer l’ensemble des unités dans un même espace. A partir de là, il est également possible, en réalisant des analyses en composantes principales pour chaque année disponible, d’estimer l’évolution de cet ensemble. Une extension développée pour ArcGis permet déjà de faire ces ACP. Son utilisation est en plus facilitée par notre outil puisque la donnée de base servant pour ce type d’analyse est le tableau de contingence. Avec cette extension et les tableaux de contingence, un utilisateur averti pourra réaliser sans difficulté ces traitements. La qualité des résultats et leur interprétation nécessitent cependant la rigueur et le bon sens de cet utilisateur.


51

CONCLUSION

La participation au projet RTE-Apoge a été une source d’apprentissage thématique et technique indéniable. Ce stage a requis des compétences en Aménagement, et plus particulièrement en analyse du territoire, et des compétences techniques en matière d’applications « SIG » et de développement informatique.

Avoir la possibilité de travailler à la fois sur la définition des spécifications, la création d’un produit et sur le développement de ce produit est une expérience enrichissante. Elle permet d’apprécier la conduite, le déroulement d’un projet dans sa totalité. Le projet Apoge s’inscrit dans une démarche de développement raisonné et répond en partie aux problématiques actuelles des aménageurs et des gestionnaires de l’environnement. En ce sens, l’outil contribue, à sa mesure, à une meilleure gestion du territoire.

Thierry RABAUTE, maître de stage, m’a accordé toute sa confiance pour mener à bien l’intégralité du développement de cet outil statistique. En retour, la société est satisfaite des résultats obtenus, répondant aux besoins exprimés.


52

ACRONYMES ACP : Analyse en Composantes Principales. APOGE : Aide à la Planification de l'Occupation des sols et à la Gestion de la ressource en Eau et de la production agricole à l'échelle régionale. CASE : Computer-Aided Software Engineering (Ingénierie logicielle assistée par ordinateur) CESBIO : Centre d’Etudes Spatiales de la Biosphère COM : Component Object Model DLL : Dynamic Linking Library ENSG : Ecole Nationale des Sciences Géographiques ESRI : Environmental Systems Research Institute HRV : Haute Résolution dans le Visible IGN : Institut Géographique National IHM : Interface Homme-Machine INRA : Institut National de Recherche Agronomique OMD : Objects Model Diagrams OWC : Office Web Components QI : Query Interface RTE : Réseau Terre et Espace SCOT : Services et Conception de système en Observation de la Terre SGBD : Système de gestion de bases de données SIG : Système d’Information Géographique TM/ETM+ : Thematic Mapper/Enhanced Thematic Mapper Plus UML: Unified Modeling Language VB : Visual Basic VBA: Visual Basic for Application


53

GLOSSAIRE

ActiveX Un contrôle ActiveX est en fait un composant COM (donc technologie Microsoft), mais il se doit

de pouvoir être visuellement manipulable via un atelier d'assemblage de composants. ActiveX permet d'obtenir la même productivité d'utilisation d'un composant logiciel que celle

que l'on peut avoir avec un générateur d'IHM (Interface Homme/Machine). L'atelier Visual Basic (en autre) permet d'assembler de tels composants, non forcément visuels.

Algorithme Terme venu du XIIIème siècle, de la traduction en latin d'un mémoire de Mohammed Ibn Musa

Abu Djefar Al-Khwarizmi commençant par : « Algoritmi dixit... ». Séquence d'opérations visant à la résolution d'un problème en un temps fini (mentionner la

condition d'arrêt). Fondé sur la thèse de Church Alonzo.

C Langage de programmation crée par Brian W. Kernighan et Dennis M. Ritchie au début des

années 70. Il fait office, à l'heure actuelle, de langage "universel". En effet il est parmi les langages les plus utilisés, cela quels que soient les domaines d'application et les machines utilisées.

C++ Langage orienté objet définit en tant qu'extension du langage C (d'où les signes ++) par Bjarne

Stroustrup en 1983.

CASE « Computer-Aided Software Engineering ». En français : Ingénierie logicielle assistée par

ordinateur. Le terme CASE regroupe tous les outils utiles dans les diverses disciplines de développement

logiciel que sont l'analyse, la conception, l'implémentation. Les outils d'aide au développement de logiciels : éditeurs de texte, de diagrammes, outils de

gestion de configuration, SGBD, compilateurs, debuggers, outils pour la mise en forme, la génération de tests, la génération d'interfaces homme-machine, etc.

Ces différents outils interviennent lors d'une ou plusieurs phases du cycle de vie du logiciel :

conception (éditeurs de texte, de diagrammes), programmation (éditeurs de texte, compilateurs, générateurs d'interfaces homme/machine), mise au point (debuggers, outils de génération de tests), etc. Certains outils, concernant notamment la gestion de configurations, la gestion de projet, interviennent durant la totalité du processus logiciel.

Component Object Model (COM)

Ce standard est propriétaire de la société Microsoft. Ce modèle permet de faire communiquer des objets (au sens de la programmation orientée objets) les uns avec les autres.

Là où le modèle COM est intéressant, c'est que les différents objets constituant une application peuvent être codés via différents langages de programmation supportant COM (Visual C++, Visual Basic, Visual J++, Visual Fox Pro, JScript, VBScript, ...). En fait, COM spécifie comment un appel de méthode va pouvoir se réaliser en unifiant (dans une certaine mesure) les types de données utilisés par

http://www.infini-fr.com/Sciences/Informatique/#Com

http://www.tout-savoir.net/lexique.php?rub=definition&code=4632



http://www.infini-fr.com/Sciences/Informatique/#C

http://javarome.free.fr/net/Analyse.html

http://javarome.free.fr/net/Conception.html

http://javarome.free.fr/net/Implementation.html


54

les langages. Ce n'est à priori pas au programmeur de garantir que son objet respecte le modèle COM, mais au compilateur utilisé.

Composant Elément d'un système. On parle de « composant électronique » pour désigner les puces, et de

« composant logiciel » pour désigner les parties de programme réutilisables.

DLL (Dynamic Linking Library) En français : Librairie à chargement dynamique. Une dll est un fichier de code similaire à un exécutable. Cependant, une dll ne peut pas

démarrer seule. Elle est obligatoirement chargée par un exécutable. Cela permet de pouvoir partager du code pour différentes applications.

Langages informatiques Les langages informatiques peuvent grossièrement se classer en deux catégories: les langages

interprétés et les langages compilés :

Langage interprété Un langage informatique est par définition différent du langage machine. Il faut donc le traduire pour le

rendre intelligible du point de vue du processeur. Un programme écrit dans un langage interprété a besoin d'un programme auxiliaire (l'interpréteur) pour traduire au fur et à mesure les instructions du programme. Langage compilé

Un programme écrit dans un langage dit "compilé" va être traduit une fois pour toutes par un programme annexe (le compilateur) afin de générer un nouveau fichier qui sera autonome, c'est-à-dire qui n'aura plus besoin d'un programme autre que lui pour s'exécuter (on dit que ce fichier est exécutable).

Méthode Une méthode est une action qu’un objet peut exécuter. Par exemple « Add » est une méthode

de l’objet « ComboBox » qui ajoute une nouvelle entrée à la liste modifiable.

Paramètre Option d'un programme, permettant de choisir entre différents traitements ou modes de

fonctionnement. Configuration des paramètres d'un programme : Action consistant à paramétrer un programme.

Programme Succession d'ordres basiques qui globalement permet de résoudre des problèmes complexes.

Tout programme est décrit par un langage de programmation.

Propriété Une propriété est un attribut de l’objet définissant l’une de ses caractéristiques telle que la

taille, la couleur, etc.







http://www.infini-fr.com/Sciences/Informatique/Langages/index.html


55

BIBLIOGRAPHIE

La documentation liée au projet Apoge

Thierry RABAUTE. « Détermination de l'occupation des sols à partir de données d'observation de la Terre »

SCOT, Juin 2003. Véronique LEFEVRE. « Spécification de réalisation de la première version du démonstrateur du projet APOGE »

EADS-Astrium, Février 2004. Les ouvrages

Denise Pumain et Thérèse Saint-Julien. « L’analyse spatiale – la localisation dans l’espace »

Editions Armand Colin, Collection Cursus Géographie, Paris 1997. Denise Pumain et Thérèse Saint-Julien. « Les interactions spatiales »

Editions Armand Colin, Collection Cursus Géographie, Paris 2001. Lena Senders. « L’analyse statistique des données en géographie »

Editions Alidade Reclus, Montpellier 1989. Erwann MinVielle et Sid-Ahmed Souiah. « L’analyse statistique et spatiale »

Editions Du Temps, Collection « Outils et méthodes en géographie », Nantes 2003. Philippe Lahousse et Vincent Piédanna. « L’outil statistique en géographie – Tome 1 : les distributions à une dimension »

Editions Armand Colin, Collection Synthèse, Paris 1998. Marc Robin. « La télédétection »

Editions Nathan Université, Collection « Fac Géographie », Paris 1995. La documentation technique

Ecole Nationale des Sciences Géographiques. « Visual Basic 6.0 », Mai 2002. Ecole Nationale des Sciences Géographiques. « Initiation à la programmation en VBA sur ArcGis », Juillet 2003. Ecole Nationale des Sciences Géographiques. « ArcGis 8.1, fonctionnalités », Juillet 2002. Ecole Nationale des Sciences Géographiques. « Initiation à la programmation », Août 2001.


56

Les sites Internet

ESRI : http://www.esrifrance.fr

http://esri.com http://support.esri.com http://support.esrifrance.fr http://arcobjectsonline.esri.com

Microsoft : http://support.microsoft.com

http://msdn.microsoft.com Compléments : http://www.infini-fr.com

http://www.vbfrance.com http://www.univ-tlse2.fr/geoprdc/bazarcarto/index.php http://www.ensg.ign.com

http://www.esrifrance.fr/

http://esri.com/

http://support.esri.com/

http://support.esrifrance.fr/

http://arcobjectsonline.esri.com/

http://support.microsoft.com/

http://msdn.microsoft.com/

http://www.infini-fr.com/

http://www.vbfrance.com/

http://www.univ-tlse2.fr/geoprdc/bazarcarto/index.php

http://www.ensg.ign.com/


57

TABLE DES FIGURES Figure 1 : Cadre géographique de l’étude ....................................................................................... 10 Figure 2 : Représentation graphique des répartitions de chaque poste d’occupation du sol ................ 15 Figure 3 : Représentation des résultats de la première ACP.............................................................. 17 Figure 4 : Représentation des résultats de la seconde ACP............................................................... 18 Figure 5 : Représentation graphique des taux d’évolution ................................................................ 20 Figure 6 : Prototypage de l’interface ............................................................................................... 22 Figure 7 : Comparaison entre les deux versions d’ArcView ............................................................... 26 Figure 8 : Diagramme de classe ..................................................................................................... 28 Figures 9 et 10 : Illustrations du principe de « Query Interface » ..................................................... 29 Figure 11 : Architecture générale de l’outil ...................................................................................... 32 Figure 12 : Diagramme fonctionnel................................................................................................. 33 Figure 13 : Organigramme de la préparation des données ............................................................... 34 Figure 14 : L’interface de préparation des données ......................................................................... 35 Figure 15 : Interface d’exploitation des données ............................................................................. 38 Figure 16 : Barre d’outil « Analyse Occupation du sol » ................................................................... 41 Figure 17 : Interface résultat (1 année étudiée, tri par données)...................................................... 45 Figure 18 : Interface résultat (1 année étudiée, tri par unité)........................................................... 46 Figure 19 : Interface résultat (2 années étudiées) ........................................................................... 47 Figure 20 : Interface résultat (3 années étudiées) ........................................................................... 48

TABLE DES TABLEAUX Tableau 1 : Tableau de contingence (surfaces en hectares) ............................................................. 14 Tableau 2 : Tableau de profils en lignes (profils des unités spatiales) ............................................... 14 Tableau 3 : Tableau de profils en colonnes (profils des postes d’occupation du sol)........................... 15 Tableau 4 : Tableau des coordonnées factorielles de la deuxième ACP ............................................. 17 Tableau 5 : Tableau de contingence pour l’an 1 .............................................................................. 19 Tableau 6 : Tableau de contingence pour l’an 2 .............................................................................. 19 Tableau 7 : Tableau des taux d’évolution entre l’an 1 et l’an 2 ......................................................... 19 Tableau 8 : Liste des paramètres nécessaires à la préparation des données...................................... 36 Tableau 9 : Tableau « élémentaire » représentant les données pour une unité et pour une année ..... 40


58

ANNEXES Annexe I : Procédure de peuplement du tableau de contingence (code-source) ................................ 59 Annexe II : Extrait du module de peuplement de la FlexGrid (code-source)....................................... 62 Annexe III : Procédure de création des graphiques (code-source) .................................................... 66 Annexe IV :Manuel d’aide .............................................................................................................. 69


59

ANNEXE I – Procédure de peuplement du tableau de contingence Option Explicit Public Sub Contingence(strPathName As String, strResultLayerName As String, _ strChampNomName As String, strChampOSName As String, _ strOverlayLayerName As String, strTabName As String, _ ConversionVal) '====================================================================== ' Générer le tableau de contingence à partir de la couche de travail ' ' Entrées : "strPathName" : répertoire de travail ' "strResultLayerName" : nom de la couche de travail ' "strChampNomName" : nom du champ contenant le nom des unités spatiales ' "strChampOSName" : nom du champ contenant les types d'occupation du sol ' "strOverlayLayerName" : nom de la couche d'unités spatiales ' ' Sortie : Le tableau de contingence (Table nommée "Surface") '====================================================================== ' Déclarations Dim pMxDoc As IMxDocument Dim pEnumLayer As IEnumLayer 'Emumérateur Dim pLayer As ILayer 'Couche énumérée Dim pTabShp As ITable 'Table de la couche de travail Dim pQuery As IQueryFilter 'Requête Dim pQuery2 As IQueryFilter 'Requête Dim strWhereClause As String ‘WhereClause de la requête Dim pCursorUG As ICursor 'Curseur Dim pCursor As ICursor 'Curseur Dim pCursor2 As ICursor 'Curseur Dim pStdTabColl As IStandaloneTableCollection 'Collection des tables seules(.dbf) Dim pTab As Itable 'Tableau de contingence Dim dictVal As Dictionary 'Dictionnaire des occupations du sol Dim sVal As String Dim strNomUG As String 'Nom de chaque unité spatiale Dim pRow As IRow 'Ligne du tableau de contingence Dim pRowShp As IRow 'Ligne de la table de la couche de travail Dim lngFieldOS As Long 'Champ des identifiants des occupations du sol dans la ‘couche

de travail Dim lngFieldUG As Long 'Champ des nom des unités spatiales dans la couche de ‘travail Dim lngFieldOS2 As Long 'Champ pour chaque occupations du sol du tableau de

‘contingence Dim lngField As Long 'Champ des surfaces dans la couche de travail Dim lngCountStdTab, i As Long Dim vVal, dblSum As Double ' Corps Set pMxDoc = ThisDocument ' Affectation de pTabShp, la table de la couche de travail Set pEnumLayer = pMxDoc.FocusMap.Layers


60

pEnumLayer.Reset Set pLayer = pEnumLayer.Next Do While Not pLayer Is Nothing If pLayer.Name = strResultLayerName Then Set pTabShp = pLayer Set pLayer = Nothing Else Set pLayer = pEnumLayer.Next End If Loop ' Index du champ contenant les types d'occupation du sol lngFieldOS = pTabShp.FindField(strChampOSName) ' Récuperation des types d'occupation du sol distinctement dans un dictionnaire Set pCursor = pTabShp.Search(Nothing, False) Set pRowShp = pCursor.NextRow Set dictVal = New Dictionary Do While Not pRowShp Is Nothing If pRowShp.Value(lngFieldOS) <> 0 Then sVal = CStr(pRowShp.Value(lngFieldOS)) If Not dictVal.Exists(sVal) Then dictVal.Add sVal, sVal End If End If Set pRowShp = pCursor.NextRow Loop ' Transfert des données du dictionnaire dans un tableau Dim parray() As Variant ReDim parray(dictVal.Count) parray = dictVal.Items ' Appel de "CreateTable" Call mNewTable.CreateTable(strPathName, strResultLayerName, strTabName, _

strChampNomName, strChampOSName, strOverlayLayerName) ' Affectation de pTab, la table qui vient d'etre créée (le tableau de contingence) Set pStdTabColl = pMxDoc.FocusMap lngCountStdTab = pStdTabColl.StandaloneTableCount For i = 0 To lngCountStdTab - 1 If pStdTabColl.StandaloneTable(i).Name = strTabName Then Set pTab = pStdTabColl.StandaloneTable(i) End If Next ' Recherche de toutes les lignes du tableau de contingence pour récupérer toutes les unités lngFieldUG = pTab.FindField("Nom_UG") Set pCursorUG = pTab.Search(Nothing, False) Set pRow = pCursorUG.NextRow ' Tant qu'une ligne existe Do While Not pRow Is Nothing ' Récupérer le nom de l'unité spatiale strNomUG = pRow.Value(lngFieldUG)


61

' Pour chaque type d'occupation du sol For i = 0 To dictVal.Count - 1 ' Recherche des polygones de la couche de travail correspondant ' à l'unité en cours et à l'occupation du sol en cours Set pQuery2 = New QueryFilter strWhereClause = strChampNomName & " = '" & strNomUG & "' AND " & _

strChampOSName & " = " & parray(i) pQuery2.WhereClause = strWhereClause Set pCursor2 = pTabShp.Search(pQuery2, False) ' Calcul de la surface totale de ces polygones lngField = pTabShp.FindField("Surf_Poly") vVal = 0 dblSum = 0 Set pRowShp = pCursor2.NextRow ' Tant qu'il y a un polygone répondant à la requete, additionner sa surface Do While Not pRowShp Is Nothing vVal = pRowShp.Value(lngField) dblSum = dblSum + vVal Set pRowShp = pCursor2.NextRow Loop ' Recherche du champ correspondant à l'occupation du sol en cours ' dans le tableau de contingence lngFieldOS2 = pTab.FindField(CStr(parray(i))) ' Peuplement du tableau de contingence pRow.Value(lngFieldOS2) = dblSum / ConversionVal 'Conversion en hectare pRow.Store ' Passage à l'occupation du sol suivante Next i ' Passage à l'unité suivante Set pRow = pCursorUG.NextRow Loop GoTo ResetVar Exit Sub ResetVar: Set pMxDoc = Nothing Set pEnumLayer = Nothing Set pLayer = Nothing Set pTabShp = Nothing Set pCursorUG = Nothing Set pQuery = Nothing Set pCursor = Nothing Set pRow = Nothing Set dictVal = Nothing Set pStdTabColl = Nothing Set pTab = Nothing Set pQuery2 = Nothing Set pCursor2 = Nothing Set pRowShp = Nothing End Sub


62

ANNEXE II – Extrait du module de peuplement de la FlexGrid Option Explicit Function CellIndex(row As Integer, col As Integer) As Long ' Calcul de l'index pour utiliser la TextArray property. CellIndex = row * FicheStat.MSHFlexGrid1.Cols + col End Function

Public Function ConcatString(lstItem() As Variant) As String ' Fabrique la chaîne de caractères entrée dans la FlexGrid - entrée = un tableau à deux dimensions Dim strTemp As String Dim strEntry As String Dim j As Integer For j = 0 To UBound(lstItem, 2) strTemp = " " & Chr(9) & " " & lstItem(1, j) strEntry = strEntry & strTemp Next j ConcatString = strEntry End Function

Public Sub Flex1An(lstNames() As Variant, lstResults() As Variant, lstYears As Variant, _ boolTri As Boolean, lstAlias As Variant) '=========================================================================== ' Gère le contenu de la FlexGrid pour une année analysée ' ' Reçoit la liste des unités et leurs valeurs de surface (lstNames et lstResults) ' Reçoit la liste des années (normalement une seule année) ' Reçoit l'option de tri des données dans la flexgrid ' Reçoit la liste des noms (labels) des occupations du sol (lstAlias) ' (cette liste est vide si l'utilisateur n'a pas choisi de couche) '=========================================================================== ' Déclarations Dim lstItem() As Variant 'Tableau représentant les données d'une unité (index et valeurs) Dim strEntry As String 'Valeurs entrées dans la flexgrid Dim Entry As String 'Lignes entrées dans la flexgrid (nom de la ligne + valeurs) Dim dblSurfTotale As Double 'Valeurs de surface totale Dim lstPart() As Variant 'Tableau des surfaces relatives (répartition des occupations dans les

unités – Profil des unités) Dim lstPartOS() As Variant 'Tableau des surfaces relatives (répartition des unités dans les

occupations – Profil des occupations du sol) Dim strTabName As String 'Nom du tableau de contingence Dim i, j As Integer Dim CurItem As Integer Dim intCountRow As Integer


63

' Corps 'Construction de la structure de la flexgrid (nombre et noms des colonnes) intCountRow = 1 lstItem = lstResults(0, 0) FicheStat.MSHFlexGrid1.Cols = UBound(lstItem, 2) + 2 For j = 1 To UBound(lstItem, 2) + 1 FicheStat.MSHFlexGrid1.col = j FicheStat.MSHFlexGrid1.row = 0 ' Si la liste des alias n'est pas vide, If UBound(lstAlias, 1) > 0 Then ' les noms de colonnes sont les alias FicheStat.MSHFlexGrid1.Text = lstAlias(1, j - 1) Else ' Sinon, les noms sont les index FicheStat.MSHFlexGrid1.Text = lstItem(0, j - 1) End If FicheStat.MSHFlexGrid1.CellAlignment = 1 FicheStat.MSHFlexGrid1.ColWidth(j) = 800 Next j ' Proprietés de la FlexGrid FicheStat.MSHFlexGrid1.ColWidth(0) = 1500 ' Calcul des surfaces totales de chaque type d'occupation du sol strTabName = "COMSurface" & lstYears(0) Dim lstSumVal() As Variant lstSumVal = mCalculTools.SumFieldITable(strTabName) If boolTri = True Then ' Tri par données ' Surfaces brutes FicheStat.MSHFlexGrid1.AddItem "Surface (en ha)", intCountRow FicheStat.MSHFlexGrid1.col = 0 FicheStat.MSHFlexGrid1.row = intCountRow FicheStat.MSHFlexGrid1.CellFontBold = True intCountRow = intCountRow + 1 ' Pour chaque unité For CurItem = 0 To UBound(lstResults, 2) ' Liste des surfaces brutes pour l'unité en cours lstItem = lstResults(0, CurItem) ' Peuplement de la flexgrid strEntry = ConcatString(lstItem) Entry = lstNames(CurItem) & " " & strEntry FicheStat.MSHFlexGrid1.AddItem Entry, intCountRow intCountRow = intCountRow + 1 Next CurItem ' Surfaces relatives FicheStat.MSHFlexGrid1.AddItem "Part (%)", intCountRow FicheStat.MSHFlexGrid1.col = 0 FicheStat.MSHFlexGrid1.row = intCountRow FicheStat.MSHFlexGrid1.CellFontBold = True intCountRow = intCountRow + 1


64

' Pour chaque unité For CurItem = 0 To UBound(lstResults, 2) ' Liste des surfaces brutes pour l'unité en cours lstItem = lstResults(0, CurItem) ' Appel de la fonction "Somme" dblSurfTotale = mCalculTools.SumRow(lstItem) ' Appel de la fonction "Part" pour calculer le profil de l'unité lstPart = mCalculTools.Part(lstItem, dblSurfTotale) ' Peuplement de la flexgrid strEntry = ConcatString(lstPart) Entry = lstNames(CurItem) & " " & strEntry FicheStat.MSHFlexGrid1.AddItem Entry, intCountRow intCountRow = intCountRow + 1 Next CurItem ' Profil Occupation du sol FicheStat.MSHFlexGrid1.AddItem "Part OS (%)", intCountRow FicheStat.MSHFlexGrid1.col = 0 FicheStat.MSHFlexGrid1.row = intCountRow FicheStat.MSHFlexGrid1.CellFontBold = True intCountRow = intCountRow + 1 ' Pour chaque unité For CurItem = 0 To UBound(lstResults, 2) ' Liste des surfaces brutes pour l'unité en cours lstItem = lstResults(0, CurItem) ' Appel de la fonction "PartOS" pour calculer le profil de l'occupation du sol lstPartOS = mCalculTools.PartOS(lstItem, lstSumVal) ' Peuplement de la flexgrid strEntry = ConcatString(lstPartOS) Entry = lstNames(CurItem) & " " & strEntry FicheStat.MSHFlexGrid1.AddItem Entry, intCountRow intCountRow = intCountRow + 1 Next CurItem Else ' Tri par unité ' Pour chaque unité For CurItem = 0 To UBound(lstResults, 2) FicheStat.MSHFlexGrid1.AddItem lstNames(CurItem), intCountRow FicheStat.MSHFlexGrid1.col = 0 FicheStat.MSHFlexGrid1.row = intCountRow FicheStat.MSHFlexGrid1.CellFontBold = True intCountRow = intCountRow + 1 ' Liste des surfaces brutes pour l'unité en cours lstItem = lstResults(0, CurItem) ' Surface brutes ' Peuplement de la flexgrid strEntry = ConcatString(lstItem) Entry = "Surface (en ha)" & " " & strEntry FicheStat.MSHFlexGrid1.AddItem Entry, intCountRow intCountRow = intCountRow + 1


65

' Surfaces relatives ' Appel de la fonction "Somme" dblSurfTotale = mCalculTools.SumRow(lstItem) ' Appel de la fonction "Part" pour calculer le profil de l'unité lstPart = mCalculTools.Part(lstItem, dblSurfTotale) ' Peuplement de la flexgrid strEntry = ConcatString(lstPart) Entry = "Part (%)" & " " & strEntry FicheStat.MSHFlexGrid1.AddItem Entry, intCountRow intCountRow = intCountRow + 1 ' Profil Occupation du sol ' Appel de la fonction "PartOS" pour calculer le profil de l'occupation du sol lstPartOS = mCalculTools.PartOS(lstItem, lstSumVal) ' Peuplement de la flexgrid strEntry = ConcatString(lstPartOS) Entry = "Part OS (%)" & " " & strEntry FicheStat.MSHFlexGrid1.AddItem Entry, intCountRow intCountRow = intCountRow + 1 Next CurItem End If End Sub

Public Sub FlexFormat() 'Format des cellules de la FlexGrid Dim Val As Variant Dim idVal As Integer Dim i, j As Integer For i = 1 To FicheStat.MSHFlexGrid1.Cols - 1 For j = 1 To FicheStat.MSHFlexGrid1.Rows - 1 idVal = j * FicheStat.MSHFlexGrid1.Cols + i FicheStat.MSHFlexGrid1.col = i FicheStat.MSHFlexGrid1.row = j Val = FicheStat.MSHFlexGrid1.Text FicheStat.MSHFlexGrid1.TextArray(idVal) = Format(Val, "#0.00") Next j Next i End Sub


66

ANNEXE III – Procédure de création des graphiques Option Explicit Public Sub Graph(lstSelectedItems() As Variant, lstSelectedYears() As Variant, _ strLegendLayer As String, boolTri As Boolean) '============================================================================ ' Générer les graphiques en fonction du nombre d'années sélectionnées ' ' Reçoit la liste des unités et des années sélectionnées ' Reçoit le nom de la couche contenant la légende de l'occupation du sol ' Reçoit l'option de tri des données de la flex grid '============================================================================ 'Déclarations Dim oChart As OWC.WCChart 'Espace graphique Dim oSeries As OWC.WCSeries 'Séries de données des graphiques Dim CurYear As Integer 'Année en cours (boucle) Dim CurItem As Integer 'Unité en cours (boucle) Dim CurId As Integer 'Index d'occupation du sol en cours (boucle) Dim lstNames() As Variant 'Tableau contenant les noms des unités Dim lstResults() As Variant 'Tableau contenant les valeurs et leur index pour toutes les

‘unités et années Dim lstItemRef() As Variant 'Tableau d'une unité servant de référence Dim lstItem() As Variant 'Tableau représentant une unité (item), valeurs + index Dim lstIndex() As Variant 'Tableau des index d'occupation du sol Dim lstValues() As Variant 'Tableau des valeurs de surface de chaque occupation du sol Dim lstColor() As Variant 'Tableau contenant les couleurs (code RGB) d'une occupation

‘du sol Dim lstAlias() As Variant 'Tableau contenant les labels (noms) des occupations du sol Dim lngCountYears As Long Dim i As Integer 'Corps ' Appel de la procédure de gestion des données Call mData.GraphData(lstSelectedItems, lstSelectedYears, lstNames, lstResults) 'Création d'un nouveau graphique FicheStat.ChartSpace1.Clear FicheStat.ChartSpace1.Refresh Set oChart = FicheStat.ChartSpace1.Charts.Add oChart.Interior.color = RGB(255, 255, 255) ' Affectation du tableau de référence pour retrouver chaque index lstItemRef = lstResults(0, 0) ReDim lstIndex(0 To 0) For i = 0 To UBound(lstItemRef, 2) ' Peuplement du tableau des index (une dimension) lstIndex(i) = lstItemRef(0, i) ReDim Preserve lstIndex(UBound(lstIndex) + 1) Next i ReDim Preserve lstIndex(UBound(lstIndex) - 1) ' Récupération des années sélectionnées dans un tableau à une dimension Dim lstYears() As Variant ReDim lstYears(0 To UBound(lstResults, 1)) lngCountYears = UBound(lstSelectedYears)


67

For i = 1 To lngCountYears lstYears(i - 1) = lstSelectedYears(i) Next i ' Récupération des alias lstAlias = mLegend.LegendAlias(lstIndex, strLegendLayer) '--Construit les series adaptées au type de graph selon le nombre d'années sélectionnées-- ' Selon le nombre d'année Select Case lngCountYears Case 1 'une année ReDim lstValues(UBound(lstResults, 2)) ' Pour l'année For CurYear = 0 To UBound(lstResults, 1) ' Pour chaque index For CurId = 0 To UBound(lstItemRef, 2) ' Pour chaque unité (item) For CurItem = 0 To UBound(lstResults, 2) lstItem = lstResults(CurYear, CurItem) ' Peuplement du tableau contenant les valeurs de surface lstValues(CurItem) = lstItem(1, CurId) Next CurItem ' Récupération de la couleur de l'occupation du sol en cours lstColor = mLegend.LegendColor(lstIndex(CurId), strLegendLayer) ' Ajout d'une série au graphique et définition des paramètres Set oSeries = oChart.SeriesCollection.Add With oSeries .Caption = lstIndex(CurId) ' Ajout des noms des unités à la dernière série If CurId <> UBound(lstItem, 1) Then .SetData chDimCategories, chDataLiteral, lstNames End If .SetData chDimValues, chDataLiteral, lstValues .Type = chChartTypeColumnStacked100 ' Affectation d'une couleur si lstColor n'est pas vide If UBound(lstColor) > 0 Then .Interior.color = RGB(lstColor(1), lstColor(2), lstColor(3)) End If End With Next CurId Next CurYear ' Appel des procédures de construction de la flexgrid pour une année Call mFlexGrid.Flex1An(lstNames, lstResults, lstYears, boolTri, lstAlias) Call mFlexGrid.FlexFormat Case 2 'Deux années Dim lstAn1() As Variant 'Tableau des index et valeurs de surface d'une unité pour l'An1 Dim lstAn2() As Variant 'Tableau des index et valeurs de surface d'une unité pour l'An2


68

Dim lstEvoItem() As Variant 'Tableau des index et valeurs des taux d'évolution Dim MaxValue As Integer 'Max de l'axe des ordonnées Dim MinValue As Integer 'Min de l'axe des ordonnées MaxValue = 20 MinValue = -20 lstAn1 = lstResults(0, 0) 'lstResults (An1, Item1) lstAn2 = lstResults(1, 0) 'lstResults (An2, Item1) ' Appel de la fonction "TauxEvo" lstEvoItem = mCalculTools.TauxEvo(lstAn1, lstAn2) ReDim lstIndex(0 To UBound(lstEvoItem, 2)) ReDim lstValues(0 To UBound(lstEvoItem, 2)) ' Pour chaque index de lstEvoItem For CurId = 0 To (UBound(lstEvoItem, 2)) ' Récupération des index et des valeurs dans deux tableaux à une dimension lstIndex(CurId) = lstEvoItem(0, CurId) lstValues(CurId) = lstEvoItem(1, CurId) ' Ajustement du format de l'axe des ordonnées If lstValues(CurId) < MinValue Then MinValue = CInt(lstValues(CurId)) End If If lstValues(CurId) > MaxValue Then MaxValue = CInt(lstValues(CurId)) End If Next CurId ' Ajout d'une série au graphique et définition des paramètres Set oSeries = oChart.SeriesCollection.Add With oSeries .Caption = lstNames(0) .SetData chDimCategories, chDataLiteral, lstIndex .SetData chDimValues, chDataLiteral, lstValues .Type = chChartTypeColumnClustered End With ' Fixe le Min/Max de l'axe des ordonnées Dim axisScale As OWC.WCScaling Set axisScale = oChart.Axes(0).Scaling axisScale.Maximum = MaxValue axisScale.Minimum = MinValue ' Appel des procédures de construction de la flexgrid pour deux années Call mFlexGrid.Flex2An(lstAn1, lstAn2, lstEvoItem, lstYears, lstAlias) Call mFlexGrid.FlexFormat Case Else 'plus de deux années ReDim lstValues(0 To UBound(lstResults, 1)) Dim bOk As Boolean Dim pos As Integer Dim lstItemId() As Variant ReDim lstItemId(UBound(lstItemRef, 2))


69

' Pour chaque index d'occupation du sol For CurId = 0 To UBound(lstItemRef, 2) ' Pour chaque unité (item) For CurItem = 0 To UBound(lstResults, 2) ' Pour chaque année For CurYear = 0 To UBound(lstResults, 1) ' Récupération des index et valeurs de l'unité à l'année courante lstItem = lstResults(CurYear, CurItem) ' Récupération des index dans un tableau à une dimension For i = 0 To UBound(lstItem, 2) lstItemId(i) = lstItem(0, i) Next i ' Recherche de la position de l'occupation du sol en cours dans le tableau bOk = mIHM.contains(lstItemId, lstItemRef(0, CurId), pos) ' Peuplement du tableau des valeurs de surface (série du graph) lstValues(CurYear) = lstItem(1, pos) Next CurYear Next CurItem ' Récupération de la couleur de l'occupation du sol en cours lstColor = mLegend.LegendColor(lstIndex(CurId), strLegendLayer) ' Ajout d'une série au graphique et définition des paramètres Set oSeries = oChart.SeriesCollection.Add With oSeries .Caption = lstIndex(CurId) ' Ajout des noms des unités à la dernière série If CurId = UBound(lstItem, 2) Then .SetData chDimCategories, chDataLiteral, lstYears End If .SetData chDimValues, chDataLiteral, lstValues .Type = chChartTypeColumnStacked100 ' Affectation d'une couleur si lstColor n'est pas vide If UBound(lstColor) > 0 Then .Interior.color = RGB(lstColor(1), lstColor(2), lstColor(3)) End If End With Next CurId ' Appel des procédures de construction de la flexgrid pour plus de deux années Call mFlexGrid.FlexXAn(lstResults, lstYears, lstAlias) Call mFlexGrid.FlexFormat End Select 'Format et propriétés du graphique et de la légende oChart.HasLegend = True oChart.Legend.Position = chLegendPositionBottom oChart.Legend.Font.Name = "Tahoma" oChart.Legend.Font.size = "8" oChart.Legend.Border.color = RGB(255, 255, 255) oChart.Axes(chAxisPositionLeft).Font.Name = "Monotype Corsiva" oChart.Axes(chAxisPositionLeft).Font.size = "10" oChart.PlotArea.Interior.color = RGB(224, 224, 224) End Sub

Projet RTE-Apoge

Outil d’aide à l’analyse de l’occupation du sol et de son évolution

- Manuel d’utilisation -

Document réalisé par Emilie DUC Septembre 2004

O u t i l d ’ a i d e à l ’ a n a l y s e d e l ’ o c c u p a t i o n d u s o l e t d e s o n é v o l u t i o n

2

TABLE DES MATIERES 1. Présentation...............................................................................................................3 2. Quelques notions d’analyse statistique..........................................................................5 3. La barre d’outils .........................................................................................................6 4. La préparation des données ........................................................................................7

4.1. Objectifs .......................................................................................................................... 7 4.2. La couche de travail.......................................................................................................... 8 4.3. Les tables statistiques ....................................................................................................... 8 4.4. Le répertoire de travail...................................................................................................... 9

5. La visualisation des données......................................................................................10

5.1. Le lancement de l’interface...............................................................................................10 5.2. Les contrôles ...................................................................................................................11 5.3. Trois types de graphiques et de tables..............................................................................12 5.4. Les sous-ensembles .........................................................................................................16 5.5. Les couleurs et les noms des types d’occupation du sol......................................................16


3

1. Présentation

L’outil se présente sous la forme d’un document ArcMap (.mxd) Configuration requise : - ArcGis 8 - Composants Office Web Components (fourni avec l’outil) Cet outil a pour objectif de faciliter l’analyse spatiale. Il aide à mettre en évidence l’existence de

sous-ensembles territoriaux, à dégager de grands ensembles d’occupation du sol, à rechercher, quantifier et localiser les spécialisations d’unités géographiques. Il sert également à comparer les différentes unités spatiales de l’ensemble géographique étudié, grâce notamment à la génération des profils, de la typologie de ces unités.

Le but est de faire un début d’analyse spatiale rapide d’un territoire peu ou mal connu en

fonction d’un ensemble d’unités géographiques pertinemment établi. Il s’agit d’un outil statistique avant tout.

Il permet donc de : ! Fournir rapidement des éléments, des axes d’analyse et d’aide à la décision en matière

d’organisation spatiale, d’aménagement et de planification territoriale.

! Faciliter l’usage des procédures et méthodes relatives à l’analyse spatiale.

! Effectuer des traitements identiques, donc comparables, à différents ensembles géographiques (par exemple pour l’étude menée sur les grandes agglomérations du sud-ouest européen).

! Créer de l’information géographique à jour et qui souvent n’existe pas directement à l’échelle

de l’étude.

Cet outil est destiné aux gestionnaires de l’aménagement et de l’environnement. Il peut être

utilisé dans le cadre de l’élaboration d’un diagnostic territorial ou pour l’étude de tout ensemble géographique cohérent (territoires d’intercommunalité, régions agricoles, bassins versants, etc.)

Il est potentiellement utilisable par toutes les personnes ayant quelques bases en analyse statistique et spatiale et désireuses de s’informer sur l’occupation du sol et son évolution sur un territoire d’étude.


4

L’outil permet de représenter graphiquement les répartitions des différents types d’occupation du sol par rapport à des unités spatiales.

Trois types d’analyse sont possibles :

Etude d’une couche d’occupation du sol : Un graphique de type histogramme empilé 100% permettant de comparer la contribution en

pourcentage de chaque valeur y par rapport au total. Les abscisses x pourront représenter soit une unité, soit un sous-ensemble d’unités, soit l’ensemble des unités. Ce graphique représente donc la répartition de l’occupation d’une année pour plusieurs unités.

Etude de l’évolution de l’occupation du sol entre deux dates : Un graphique de type histogramme classique représentant les taux d’évolution entre deux

dates des différents types d’occupation du sol pour une unité. Etude de l’évolution de l’occupation du sol sur plus de deux années : Un graphique de type histogramme empilé 100% permettant de représenter la répartition en

pourcentage des types d’occupation du sol sur plusieurs années pour une unité.


5

2. Quelques notions d’analyse statistique

Il faut entendre par analyse spatiale la mise en évidence de sous-ensembles territoriaux, l’étude des répartitions des différents types d’occupation du sol et la détermination d’unité géographique spécialisée ou plus généralement l’élaboration de typologies, de profils de l’ensemble, de sous-ensembles ou d’unités spatiales.

L’analyse spatiale met l’accent sur les règles d’organisation de l’espace. Elle a pour objectif de décrire une disposition particulière de certains objets, leur organisation spatiale, repérer les structures, expliquer une localisation par une autre.

Il est rare que l’analyse spatiale porte sur des objets élémentaires, c’est à dire dont l’implantation physique corresponde directement à l’implantation géographique. Les objets sont souvent des agrégats, des regroupements d’objets élémentaires. On appelle « unité spatiale » une portion de la surface terrestre à laquelle on associe des informations spatiales et sémantiques qui résument l’ensemble des objets élémentaires qui y sont localisés.

Les individus sont ceux sur lesquels porte l’observation, l’analyse. Dans notre cas, les individus

statistiques sont des unités géographiques (ou unités spatiales), soit des communes, des petites régions agricoles ou encore des bassins hydrauliques.

Les variables sont des caractéristiques qui décrivent, représentent les individus. Ici, nous étudions l’occupation du sol, donc les variables sont les différents types de couverture territoriale (espaces urbains, espaces agricoles, etc.)

Les données utilisées pour générer les graphiques sont celles de surfaces brutes (toujours calculées en hectares). Elles se récapitulent dans un tableau de contingence (en terme statistique) ou, concrètement, sous forme d’une table Dbase qui sera créée dans l’application ArcGis.

Les tables statistiques créées :

Table principale Tableau de contingence : Il décrit l’occupation du sol selon deux critères : La localisation géographique dont les n modalités sont représentées par un ensemble

géographique d’unités spatiales. Les types d’occupation du sol dont les p modalités correspondent aux p différents types de la

nomenclature utilisée. Pour l’analyse d’un tableau de contingence, on emploie le terme « d’individus » pour désigner

les lignes qui sont souvent en géographie des unités spatiales et le terme de « variables » pour les colonnes.

Tables annexes Le tableau de profils en lignes : Il récapitule la répartition (en %) de chaque type d’occupation du sol par unité spatiale. Le tableau de profils en colonnes : Il récapitule la répartition (en %) des unités spatiales pour chaque type d’occupation du sol.


6

3. La barre d’outils L’application se décompose en deux fonctions distinctes mais dépendantes : - la préparation des données de surfaces de chaque type d’occupation du sol de la zone d’étude en fonction d’un type d’unités spatiales. - la visualisation, la représentation graphique de ces données. Ces fonctions sont accessibles grâce à la barre d’outils « Analyse Occupation du sol ».

Figure 1 : La barre d’outils

1 Le bouton ouvre l’interface de préparation des données.

2 Le bouton ouvre la « Fiche Statistique ».

3 Choisissez le type d’unités spatiales que vous souhaitez étudier (après en avoir préparer les données)

C’est le « code » sélectionné dans cette liste qui permet de définir les unités étudiées dans la « Fiche Statistique ».

4 Optionnellement, spécifiez la couche des unités spatiales étudiées (utilisé lors de la phase de préparation des données).

La liste propose toutes les couches polygonales de la fenêtre carte active. Cette information sert à ouvrir la fiche à partir d’unités sélectionnées directement dans la

couche. La préparation des données est possible si au moins deux couches polygonales sont présentes dans la fenêtre carte et que ces dernières ont un système de projection. La « Fiche Statistique » est disponible si vous avez préparé au moins un jeu de données (Le tableau de contingence doit être dans la fenêtre carte.)

2 1 4 3


7

4. La préparation des données

Figure 2 : L’interface de préparation des données

4.1 Objectifs Cette fonction a pour objectif de générer le tableau de contingence et ses deux tableaux

dérivés informant sur les surfaces relatives. Pour l’analyse graphique, seules les données du tableau de contingence (table nommée

« Surface ») sont utilisées. Toutes les données nécessaires peuvent être recalculées à partir de ce tableau.

Les deux tableaux de profils sont créés uniquement pour que vous n’ayez pas à les construire.

Ils vous permettrons de continuer l’analyse dans d’autres applications statistiques. Afin de créer ce tableau de contingence, des traitements préalables sur les couches

d’occupation du sol et d’unités spatiales sont indispensables. La préparation des données se décompose en deux étapes :

- la création d’une couche de travail (résultante des géotraitements), - la création des trois tables statistiques à partir de cette couche de travail.

IMPORTANT : Il ne faut jamais modifier le nom, la structure ou le contenu des tables statistiques créées. Si les données de ces tables sont altérées ou perdues, il est préférable de recommencer la procédure de préparation des données.

1

8

67

3 2

5

4


8

4.2. La couche de travail

La couche de travail est préparée afin de fournir les informations nécessaires à la génération de la table de « Surface » (ou tableau de contingence).

Définir : 1 Une couche polygonale de l’occupation du sol d’une zone d’étude. 2 Le champ de la table attributaire contenant les identifiants des types d’occupation du sol. Ces identifiants peuvent être de différents types : un code numérique, un nom d’occupation du sol. (Le numéro « 0 » n’est pas considéré dans les traitements.) Il est conseillé de travailler avec des codes numériques. 3 Une couche polygonale d’unités spatiales. Celles-ci doivent être totalement contenues dans la couche de l’occupation du sol. 4 Le champ de la table attributaire contenant les noms de ces unités spatiales. La liste présentée pour sélectionner ce champ propose uniquement les champs de type « texte ». 5 Le nom de la couche de travail qui sera créée.

4.3. Les tables statistiques

Trois tables (.dbf) sont générées à partir de la couche de travail.

La première table contient les surfaces, en hectare, de chaque type d’occupation du sol par rapport à un ensemble d’unités spatiales (table nommée « Surface »).

La deuxième est calculée à partir de la surface totale des unités spatiales, et informe donc sur le profil des unités (table nommée « ProfilUG »).

La troisième est calculée à partir de la surface totale des types d’occupation du sol, et informe donc sur le profil de l’occupation du sol (table nommée « ProfilOS »). 6 Spécifier quel type d’unités spatiales est utilisé par le biais d’un identifiant de trois caractères 7 Spécifier l’année des données d’occupation du sol.


9

Exemple : Le travail s’effectue sur une couche d’occupation du sol pour l’année 2002 et une couche d’unités spatiales représentant les communes de cette zone d’étude. Il s’agit de choisir un identifiant de trois caractères pour ces unités (COM par exemple) et de spécifier l’année par le biais de la liste proposée (2002). Dans ce cas les tables créées seront : « COMSurface2002 » « COMProfilUG2002 » « COMProfilOS2002 »

Si les noms de tables sont gérés ainsi, c’est dans le but de distinguer les unités spatiales

utilisées et de récupérer l’information « année » utile dans l’étude de l’évolution de l’occupation du sol. Les identifiants des unités spatiales apparaîtront ensuite dans la première liste de choix de la barre d’outils « GraphTools ».

Les tables créées ont toutes la même structure : - Un champ identifiant et un champ « Nom_UG » repris dans la table attributaire de la couche

d’unités spatiales. L’ordre et les identifiants des unités sont donc identiques dans ces tables. - Un champ ajouté par type d’occupation du sol.

4.4. Le répertoire de travail 8 Spécifier le répertoire où seront sauvegardées les données créées. Par défaut, le répertoire

« temp » est proposé. Spécifier un nom de dossier inexistant est possible. Il sera proposer à l’utilisateur de le créer. Un dossier portant le nom de la couche d’occupation du sol est crée afin de différencier les données en fonction de la zone d’étude.

La couche de travail et les trois tables créées sont ajoutées à la fenêtre carte. Les tables sont visibles dans la table des matières de la carte, à l’onglet « Source ».


10

5. La visualisation des données

5.1. Le lancement de l’interface

Vous avez la possibilité d’effectuer une première requête en sélectionnant des entités de la

couche des unités spatiales étudiées. Il est nécessaire d’avoir préalablement spécifier le nom de cette couche dans la liste de la boite à outil. (élément 3)

Figure 3 : L’interface de visualisation des données

1

2

4

7

6

3

5

8


11

5.2. Les contrôles

1 Liste des années disponibles.

2 Liste des unités spatiales disponibles.

3 Liste des couches polygonales dont la légende est de type « Valeurs uniques ». Cette légende permet de définir les couleurs et noms des modes d’occupation du sol.

4 Option de tri des données dans le tableau. Par défaut ce tri est par données. Option disponible pour l’étude d’une année d’occupation du sol.

5 Indication du nombre d’unités spatiales sélectionnées dans la liste.

6 Tableau des données.

7 Espace graphique.

8 Bouton de fermeture de l’interface.

Exécuter une requête.

Enregistrer un sous-ensemble. (voir chapitre 5.4)

Supprimer un sous-ensemble. (voir chapitre 5.4)

Restaurer un sous-ensemble. (voir chapitre 5.4)

Tout désélectionner dans la liste.

Tableau 1 : Liste des contrôles de l’interface de visualisation.


12

5.3. Trois types de graphiques et de tables Les données représentées dépendent du nombre d’années sélectionnées dans la première liste

de choix. Il est possible : - D’étudier la répartition des types d’occupation du sol d’une ou plusieurs unités pour une

année donnée.

Figure 4 : Représentation graphique pour une année d’étude

Ce graphique représente le poids de chaque type d’occupation du sol dans une unité spatiale. Ces données sont retranscrites dans la table à l’entête « Part (%) ». La table présente également :

- les données de surfaces brutes (en hectare) à partir desquelles a été calculé ce poids, - la part que représente une unité dans la surface totale de chaque mode d’occupation du sol.

Tableau 2 : Tableau des données pour une année d’étude (tri par unité)


13

Tableau 3 : Tableau des données pour une année d’étude (tri par données)

Limites d’affichage :

La sélection d’un nombre important d’unités risque de rendre le graphique illisible. Nous conseillons de ne pas dépasser 7/8 unités.


14

- D’étudier l’évolution de l’occupation du sol d’une seule unité sur deux années (représentation des taux d’évolution).

Figure 5 : Représentation graphique des taux d’évolution entre deux années

Ce graphique représente les taux d’évolution de chaque type d’occupation du sol entre deux années données.

La table récapitule la part de chaque type d’occupation du sol dans l’unité étudiée et le taux d’évolution.

Tableau 4 : Tableau des données pour deux années d’étude


15

- D’étudier l’évolution de l’occupation du sol d’une seule unité sur plusieurs années.

Figure 6 : Représentation graphique pour plus de deux années d’étude

Ce graphique représente l’évolution sur plus de deux années des répartitions de chaque type d’occupation du sol pour une unité choisie.

Les données qui l’accompagne récapitulent ces valeurs de répartition (donc la part en %).

Tableau 5 : Tableau des données pour plus de deux années d’étude


16

5.4. Les sous-ensembles Il est possible de constituer des sous-ensembles en regroupant des unités spatiales simples. Un

sous-ensemble est ensuite considéré comme une unité spatiale à part entière. Il est donc rajouté à la liste de choix des unités.

Un sous-ensemble nommé <Ensemble> est toujours créé. Il représente toutes les unités spatiales.

Sa restauration est possible et sélectionnera donc toutes les unités de la liste (hors sous-ensembles). Les sous-ensembles sont mémorisés pendant la durée d’exécution du programme, c’est à dire tant

que la « Fiche Statistique » est ouverte. Cette fonction s’agrémente de trois contrôles : - Le bouton propose d’enregistrer les éléments sélectionnés dans la liste sous un nom de votre

choix. Un sous-ensemble est créé et ajouté à la liste des unités spatiales. Ils sont distingués par des

crochets (<>) aux extrémités du nom. - Le bouton permet de restaurer un sous-ensemble. Une boite de dialogue vous demande de spécifier le nom du sous-ensemble à restaurer. Les unités

spatiales composant ce sous-ensemble sont alors sélectionnées dans la liste. - Le bouton supprime un sous-ensemble. Il n’est pas possible d’inclure un sous-ensemble dans un nouveau sous-ensemble. Il est impossible de supprimer <Ensemble> et de nommer un sous-ensemble « Ensemble ».

5.5. Les couleurs et les noms des types d’occupation du sol

Les couleurs de représentation des occupations du sol sont définies aléatoirement. Vous avez la possibilité de récupérer, dans la légende de la couche d’occupation du sol, les

couleurs et les labels utilisés pour chaque type d’occupation du sol. Ceci suppose que la légende soit affichée dans la fenêtre carte. Cette légende doit être

construite à partir du champ identifiant les types d’occupation du sol et de type « Valeurs Uniques ». (Ce champ est le même que celui spécifié lors de la préparation des données.)

La liste placée sous l’espace graphique vous permet d’indiquer cette couche.


17

Tables des figures et tableaux Figure 1 : La barre d’outils ............................................................................................................. 6 Figure 2 : L’interface de préparation des données ........................................................................... 7 Figure 3 : L’interface de visualisation de données ...........................................................................10 Figure 4 : Représentation graphique pour une année d’étude..........................................................12 Figure 5 : Représentation graphique des taux d’évolution entre deux années...................................14 Figure 6 : Représentation graphique pour plus de deux années d’étude...........................................15 Tableau 1 : Liste des contrôles de l’interface du visualisation ..........................................................11 Tableau 2 : Tableau des données pour une année d’étude (tri par unité).........................................12 Tableau 3 : Tableau des données pour une année d’étude (tri par données)....................................14 Tableau 4 : Tableau des données pour deux années d’étude...........................................................14 Tableau 5 : Tableau des données pour plus de deux années d’étude ...............................................15

Développement d’un outil d’aide à l’analyse de l...

Documents

Transcript of Développement d’un outil d’aide à l’analyse de l...