Les principes des systmes dinformation gographique

Principes, algorithmes et architecture du systme Savane

Marc Souris

Sommaire

Premire partie : introduction et prsentation gnrale du systme SAVANE 0. Introduction ..1 1. Prsentation gnrale des systmes d'information gographique .. 9
1.1. L'apport de l'informatique pour la gographie ou la cartographie 1.2. Les SIG comme synthse de ces domaines : historique et volution 1.2.1. Les dbuts : les annes 60-70 1.2.2. La consolidation : les annes 80 1.2.3. La diffusion : les annes 90 1.2.4. Les volutions actuelles 1.3. Les SIG : objectifs gnraux 1.4. Conclusion

2. Prsentation du systme SAVANE.... 21

2.1. Le systme SAVANE : principes gnraux 2.1.1. Les concepts gnraux de SAVANE 2.1.2. Larchitecture gnrale de SAVANE 2.1.3. Administrer une base SAVANE 2.2. Prsentation des diffrents modules 2.2.1. SAVATECA : administration des bases de donnes
2.2.1.1. Principes gnraux dadministration 2.2.1.2. Configuration du systme 2.2.1.3. Organisation dune base de donnes SAVANE : principe gnraux 2.2.1.4. Cration dune base de donnes 2.2.1.5. Gestion du schma 2.2.1.6. Gestion des vues externes 2.2.1.7. Intgration dobjets 2.2.1.8. Gestion des utilisateurs

2.2.2. SAVAMER : gorfrencement dimages et constitution de mosaques

2.2.2.1. Le gorfrencement 2.2.2.2. Le r-chantillonage

II Sommaire
2.2.2.3. Le mosaquage et lintgration

2.2.3. SAVEDIT : saisie vectorielle sur cran avec gestion des contraintes dintgrit
2.2.3.1. Principes gnraux 2.2.3.1. Format des documents SAVEDIT 2.2.3.1. Principes gnraux 2.2.3.1. Principes gnraux

2.2.4. SAVANE : exploitation des bases de donnes et cartographie

2.2.4.1. Cartes, cadres et requtes 2.2.4.1.1. La classe CCarte 2.2.4.1.2. La classe CCadre 2.2.4.2. Principales oprations de manipulation de donnes 2.2.4.3. Masques et distances 2.2.4.4. Macro-commandes et mthodes 2.2.4.5. Edition cartographique et impression 2.2.4.6. Utilisateurs et partage des bases de donnes 2.2.4.7. Raster et vecteur

2.2.5. SAVATLAS : consultation de cartes et de donnes 2.2.6. SAVLIBRARY : librairie de dveloppement VC++ 2.2.7. SAVSERVEUR : serveur de requtes via Internet
2.2.7.1. Mthodes client/serveur via Internet 2.2.7.2. Larchitecture du serveur 2.2.7.3. Larchitecture dun client

2.3. La constitution et lexploitation dune base de donnes avec SAVANE 2.3.1. Gnralit sur la constitution d'une base de donnes gographiques
2.3.1.1 Mthodes de mise en place, d'administration, et d'exploitation 2.3.1.2 Difficults

2.3.2. De la cration d'une base de donnes son exploitation

2.3.2.1 La cration d'une base de donnes : schma et mthodes 2.3.2.2 L'intgration graphique 2.3.2.3 Modifications et unions graphiques, contraintes d'intgrits 2.3.2.4 L'intgration descriptive 2.3.2.5 Vues externes et droits d'accs 2.3.2.6 Cration et gestion de mthodes

Deuxime partie : Modliser et grer linformation gographique 3. Modliser le monde rel ... 59
3.1. Prambule 3.1.1. Quelques exemples 3.1.2. Prcision et description 3.2. Pourquoi et comment modliser le monde rel 3.2.1. Comment apprhender et reprsenter la ralit avec un ordinateur 3.2.2. Ralit et connaissance 3.2.3. Modliser la connaissance 3.2.4. Collection dobjet et gestion 3.3. La schmatisation du monde rel : de la ralit la gographie 3.3.1. La localisation comme attribut : lobjet gographique 3.4. La schmatisation de la localisation : de la gographie la gomtrie

Sommaire III
3.4.1. Gographie et cartographie : une union agite 3.4.2. Cartes de localisation et cartes thmatiques 3.4.3. La reprsentation gomtrique de la localisation gographique 3.4.4. Dcrire la localisation 3.4.5. Les limites du modle gomtrique 3.5. De la gomtrie linformatique : la reprsentation informatique de la localisation 3.5.1. La reprsentation en maille 3.5.2. La reprsentation vectorielle 3.5.3. Les structures de reprsentation de linformation localise 3.5.4. Les mthodes de compactage 3.6. Les sources de linformation localise : nature et validit 3.6.1. Les moyens dacquisition des donnes localises 3.6.2. La validit de linformation 3.7. Structure gomtriques des objets dans le systme SAVANE 3.7.1. Le modle gomtrique 3.7.2. La classe CArc 3.7.3. Les changements de reprsentation interne 3.8. Conclusion

4. Mesurer la localisation . 95
4.1. Introduction 4.2. Formes et mesure de la Terre : godsie et gravimtrie 4.2.1. Mesurer la forme de la Terre : la godsie 4.2.2. Lapproche gomtrique 4.2.3. Lapproche gophysique
4.2.3.1. Gravit et gode. 4.2.3.2. De nouveaux ellipsodes

4.2.4. Nouveaux instruments, nouvelles mesures, nouvelles prcisions

4.2.4.1. Le systme GPS 4.2.4.2 Les changements de datum

4.2.5. Prcision des mesures 4.3. Reprsenter l'ellipsode sur une surface plane : cartographie et projections 4.3.1. Les dformations 4.3.2. Les surfaces dveloppables 4.3.3. Coordonnes et espace de projection 4.3.4. chelles et cartes 4.3.5. chelle, projection, prcision 4.4. Exemples de projections 4.4.1. La projection Mercator 4.4.2. La projection UTM (Universal Transverse Mercator) 4.4.3. La projection conique de Lambert 4.5. SAVANE, datum et projections 4.5.1. Provenance des donnes en entre 4.5.2. Fonctionnement de SAVEDIT pour les projections et le datum 4.5.3. Fonctionnement de SAVANE pour les projections dans un cadre 4.6. Conclusion

IV Sommaire

5. De l'objet la collection d'objet : les SGBD .... 129

5.1 Introduction 5.2 Notions classiques sur les SGDB 5.2.1. Les problmes soulevs par l'utilisation de fichiers traditionnels : dpendance, redondance, intgrit, scurit 5.2.2. Lobjectif des SGBD 5.2.3. La modlisation de la ralit dans les SGBD
5.2.3.1. Les diffrents modles de donnes 5.2.3.2. Les niveaux de description

5.2.4. Les modles hirarchique et rseau 5.2.5. Le modle relationnel

5.2.5.1. Les principes du relationnel 5.2.5.2. La notion de cl et la thorie de la normalisation 5.2.5.3. Lalgbre relationnelle 5.2.5.4. Puissance et limite du relationnel

5.2.6. Le modle objet

5.2.6.1. Objets, mthodes, encapsulation et hritage 5.2.6.2. Les bases de donnes objets

5.3. SGBDR et objets gographiques : lextension du modle relationnel 5.3.1 Objectifs 5.3.2 Lextension du modle relationnel
5.3.2.1. Les principes de lextension du modle 5.3.2.2. Relations localises et notion de cl gographique

5.3.3. Les extensions de lalgbre relationnelle

5.3.3.1. La restriction spatiale 5.3.3.2. La jointure spatiale 5.3.3.3. La projection spatiale 5.3.3.4. Masques et semi-jointures gomtriques

5.3.4. Objets spatiaux et oprations relationnelles classiques 5.4. Structuration et indexation de lattribut de localisation 5.4.1. Les mthodes classiques dindexation 5.4.2. Lindexation multidimensionnelle 5.5. SAVANE : mise en uvre du relationnel tendu 5.5.1. Schma : relations et attributs 5.5.2. Structuration des collections dobjet
5.5.2.1. Architecture gnrale et organisation des bases de donnes 5.5.2.2. Indexation gographique et structure des fichiers 5.5.2.2.1. Le type non localis 5.5.2.2.2. Le type point 5.5.2.2.3. Le type ligne 5.5.2.2.4. Le type zone 5.5.2.2.5. Le type mosaque

5.5.3. Intgration dobjets et de valeurs dattributs

5.5.3.1. La constitution dune relation 5.5.3.2. Codage des valeurs dattributs descriptifs 5.5.3.3. Lintgration graphique 5.5.3.4. Lintgration descriptive

Sommaire V
5.5.3.5. La classe CIndexAttribut

5.5.4. SAVANE : requtes et tats temporaires

5.5.4.1. Principes dune requte dans SAVANE 5.5.4.2. Dfinition et gestion des macro-commandes

5.5.5. La classe CLecture 5.5.6. SAVANE : les structures internes

5.5.6.1. Vecteur et raster 5.5.6.2. Un algorithme de rasterisation

5.5.7.Les masques
5.5.7.1. La structure dun masque 5.5.7.2. Cration dun masque : zone tampon ou dfinition sur cran 5.5.7.3. Lalgbre des masques

5.5.8. La ralisation des opration relationnelles classiques

5.5.8.1. La restriction 5.5.8.2. La jointure

5.5.9. La ralisation des opration relationnelles tendues

5.5.9.1. La restriction spatiale 5.5.9.1.1. La restriction spatiale par fentre dtude 5.5.9.1.2. La restriction spatiale par domaine 5.5.9.2. La jointure spatiale 5.5.9.3. Les semi-jointures spatiales

5.5.10. La connexion dautres systmes de gestion de base de donnes 5.6. Conclusion

6. Gorfrencement et intgration dimages .. 195

6.1. Introduction 6.2. Dfinition d'une classe d'objet pour les donnes venant dimages : le pixel 6.2.1. Dfinition de lobjet 6.2.2. Gestion des collections de pixel 6.3. Gorfrencement des images et cration des objets 6.3.1. Redressement dimage 6.3.2. Le choix des points dappui 6.3.3. Le r-chantillonnage 6.3.4. Le mosaquage et lintgration dans une relation
6.3.4.1. Les mthodes de correction gomtriques pour les mosaques 6.3.4.2. Les mthodes de correction descriptives pour les mosaques 6.3.4.3. Lassemblage des images

6.3.5. Un cas particulier : les satellites dobservation de la Terre 6.4. SAVANE et la gestion des mosaques 6.4.1. Structure des relations de type mosaque 6.4.2.Oprations relationnelles 6.4.3. Cration de relations de type mosaque et oprations de changement de type 6.4.4. Utilisation des mosaques dans le cadre objet
6.4.4.1. La classe Cmosaque 6.4.4.2. Quelques classes drives

6.5. Le module SAVAMER 6.5.1. Prsentation gnrale

VI Sommaire
6.5.2. La prise de points dappui
6.5.2.1. Principes gnraux et interface graphique 6.5.2.2. La saisie manuelle des points dappui 6.5.2.3. La saisie semi-automatique et automatique

6.5.3. Le redressement et le r-chantillonnage

6.5.3.1. Le redressement 6.5.3.2. Le r-chantillonnage 6.5.3.3. Un algorithme de triangulation 6.5.3.4. Le redressement descriptif des dynamiques

6.5.4. Le mosaquage et lintgration dans une mosaque 6.6. Conclusion

7. Les contraintes d'intgrits spatiales et la saisie graphique .. 227

7.0. Introduction 7.1. La qualit dans les bases de donnes gographiques 7.1.1. Le problme gnral de la qualit dans les bases de donnes gographiques 7.1.2. La cohrence spatiale 7.1.3. Les contraintes dintgrit spatiales 7.2. Les contraintes dintgrit pour les bases de donnes 7.2.1. Le cadre relationnel 7.2.2. Les contraintes dintgrit 7.2.3. Les contraintes dintgrit pour les donnes localises 7.3. Les contraintes dintgrit spatiale 7.3.1. Une typologie des contraintes dintgrit spatiale 7.3.2. Les contraintes gomtriques 7.3.3. Les contraintes topologiques de type
7.3.3.1. Fermeture et centrode 7.3.3.2. Connexit 7.3.3.3 Surface et primtre

7.3.4. Les contraintes relationnelles

7.3.4.1. Contrainte d'unicit de cl 7.3.4.2. Contrainte d'appartenance un domaine 7.3.4.3. Contraintes descriptives de voisinage 7.3.4.4. Contraintes topologiques 7.3.4.5. Contraintes mtriques

7.3.5. Les contraintes de jointure

7.3.5.1. Les relations spatiales entre objets gographiques 7.3.5.2. Les contraintes topologiques 7.3.5.3. Les contraintes descriptives

7.4. Modles gomtriques et mise en uvre des contraintes dintgrit spatiale 7.4.1. Les diffrentes mthodes de stockage
7.4.1.1. Les modles spaghetti 7.4.1.2. Les modles topologiques

7.4.2. La vrification de la cohrence spatiale 7.5. SAVANE, saisie graphique et contraintes d'intgrit spatiale 7.5.1. Prsentation du module SAVEDIT
7.5.1.1. Les principes de la saisie graphique avec SAVEDIT 7.5.1.2. Saisie et indexation gographique 7.5.1.3. La saisie de points 7.5.1.4. La saisie de lignes

Sommaire VII
7.5.1.5. La saisie de zones 7.5.1.6. Saisie, datum et projection gographique 7.5.1.7. Le format des documents SAVEDIT

7.5.2.Les contraintes sur les objets gomtriques

7.5.2.1. La classe CArc 7.5.2.2. Nettoyage des arcs 7.5.2.3. Simplicit 7.5.2.4. Extra-simplicit 7.5.2.5. Fusion darc 7.5.2.6. Suppression darcs en double 7.5.2.7. Union darcs

7.5.3.Les contraintes sur les objets gographiques

7.5.2.1. Le nettoyage des zones 7.5.3.2. La fermeture de zones 7.5.3.3. Connexit et fermeture des arcs 7.5.3.4. Unicit de cl (zones scantes, zones incluses) 7.5.3.5. Centrode de zones 7.5.3.6. Valeurs adjacentes (courbes de niveaux) 7.5.3.7. Valeurs adjacentes (points cots)

7.5.4. Quelques procdures automatiques : algorithmes

7.5.4.1. La dtection automatique des contours de zone 7.5.4.2. La saisie semi-automatique darc par suivi de contour 7.5.4.3. Le calcul automatique de centrode de zones 7.5.4.4. La cration de taches fermes partir darcs frontires

7.6. Conclusion

Troisime partie : analyse spatiale et reprsentation cartographique 8. Analyser : calculs et analyse spatiale ... 267
8.1. Introduction 8.2. Rappels sur lanalyse spatiale 8.2.1. Structures spatiales et objets gographiques : gnralisation et agrgation 8.2.2. Distribution spatiale dun phnomne 8.2.3. Homognit spatiale, relations de voisinage, regroupement 8.3. SAVANE : exploration des donnes et statistique 8.3.1. Lexploration individuelle 8.3.2. Lexploration statistique 8.4. SAVANE et les mthodes sur les attributs descriptifs 8.4.1. Le principe de la cration de nouveaux attributs descriptifs 8.4.2. Calcul numrique et logique 8.4.3. Classifications et mthodes de discrtisation 8.4.4. Agrgations descriptives 8.4.5. Comparaison dattributs 8.4.6. Combinaison dattributs 8.4.7. Ordre 8.5. Lutilisation de la localisation pour la cration de nouveaux attributs descriptifs 8.5.1. Surface, primtre, coordonnes 8.5.2. Orientation

VIII Sommaire
8.5.3. Distance un point, une relation, un masque 8.5.4. Go-agrgations
8.5.4.1. La go-agrgation gomtrique par distance 8.5.4.2. Go-agrgation par surface dun masque 8.5.4.3. Go-agrgation par valeur pondre par la surface

8.5.5. Appartenance 8.5.6. Go-agrgation sur les pixels : le r-chantillonage 8.5.7. Oprations sur les modles numriques de terrain : orientation, pente, coulement
8.5.7.1. Pente et orientation 8.5.7.2. Dautres indices en gomorphologie et hydrologie

8.6. La cration de relations temporaires 8.6.1. Le principe de la cration de nouvelles relations 8.6.2. La duplication 8.6.3. La dfinition directe sur cran ou par masque 8.6.4. La cration de mailles 8.6.5. La cration par changement de type dobjet 8.7. Les oprations de changement de type dobjet 8.7.1. Vers le pixel : interpolation ou rasterisation
8.7.1.1. Mosaque et type Raster 8.7.1.2. Mthodes dinterpolation 8.7.1.2.1. La mthode barycentrique 8.7.1.2.2. Barycentre sur tous les points 8.7.1.2.3. Interpolation sous contrainte 8.7.1.3. Zone vers pixel : rasterisation

8.7.2. Vers la zone : vectorisation ou tesslation

8.7.2.1. Un algorithme de vectorisation 8.7.2.2. Un algorithme de tesslation 8.7.2.3. De la ligne la zone : crer la topologie 8.7.2.4. De la zone la zone : regrouper, roder, dilater

8.7.3. Vers la ligne

8.7.3.1. Squelettisation de zones 8.7.3.2. Vectorisation et courbes disovaleurs

8.7.4. Vers le point

8.7.4.1. Centre dun semis de points 8.7.4.2. De la ligne aux points : lutilisation des nuds

8.8. Conclusion

9. Reprsenter ... 315

9.1. Les principes de la reprsentation cartographique 9.1.1. Le langage cartographique 9.1.2. Les variables visuelles
9.1.2.1. La forme 9.1.2.2. La taille 9.1.2.3. La couleur 9.1.2.4. La valeurs 9.1.2.5. Grain, trame, texture 9.1.2.6. Orientation

9.1.3. La reprsentation cartographique

Sommaire IX
9.1.4. Lgendes et habillage 9.2. La cartographique avec SAVANE : cartes et cadres 9.2.1. La carte 9.2.2. Les cadres 9.2.3. Couleurs et palettes 9.3. Lexplorateur cartographique 9.3.1. Principes de lexplorateur cartographique 9.3.2. Limplantation graphique ponctuelle 9.3.3. Limplantation graphique zonale 9.3.4. Limplantation graphique linaire 9.3.5. La reprsentation des images 9.3.6. Masques, fonds graphiques, documents digitaliss 9.3.7. Les procdures de trac 9.3.8. Les lgendes 9.4. La reprsentation en perspective 9.5. Louverture ou la sauvegarde dune carte dans SAVANE

10. Conclusion ....... 343

10.1. La construction du SIG SAVANE : synthse 10.2. Vers plus dintelligibilit pour les bases de donnes gographiques

Bibliographie gnrale ... 351 Annexe : exemples de classes et implmentation en C++ ... 361

A.1. Savateca
A.1.1. Les classes CAttribut et CRelation A.1.2. La classe CBase A.1.3. La classe CDico A.1.4. La classe CFpacc8 A.1.5. La classe CIndexAttribut A.1.6. La classe CIntegrationObjetsLocalises

A.2. Savane
A.2.1. La manipulation de la base de donnes dans un cadre A.2.1.1. Les classes CRelation et CAttribut A.2.1.2. Les classe CSchema A.2.1.3. La classe CLecture A.2.1.4. La classe CMacro A.2.1.5. La classe CCalculateur

X Sommaire
A.2.1.6. La classe CBabel : interpolation A.2.2. Algorithmique graphique A.2.2.1. La classe CArc A.2.2.2. Les classes CCellule et CYX A.2.2.3. la classe CVectoriser A.2.2.4. DilaterImage() A.2.2.5. SegmentIntersection() A.2.2.6. Les classes CZone et CTache A.2.3. Fentre et projections A.2.3.1. La classe CWind A.2.3.2. La classe CProjection A.2.3.3. La classe CMolodensky A.2.4. Documents et cartographie A.2.4.1. La classe CCarte A.2.4.2. Les classes CODD A.2.4.3. Les classes Cgroupe et CSelection A.2.4.4. La classe CCadre A.2.4.5. La classe CCartExplorateur A.2.4.6. Les classes CDessin A.2.4.7. La classe CLegende A.2.4.8. La classe CPaletteSavane A.2.4.9. La classe CPerspective A.2.5. Exemples doprations dans un cadre A.2.5.1. XQuestUnion() A.2.5.2. XQuestJoinGeo() A.2.5.3. XCrisCalcul() A.2.5.4. XTri()

A.3. Savamer
A.3.1. La classe CAmers A.3.2. La classe CSysteme1 A.3.3. La classe CTessel

A.4. Savedit
A.4.1. La classe CArc A.4.2. La classe CSaveditDocument

Sommaire XI Table des illustrations

fig. 2.1 : exemple de prise de points damers avec SAVAMER fig. 2.2 : exemple de constitution de mosaque dimages go-rfrences fig. 2.3 : la saisie sur cran avec le module SAVEDIT fig. 2.4 : lcran principal de SAVANE avec une carte contenant un cadre fig. 2.5 : une image satellite mise en perspective grce un modle numrique de terrain fig. 2.6 : lcran principal dune application de type SavAtlas fig. 4.1 : coordonnes godsiques, et projection dun point sur un ellipsode de rvolution fig. 4.2 : un thodolite et son utilisation en godsie fig. 4.3 : dformation du gode terrestre, lchelle 10000 fig. 5.1 : les diffrents niveaux de description fig. 5.2 : jointure entre zones et points sur la qualification d(O1,O2)=0 fig. 5.3 : jointure entre zones sur la qualification d(O1,O2)=0 fig. 5.4 : hirarchie en feuilles et region quadtree associ fig. 5.5 : dcoupage en k-d tree et arbre binaire associ fig. 5.6 : le dialogue pour la gestion des relations fig. 5.7 : le dialogue de cration dune relation fig. 5.8 : le dialogue de gestion du schma des attributs dune relation fig. 5.9 : le dialogue de cration dun attribut fig. 5.10 : les dialogues de lintgration graphique fig. 5.11 : les diffrents dialogues de lintgration descriptive fig. 5.13 : structure de limage raster associe une relation zonale fig. 5.14 : la cration dun masque partir des points dune relation et dune distance ces points Fig. 5.15 : un masque rsultat de la diffrence de deux masques fig. 5.16 : dialogue de restriction par formule fig. 5.17 : dialogue de restriction sur un attribut nominal fig. 5.18 : une qui-jointure spatiale zone-zone fig. 6.1. : le dialogue de cration dune relation mosaque fig. 6.2. : le dialogue de cration dun attribut dune relation mosaque fig. 6.3 : structure interne des relations mosaques fig. 6.4 : un modle numrique de terrain fig. 6.5 : linterface graphique du module SAVAMER fig. 6.6 : exemple de prise de points damers dans une zone commune deux images fig. 6.7 : le dialogue de redressement de SAVAMER fig. 6.8 : triangulation obtenue partir des points dappui fig. 6.9 : le dialogue dintgration dune image dans une mosaque fig. 6.10 : le choix des pixels intgrer : mthode par polynme fig. 6.11 : exemple de constitution de mosaque dimages gorfrences fig. 7.1 : Simplicit des arcs fig. 7.2 : Extra-simplicit des arcs fig. 7.3 : Fermeture dun ensemble darcs fig. 7.4 : connexit dun ensemble darcs fig. 7.5 : test de simplicit sur un arc fig. 7.6 : test de fermeture dune zone

XII Sommaire
fig. 7.7 : visualisation de la fermeture par remplissage en couleur fig. 8.1 : interrogation sur cran des objets prsents dans le cadre gographique fig. 8.2 : statistiques univaries sur un attribut dune collection dobjets fig. 8.3 : exemple de reprsentation des carts par rapport une distribution donne fig. 8.4 : le dialogue de cration dattribut par calcul numrique ou logique fig. 8.5 : le dialogue de cration dun attribut dune mosaque fig. 8.6 : le calcul dun indice de vgtation (NDVI) partir des canaux 3 et 4 dune image Thematic Mapper fig. 8.7 : le menu de classification de SAVANE fig. 8.8 : dialogue de dfinition des classes par quantiles fig. 8.9 : le choix de lopration dagrgation descriptive fig. 8.10 : dessin et histogramme de la rpartition de lorientation de failles gologiques, calcule partir de la gomtrie des objets fig. 8.11 : exemple de go-agrgation de points dans des zones : calcul de laltitude moyenne par lot partir de points cots (moyenne, d < 100 m) fig. 8.12 : la page finale du dialogue de go-agrgation par distance fig. 8.13 : exemple de go-agrgation de zone zone sans ambiguit : agrgation de la population dlots aux quartiers (somme, d=0) fig. 8.14 : un masque (cultures et paturages) et le pourcentage de la surface dans un dcoupage (cantons) fig. 8.15 : calcul de la moyenne dun indice radiomtrique (TM, canal 1) dans des zones prdfinies (quartiers) par go-agrgation pondre par la surface fig. 8.16 : pente et orientation calcules partir dun modle numrique de terrain fig. 8.17 : Donnes ponctuelles, mailles, et go-agrgation dans les mailles fig. 8.18 : le dialogue du choix de lopration dinterpolation fig. 8.19 : rsultat de linterpolation barycentrique partir de courbes de niveau fig. 8.20 :exemple dinterpolation barycentrique sur tous les points de rfrence (classe par quantiles) fig. 8.21 : vectorisation aprs classification dune mosaque (image TM) fig. 8.22 : cration de zones partir de points : tesslation de Vorono fig. 8.23 : deux dilatations partir des objets initiaux (5 m, 20 m). Lobjectif est ici de diminuer ou de remplir lespace interstitiel en ville fig. 8.24 : cration de zones par dilatation partir de lignes ou de points fig. 8.25 : Courbes de niveau initiales, interpolation, puis cration de courbes de niveau par vectorisation (en rouge, superposes aux courbes initiales en bleu) fig. 8.26 : Cration de points centraux (en bleu) partir dun semis de points (provenant des lots, en rouge) et de lappartenance au quartier (attribut cr par go-appartenance) fig. 8.27 : occurrence des nuds dans un rseau de lignes de bus fig. 9.1 : une carte ralise avec SAVANE fig. 9.2 : la fentre principale de SAVANE est un diteur graphique fig. 9.3 : dialogue de proprits dun cadre gographique fig. 9.4 : dialogues de dfinition dune couleur et de choix dans une palette fig. 9.5 : le dialogue principal de lexplorateur cartographique fig. 9.6 : les trois possibilits de figurs en implantation ponctuelle : symboles, valeurs, diagrammes sectoriels fig. 9.7 : la reprsentation par symbole selon deux caractres fig. 9.8 : la reprsentation par diagramme sectoriel suivant trois attributs descriptifs

Sommaire XIII
fig. 9.9 : les dialogues pour le trac en implantation zonale fig. 9.10 : proprits de dessin pour les relations de type ligne fig. 9.11 : reprsentation dun mnt par valeur ou par illumination fig. 9.12 : diffrents types de lgendes gnres partir de lexplorateur cartographique et des dialogues de proprits de lgende fig. 9.13 : dialogues pour crer une vue en perspective fig. 9.14 : reprsentation en perspective cavalire des valeurs daltitude dun mnt

Introduction

Les systmes d'information gographique (SIG) regroupent diffrentes mthodes et techniques informatiques, permettant de modliser, de saisir sous forme numrique, de stocker, de grer, de consulter, d'analyser, de reprsenter des objets ou des collections d'objets gographiques, avec la particularit essentielle de prendre en compte les caractristiques spatiales de ces objets au mme titre que les attributs descriptifs qui y sont attachs. En fait, la dnomination SIG recouvre une grande varit de ralisations logicielles construites suivant des choix techniques diffrents, aux fonctionnalits et aux performances trs diverses. Les systmes dinformation gographique ont la particularit de faire appel de nombreux domaines scientifiques et techniques et de nombreuses mthodes, allant de la godsie aux systmes de gestion de bases de donnes, en passant par le traitement dimages, lalgorithmique gomtrique, la modlisation et linterpolation gomtrique, la statistique, la cartographie automatique, lanalyse spatiale, etc. Construire un systme dinformation gographique sans sloigner de la rigueur scientifique est une tche complexe, aussi bien en terme de dfinition des concepts, dorganisation fonctionnelle, darchitecture logicielle, dalgorithmique, dergonomie. Cet ouvrage prsente un travail de recherche et de dveloppement informatique visant apporter une rponse concrte la question suivante : comment construire un systme dinformation gographique complet et oprationnel, en suivant les principes thoriques de la gestion de donnes et en les adaptant aux donnes gographiques . Il a pour vocation de dcrire lensemble des connaissances rsultant de cette exprience, ainsi que de prsenter les principes du systme informatique oprationnel qui en rsulte, que lon trouvera dans le CDROM accompagnant ce livre avec des exemples de base de donnes permettant de mettre en uvre les exemples prsents dans louvrage. Lobjet de cet ouvrage est donc de montrer sur un exemple concret limplication des principes thoriques dans la ralisation pratique dun logiciel de type SIG. Il a pour objectif de prsenter de faon complte et dtaille l'architecture et la

Introduction

ralisation dun systme d'information gographique oprationnel le systme SAVANE - partir des nombreux concepts, techniques et algorithmes ncessaires cette ralisation, den expliquer les choix informatiques et les contraintes qui en dcoulent, en fonction des objectifs recherchs. Travail de recherche, de synthse, darchitecture, dalgorithmique, et de dveloppement logiciel, laspect tudi rside plus dans la synthse des principes thoriques, dans la recherche de larchitecture dun ensemble complet et oprationnel - la fois systme de gestion de donnes et programme dapplication - que dans ltude dun thme particulier de cet ensemble. Cet ouvrage reprend la dmarche que nous avons suivie tout au long de ce travail, savoir : - exposer avec prcision tous les aspects concernant la dfinition et lutilisation de linformation gographique ; - exposer et dvelopper les principes de la gestion de donnes (modle relationnel et objet) pour les tendre aux donnes localises ; - dvelopper ou mettre en uvre les algorithmes ncessaires limplantation de ces principes dans un systme dinformation ; - construire un systme oprationnel, mettant en uvre les principes thoriques et rpondant un cahier des charges fonctionnel couvrant lensemble des besoins ncessaires lutilisation de ce systme dans le cadre de projets appliqus, notamment en gographie et dans le cadre de la recherche pour le dveloppement. En effet, et cest une autre caractristique de ce travail, il a t effectu dans un cadre oprationnel et non dans un laboratoire de recherche classique. Le cadre gnral est celui de lIRD (Institut de recherche pour le dveloppement, anciennement ORSTOM), et le cadre oprationnel est celui de projets de recherche ou de dveloppement dans divers pays ou rgions de la zone tropicale. Notre objectif a donc toujours t double : concilier le dveloppement ou lapplication de principes thoriques pour la gestion de donnes gographiques et la construction dun logiciel oprationnel dans le cadre de projets de recherche ou de dveloppement. Le cahier des charges fonctionnel a t fortement influenc par cet impratif, le systme construire devant rpondre plusieurs objectifs parmi lesquels on peut notamment souligner : - la ncessit dune gestion efficace, et donc la construction dun moteur BD relationnel interne tendu aux donnes localises (gestion intgre des attributs descriptifs et de localisation), avec indexation primaire sur la localisation, en plus de procdures de connexion des moteurs BD externes ; - la ncessit dun systme pouvant grer un nombre important dobjets (typiquement de plusieurs millions) sans dgradation de performance, dans un cadre oprationnel ;

Introduction

- la ncessit de conserver la meilleure prcision possible en fonction de la modlisation de la ralit en objets gographiques, ce qui implique un systme double structure interne (vecteur, raster) permettant la gestion intgre de limagerie arienne et satellitale et de la troisime dimension ; - la ncessit dune gestion souple et de fonctionnalits volutives, et donc la mise en uvre de lapproche objet avec la gestion de mthodes, aussi bien au niveau du schma des donnes que du dveloppement et de limplmentation ; - la ncessit dassurer la prennit des bases de donnes, et donc la rflexion sur la documentation de linformation et la gestion des mta-donnes dans une approche orient-objet ; - la ncessit dune fiabilit complte au niveau de la saisie des donnes, et donc la dfinition et la mise en uvre concrte de multiples contraintes dintgrit spatiale lors de la saisie graphique ; - une ergonomie permettant lapproche exploratoire et empirique multiutilisateur, et donc la gestion dtats temporaires par utilisateur sans modification de la base de donnes ; - la ncessit de fonctionnalits intgres permettant lanalyse, et donc la dfinition et la mise en uvre doprations propres aux donnes gographiques : analyse spatiale, statistique, gostatistique ; - des fonctionnalits de dessin et de cartographie automatique permettant daboutir des produits ddition cartographique professionnels. Nous allons dans cet ouvrage reprendre lensemble des travaux effectus, en dcrivant chaque aspect ncessaire la construction du systme et en expliquant les choix effectus. Nous rappellerons les principes de base, nous dvelopperons certains domaines lorsque la thorie actuelle nest pas adapte aux types de donnes traits. L'expos des mthodes sera souvent suivi de la prsentation d'algorithmes et de leur ralisation concrte dans le systme d'information gographique que nous avons dvelopp, de manire construire peu peu un systme oprationnel complet. Des rfrences renverront frquemment le lecteur une annexe contenant limplantation effective des structures et des algorithmes, directement en langage de programmation (C++). Il se divise en plusieurs parties : - premire partie : Introduction. Rappels sur les SIG et prsentation gnrale des diffrents modules du systme SAVANE ; - seconde partie : modlisation, mesure, gestion et SGBD, go-rfrencement et intgration d'images, contraintes d'intgrit spatiale et saisie ; - troisime partie : exploitation des donnes, requtes, analyse spatiale et reprsentation cartographique.

Introduction

La premire partie donne un panorama gnral des SIG, puis prsente le systme SAVANE. Aprs une brve introduction sur les objectifs gnraux des SIG, nous rappellerons rapidement l'histoire du dveloppement des systmes d'information gographiques, ainsi que les fonctionnalits actuellement rencontres dans les systmes du commerce. Le second chapitre prsente de faon gnrale le systme SAVANE : architecture gnrale, fonctionnement et possibilits des diffrents modules. La seconde partie expose les caractristiques des donnes gographiques : modlisation de la ralit, reprsentation informatique, modes d'acquisition, prcision et qualit, description et documentation, mta-donnes. Nous dtaillerons le mode de reprsentation utilis dans le SIG SAVANE pour tous les objets gographiques. Nous prsenterons l'aspect base de donnes dans les SIG, en commenant par rappeler l'ensemble de la thorie des SGBD relationnels et objets. Nous proposons ensuite des extensions du modle de gestion relationnel et objet aux donnes localises, et nous prsenterons limplmentation de ces nouvelles oprations dans SAVANE. Nous prsenterons de nombreux algorithmes gomtriques concernant la saisie et le contrle de la qualit des donnes gomtriques, le redressement dimages, les jointures gomtriques, etc. La troisime partie concerne les mthodes utilisant plus spcialement la localisation des objets dans les SGBD gographiques. Il s'agit de l'analyse spatiale dont nous donnerons de nombreux exemples et algorithmes de rsolution (traitements vectoriels, traitements matriciels, distances et proximit, changements d'implantation spatiales, modles numriques et interpolation, etc.). Nous prsenterons enfin les modules de cartographie automatique de SAVANE. Lannexe regroupe les principales structures et algorithmes du systme. Ils seront donnes, lorsque cela est possible et facilement comprhensible par le lecteur, directement en langage de programmation.

Un systme dinformation gographique rpondant nos objectifs est la fois un systme de gestion de donnes et un programme dapplication, et cest bien ce mlange des genres qui en fait la complexit, au-del du caractre particulier d la dimension gomtrique des donnes grer et traiter. En tant que programme dapplication, le systme construit nest pas complet, certains domaines ntant pas ou peu abord (lanalyse de rseaux et la recherche oprationnelle par exemple). Il na dailleurs pas vocation ltre, mais sa structure volutive devrait lui permettre de continuer se dvelopper, et cest dailleurs un de nos principaux objectifs initiaux : fournir la base logicielle au dveloppement de nouvelles fonctionnalits - aussi bien dans un cadre universitaire que dans un environnement

Introduction

oprationnel - et implmenter ces fonctionnalits en tant que mthodes, soit directement dans le systme, au niveau des classes de bases, soit en tant que classes dobjets drives qui seront la disposition du concepteur de base de donnes. Nous donnerons, en conclusion, quelques lments de rflexion sur ce thme.

Premire partie : introduction et prsentation du systme SAVANE

Chapitre 1

Les systmes dinformation gographique 9

Chapitre 1

Prsentation gnrale des systmes d'information gographique

Depuis plus de vingt ans, le dveloppement de l'informatique a entran des modifications importantes pour la gographie et la cartographie. La production de donnes s'est acclre, grce de nouvelles mthodes de collecte et d'acquisition. Le traitement des donnes localises s'est largement dvelopp, avec la saisie numrique des donnes graphiques, cartes et plans, avec les systmes de gestion de bases de donnes et les capacits de stockage des systmes informatiques. Enfin, de nombreux aspects de la cartographie ont t automatiss et les techniques de production compltement modifies, avec en corollaire une acclration de la diffusion et de l'utilisation de donnes gographiques. Un systme d'information gographique (SIG) est avant tout un systme de gestion de base de donnes capable de grer des donnes localises, et donc capable de les saisir, de les stocker, les extraire (et notamment sur des critres gographiques), de les interroger et analyser, et enfin de les reprsenter et les cartographier. L'objectif affich est essentiellement un objectif de synthse, permettant la fois la gestion des donnes comme l'aide la dcision. Si l'informatique a d'abord permis des progrs dans l'automatisation de la production cartographique, les SIG vont bien au-del d'une simple fonction de stockage et de restitution graphique. Par leurs possibilits de modlisation et de gestion, par leurs fonctions d'analyse et d'interrogation, par les possibilits de mises en relation des objets les uns par rapport aux autres, par leurs capacits stocker et traiter de gros volumes d'information, les SIG ont profondment boulevers les mthodes traditionnelles d'analyse et de gestion de l'espace. Grce aux possibilits

10

Chapitre 1

de modlisation et de calcul, l'informatique et les SIG n'ont pas seulement permis l'amlioration de techniques existantes, ils ont remis en cause bon nombre de concepts classiques de la gographie et renouvel la dynamique de cette discipline. 1.1. L'apport de l'informatique pour la gographie et la cartographie L'informatique intervient depuis plusieurs dizaines d'annes dans beaucoup de domaines et, depuis plus de vingt ans, son dveloppement a entran des modifications importantes pour la gographie et la cartographie. Parmi les secteurs qui nous intressent, on peut citer la gestion de donnes, le stockage numrique, la statistique, de nouvelles formes d'expression et de communication. De plus, de nouveaux moyens d'acquisition de donnes se sont dvelopps : la tldtection spatiale et le positionnement par satellite en sont les principaux exemples. La gographie et la cartographie se sont construites peu peu sur la base de possibilits techniques qui, pendant longtemps, n'ont pas volu. Depuis une vingtaine d'annes, beaucoup de ces fondements sont les uns aprs les autres remis en cause ou modifis par des possibilits techniques indites. Chaque domaine a d'abord t touch, mais indpendamment des autres. Par exemple, les logiciels de dessin ont remplac peu peu des travaux manuels longs et fastidieux, des techniques de structuration et de gestion de donnes et de nouveaux moyens de stockage ont permis de mettre en uvre de nouveaux moyens de traitement et d'analyse, notamment statistiques, des logiciels de prsentation de donnes et d'images permettent d'envisager de nouvelles formes d'expression cartographique. L'originalit des SIG, c'est d'essayer de runir toutes les nouvelles techniques de traitement de donnes localises, tous les nouveaux moyens d'expression dans un seul et unique environnement, dcuplant en cela l'efficacit de chaque domaine et permettant de nouvelles avances conceptuelles, impossible concevoir dans la sparation des techniques : c'est donc aux fondements de la gographie qu'il faut retourner, pour ne pas conserver des limitations conceptuelles lies des impossibilits techniques maintenant dpasses ou en passe de l'tre. Cette remise en cause, cette renaissance conceptuelle ne peut tre mene que dans le cadre des SIG, et c'est bien ce qui fait la force de ce courant, qui ne doit pas tre conu ou interprt uniquement sous l'aspect de l'avance technique qu'il apporte : il doit fournir aux gographes et aux informaticiens l'occasion de rflchir de nouveau sur l'espace gographique, sur la manire de le concevoir, de le traiter, de le reprsenter. Mais le concept de SIG n'a pas t dfini directement, au dbut des annes 60. Il s'est construit peu peu, au fur et mesure de l'introduction de l'informatique dans

Les systmes dinformation gographique 11 l'ensemble des mthodes lies l'analyse et la reprsentation de donnes spatiales. Nous pouvons faire rapidement l'historique de ce champ d'activit. 1.2. Les SIG comme synthse de ces domaines : historique et volution Lhistorique du dveloppement des SIG peut tre divis en trois priodes : les annes 60-70, reprsentant les dbuts et les premires ralisation, les annes 80 pour la consolidation et lapparition des premiers logiciels commerciaux, et les annes 90 pour la diffusion gnrale des outils et de la technologie SIG. 1.2.1. Les dbuts : les annes 60-70 Les applications militaires et l'intrt croissant des gouvernements pour la gestion des ressources sont l'origine du dveloppement des systmes d'information gographique. Prenons par exemple le Canada, qui a dvelopp l'un des premiers systmes dans les annes 1960 : pour la premire fois, un tat avait le sentiment que ses ressources naturelles n'taient pas sans limites, et son gouvernement a peru la ncessit d'intervenir au niveau de la planification et de l'utilisation des ressources. L'chelle utile pour une telle planification varie entre le 1:20000 et le 1:250000 : sur un pays de la taille du Canada, il fallait utiliser entre 200 et 3000 coupures de carte, pour chaque thme d'tude. Manuellement, le travail de lecture et d'analyse de l'information cartographique aurait pris au minimum trois ans et plus de cinq cent techniciens. Dans les annes 60, le concept mme de SIG n'tait pas encore dvelopp et les mthodes de stockage et d'analyse d'un nombre important de cartes taient inexistantes. Les ordinateurs avaient de faibles mmoires et des vitesses de calculs largement dpasses par les plus petits micro-ordinateurs d'aujourd'hui. L'informatique graphique en tait ses dbuts, aussi bien pour le matriel que sur la thorie et les algorithmes [PAL 75]. C'est entre 1960 et 1970 qu'ont t dvelopps les premires tables digitaliser, les scanners, les tables traantes, ainsi que les techniques de base de l'informatique graphique : algorithmique graphique, topologie informatique, traitement d'image et reconnaissance des formes, modlisation bi- ou tri-dimensionnelle. L'interactivit est alors inexistante , et les possibilits de restitution graphique trs limite. Les cots sont importants : par exemple, un cran graphique - alors basse rsolution- cote environ 10000 USD en 1967. La plupart des systmes d'analyse spatiale dvelopps pendant les annes soixante et soixante dix utilisent des structures de donnes trs simples, qui sont bass sur des grilles arbitraires, maillage de l'espace qui ressemble ce qu'un gographe peut faire manuellement sur une petite surface [DAN 81]. C'est

12

Chapitre 1

principalement le cot lev des tables digitaliser qui est l'origine de ce choix, surtout dans les universits, o certains tudiants devaient remplir la main les mailles en fonction de la carte d'origine SYMAP, MIADS, GRID, MLMIS, GEOMAP sont des exemples de systmes de ce type. D'un autre cot, les systmes de dessin automatis se dveloppent, mais sans la notion de base de donnes. C'est ainsi que se dveloppent les premiers systmes d'information urbain la fin des annes 60, et ils s'apparentent plus des systmes de dessins automatiques qu' des systmes de gestion de l'information (DIME, GRDSR) [DIM 70]. Dans les annes qui suivent, la perception de la ncessit d'une gestion gnrale des ressources et des potentialits est de plus en plus rpandue. Elle implique des moyens de traitement de l'information volu, notamment dans le domaine de l'information spatialise. D'autre part, les progrs de la technologie informatique sont importants et rapides ; l'interactivit se dveloppe et les cots des matriels graphiques sont en baisse, mme s'ils restent encore levs. Les systmes de gestion de bases de donnes sont en pleine volution. Le nombre de systmes en dveloppement est important, mais peu d'innovations voient le jour, la plupart des dveloppements se font dans le domaine du dessin automatique ou de la cartographie automatique. Les universits sont dsormais nombreuses s'intresser ce domaine, et des socits commerciales commencent voir le jour alors qu'elles taient inexistantes durant les annes 60 : ESRI, GIMMS, INTERGRAPH, COMPUTERVISION On ne parle pas encore de SIG proprement dit, et le dveloppement est plutt tourn vers les systmes de dessin et de conception assiste par ordinateur, systmes que l'on essaye d'adapter aux besoins de la cartographie. Le dveloppement des matriels graphiques est d'ailleurs essentiellement d au dveloppement de la CAO (conception assiste par ordinateur), en pleine expansion et beaucoup plus porteur l'poque que celui de l'information gographique. Ce type de matriel reste nanmoins trs coteux. Si le dveloppement logiciel est important, le nombre des systmes d'information gographique couvrant de larges territoires reste trs faible. Les systmes sont conus soit pour stocker, soit pour grer, soit pour traiter, mais aucun n'est encore vraiment capable non seulement d'archiver, mais aussi de grer et de traiter un important volume d'informations spatialises. Les techniques volues de gestion de donnes sont d'ailleurs peu dveloppes, et les modles utiliss conviennent mal aux donnes gographiques. Par contre, l'algorithmique graphique, la reconnaissance des formes, le traitement d'image sont des secteurs en plein dveloppement en sciences de l'information. Le dbut des annes 70 va galement voir le dveloppement rapide de la tldtection spatiale et des mthodes de traitement d'image associes. Ces

Les systmes dinformation gographique 13 technologies restent alors spares des SIG, mais elles vont contribuer favoriser l'essor gnral de l'infographie. Il faudra nanmoins attendre les annes 80 pour voir s'esquisser un rapprochement entre la tldtection spatiale et les SIG, par une intgration rciproque d'information de sources multiples. 1.2.2. La consolidation : les annes 80 Les annes 80 sont une priode de dveloppement des mthodes de gestion de donnes. La saisie et la gestion de larges bases de donnes sont maintenant les principaux problmes thoriques et pratiques. Les problmes dus au volume des donnes sont souvent mal perus ou mme ignors par les administrateurs : un systme contenant une dizaine de cartes sera bien diffrent d'un systme contenant 5000 coupures ou plus. Voici quelques chiffres donnant une ide du volume de donnes de SIG potentiels : - les 359 coupures de carte de l'United States Geological Survey (utilisation des sols) contiennent approximativement 68 millions de points, - les cartes topographiques sont beaucoup plus riches : il existe environ 40000 coupures de la carte topographique de l'USGS au 1:25000, ce qui reprsente environ 4000 millions de points. Pour raliser de telles bases de donnes, il faudra dvelopper des mthodes de gestion et d'organisation de donnes de plus en plus efficaces. Le dbut des annes 80 a vu une avance importante dans les techniques de gestion de donnes : les systmes de gestion schma relationnel sont plus performants, ils structurent l'information de faon plus rigoureuse et amliorent la rsolution des problmes d'administration de donnes. Dans ces systmes, les relations spatiales entre entits gographiques sont malheureusement inexistantes, aussi bien sur le plan thorique que sur le plan pratique : la spatialisation n'est pas gre en tant que telle, et les concepts thoriques ne sont pas adapts aux donnes multidimensionnelles, si bien qu'il est impossible de les faire entrer dans le schma des systmes de gestion de bases de donnes relationnelle classique. De nombreux efforts seront donc entrepris pour tendre le modle relationnel aux donnes gographiques, mais il faudra attendre la prochaine dcennie pour voir les ralisations pratiques de ces dveloppements [FRA 81] [DAN 81] Paralllement, l'interactivit graphique se dveloppe. Les stations de travail apparaissent, et sont parfaitement adaptes ce type d'application. Le matriel graphique (traceur, imprimante couleur, table digitaliser, scanner) reste nanmoins encore coteux, et le SIG n'est pas encore une application disponible sur microordinateur et accessible du grand public.

14

Chapitre 1

1.2.3. La diffusion : les annes 90 Les annes 90 vont transformer ce panorama, et permettre une large diffusion de la technologie. Les micro-ordinateurs, de plus en plus puissants, remplacent peu peu les stations de travail. Les accessoires graphiques deviennent galement accessibles au grand public. L'offre commerciale s'toffe, avec des logiciels plus complets et moins chers. On assiste donc une large dmocratisation de l'usage des SIG, avec de nombreux projets qui se dveloppent sans trop de difficults du fait du modeste volume de donnes traites. Mais les mthodes n'voluent pas beaucoup : la plupart des logiciels commerciaux sont l'manation directe de produits conus au dbut des annes 80. Les logiciels commerciaux les plus rpandus sont d'ailleurs parfois trop simples, et cherchent ne pas emmener l'utilisateur non averti sur des chemins trop complexes Mais la baisse des cots des matriels de traitement et de restitution va peu peu mettre le SIG la porte de tous [WOR 95]. 1.2.4. Les volutions actuelles Le dveloppement de l'Internet pousse l'ensemble des produits commerciaux offrir une solution pour l'interrogation du SIG et la conception de cartes via Internet. Mais cette offre met l'accent sur une consultation simple, au dpend de procdures d'analyse plus complexes. La gestion du temps est encore peu effective dans les SIG, mme si le cadre thorique est bien pos. Le problme des multireprsentations spatiale d'un mme objet doit galement faire l'objet de dveloppements, au niveau de l'implmentation des objets comme au niveau des contraintes d'intgrit. La gostatistique se dmocratise peu peu, mme si elle reste encore sous-utilise dans de nombreux domaines dapplication. L'volution vers des SIG 3D est galement sensible, avec des techniques de reprsentation et de visualisation qui suivent les capacits de matriels graphiques en forte volution. L'introduction de mthodes issues de la vision par ordinateur, de la reconstruction 3D, de techniques d'animation devrait fortement pousser ce secteur en pleine volution. 1.3. Les SIG : objectifs gnraux Avant de prsenter les principes et fonctionnalits du systme SAVANE que nous allons dcrire tout au long de cet ouvrage, nous dressons un panorama gnral des principaux objectifs des systmes d'information gographique [TOM 76] [DAN 83] [LAU 93] [SCHO 96] [SOU 86].

Saisie et stockage numrique de plans et de cartes :

Les systmes dinformation gographique 15 Le premier et principal objectif des SIG reste le stockage numrique de donnes gographiques, bi- ou tridimensionnelles. Mais il y a beaucoup de diffrences entre un systme qui va conserver des objets, avec une description aussi bien graphique que descriptive, et un systme qui va seulement conserver un dessin sans contenu smantique.

Structuration de l'information :
Comme tout systme de gestion de bases de donnes, un SIG qui gre une base de donnes demande une modlisation du monde rel et une structuration de l'information. Cette structuration est souvent plus complexe, car elle touche des objets qui peuvent avoir de multiples reprsentations, aussi bien graphiques que descriptives, essentiellement en fonction de l'utilisation qui en sera faite.

Calculs mtriques (distances, surfaces), calculs techniques (visibilit, volumes, recherche oprationnelle), positionnement et projections gographiques :
Les SIG permettent de calculer facilement surfaces, distances et volumes partir des donnes de localisation des objets. Les calculs et les changements de projections gographiques sont facilement accessibles. La recherche oprationnelle (essentiellement calculs de chemins dans des graphes) trouvent dans les SIG toutes les donnes dont elle a besoin.

Gestion et traitement des collections d'objets :

C'est l'un des objectifs principaux des SIG. Une fois l'information structure, elle doit tre saisie et gre par le systme. Souvent, les SIG laissent la gestion des donnes descriptive des SGBD relationnels classiques (comme ACCESS, ORACLE, SQL Server, DBase, etc.), et ne grent eux-mmes que la localisation des objets et les liens entre graphique et description. Comme tout systme de gestion de base de donnes, le SIG doit assurer la bonne gestion des flux d'informations, des modifications, des mises jour, et notamment pour la partie graphique des objets.

Gestion administrative et partage de donnes entre utilisateurs :

Lorsque les donnes sont partages entre plusieurs utilisateurs, comme c'est souvent le cas pour les applications administratives de type cadastre, le SIG a pour objectif de grer ce partage et d'optimiser l'accs des donnes entre utilisateurs.

Gestion et analyse spatiale :

Les SIG ont vocation grer tout type d'objet gographique, du point au pixel, en passant par les zones, les rseaux, etc. L'objectif atteindre est la constitution d'une base de donnes go-rfrences, permettant la mise en relation des diffrents objets de la base, quels que soient les types de ces objets. Cette mise en relation doit

16

Chapitre 1

permettre l'analyse spatiale, c'est--dire la prise en compte de la localisation dans l'analyse des donnes. De nombreuses procdures faisant appel la localisation des objets sont donc implantes dans les SIG (slections d'objets sur des critres de distances, recherche oprationnelle, agrgations spatiales et changements d'chelle, go-jointures, interpolations, vectorisations, classifications par proximit, etc.).

Gestion spatio-temporelle :
Lintroduction du temps dans les SIG permet deffectuer des interrogations mlant espace et temps, de manire pouvoir grer la fois lhistorique dun objet et ltat dun ensemble dobjet une date donne. Les SIG ont donc galement vocation grer les volutions des objets gographiques. Mais les ralisations concrtes sont peu rpandues, car la gestion de lhistorique des modifications de la localisation dun grand ensemble dobjets est complexe, aussi bien du point de vue informatique que de celui de la gestion des flux dinformations.

Statistique et gostatistique :
La constitution d'une base de donnes gographiques a souvent pour objectif l'tude d'un territoire dans toutes ses composantes, et le SIG doit alors permettre l'accs facile au calcul statistique, qu'il soit exploratoire ou mthodologique. Certains SIG comportent un module statistique, d'autres grent l'interface avec un logiciel spcialis. L'utilisation de mthodes de la gostatistique doit galement tre l'un des objectifs du SIG, puisqu'en grant la localisation, il facilite considrablement l'utilisation de ces mthodes d'analyse ou d'interpolation spatiale.

Simulation et modlisation :
L'objectif d'un SIG peut galement tre l'utilisation d'un modle pour la simulation d'un processus. Le SIG doit alors faciliter l'interface entre le programme de modlisation ou de simulation et la base de donnes gographiques, et doit prendre en charge l'ensemble de l'accs l'information spatiale dont a besoin le programme d'application.

Tldtection, go-rfrencement et traitement d'image :

Les SIG ont vocation grer tout type d'objet gographique. La tldtection arienne ou spatiale offre une source privilgie de donnes gographiques. Les SIG doivent donc galement grer et traiter de type de donnes, souvent volumineuses. Ils doivent en assurer le bon go-rfrencement, permettre l'accs aux traitements propres ce type de donnes, et permettre leur mise en relation avec l'ensemble des autres donnes localises gres par le systme.

Dessin et dition cartographique, cartographie automatique, 3D :

Les systmes dinformation gographique 17 Comme tout systme de gestion de donnes, les SIG ont pour objectif l'dition des donnes rsultats d'une requte. Cette dition est souvent graphique puisque l'on traite de donnes localises. Les modules de cartographie automatique partir des donnes gres par le systme sont donc fondamentaux pour l'utilisateur. De plus en plus, les systmes intgrent la troisime dimension, et permettent l'dition de donnes en perspective. Mais la saisie et la maintenance de la troisime dimension est plus complexe.

Internet et accessibilit distante :

L'Internet offre depuis plusieurs annes de nouvelles perspectives d'accs distant aux donnes. Les SIG doivent donc permettrent cet accs, en grant la complexit de structure de l'information localise, de manire fournir aux utilisateurs des mthodes simples de consultation et de cartographie via Internet. 1.4. Conclusion Commenc il y a maintenant plus de 30 ans, lintroduction de linformatique dans le champ de la gographie a profondment renouvel la dynamique de cette discipline. Ce renouvellement nest pas d au seul dveloppement des SIG : les nouveaux moyens de mesure ou dobservation de la Terre y participent aussi largement. La dnomination SIG recouvre une grande varit de ralisations logicielles construites suivant des choix techniques diffrents, aux fonctionnalits et aux performances trs diverses. Le lien entre dveloppement de nouvelles technologies et mergence de nouveaux paradigmes de recherche est indniable. Et inversement, le questionnement mthodologique se nourrit en permanence de lapplication thmatique des mthodes et des outils quelle conoit. Toutes ces technologies vont dans le mme sens : celui dune prise en compte toujours plus importante de la localisation dans la gestion ou lanalyse des phnomnes, des prcisions qui permettent de dvelopper de nouveaux objectifs de recherche et damliorer considrablement les rsultats obtenus dans les tudes qui en dcoulent.

18

Chapitre 1

Les systmes dinformation gographique 19

Bibliographie

[DAN 81] DANGERMOND J., Some trends in the evolution of GIS technology, Marble Ed., 1981, Kensington Workshop, p. 25-57 [DAN 83] DANGERMOND J., Classification des lments logiciels utiliss habituellement dans les systme dinformation gographique, fascicule n 96 du comit franais de cartographie, 1983, p. 7-20 [DIM 70] DIME, Technical description of the DIME System, U.S. Bureau of Census : Census and study, the DIME Geocoding System, Report n 4, Washington D.C., 1970, p. 25-30 [FRA 81] FRANCK A., Application of DBMS to Land information systems, CH 1701-2, IEEE 81, 1981, p. 448-453 [GUP 95] GUPTILL S.C., MORRISON J.L., Pergamon/Elsevier Science, 1995 Elements of Spatial Data Quality,

[LAU 93] LAURINI R., MILLERET-RAFFORT F., Les bases de donnes en gomatique, Paris, Ed. Herms, 1993 [PAL 75] PALMER J.A.S., Computer Science aspects of the mapping problem, from Davis and Mc Cullagh, Display and analysis of spatial Data, New York, John Wiley and Sons, 1975 [SCH 96] SCHOLL M., VOISARD A., Thomson Publishing France, 1996
ET

TOUS, SGBD Gographiques, Spcificits, Paris,

[SOU 86] SOURIS M., Systmes dinformation gographique et bases de donnes, Colloques et Sminaires sur le Traitement des donnes localises, Paris, Editions de lORSTOM, 1986, p. 29-87 [TOM 76] TOMLINSON, CALKINS AND MARBLE, Essential part of a geographic information system, Computer Handling of geographic Data, UNESCO Press, Paris, 1976 [WOR 95] WORBOYS M. F., GIS, a Computer Perspective, Taylor and Francis, 1995

Chapitre 2

Prsentation du systme SAVANE

Cette prsentation du systme SAVANE a pour objectif de dcrire rapidement les principes gnraux de sa conception et de situer ce logiciel dans lensemble des systmes dinformation gographique. Il prsente les concepts gnraux du systme et ses spcifications fonctionnelles. 2.1. Le systme SAVANE : principes gnraux Le systme SAVANE prsent dans cet ouvrage est dabord un systme de gestion de base de donnes relationnelle tendu aux donnes localises, avec des fonctionnalits de type objet. Son objet est de grouper, grer, traiter, cartographier des donnes gographiques de diverses origines et diffrents types, comme des donnes d'enqutes, des cartes thmatiques, des donnes topographiques, des rseaux, des images satellites, des photographies ariennes, des modles numriques de terrain, etc. Le systme SAVANE possde les principales fonctionnalits des SIG : multiples sont les possibilits de croisement, de mise en relation, de regroupement, d'agrgation de donnes gographiques d'origines diverses. Il n'y a pas dans SAVANE de sparation entre la localisation et la description, entre le dessin et l'information : chaque objet est conserv avec tous ses attributs, qu'ils soient graphiques ou descriptifs : c'est le systme qui gre l'ensemble. Le systme SAVANE possde son propre systme de gestion de base de donnes, de type relationnel tendu aux donnes localises dans l'espace. la fois systme de gestion de bases de donnes relationnelles, systme d'analyse et d'aide la recherche en gographie, systme de cartographie et de dessin automatique, SAVANE va de la constitution d'une base de donnes l'dition

22

Chapitre 2

: il offre ainsi la matrise de toute la chane cartographique de la conception de l'information au produit cartographique. Bien sr, la constitution et l'exploitation d'une importante base de donnes localises n'est pas chose simple et fait appel de nombreux concepts, de la structuration et gestion de base de donnes l'laboration cartographique, en passant par la statistique, la godsie, le traitement d'image. Nous prsentons dans ce chapitre une description rapide des principes et des fonctionnalits du systme, sans rentrer dans la description de la structure interne ou des algorithmes de rsolution, que nous prsenterons tout au cours de cet ouvrage. Le systme comprend cinq modules principaux (saisie graphique, gorfrencement d'images, administration des bases de donnes, exploitation des bases de donnes et cartographie, prsentation datlas). Les bases de donnes gographiques sont gres par un moteur de gestion de donnes bi-dimensionnel, avec indexation primaire base sur la localisation. Nous prsenterons dans les chapitres qui suivent l'architecture dtaille du systme, la structure des bases de donnes, les mthodes de gestion et d'exploitation, ainsi que les principales fonctions, modules et algorithmes correspondants. Le logiciel est crit en Visual C++ et fonctionne avec tout systme d'exploitation Win32. 2.1.1. Les concepts gnraux de SAVANE Le sujet principal de notre travail, cest de montrer comment construire un systme rpondant aux objectifs gnraux des SIG tels que nous les avons prsents dans lintroduction de cet ouvrage, savoir principalement : une gestion efficace dobjets localiss, une gestion volutive, une ergonomie permettant lapproche exploratoire, des fonctionnalits permettant lanalyse spatiale, et des fonctionnalits de dessin et de cartographie automatique. De nombreux choix peuvent tre effectus pour construire un logiciel de type SIG, aussi bien pour larchitecture gnrale du systme, pour les structures de donnes, pour les algorithmes de rsolution, les mthodes dindexation, de gestion, etc. Nous allons ici expliciter globalement ces choix, avant dy revenir en dtail au cours des chapitres qui suivent. A lorigine de la construction du SIG, il y a deux objectifs majeurs : grer des objets gographiques, en assurant la prennisation et le partage de linformation, et avoir la possibilit de mettre ces objets en relation les uns avec les autres en utilisant leur localisation. Mettre en relation, comme pouvait le faire simplement le gographe lorsquil superposait deux cartes thmatiques, pour vrifier ou mettre en vidence des corrlations spatiales. Lide initiale est donc simple : grer des objets tels quils apparaissent sur des cartes, par thmes indpendamment les uns des autres, et utiliser cette localisation, considre comme universelle entre tous les

Prsentation du systme SAVANE 23 objets localiss, pour les relier les uns aux autres. Bien sr, il faudra faire attention conserver cette universalit lors de la mesure de la localisation : datum et projections cartographiques seront largement discuts au chapitre 4. Pour viter tout problme li au rfrentiel, nous avons choisi dans notre systme de conserver les coordonnes indpendamment de la projection cartographique, et dimposer un mme datum pour lensemble des objets dune base de donnes. Cest la solution la plus simple au niveau du systme de gestion, mais elle requiert davoir les capacits de transformer toute coordonne pour la ramener dans ce rfrentiel : il nous faudra donc dvelopper changements de projection et changements de datum. Grer des objets suivant des collections thmatiques, et pouvoir les mettre en relation grce un attribut, tout cela rappelle la gestion relationnelle pour les bases de donnes classiques. Les objets y sont grs par collections dobjets de mme type, et ils sont mis en relation sur un attribut commun par une qualification de jointure sur cet attribut. Le modle relationnel permet dassurer au mieux cohrence et intgrit dune base de donnes, en laissant des oprations de restriction ou de jointure le soin de rpondre une requte. Lide de base de la construction du systme que nous prsentons, cest dtendre le mode de gestion relationnel aux objets localiss, avec la possibilit dune jointure sur lattribut donnant la localisation des objets pour les mettre en relation, entre objets de collections diffrentes. Dans une premire tape, il faut analyser le problme de la reprsentation des objets gographiques dans une base de donnes, dans loptique de les grer en collections dlments dcrits par les mmes attributs. Car une carte reprsente effectivement un ensemble dobjet, linverse de la description dun paysage ou dun quartier, qui, en gnral, ne reprsente quun seul objet et na pas pour objectif une tude comparative avec dautres objets du mme type. Lide de la collection est donc omniprsente dans notre approche : si lon cherche regrouper les objets en collections dcrits par les mmes attributs, cest pour pouvoir bien les grer, les comparer entre eux, les comparer aux objets dautres collections. La localisation dans lespace doit tre un lment fondamental de cette comparaison. Partir du modle relationnel pour la gestion de base de donnes permet dutiliser un modle qui donne satisfaction dans la gestion dobjets dcrits par des attributs simples (nominaux ou numriques de dimension 1). Mais la prise en compte de lattribut de localisation savre plus complexe, car des questions indites se posent pour des attributs de dimension suprieure 1 : comment dcrire et reprsenter des sous-ensembles de dimension un ou deux ? Comment conserver la structure mtrique de lespace ? Est-il possible dutiliser les systmes existants, ou faut-il construire un nouveau moteur de gestion de donnes ? Faut-il stocker des cartes, ou revenir sur la schmatisation et la modlisation qui a dj t effectue par le gographe ou le cartographe ?

24

Chapitre 2

Dans la conception du systme que nous proposons, le point de dpart de linformation reste la carte ou la mesure directe de terrain, comme dailleurs dans la grande majorit des SIG. Mais la carte nintervient que comme support dun ensemble dobjets correspondant une mme entit du monde rel, non plus cartographique mais gographique, dpouille de toute reprsentation smiologique. La modlisation ne retient que la schmatisation gomtrique utilise pour rendre compte des phnomnes dans lespace, avec, pour forte contrainte, lunicit dun phnomne dans lespace et le temps : dans une collection, on ne peut avoir deux objets au mme endroit et au mme moment (si lon prend en compte le temps). Le respect de cette contrainte est fondamental pour assurer la validit conceptuelle de la modlisation de la ralit. A partir de ce choix (une reprsentation gomtrique des objets base sur une description cartographique), plusieurs possibilits existent pour conserver la description de cette reprsentation gomtrique dans un systme informatique. Il est ncessaire de dfinir des types diffrents suivant le type de localisation, ponctuelle ou ensembliste, de dimension 1 ou de dimension 2. Dj, on pressent quun systme de gestion de base de donnes classique ne peut convenir pour stocker efficacement cette description, pour peu que lon veuille lutiliser dans sa structure despace mtrique. Rien nempche dutiliser des tables classiques pour stocker des points (x,y), mais un systme classique sera incapable de reconstituer un contour, deffectuer des tests dappartenance, ou une interrogation sur la distance entre les objets : lincapacit des SGBD classiques grer lattribut de localisation dans sa structure est vidente. On peut alors sparer graphique et descriptif, utilisant un systme particulier pour grer lattribut de localisation, et un systme classique pour grer lensemble des attributs descriptifs, en tablissant un lien entre les deux systmes par une cl de jointure pour reconstituer les objets. Cette solution ne nous satisfait pas, pour deux raisons essentielles : il est alors impossible dindexer les objets sur leur localisation, alors que ce critre est de loin le plus discriminant, et la gestion spare de deux ensembles dattributs, correspondant un mme objet, est source dincohrence dans les bases de donnes et de perte de performance ds que le nombre dobjet devient grand. Lorsque les objets sont localiss, lattribut de localisation devient en effet le plus efficace en terme dindexation : nous souhaitons mettre en uvre une indexation de type squentiel index base sur la localisation, ce qui impose aux valeurs descriptives dtre stockes dans lordre des objets si lon veut bnficier des performances de lindexation sans avoir maintenir des index denses. Ceci ne peut se faire que dans un systme grant la fois le descriptif et le graphique. Lautre objectif principal du systme que nous proposons de construire, cest de prenniser linformation, de faon centralise, et den permettre la consultation et lexploitation dcentralise, avec une dmarche exploratoire. En effet, si linterrogation dun SGBD classique utilise habituellement un langage de requte permettant dexprimer en une phrase la demande faite la base de donnes, le processus dinterrogation de donnes gographiques et la dmarche du gographe

Prsentation du systme SAVANE 25 relve bien souvent dune approche exploratoire, sans la dfinition formelle du cheminement des oprations permettant de rpondre une question qui peut ellemme varier en fonction du cheminement. Il est essentiel de conserver cet aspect interactif dans le processus de requte, ce qui implique concrtement la cration temporaire lors de linterrogation de nouveaux attributs ou relations. Le systme doit donc maintenir des tats temporaires, par utilisateur : il ne pouvait tre question de permettre la modification de la base de donnes par un utilisateur sous peine de remettre en question lobjectif fondamental de prennisation et de centralisation de linformation. Pour toutes ces raisons, nous avons choisi de construire un systme possdant son propre moteur BD, permettant lindexation primaire sur la localisation, permettant le stockage et la gestion de la gomtrie reprsentant la localisation des objets, regroups en relations, en fonction dune modlisation de lespace respectant le principe dunicit de cl pour la localisation. Cette modlisation doit prendre en compte les diffrents types dimplantation spatiale : zone, ligne, points, pixels. Nous avons galement choisi de sparer ladministration de lexploitation : le module dinterrogation doit permettre lapproche exploratoire et la gestion dtats temporaires lors dune requte, mais il ne peut pas modifier la base de donnes, droit rserv au module dadministration. Nous avons galement choisi de sparer lexploitation de la saisie graphique et de la vrification des contraintes dintgrit. Pour le choix des structures internes de reprsentation de la localisation, nous privilgions systmatiquement la simplicit des structures sur la simplicit des algorithmes de traitement : ainsi, nous choisirons de conserver des arcs frontires, quitte avoir reconstituer le contour des zones, plutt que de conserver un contour ferm imposant un sens dans le stockage des arcs. Des structures plus simples pour la reprsentation de la localisation permettent de rduire les contraintes dintgrit sur cet attribut. A partir de la modlisation en collections thmatiques, lextension du modle relationnel aux donnes localises devient naturelle. Les oprations de lalgbre relationnelle (restriction, projection, jointure) sont tendues la localisation en utilisant des critres de distance ou dappartenance, la place dune relation dordre ou dgalit. Malheureusement, on saperoit rapidement que cet attribut de localisation, que nous avions qualifi duniversel, ne lest pas vraiment. Il varie considrablement, aussi bien dans sa conception, dans la manire de le reprsenter, que dans la prcision de sa mesure. La jointure spatiale, extension de la jointure classique et opration formelle correspondant la mise en relation par superposition, ne tient pas compte de la validit ou de lchelle de description. Dans de nombreux cas, elle savre donc inutilisable en ltat : il va falloir grer des transferts dchelle pour mettre effectivement en relation des objets de validit ou dimplantation spatiale diffrente. La conception de notre systme est-elle encore valide, si son principal objectif, savoir mettre les objets localiss en relation grce

26

Chapitre 2

leur localisation, ne peut tre atteint efficacement ? Grer ensemble des collections dobjets en conservant lambigut sur la validit de lattribut de localisation est-il possible ? Pour rpondre positivement cette question, il est ncessaire dintroduire de nouvelles mthodes de gestion et dexploitation, au-del dune jointure dont lobjectif initial retrouver les valeurs dun point de lespace partir de collections distinctes doit tre analys en fonction de la modlisation du monde rel. La premire rponse, cest lintroduction de procdures permettant de grer les transferts dchelle, la fois par des procdures dagrgation, par des procdures de changement de type dimplantation spatiale, par des procdures dinterpolation, par des procdures dextrapolation. Lautre rponse, complmentaire, consiste documenter les bases de donnes par lintroduction systmatique de mta-donnes permettant lutilisateur de revenir la gense de linformation et dviter les cueils dune utilisation errone. Elle consiste galement introduire dans le schma de la base de donnes des mthodes dutilisation de ces donnes, de manire proposer lutilisateur un ensemble de mthodes dexploitation qui dpendent non seulement du type des objets, mais galement de leur contenu smantique et de leur prcision gographique. Enfin, lergonomie du logiciel est importante : elle doit permettre la fois lapproche exploratoire et la reprsentation cartographique des rsultats, chaque tape de la requte. Ces deux objectifs sous-tendent la conception de lergonomie du module dexploitation. 2.1.2. Architecture gnrale de SAVANE Le systme SAVANE se caractrise donc par une stricte application de la logique et des concepts des base de donnes, notamment relationnelles et objets, aux objets gographiques localiss. Il y a d'abord le concept d'objet, qui est l'entit de base gre par le systme : une zone dans une carte, un individu dans un recensement, un tronon de rseau, etc. Chaque objet est dcrit par un certain nombre d'attributs, comme un nom, des coordonnes, des valeurs numriques. Le systme gre des objets et les valeurs des attributs qui les dcrivent. On regroupe les objets qui sont dcrits par les mmes attributs dans des collections, que l'on appelle relations ou tables : le schma d'une relation, c'est l'ensemble des attributs servant dcrire les objets de la relation, ainsi quun ensemble de mthodes pouvant tre appliques ces objets. L'ensemble des schmas des relations donne le schma de la base de donnes, qui est constitue quant elle des objets de toutes les relations. Le systme stocke et gre les objets en s'appuyant sur cette structure de relation collections d'objets du mme type - et traite les objets grce leur description par attributs - variables dont les valeurs dcrivent l'objet : le systme SAVANE est construit sur le principe des systmes de gestion de donnes relationnels [SOU 87].

Prsentation du systme SAVANE 27 Lorsqu'un objet est gographique, il est souvent localis, c'est--dire que l'on tient compte de sa position dans l'espace en deux ou trois dimensions, et cette position sert aussi dcrire l'objet. On parlera d'attribut de localisation comme on a parl d'attribut de description. Le schma d'une relation dont les objets sont localiss - on dira une relation localise - comporte donc toujours un attribut de localisation : c'est la gestion de cet attribut qui fait la diffrence entre un SIG (systme d'information gographique) et un simple SGBD (systme de gestion de base de donnes). Le systme SAVANE tend la gestion relationnelle lattribut de localisation : il utilise la localisation pour mettre les objets dune collection en relation avec les objets dune autre collection. La localisation d'objets gographiques peut tre zonale (l'objet est une zone; une collection de zones donne une relation zonale, ou de type zone), linaire (l'objet est une portion de ligne, et la relation correspondante est dite linaire), ponctuelle (la localisation est donne par un point, la relation est dite ponctuelle), ou encore donne sous forme d'image numrique go-rfrence (les objets sont alors les pixels qui forment l'image). La localisation peut tre donne sous forme vectorielle (des contours, des arcs) ou sous forme matricielle (des pixels) : de toutes les faons, le systme SAVANE cre partir des vecteurs une reprsentation matricielle lorsqu'il en a besoin, lors de l'exploitation des donnes. Il peut galement crer des vecteurs partir de pixels dune image. Ces diffrents types de localisation correspondent des types de base pour les objets : zone, ligne, point, pixel. A chaque type correspondent des mthodes particulires (par exemple, la surface pour les zones), mthodes accessibles directement dans les menus de SAVANE. Ce modle de donnes reprend donc la schmatisation cartographique de la ralit gographique. La saisie et le stockage de la localisation des objets gographiques impliquent des procdures tout fait spcifiques ces objets, et l'administration d'une base de donnes gographiques ncessite aussi quelques connaissances en cartographie (les projections, le redressement, les chelles, la prcision gographique, la gnralisation, etc.). La structuration des donnes dans SAVANE correspond au modle relationnel des systmes de gestion de base de donnes tendu aux donnes gographiques localises. Il s'oriente galement vers le modle objet par l'introduction de classes d'objets et de mthodes sur ces classes. L'architecture gnrale est celle d'un calculateur base de donnes simplifi : il possde un dictionnaire des donnes, indiquant les relations, attributs, mthodes, ainsi que leurs caractristiques (types, dfinition du schma interne associ), un dictionnaire des accs permettant de grer les niveaux externes (par l'allocation de droits et la dfinition de l'accs aux donnes), un langage de commande permettant d'interroger et de manipuler les

28

Chapitre 2

donnes suivant une structure client/serveur. Chaque opration utilise ces trois structures pour accder au niveau interne et au systme de gestion de fichier. Le systme SAVANE cre et administre ses propres bases de donnes, intgrant dans un mme ensemble l'information descriptive et l'information de localisation, contrairement la plupart des SIG qui utilisent un SGBD classique pour les donnes descriptives et crent le lien entre descriptif et graphique au moment de l'exploitation des donnes. L'information de localisation est conserve dans sa forme originale, vectorielle ou pixel selon la modlisation d'origine. Le systme se charge de l'ensemble des oprations de changement de type (vecteur-raster ou rastervecteur notamment) en fonction des besoins de l'utilisateur : il privilgie toujours l'aspect fonctionnel l'aspect technique. Tous les points sont dcrits par leurs coordonnes gographiques dans un datum unique. La projection gographique de restitution peut tre choisie par l'utilisateur lors de l'interrogation des donnes. Les relations localises sont indexes sur la localisation par la notion naturelle de feuille, chaque feuille correspondant une coupure de carte. Toute recherche dans une relation localise passe par la recherche des feuilles concernes par le territoire d'tude. Chaque relation localise possde son propre ensemble de feuilles, puisque cette indexation dpend essentiellement de la densit des objets propre une relation donne. Cette indexation sapparente donc un dcoupage en grille adaptative. Lexploitation des bases de donnes est multi-utilisateur. Linterrogation se fait sous forme de requtes, dans une dmarche exploratoire. Le systme gre les requtes de chaque utilisateur en crant des tats temporaires, propres lutilisateur, sans modifier la base de donnes. Lextension du modle relationnel sur la localisation permet de joindre les objets de la base sur la localisation, lors dune requte, partir dune gestion en relation. Mais la gestion seule est insuffisante pour rpondre aux besoins danalyse qui sont omniprsents lors de lexploitation de donnes gographiques. Le systme comprend donc de nombreuses fonctionnalits danalyse. De plus, les diffrences de prcision dans la localisation, dues aux diffrences dchelle de description des objets, rduisent le caractre universel de la localisation en tant quattribut de jointure. Nous avons donc dvelopp dans le systme SAVANE de nombreuses procdures pour rpondre aux besoins de jointures spatiales lorsque la simple mise en relation sur la localisation ne peut tre utilise. Lextension du modle relationnel se fait donc plusieurs niveaux : dune part par lextension des oprations classiques de lalgbre relationnelle lattribut de localisation, et dautre part par lintroduction de fonctionnalits permettant de rsoudre les problmes de transfert dchelle.

Prsentation du systme SAVANE 29 2.1.3. Administrer une base SAVANE Le schma d'une base comprend la dfinition des relations, des attributs, et des mthodes. Contrairement aux SGBD classiques, chaque relation a ici un type, qui dfinit le type des objets contenus dans la relation, et permet dassocier des mthodes de base uniquement lies au type dimplantation gographique (comme le primtre ou la surface pour les zones, ou la longueur pour les lignes, etc.). La structuration et la gestion interne sont galement propres chaque type dobjet. Les types supports par SAVANE correspondent aux objets habituellement rencontrs en gographie : zone, ligne, point, pixel, non localis. Tous les objets d'une mme relation sont donc du mme type. La localisation des objets gographiques est conserve dans le repre d'un datum commun, en coordonnes sphriques et hauteur au-dessus du gode. Le schma d'une base est conserv dans un dictionnaire de donnes ; tous les modules du systme accdent ce dictionnaire pour lire le schma et utiliser une base de donnes. Les bases de donnes sont cres et administres par le module dadministration, qui est spar des modules dexploitation. Ce module gre galement les vues externes, qui permettent aux modules d'exploitation d'avoir une vision diffrente de la base, par le choix ou le regroupement logique de relations, d'attributs et de mthodes. Il gre galement les mta-donnes, pour les relations, attributs et mthodes. L'administration d'une base de donnes est un travail en soi ds que la base atteint des dimensions importantes. Pour grer une base de donnes gographiques avec le systme SAVANE, et comme pour toute base de donnes, il faut rflchir la structuration des donnes, leur organisation, leur gestion, la manipulation des donnes, ainsi qu' la formation des utilisateurs : c'est l'administrateur de la base de donnes qui en aura la charge, poste fondamental pour le bon fonctionnement du systme. En revanche, un utilisateur du systme d'information n'a pas se proccuper de l'administration de la base de donnes, ni de celle de la machine sur laquelle il travaille. Il se consacrera uniquement l'exploitation des donnes, en supposant la base fiable, mise jour, prte l'emploi. D'une manire gnrale, l'administration d'une base SAVANE, de sa cration son exploitation, peut se rsumer en plusieurs grandes tapes : dcrire, saisir, intgrer, modifier :

Dcrire ...
Pour crer une base de donnes il faut, avant tout, dcrire cette base, dcrire les donnes, indiquer comment se regroupent les objets, quels sont les attributs, leurs types, etc. C'est la premire tape, celle de la rflexion, de la structuration, de la schmatisation, de la description, pour crer ce que l'on appelle le schma de la base de donnes.

30

Chapitre 2

Une fois cr le schma de la base, l'administrateur pourra dfinir des utilisateurs et leur allouera des droits d'utilisation.

Saisir ...
Une fois dfini le schma d'une collection d'objet, nous savons quels sont les attributs qui dcrivent chaque objet. Il faut donc saisir, pour chaque objet, la valeur de ces attributs. Si les objets sont localiss, et que l'on a dcid dans le schma de prendre en compte cette localisation, il faut galement saisir la partie graphique des objets, en fonction du type de la relation. Cette tape, dans le cas de grandes bases de donnes, est contraignante, longue et lourde, et il convient de la grer avec le plus grand soin car elle est bien sur trs importante.

Intgrer ...
La saisie des donnes se fait, disons, par morceaux. Les donnes peuvent tre htrognes : diffrences de formats, de codages... S'il s'agit de gographie et de localisation, les problmes sont plus nombreux. Entre la saisie et la base de donnes, il y a donc une phase d'intgration des morceaux dans l'ensemble homogne que constitue une base de donnes SAVANE. Intgrer, c'est donc lire des donnes (graphiques ou descriptives) dans des fichiers pour les rcrire dans un ensemble la base de donnes proprement dite - qui se constitue peu peu. Il est important de noter que cette phase d'intgration lit des donnes pour crer ou modifier une base de donnes qui sera indpendante de ces fichiers (qui ne serviront plus dans SAVANE aprs l'intgration). Les fichiers contiennent soit des donnes descriptives (des valeurs qualitatives, des valeurs quantitatives, des dates, etc.), soit des donnes graphiques provenant de la saisie graphique ou d'images.

Modifier...
Une fois la base constitue, il faut pouvoir la modifier pour corriger d'ventuelles erreurs ou intgrer les volutions et modifications dans linformation. Ces modifications se font grce des diteurs propres SAVANE, pour la partie graphique comme pour les donnes descriptives. Ces diffrentes oprations ne s'effectuent pas une fois pour toute. Il est courant de crer une base petit petit, de modifier le schma pour rajouter des relations, des attributs, etc. Il est important, pour l'administrateur de la base, de bien connatre toutes les phases indiques plus haut, dans l'ordre comme chaque opration spare.

Prsentation du systme SAVANE 31 2.2. Prsentation fonctionnelle des diffrents modules Le systme est compos de plusieurs modules, sparant les trois oprations fondamentales que sont l'administration et la gestion, la saisie, l'exploitation. 2.2.1. SAVATECA : administration des bases de donnes Le module SAVATECA regroupe lensemble des oprations de gestion et dadministration des bases de donnes, indpendamment de leur exploitation. Il gre la configuration du systme global (emplacement des bases de donnes, emplacement des utilisateurs), les dictionnaires des bases de donnes, les vues externes. Son utilisation est en principe rserv ladministrateur de la base de donnes : un mot de passe permet den restreindre laccs.

2.2.1.1. Principes gnraux dadministration Nous dcrirons plus tard lorganisation prcise des donnes graphiques et descriptives dune base de donnes gre par SAVANE. Nous pouvons ds prsent indiquer lorganisation gnrale du systme : - Bases de donnes : tous les fichiers internes dune mme base de donnes SAVANE (donnes, mthodes, accs, dictionnaire) sont regroups dans un seul rpertoire, lexception des relations de type mosaque dont lemplacement peut tre distinct (pour pouvoir les partager entre plusieurs bases de donnes). Le rpertoire de la base peut se trouver nimporte o sur le rseau local. Le systme SAVANE permet de grer plusieurs bases de donnes. Le schma dune base de donnes est dcrit dans un fichier spcial (le fichier base), les vues externes (description daccs aux relations, aux attributs et aux mthodes) sont dcrites dans le fichier nomm fpacc. - Utilisateurs : pour exploiter une base de donnes SAVANE, il faut tre un utilisateur dclar du systme SAVANE. Lors de lexploitation, de nombreux fichiers temporaires sont crs : ils seront stocks dans un rpertoire propre lutilisateur. De mme, ce rpertoire de lutilisateur permet de stocker les cartes et mthodes cres par cet utilisateur. Le rpertoire de lutilisateur peut se trouver nimporte o sur le rseau.

32

Chapitre 2

- Excutables : les excutables peuvent tre installs nimporte o sur le rseau local. Lors de la premire utilisation de SAVATECA, un rpertoire admin est cr. Ce rpertoire contient les fichiers de configuration du systme. Toute utilisation de lun des modules dexploitation que nous dcrirons plus loin (SAVEDIT, SAVAMER, SAVANE) ncessite les trois paramtres suivants : nom de la base, nom de lutilisateur, vue externe. 2.2.1.2. Configuration du systme Le systme conserve dans le rpertoire admin les fichiers contenant les informations relatives la configuration gnrale : - Le fichier fpconf conserve le nom des bases de donnes dclares, avec lemplacement physique du rpertoire contenant les fichiers de la base de donnes. - Le fichier fpuser conserve le nom des utilisateurs avec lemplacement du rpertoire propre chaque utilisateur. 2.2.1.3. Organisation dune base de donnes SAVANE : principe gnraux Les objets sont regroups en collections, ou relations, suivant le principe des bases de donnes relationnelles. Chaque individu d'une collection est dcrit par un certain nombre de critres, ou attributs. Bien sr, ces critres sont les mmes pour tous les objets d'une mme relation. Il existe dans Savane cinq types de relation, suivant la dfinition gographique des objets : zones, lignes, points, pixels, non localiss. Un objet est dcrit par des attributs descriptifs, plus un attribut graphique dans le cas de relations localises. On rencontre de nombreux types d'attributs descriptifs, parmi lesquels les plus courant sont : Nominal ou qualitatif : ceux qui prennent des valeurs nominales (une chane de caractres). Certains attributs nominaux jouent un rle particulier : une cl est un attribut dont chaque valeur correspond un seul objet (par exemple le numro d'immatriculation est une cl de la relation voiture; le nom du propritaire n'est pas une cl, car un mme propritaire peut avoir deux voitures). Ordinal : ceux qui prennent des valeurs nominales que l'on veut pouvoir ordonner, Entier : ceux qui prennent des valeurs numriques entires, Rel : ceux qui prennent des valeurs numriques quelconques (comme un prix). Couleur 8 bits, 16 bits, RVB : la valeur de l'attribut correspond au codage d'une couleur. Avec 8 bits, on peut coder 256 couleurs, avec 16 bits 64000. Une couleur RVB comprend un niveau de rouge, un niveau de vert, un niveau de bleu, chaque niveau tant cod sur 8 bits (256 valeurs possibles pour chaque niveau, soit 16 millions de couleurs possibles).

Prsentation du systme SAVANE 33 Date : ceux qui prennent la valeur dune date, Son : la valeur de l'attribut correspond la description d'un son, image : la valeur de l'attribut correspond une image ou une collection dimages (album de photographies, documents scanns,), vido : la valeur de lattribut correspond une squence vido, graphe : la valeur de l'attribut correspond la description d'un graphe en deux dimensions. Chaque objet d'une relation localise est donc dcrit par un ensemble de valeurs d'attributs descriptifs ainsi que par la valeur de l'attribut de localisation. L'attribut de localisation napparat pas dans la liste des attributs d'une relation, il est sous-jacent la dfinition mme de la relation et est gr directement par le systme. En fait, on dfinit implicitement l'attribut de localisation lors de la cration de la relation, en indiquant le type des objets (zone, ligne, point, pixel, non localis). Dfinir des types d'objets en fonction de leur type de localisation revient en fait se rapprocher du modle objet : nous avons cinq grandes classes d'objets, les zones, les lignes, les points, les pixels, les objets non localiss, et chaque classe correspond diffrentes fonctions de description, de stockage, d'intgration, d'exploitation. Le systme SAVANE propose galement quelques types drivs des types de base : ces types proposent dj la dfinition d'un certain nombre d'attributs descriptifs. A chaque relation sont associs des fichiers qui contiennent les valeurs des objets. La description de la localisation est diffrente suivant le type de la relation. Pour les relations de type zone, la localisation des objets est donne par les arcs constituant la frontire de chaque objet : un fichier conserve la description de tous les arcs de la relation, un autre fichier conserve les valeurs des attributs descriptifs, et un troisime fichier donne lindexation primaire suivant la localisation. Pour les objets de type ligne, la structure est presque identique, mais la localisation ne fait pas rfrence la notion de frontire, et la localisation dun objet est dcrite par des arcs qui nappartiennent qu un seul objet. Pour les objets de type points, la localisation est donne directement par les coordonnes, et est conserv dans le fichier des valeurs descriptives : ce type de relation ne comprend donc que deux fichiers, lun pour la localisation et les donnes descriptives, lautre pour lindexation gographique. Nous reviendrons en dtail sur lorganisation interne dune base SAVANE dans le chapitre 3. Le module SAVATECA permet de grer lensemble de lorganisation dune base, que ce soit pour la description des relations, pour la gestion des fichiers associs chaque relation, pour la gestion des objets de chaque relation, pour la

34

Chapitre 2

gestion des vues externes, ou pour la gestion des utilisateurs et lutilisation en rseau. 2.2.1.4. Cration dune base de donnes Le module SAVATECA permet de crer une base de donnes SAVANE. Lors de la cration, lutilisateur doit indiquer le nom de la base, son emplacement sur le rseau, lespace gographique concern. Cette dclaration va crer lensemble de la structure ncessaire une base de donnes : un rpertoire lemplacement indiqu, et dans ce rpertoire, le dictionnaire de la base (fichier base), le fichier des vues externes (fichier fpacc). La description de la fentre gographique de la base (espace gographique concern par cette base) est stocke dans le dictionnaire de la base.

2.2.1.5. Gestion du schma Le schma dune base de donnes contient la description des relations, des attributs, et des mthodes. Cette description est conserve dans le fichier base : cest le dictionnaire de la base. Pour chaque relation, ce dictionnaire comprend : - le nom de la relation - le type de la relation (zone, ligne, point, image, non localis) - le nombre dattributs descriptifs - le nom des fichiers associs (objets et valeurs descriptives, objets graphiques associs) - la description des attributs

Prsentation du systme SAVANE 35

Pour chaque attribut, la description comprend : - le nom de lattribut - le type de lattribut (nominal, ordinal, entier, numrique, date, RVB, etc.) - le nombre de valeurs nominales (dans le cas dun attribut nominal) - ladresse de la premire valeur nominale dans le fichier des valeurs dattributs (dans le cas dun attribut nominal). La lecture du dictionnaire permet au systme de charger le schma des donnes et lensemble des paramtres permettant daccder aux objets (donnes graphiques et descriptives). La classe CDico permet dencapsuler lensemble des oprations de lecture et dcriture du dictionnaire de la base de donnes (A.1.3.). 2.2.1.6. Gestion des vues externes Une vue externe permet de donner lutilisateur une autre vision de la base de donnes. Il est possible dexclure un certain nombre de relations, dattributs ou de mthodes, de modifier lordre des relations ou des attributs, et de prsenter relations, attributs et mthodes en groupes. La vue externe est donc un ensemble dindirection entre le schma interne de la base et le schma externe prsent lutilisateur. Les vues externes sont conserves dans le fichier nomm fpacc, qui se trouve dans le rpertoire de la base de donnes. Le programme SAVATECA permet de grer les vues externes : cration, modification (ajout ou suppression de relations, dattributs ou de mthodes, ordre, regroupement), suppression. Une classe CFpaccV8 encapsule lensemble des manipulations de ce fichier (A.1.4.). 2.2.1.7. Intgration dobjets La constitution dune base de donnes se fait par intgrations successives dobjets dans la base. Pour les objets localiss, lintgration se divise en deux phases distinctes : la premire phase consiste crer les objets en intgrant lattribut de localisation (saisi ou import dans le module SAVEDIT) et un identifiant pour

36

Chapitre 2

chaque objet. La seconde phase permet dintgrer les valeurs descriptives des objets en utilisant lidentifiant comme attribut de jointure. Ces valeurs descriptives peuvent provenir dun fichier classique ou dune base de donnes relationnelle classique. Les valeurs des attributs des objets sont alors lues dans ces fichiers et recopis dans la base Savane. Pour les relations localises, chaque phase de cration cre un groupe dobjets dont ladresse et la position gographique en deux dimensions sont conserves par le systme et quil utilise lors de lexploitation de la base comme indexation primaire, dans une structure squentielle indexe en deux dimensions. Une fois des objets intgrs dans la relation, il est bien sr possible de modifier le schma de la relation en ajoutant ou supprimant des attributs. Il est galement possible de modifier les valeurs des objets. Ces oprations modifient le contenu de la base de donnes. Les attributs sont grs diffremment suivant leur type. Par exemple, les valeurs des attributs nominaux sont codes et les modalits sont conserves dans un fichier (fpvaleurs) spar des fichiers conservant les valeurs des objets. Nous verrons en dtail dans le chapitre 5 lorganisation du stockage des objets et les principes de leur indexation dans une base de donnes Savane. 2.2.1.8. Gestion des utilisateurs Le systme SAVANE est conu pour tre multi-utilisateur et pouvoir tre utilis dans un rseau local dordinateur. Comme de nombreux fichiers temporaires sont crs lors de lutilisation du systme, chaque utilisateur doit avoir un espace de travail distinct pour stocker ses propres fichiers temporaires. Le module SAVATECA permet donc dadministrer ces utilisateurs (cration, modification, suppression). La description des utilisateurs (nom, rpertoire de stockage) est conserve dans le fichier fpuser, qui se trouve dans le rpertoire spcial admin. Le rpertoire de stockage dun utilisateur peut se trouver nimporte o sur le rseau local. 2.2.2. SAVAMER : go-rfrencement dimages et constitution de mosaques Le systme comporte deux modules de saisie graphique, lun pour les images, lautre pour les donnes vectorielles. Le module SAVAMER permet de gorfrencer des images raster et de les intgrer dans une relation de type image. Pour tre intgrs dans une relation de la base de donnes, les pixels dune images doivent tous tre go-rfrencs : la position de chaque pixel doit tre

Prsentation du systme SAVANE 37 connue. Bien souvent, limage que lon souhaite intgrer dans une base nest pas en conformit gographique avec la ralit, et il faut la redresser, cest--dire modifier la position dun certain nombre de ses pixels pour les remettre leur position gographique correcte. Limage dorigine doit donc tre dforme. Les objets dune relation de type image sont des pixels dfinis sans ambigut, pour leur position comme pour leur taille. Pour affecter une valeur un objet pixel de la relation partir dune image, il faut donc savoir quels sont les pixels de limage qui participent la dfinition de la valeur de lobjet pixel de la relation. Lopration de go-rfrencement consiste donc en une opration de redressement (repositionnement des pixels dans lespace) et une opration de r-chantillonage (modification de la taille des pixels de limage). A partir dune image non go-rfrence, le module SAVAMER cre donc une nouvelle image, par redressement et r-chantillonage. Les paramtres de cette nouvelle image sont alors compatibles avec les paramtres de la relation qui doit recevoir les valeurs (projection gographique, taille de pixel). Une fois cette opration effectue, le module SAVAMER permet dintgrer les valeurs de limage un attribut de la relation. 2.2.2.1. Le go-rfrencement Le go-rfrencement a pour objet la mise en conformit gographique de limage. Lopration a donc pour objet de placer chaque pixel de limage dorigine sa position gographique exacte. Comme il nest pas possible dindiquer manuellement la position exacte de chaque pixel de limage, on utilise des fonctions de dformation globales ou semi-locales. Le choix de la fonction de dformation dpend de la dformation suppose de limage. Certains paramtres de dformation sont intrinsques au type de capteur, comme la position et le type de capteur dun satellite ou lobjectif dun appareil de prise de vues ariennes. Les autres paramtres doivent tre calculs partir de points dappui entre image et position dans le plan de projection, et par lutilisation dun modle numrique pour la prise en compte de la dformation due aux diffrences daltitude. Le module SAVAMER permet la saisie de points dappui (fig. 2.1) et le redressement, en donnant le choix de la fonction de redressement : similitude, projection centrale, fonction polynomiale de degr 1 ou 3, tessellation, etc. Plusieurs fonctions de redressement peuvent tre combines : il est courant deffectuer une transformation globale (de type projective ou de degr1) suivie de transformations locales (par exemple, redressement de degr 1 dans les triangles issues dune tessellation partir de points dappui).

38

Chapitre 2

fig. 2.1 : exemple de prise de points damers avec SAVAMER

2.2.2.2. Le r-chantillonage Les pixels dune relation sont dfinis sans ambigut, taille et position. La taille de ce pixel peut tre diffrente de celle -suppose- des pixels de limage dorigine. Pour savoir quelle valeur affecter un pixel de la relation partir des pixels dune image, il faut calculer, par go-rfrencement, quels pixels de limage dorigine participent par leur position la dfinition de la valeur du pixel de la relation, puis, par une opration de r-chantillonage, il faut affecter une nouvelle valeur partir de ces pixels. Plusieurs mthodes peuvent tre employes pour effectuer cette opration. La plus simple consiste prendre la valeur du pixel de limage dorigine le plus proche (plus proche voisin), mais il est galement courant de faire une moyenne sur les pixels voisins, par un calcul bilinaire ou bicubique. Ces trois oprations de rchantillonage sont implants dans le module de redressement de SAVAMER. 2.2.2.3. Le mosaquage et lintgration Lopration de mosaquage permet dintgrer une image go-rfrence un attribut dune relation de type pixel. Le systme SAVANE gre ces attributs de manire permettre des ensembles de pixels plus complexes que des images rectangulaires. Lopration dintgration consiste donc, partir dune image gorfrence, crer des objets pixels dans une relation (si ces objets nexistent pas dj), et affecter les valeurs des pixels de limage un attribut dans cette relation. On constitue ainsi une mosaque (fig. 2.2) dont la gestion est entirement la

Prsentation du systme SAVANE 39 charge du systme, et dont la structure externe est identique celle des autres types de relation.

fig. 2.2 : exemple de constitution de mosaque dimages go-rfrences

Nous verrons en dtail dans le chapitre 6 lorganisation du stockage des objets pixels, les principes de leur gestion dans une base de donnes Savane, ainsi que les algorithmes utiliss pour le redressement et le r-chantillonage. 2.2.3. SAVEDIT : saisie vectorielle sur cran avec gestion des contraintes dintgrit Le module SAVEDIT permet la saisie et la correction de lattribut de localisation pour les objets dont la localisation est donne sous forme de zone, de ligne, ou de point, partir de plans ou de cartes. Il permet galement limportation de documents provenant dautres logiciels (format ShapeFile ou DXF). La saisie est dite vectorielle car le rsultat est stock sous forme discrte densembles de points, permettant de schmatiser les contours des zones ou les arcs des lignes. 2.2.3.1. Principes gnraux La saisie se fait sur cran avec une souris. Le support de la digitalisation peut tre une carte ou un plan, go-rfrenc (grce au module SAVAMER) et visualis sur lcran. Lutilisateur peut galement visualiser lensemble des objets dj intgrs dans une base de donnes. De nombreuses options permettent de choisir lespace gographique affich lcran.

40

Chapitre 2

Contrairement aux logiciels de saisie graphique (de type AUTOCAD) qui permettent la saisie, dans un mme document, dobjets de diffrents types (des zones, les lignes, du texte, des symboles, etc.), un document SAVEDIT ne doit contenir que les objets dune mme collection, destins tre intgrs dans une mme relation. La saisie se limite, pour chaque objet, la description de la localisation, et la saisie dune valeur propre chaque objet (un identifiant, ou cl) qui sera utilis par la suite comme cl de jointure pour lintgration des valeurs descriptives de lobjet. Aucun attribut de dessin (couleur, type de trait, symbole, etc.) nest indiqu lors de la saisie (fig. 2.3). Ces attributs de dessin seront affects par la suite chaque objet en fonction de leurs attributs descriptifs, dans le processus dinterrogation et dexploitation de la base de donnes effectus grce au module SAVANE.

fig. 2.3 : la saisie sur cran avec le module SAVEDIT

Puisque la saisie suit la schmatisation du rel en collections, cette saisie doit satisfaire de nombreux contrles de cohrence lies cette description. Par exemple, les zones doivent tre fermes ; les zones dune mme relation ne doivent pas avoir dintersection ; les arcs ne doivent pas se croiser ; etc. Nous verrons en dtail dans le chapitre 6 les contraintes dintgrit qui psent sur lattribut de localisation, et les algorithmes employs dans le module SAVEDIT pour vrifier ces contraintes et produire des document exempts derreurs. Le module SAVEDIT prsente galement de nombreuses fonctionnalits propres amliorer les performances de lopration de saisie graphique. Par exemple : gestion de la prcision et de la connexit entre arcs ; jointure automatique darcs ; division automatique darcs en cours de saisie sur lintersection ; vrification

Prsentation du systme SAVANE 41 permanente de la fermeture des zones ; suppression automatique darcs en double ; etc. Nous prsenterons en dtail dans le chapitre 7 (contraintes dintgrit spatiale) la mise en uvre et les algorithmes utiliss par SAVEDIT. Chaque point saisi sur lcran est transform en coordonnes gographiques (longitude, colatitude) selon le datum et la projection gographique utiliss. Tous les points sont donc conservs en coordonnes sphriques. Le datum dun document peut tre modifi : dans ce cas, lutilisateur a le choix de transformer ou non les coordonnes des points saisis. Ceci peut tre ncessaire car tous les objets dune base de donnes SAVANE doivent tre exprims dans le mme datum. 2.2.4. SAVANE : exploitation des bases de donnes et cartographie Le module dexploitation SAVANE est le principal module du systme. Il intgre un ensemble tendu de fonctionnalits pour linterrogation, le traitement et la reprsentation des informations contenues dans une base de donnes gographiques. Lutilisation de SAVANE ne rclame pas lapprentissage dun langage de commande spcifique. Linterface rassemble dans un environnement ergonomique une grande varit doutils de consultation, de cartographie, de recherches multicritres, danalyse statistique, de superpositions, go-jointures, lissages, danalyses ditinraires et de voisinage, de modlisation. Le logiciel est un outil polyvalent et intgr qui permet dapprhender rapidement toutes les facettes du travail dexploitation dun SIG. 2.2.4.1. Cartes, cadres et requtes Le document de base du logiciel SAVANE est une carte, cest--dire une feuille de papier destine contenir une reprsentation graphique de donnes gographiques. A lentre dans SAVANE aprs avoir indiqu le nom de la base, lutilisateur et la vue externe - apparat donc une feuille de papier sur lcran. Cette feuille contient par dfaut un cadre gographique (fig. 2.4). Un cadre gographique correspond au rsultat dune requte sur la base de donnes : SAVANE utilise le principe de la requte pour linterrogation dune base de donnes. Il faut enchaner les oprations, le rsultat de lune pouvant servir dentre la suivante. Une interrogation, une requte, est donc compose dun ensemble doprations que lon dclenche grce au menu principal, et que lon peut conserver sous forme de macro-commande. Un cadre peut donc tre vu comme une fentre sur la base de donnes contenant, un moment donn, un tat temporaire de la base correspondant une interrogation et aux oprations effectues (calculs, cration de nouvelles variables, croisement et jointure dobjets, etc.). Ltat temporaire de la base li au cadre est conserv avec la

42

Chapitre 2

carte qui contient le cadre, ainsi que la macro-commande correspondant toutes les oprations effectues dans ce cadre. En plus de la requte et de ltat temporaire de la base, au cadre sont attachs des paramtres qui lui sont propres (espace visualis, projection gographique, chelle de trac, visualisation des amorces gographiques ou de projection, type de dessin pour le bord, position dans la carte).

fig. 2.4 : lcran principal de SAVANE avec une carte contenant un cadre

Une carte peut contenir simultanment jusqu dix cadres diffrents. Elle doit en contenir un au minimum. Un cadre doit tre slectionn dans la carte pour avoir accs aux menus des commandes dinterrogation de la base de donnes. Le cadre correspond un espace gographique, dlimit par le bord du cadre. La requte lie au cadre utilise par dfaut cet espace gographique pour slectionner les objets de la base, mais lutilisateur peut spcifier une fentre gographique diffrente pour la requte, ou modifier lespace de visualisation du cadre sans modifier la fentre gographique de la requte. Dans un cas, la fentre de la requte correspond une opration de slection des objets de la base de donnes, dans lautre cas, lespace de visualisation du cadre correspond un espace de dessin dans la carte, une chelle donne par lutilisateur. Un certain nombre de classes correspondent ces objets : la classe CCarte (A.2.4.1.) pour encapsuler lensemble des variables et des oprations correspondant la carte dessine sur lcran, la classe CCadre (A.2.4.4.) pour les cadres gographiques, les classes CWind (A.2.3.1.) et CProjection (A.2.3.2.) pour dcrire la fentre gographique de travail et la projection gographique utilise dans un cadre, et la classe CSchema (A.2.1.2.) pour dcrire ltat de la base de donne correspondant la requte effectue dans un cadre.

Prsentation du systme SAVANE 43 Nous allons ici dcrire rapidement les classes CCarte et CCadre. Les autres classes essentielles seront dcrites en dtail dans les chapitres 4 (CProjection et CWind) et 5 (CSchema, CRelation, CAttribut). 2.2.4.2.1. La classe CCarte Comme nous lavons dj dit plus haut, le document de base du logiciel SAVANE est une carte : une feuille de papier destine contenir une reprsentation graphique de donnes gographique. Il nexiste quun seul objet de type CCarte par session de travail dans SAVANE (on ne peut avoir plusieurs cartes ouvertes en mme temps, il faut fermer une carte pour en ouvrir une autre). La classe CCarte encapsule toutes les informations et oprations propre une carte (A.2.4.1.). Les seuls membres lis la base de donnes sont les pointeurs des objets de type
CCadre (CCadre* m_pCadre[NB_MAX_CADRES]). Tous les autres membres et

mthodes de cette classe sont lies la reprsentation graphique de la carte, sur lcran ou sur limprimante. Outre des cadres, une carte peut contenir des objets graphiques provenant du dessin direct effectu lcran. Ces objets sont grs par la classe CODD (A.2.4.2.). Les ODD reprsentent des classes propres chaque type dobjet graphique (texte, ligne, polyligne, polygone, rectangle, rectangle dgrad, cercle, ellipse, symbole, chelle graphique, bitmap). Par exemple, la classe CODD_Symbole encapsule toutes les informations ncessaires la manipulation des objets graphiques de type symbole (A.2.4.2.). Les objets graphiques sont conservs dans la carte par le tableau des pointeurs des objets de type CODD correspondants. Toutes les coordonnes des objets sont conserves en mm/100 dans le repre de la carte (origine : point bas-gauche de la feuille, unit mm/100). Plusieurs procdures permettent de passer des coordonnes carte aux autres repres prsents dans le systme : vue (cran ou imprimante), cadres, coordonnes gographiques, projection gographique, coordonnes dans la base de donnes (A.2.4.). 2.2.4.2.2. La classe CCadre La classe CCadre (A.2.4.4.) est essentielle : elle encapsule toutes les donnes et mthodes lies une interrogation de la base de donnes et la reprsentation graphique du rsultat obtenu. La classe regroupe toutes les donnes et mthodes permettant de dcrire, stocker et dessiner le rsultat dune requte. La description et le stockage de ltat de la base de donnes utilise les classes CSchema (description de ltat de la base de donnes, voir chapitre 3), CWind et CProjection (description de lespace dtude et de la projection gographique utilise dans le cadre, voir chapitre 4), CMacro (gestion des oprations relationnelles effectues dans le cadre, A.2.1.4.). La description des paramtres de reprsentation graphique

44

Chapitre 2

du rsultat de la requte du cadre est conserve dans un objet de la classe CCartExplorateur (A.2.4.5.), que nous prsenterons au chapitre 9. 2.2.4.2. Principales oprations de manipulation de donnes Les principales oprations concernent linterrogation relationnelle des donnes gographiques dans un cadre. Toutes ces oprations sont accessibles par les menus et les dialogues : - restriction, par formule, par valeur, ou sur un espace gographique, - suppression de relations ou dattributs, correspondant lopration relationnelle de projection, - jointures (classique, semi-jointure, jointures gomtriques, semi-jointures gomtriques), - agrgations, - regroupement thmatique dobjets dune mme relation, - go-jointures suivies dagrgations. Outre les oprations relationnelles utilisant la localisation comme cl de jointure, des oprations sont spcifiques la localisation des objets : - calculs mtriques (longueurs, primtres, surfaces), - cration de zones tampons, - calculs de distance entre objets, - calculs de proximit ou faisant intervenir les voisins (comme par exemple les calculs de texture dans une relation de type pixel), Plusieurs oprations permettent de changer de type dobjet gographique, comme par exemple : - procdures dinterpolation, permettant de passer dun type ligne ou point un type pixel, - procdures de rasterisation, permettant de passer dun type zone un type pixel, - procdures de vectorisation, permettant de passer dun type image un type zone ou ligne. De nombreuses autres oprations sont disponibles. Elles concernent essentiellement la cration de nouveaux attributs partir des attributs dune relation, et lexploration statistique des attributs. Par exemple, on peut crer de nouveaux attributs dans une relation :

Prsentation du systme SAVANE 45 - par calcul numrique ou logique entre les autres attributs de la relation. Il suffit dindiquer la formule, qui peut contenir des oprateurs logiques (and, or, xor, not) comme des oprateurs numriques. - par agrgation statistique (moyenne, somme, cart-type, etc.) dun attribut numrique par rapport un attribut nominal, - par combinaison, comparaison, tri, etc., - par classification, pour crer un attribut nominal partir dun attribut numrique (classifications par intervalles, par quantiles, par progression, par moyennes embotes, etc.). Nous prsenterons toutes ces oprations partir du chapitre 5, aprs avoir dcrit en dtail la structure et lorganisation des bases de donnes SAVANE. 2.2.4.3. Masques et distances La cration de zones tampon, ou masques, permet de grer agrablement les oprations de semi-jointures gomtriques. Un masque est dfini comme une zone gographique sans attribut dont lobjectif est lutilisation ultrieure dans des oprations de slection sur la localisation (appartenance ou non dun objet au masque, lors dune opration impliquant lobjet). Les masques peuvent tre crs directement en dessinant sur lcran, ou par rapport aux objets dune relation (avec une distance permettant de crer un tampon autour de ces objets). Le systme SAVANE permet de combiner des masques entre eux grce une algbre de masques : intersection, union, union exclusive, diffrence, inversion. Il permet galement les oprations morphologiques drosion et de dilatation. Les masques sont conservs par le systme la fois sous forme vectorielle et sous forme matricielle. La forme matricielle est recalcule chaque changement despace gographique de travail. 2.2.4.4. Macro-commandes et mthodes Toutes les oprations ralises pendant une session de travail dans un cadre sont conserves dans une structure de macro-commande, lie au cadre. Cette macro-commande peut tre excute de nouveau pour actualiser ltat de la base de donnes li au cadre, et donc li la requte associe. Une macro-commande peut galement tre cre directement par lutilisateur, en enregistrant une partie dune requte. Cette macro-commande peut ensuite tre excute de nouveau, et tre intgre dans la structure de la base comme une mthode sur les relations de la base. La base de donnes initiale peut donc senrichir peu peu de mthodes dutilisation des donnes. Une mthode est soit lie une relation, si les procdures utilises ne font appels quaux seuls attributs de cette

46

Chapitre 2

relation, soit lie directement la base, si elle fait appel aux attributs de plusieurs relations. Le schma des donnes, initialement relationnel (mis part les types dobjets lies la localisation), se rapproche donc du modle objet, en encapsulant donnes et mthodes dans une mme structure. On bnficie ainsi la fois de la gestion de la localisation (SIG) et de la gestion objet (BDOO) dans un mme systme. 2.2.4.5. Edition cartographique et impression Puisque le systme gre et manipule des donnes localises, il faut pouvoir reprsenter le rsultat dune requte, exactement comme lon peut choisir les attributs graphiques dune liste de valeurs (police, taille des caractres, largeur des colonnes, etc.) pour les imprimer sous forme de tableau. Pour des donnes bidimensionnelles, le processus est plus complexe puisque le rsultat dune requte peut tre lui-mme bi-dimensionnel, et le processus de reprsentation sapparente alors une cartographie. Le systme comporte donc naturellement un certain nombre de possibilits de reprsentation visant associer valeurs (nominales ou numriques) ou types dobjet des attributs graphiques : couleur, trame, symbole, type de trait, paisseur, etc. Evidemment, les possibilits sont diffrentes en fonction du type dobjet gographique : par exemple, on peut reprsenter une zone par son contour, ou remplir lintrieur de la zone par une couleur et une trame, mais on ne peut reprsenter un point que par un symbole.

Prsentation du systme SAVANE 47 Cette association ne se fait quau moment de reprsenter sur une carte le rsultat dune requte dans un cadre. Pour cela, lutilisateur dispose dun explorateur cartographique qui lui permet de choisir les relations dessiner dans le cadre, ainsi que tous les paramtres permettant dassocier les valeurs dun attribut une reprsentation graphique. Les lgendes sont un moyen dafficher ces paramtres : le systme permet galement de dessiner les lgendes sous des formes classiques en cartographie (caissons, symboles superposs ou contigus, etc.). Bien sr, la requte peut tre vide : lutilisateur dessine alors les objets en fonction de leurs attributs dorigine. Cest la dmarche habituelle lorsque lon utilise le SIG uniquement des fins dexploration des objets. Lexplorateur cartographique permet galement de dessiner des masques (en indiquant couleur et trame), des images gorfrences, ainsi que des fonds graphiques. Les fonds graphiques sont des fichiers contenant exclusivement du dessin, sans la notion dobjet ou dattribut descriptif. Les fichiers au format DXF sont un exemple de ce type de document. Le systme SAVANE permet lutilisateur dafficher ce type de dessin dans un cadre, condition bien sr que les coordonnes soient compatibles : le repre doit tre connu. Le dessin na pas forcment besoin dtre dans la mme projection gographique que le cadre, le systme se charge de la transformation de projection si un fichier dcrivant la projection du document a t cr. Le systme permet galement la reprsentation en trois dimensions si les donnes sy prtent (fig. 2.5). Dans ce cas, limage calcule en perspective peut tre colle dans la carte, ou sauvegarde comme un fichier image part.

fig. 2.5 : une image satellite mise en perspective grce un modle numrique de terrain

48

Chapitre 2

2.2.4.6. Utilisateurs et partage des bases de donnes Chaque utilisateur doit avoir un espace de travail rserv car de nombreux traitements crent des fichiers temporaires qui ne doivent pas tre mlangs entre diffrents utilisateurs. De mme, les cartes et tous les objets graphiques quelles contiennent sont stocks dans un rpertoire de lutilisateur qui les a produites. Cet espace de travail est cr lors de la cration de lutilisateur avec le module SAVATECA. Les bases de donnes peuvent tre partages par tous les utilisateurs du systme. Chaque module actualise le schma de la base ds quune modification a t effectue par ladministrateur avec le module SAVATECA. Les tats temporaires des bases de donnes sont stockes dans les cartes correspondantes, et se trouvent donc dans le rpertoire de lutilisateur. 2.2.4.7. Vecteur et raster Cest une question qui tait pose pendant de nombreuses annes aux concepteurs de systmes dinformation gographique : vecteur ou raster ? La question concernait le mode de stockage de linformation de localisation (par arc ou par pixel) et, donc, implicitement, le mode de rsolution et la prcision de certaines procdures impliquant la localisation, notamment pour les mises en relation spatiale. Dans le systme SAVANE, le stockage des donnes gographiques est rsolument vecteur, pour tout ce qui est point, ligne, ou zone. Le type pixel sapparente un stockage raster, mais la rsolution (la taille du pixel) est variable et est directement lie la prcision de la donne : il ny a pas de dgradation de linformation due au stockage. Par contre, le systme cre une matrice raster pour la rsolution rapide de certaines oprations impliquant des relations zonales ou des masques, lorsque la prcision de cette matrice est suffisante pour lopration en question, ainsi que pour amliorer les temps daffichage sur cran. Cette opration de rasterisation est transparente pour lutilisateur. 2.2.5. SavATLAS : prsentation datlas et de donnes Ce petit module permet de prsenter une srie de cartes et de notices associes, sous forme dun atlas lectronique. Plusieurs chemins de lecture peuvent tre associs la srie de cartes (fig. 2.6). Lutilisateur peut consulter les donnes correspondantes aux objets reprsents dans une carte en cliquant directement sur lcran. Les valeurs sont alors recherches dans la base de donnes.

Prsentation du systme SAVANE 49

fig. 2.6 : lcran principal dune application de type SavAtlas

2.2.6. SavLIBRARY : librairie de dveloppement C++ Cette librairie de classes C++ permet lintgration de fonctions de consultation ou dinterrogation dune base de donnes SAVANE dans un programme C++. Elle sinspire des objets de type DAO (DataBase Access Object) de la MFC (Microsoft Fundation Class). Elle comprend notamment les classes suivantes : - CSavaneDatabase : pour ouvrir une base de donnes Savane, - CSavaneRelation : pour dcrire et utiliser une relation de la base de donnes ouverte, - CSavaneAttribut : pour dcrire et utiliser un attribut dune relation de la base de donnes ouverte, - CSavaneWind : pour dcrire et utiliser lespace gographique dinterrogation, et pour grer les projections gographiques, - CSavaneLecture, CSavaneRecordset, CSavaneArc, etc. 2.2.7. SavSERVEUR : serveur de requtes via Internet Cette application permet dimplmenter une architecture client/serveur en recevant les requtes de type SAVANE et en renvoyant sur le client le rsultat obtenu. Linterrogation se fait via une liaison TCP/IP, et peut donc tre effectue via Internet.

50

Chapitre 2

2.3. La constitution et lexploitation dune base de donnes avec SAVANE 2.3.1. La constitution d'une base de donnes gographiques 2.3.1.1 Mthodes de mise en place, d'administration, et d'exploitation Comme pour tout systme dinformation, la mise en place dun SIG important est une opration dlicate qui demande une approche rigoureuse et lvaluation prcise des besoins et des moyens disponibles. Lanalyse gnrale dcrite ci-dessous doit aboutir la dcision de faisabilit et au calendrier de mise en place. Elle se compose de trois tapes principales : - la rdaction dun cahier des charges dcrivant les objectifs et les besoins de lapplication, lvaluation des donnes ncessaires au fonctionnement ainsi que les flux dacquisition ; - lvaluation des spcifications du systme et de ses objectifs, en fonction du cahier des charges, puis ltude des systmes existants sur le march ; cette tape doit dboucher sur une valuation de la faisabilit de lopration et des cots quelle implique (matriel, fonctionnement) ; - lvaluation finale des diffrents choix possibles en termes de bnfice et de cots, en prenant en compte lensemble des conclusions des deux premires tapes. A partir des dcisions dacquisition, lorganisation logique de la mise en place et de lexploitation sera dcompose en sous-systmes suivant une analyse organique prcise : - un organe de mise en place et dadministration gnrale du systme, qui aura la charge de rpondre aux besoins humains et financiers tout au long de la priode de dveloppement et de mise en place, dtablir les plans de formation et dassistance aux utilisateurs, de grer lvolution future en fonction des rsultats dexploitation. Il aura galement la charge de rassembler et grer la documentation technique de lensemble des sous-systmes ; - un organe dacquisition de donnes qui va permettre de grer les divers flux dinformations. Les flux peuvent tre rguliers ou propres une application prcise. Il aura la charge dvaluer et de dcrire les sources dinformations, les modalits daccs, les procdures dacquisition, et de construire et grer lensemble des mtadonnes. Cet organe est le plus important pour le fonctionnement rgulier dun systme dinformation. Il devra galement guider et renseigner les utilisateurs en insistant sur les contraintes imposes par un systme dinformation gographique : conception uniforme des donnes, cot et dure de la saisie, cot de lexploitation, etc. ; - un organe de saisie et dintgration de donnes : structuration, homognisation, validation, codage, saisie, contrle, correction et intgration des donnes suivant les techniques requises par le systme dinformation et de manire

Prsentation du systme SAVANE 51 produire des informations directement exploitables. Les diffrents problmes de la saisie graphique seront traits par cet organe ; - un organe dexploitation et danalyse de donnes assurant la rponse aux demandes des utilisateurs. Cet organe pourra tre conu de manire faire participer les usagers lutilisation interactive des logiciels en fournissant assistance, conseils et documentation. Il pourra galement tre conu comme un bureau d tude et fournir les rponses aux questions poses en se chargeant de lensemble de la procdure dexploitation et de mise en forme dfinitive des rsultats. La nomination dun responsable ayant la direction de lensemble de ces organes est essentielle : ladministration dune base de donnes est un poste de haute responsabilit. 2.3.1.2 Difficults Si les apports et possibilits dun systme bien gr sont trs importantes, les contraintes dutilisation sont galement nombreuses. Pour peu quune mauvaise analyse initiale ait oubli de spcifier tous les moyens ncessaires une bonne mise en place, notamment en ce qui concerne les flux de donnes, alors commencent retards et difficults dexploitation qui peuvent facilement mener des bilans financiers dsastreux. Les besoins doivent galement tre analyss avec le plus grand soin, car il faut viter de mettre en place un systme complexe lorsque cela ne simpose pas. Dans de nombreux cas, la consultation de documents cartographiques ou graphiques, sans notion de base de donnes, peut tre suffisante : les moyens mettre en uvre seront alors bien diffrents, et beaucoup plus lgers et faciles grer. 2.3.2. SAVANE : de la cration d'une base de donnes son exploitation Nous allons dcrire ici rapidement les principes de mise en place dune base de donnes gographiques avec le SIG SAVANE. 2.3.2.1 La cration d'une base de donnes : schma et mthodes La base de donnes va tre cre partir de lanalyse des besoins et des flux dinformations. Ladministrateur du systme va donc crer le schma de la base, en spcifiant la structure de linformation en suivant les principes du modle relationnel tendu la localisation. Le schma comprend la dfinition des relations, des attributs, des regroupements de relations, des regroupements dattributs, des mthodes, des vues externes.

52

Chapitre 2

Le schma peut voluer dans le temps : cest toujours ladministrateur qui aura la charge de modifier ce schma, en ajoutant, supprimant, ou modifiant des lments de ce schma, en principe toujours en fonction des prvisions tablies dans le cahier des charges et dans lanalyse fonctionnelle du systme. Lensemble de ces oprations sont effectues avec le module dadministration SAVATECA. 2.3.2.2 La digitalisation et l'intgration dans la base de donnes La digitalisation des documents graphiques seffectue avec le module SAVEDIT aprs prparation des documents suivant le schma des donnes, ou par importation partir de documents numriques digitaliss sous un autre format. La digitalisation requiert plusieurs tapes : - une homognisation des diffrents documents, - leur transformation en image scanne, puis le redressement de ces images avec le module SAVAMER, - la saisie des lments correspondant la schmatisation, - le contrle et la correction des erreurs. La saisie graphique peut bien sr tre rpartie en plusieurs postes. Il faut alors grer la qualit et la vitesse des diffrents oprateurs pour satisfaire le chronogramme tabli pour la phase de saisie graphique et assurer la qualit des rsultats. Le contrle et la correction des erreurs doivent tre effectus au fur et mesure et avec le plus grand soin. Le module SAVEDIT contient de nombreuses fonctions permettant dassurer la cohrence graphique, topologique, smantique des objets saisis. Les documents saisis sont ensuite intgrs dans la base de donnes. Lintgration cre les objets dans la base et les indexe en fonction de leur localisation. Les donnes descriptives sont intgres dans une seconde phase, par jointure avec les objets grce une cl de jointure descriptive. Toutes ces oprations se font sous le contrle de ladministrateur de la base de donnes. 2.3.2.3 Cration et gestion de mthodes Une fois dfini le schma des relations et attributs, ladministrateur peut galement dfinir des mthodes dutilisation qui vont se placer dans le schma de la base de donnes. La dfinition de ces mthodes peut intervenir tout moment : certaines mthodes drivent directement de la dfinition des relations et attributs, dautres peuvent tre constitues au fur et mesure de lutilisation de la base de

Prsentation du systme SAVANE 53 donnes et tre ajoutes dans le schma par la suite, de manire enrichir la connaissance sur la base de donnes par lutilisation qui en est faite. Un utilisateur peut donc proposer ladministrateur dintgrer une mthode dans la base, si cette mthode correspond un besoin gnral ou permet denrichir la connaissance. Sinon, lutilisateur conserve ses mthodes pour son propre usage, mais elles napparaissent pas dans le schma de la base de donnes. 2.3.2.5 Vues externes et droits d'accs Une fois le schma de la base de donnes constitu, ladministrateur peut dfinir des droits daccs en constituant des vues externes sur la base de donnes. Ces vues externes contrlent laccs aux relations, leurs attributs, ainsi quaux mthodes dfinies dans le schma. Elles permettent galement davoir une vision hirarchique de la base de donnes par la cration de dossiers.

54

Chapitre 2

Prsentation du systme SAVANE 55

Bibliographie

[SOU 87] SOURIS M., A Geographic Information System with relational architecture : principles and example of use, in Primera conferencia sobre informatica y geografia, 1987, San Jose, Costa Rica, pp 703-728 [SOU 90] SOURIS M., Le systme SAVANE, Manuels de rfrence, 1990-2002, IRD

Deuxime partie gographique

Modliser

et

grer

linformation

58

Chapitre 3

Modliser 59

Chapitre 3

Modliser la ralit : cartographie, gographie, gomtrie, et informatique

Lextension du modle relationnel utilise dans le SIG SAVANE est construite sur la prise en compte de types de donnes provenant de la modlisation du monde rel en deux ou trois dimensions, types qui ne sont pas ou mal grs par les systmes de gestion de base de donnes classiques. Dans ce chapitre, nous allons donc tout dabord rappeler les principes de cette schmatisation, avant de prsenter dans le chapitre 4 les mthodes de mesure et dans le chapitre 5 les mthodes de reprsentation et de gestion de ces types de donnes dans le cadre des systmes de gestion de bases de donnes tendus aux donnes localises. Cette rflexion, trs gnrale, nous servira de base dans lensemble de cet ouvrage. Elle nous permet de revenir sur les concepts de base de la cartographie et de la gographie, et de montrer comment llaboration de linformation gographique influence de manire dcisive lutilisation qui en est faite dans les systmes dinformation gographique et dans les procdures danalyse spatiale. 3.1. Prambule Une des plus grandes difficults quait toujours eu affronter la gographie est celui de la prcision de son observation et donc de la prcision de la description du phnomne observ. La nouveaut tient dans le fait que nous disposons dune avalanche dinformation de plus en plus abondante et varie qui modifie considrablement notre perception du rel. Dans le mme temps, les limites dans la gestion et le traitement de ce volume dinformation ont t repousses grce lvolution de la technologie. Tout cela concourt faire de la gographie une

60

Chapitre 3

discipline en profonde mutation ; mutation dans sa perception du rel, mutation dans ses concepts et mthodes. La mise en oeuvre et lutilisation des SIG oblige une complte remise plat de nos certitudes et une rflexion approfondie sur linformation gographique, sa schmatisation, son traitement et sa reprsentation. La validit et la fonction de la carte, support privilgi la fois de la schmatisation et de la reprsentation, sen trouvent profondment modifies. Au fond, le souci de pouvoir profiter dune information sans cesse plus abondante procde dune certaine suspicion lgard de celle-ci. Une mfiance qui se justifie non pas tant parce quelle serait suspecte de manipulation mais plus simplement parce quil nest pas dinformation qui ne soit labore en fonction dune vision schmatique du rel. Do lide, parfaitement justifie, de multiplier et confronter les points de vue par le traitement simultane dinformations dorigines trs diverses. Mais, cest aussi tout le paradoxe de ce type dapproche, le regard critique que nous portons sur linformation gographique et sur la validit de sa localisation exige de brasser toujours plus dinformation. Et plus linformation est abondante et diversifie, plus la ralit gographique nous apparat complexe et inaccessible. 3.1.1. Quelques exemples Nous sommes entours dinnombrables objets, des quantits dvnements se produisent autour de nous, nous-mmes faisons partie et sommes acteurs de divers mouvements et comportements. Pour mieux comprendre le monde qui nous entoure et sur lequel nous agissons, nous avons donc depuis longtemps entrepris den faire ltat des lieux, ou si lon prfre, linventaire. A la manire dune comptabilit analytique ncessaire la bonne gestion de toute entreprise, cet inventaire implique des rubriques et des critres. Si on introduit la localisation de ces objets dans leur description, cest bien sr parce que lon suppose que cette localisation intervient de faon essentielle dans la dfinition ou dans linterprtation de lobjet. Il faut donc maintenant envisager la manire dont on dcrit celle-ci. A travers quelques exemples nous montrerons que la description de la localisation et son niveau de prcision sont indissociables de lobjet que lon souhaite dcrire, et donc, de la question pose. Nous allons successivement envisager la description de plusieurs objets gographiques : une rivire, un terroir villageois, un milieu, une rgion, une ville. Rivire ... Plaons-nous au bord dune rivire avec lirrpressible envie de vouloir la dcrire. Que peut-on faire ? Sans doute commencer par situer lendroit o lon se

Modliser 61 trouve ; puis, mesurer la largeur du lit, tablir un profil transversal au moyen de mesures rgulires de la profondeur. Il sera sans doute utile de mesurer la vitesse du courant afin de calculer un dbit. Une lgitime curiosit sur lactivit biologique de cette rivire justifiera la mesure de la turbidit de leau ; des prlvements deau, analyss en laboratoire, livreront des indications prcieuses sur labondance du plancton... Toutes ces observations faites, sommes-nous rellement en mesure de proposer une bonne description de la rivire ? Evidemment non. Tout au plus, une bonne description dun lieu sur la rivire en un lieu et un instant prcis. On ne sait rien de sa longueur et de son trac, on ignore tout de sa source, de son embouchure, du nombre daffluents qui lalimentent, des affleurements rocheux quelle franchit tout au long de son cours et de la vgtation qui la borde... Bref, on sait fort peu de choses de lobjet que lon prtendait dcrire. Autrement dit, lobjet gographique ainsi apprhend ne peut en aucun cas tre la rivire en tant que totalit. Mais la dmarche tait-elle la bonne ? ou est-ce au contraire la question qui navait que peu de rapport avec la dmarche adopte ? Dire que je veux dcrire La rivire cest dj percevoir celle-ci dans sa globalit et cest poser cette globalit comme un objet en soi. On voit donc que le problme apparemment simple de description dune rivire savre tre dans la pratique dune immense complexit. Ainsi, pour apprhender cet objet complexe quest une rivire, sommes-nous dans lobligation de mieux srier les questions, chacune delle impliquant une mthode adapte la localisation de lobjet et rciproquement. Vouloir dcrire le trac de cette rivire fait appel des descripteurs de localisation diffrents de ceux qui seront employs pour localiser son embouchure ou tel ou tel confluent. Donner une valuation du dbit total de la rivire implique la mise en oeuvre de protocoles de mesures particuliers tout en sachant quon ne connatra jamais son dbit rel. Ainsi pour tout objet gographique devons-nous nous poser les questions suivantes : quel est lobjet que je veux vraiment dcrire ? de quel point de vue dois-je laborder pour apprhender sa totalit ? Puis-je sparer cette totalit en lments simples ? Quel degr dapproximation du rel me parait acceptable ? Terroir ... Changeons de continent et imaginons un de ces beaux villages de lAfrique soudanienne, nich dans limmensit et la monotonie de la savane. Autour des cases, harmonieusement regroupes dans des enclos, stendent les auroles des champs. Du village jusqu ces derniers, de nombreux sentiers dessinent une sorte de toile daraigne complique et irrgulire dont les fils finissent par se perdre mesure que lon sloigne du centre et que lon pntre dans la savane. Les champs euxmmes se distinguent nettement en fonction de la proximit du village. Aux

62

Chapitre 3

parcelles soigneusement dlimites et parfaitement entretenues succdent, mesure que lon se dirige vers la priphrie du terroir, des parcelles aux formes beaucoup plus irrgulires et aux limites dautant plus floues que les plantes adventices colonisent les bordures des champs.

Dores et dj, un terroir villageois sannonce donc comme un objet singulirement complexe, et ce dautant plus que lon souponne aisment quil existe un rapport troit entre les habitations (et donc ses habitants), les champs, les sentiers et la savane qui a t dfriche pour permettre linstallation de ce village. Tous les descripteurs du terroir villageois sont localisables. On peut videmment dcrire sparment chacun des lments constitutifs du terroir et lon sent bien que chacun deux renvoie une classe dobjets de nature diffrente mais galement gographiques. Ainsi, un objet gographique localisable peut tre lui mme le produit, ou le rsultat, dune combinaison de plusieurs objets gographiques de nature diffrente mais galement localisables. Poursuivons la rflexion et tenons-nous en la localisation de cette combinaison, le terroir villageois. Vu sur une photographie arienne, le village, les sentiers qui sen loignent et les parcelles gagnes sur la savane trancheront sur la relative homognit de cette formation vgtale. A ce niveau, un terroir villageois peut donc assez aisment tre dcrit comme une tache, de forme plus ou moins circulaire, localise quelque part dans la savane soudanienne. Mais prciser la

Modliser 63 localisation de cette tache implique ncessairement de prciser la description de lobjet. Quelle rfrence prendra-t-on ? le point sombre du grand manguier qui constitue le centre du village - et, par extension du terroir ? le dtail du trac de chacune des parcelles ? ou seulement la limite extrieure du terroir ? En fait, la localisation nayant de sens que par rapport lobjet que lon analyse, il va de soi que ces trois localisations sont admissibles, soit sparment soit simultanment, mais que chacune, renvoyant une collection dobjets diffrents, dpend de lobjectif vis et donc, de linformation descriptive quil sagira de recueillir puis de traiter ; - considrer le terroir comme un point sur une carte ne permet dutiliser la localisation comme un descripteur supplmentaire que si lon rapporte ce terroir dautres terroirs galement considrs comme des points. En effet, dans lhypothse o lanalyse ne porte que sur un seul terroir on ne voit pas ce que peut apporter une localisation aussi imprcise de lobjet. Dans ce cas de figure, la mention de la localisation se rsumera lnonc, sans vritable intrt, des coordonnes gographiques de ce point. Comme pour mieux assommer le lecteur, combien douvrages ne commencent-ils pas ainsi : le village de ... se trouve situ par 4 38 45" de latitude Nord et 3 27 56" de longitude ouest ? Ds lors le village ne peut plus tre considr comme un objet gographique. Il ne le redeviendra que si lanalyste ne considre plus un seul terroir pris isolment sinon lensemble des terroirs compris dans un espace donn. Chaque terroir, et donc chaque point, peut alors tre compar tous les autres points. Des mesures de distance pourront tre effectues, et des regroupements significatifs de villages ne manqueront pas de se rvler. - linverse nous pouvons considrer le terroir comme un objet en soi, en dehors de tous les autres terroirs proches ou lointains. Nous pourrions croire que les choses devraient sen trouver simplifies par la rduction du nombre dobjets (un terroir au lieu de plusieurs). Cest pourtant le contraire qui se produit puisque la localisation de cet objet unique ne peut plus tre assimile un point. Avec ses cases, ses parcelles et ses sentiers, le terroir villageois est un objet complexe. Lobservateur souhaitera sans doute tablir la relation entre les familles vivant dans chacun des enclos et les parcelles cultives ; ces dernires, de forme et de surface diffrentes, seront plus ou moins fertiles selon lexposition, la nature des sols et la proximit dun cours deau. Il sera enfin tout aussi essentiel de mesurer le temps et la distance parcourue par les femmes pour aller puiser de leau ou ramasser du bois et il sera probablement justifi den mesurer les effets sur la gestion des activits agricoles collectives. Enfin, la forme et laspect mme des parcelles loignes justifiera certainement une question subsidiaire : toutes les parcelles appartiennent-elles la mme classe dobjets ? Ou, au contraire, faut-il distinguer les champs cultivs en

64

Chapitre 3

permanence de ceux qui, du fait de leur loignement, sont priodiquement laisss en jachre ? A chaque entit, enclos familial, parcelle, sentier, seront donc associes un certain nombre dobservations localises dans lespace et dans le temps. Les dplacements seront associs des objets gographiques linaires, les sentiers ; la fertilit des sols et la production agricole sera ramene aux parcelles. Enfin, les revenus tirs de cette production sera rapporte au chef de famille habitant la case principale. Rgion ... Sil existe un objet gographique la fois aussi vident mais en mme temps aussi incertain et controvers, cest bien celui de rgion. Nous voulons parler ici dune forme plus complexe dorganisation de lespace qui se construit delle-mme et connat de constantes modifications au gr des dynamismes locaux et des concurrences interrgionales. En premire analyse la rgion fait partie de ces espaces intermdiaires entre le niveau local dune ville ou dune commune et le niveau plus englobant de la nation toute entire. Nous disons bien, en premire analyse, car, comme pour compliquer les choses, bon nombre de rgions conomiques et culturelles nexistent que par leur position frontalire, et dans ce cas, cest bien souvent la limite du territoire qui donne vie la rgion ... Dans les pays de vieille tradition urbaine, chaque rgion intgre une ou plusieurs grandes villes et tout un semis de bourgs et de petites localits. Il y a bien longtemps que les gographes ne sarrtent plus la question de lhomognit de la rgion. A moins dvoquer des rgions qualifies (rgion agricole, rgion de savane, rgion de montagne, ...), la principale caractristique de la Rgion serait au contraire dassocier une grande diversit despaces -de micro rgions si lon prfre- plus ou moins complmentaires en terme dactivits agricoles, industrielles et commerciales. Toute rgion est enfin traverse par un grand nombre de flux, les uns centriptes et orients vers la ou les villes principales, les autres centrifuges, destination dautres rgions, proches ou lointaines. A une toute autre chelle que le terroir villageois, la rgion sapparente elle aussi un objet gographique complexe compos dobjets gographiques eux-mmes simples (parcelles, usines, quipements, ...) ou complexes (villes). Cest la complexit mme de lobjet qui rend difficile la description de sa localisation. La rgion, telle que nous prtendons lapprhender ici, serait plutt ranger dans la catgorie des objets zonaux. Pourtant la difficult quil y a identifier des frontires

Modliser 65 prcises et incontestables montre bien que nous ne sommes pas dupes de notre propre schmatisation, mme si celle-ci est le plus souvent passe sous silence. Cest tout le problme de la plupart des objets gographiques complexes que nous assimilons -faute de mieux- des zones. Or, toute dlimitation zonale introduit lide dune continuit interne et dune discontinuit externe. Milieu ... La notion de milieu naturel , suppose dabord quil en existe une infinie varit. Cest la premire discontinuit que nous introduisons dans le monde qui nous entoure car il va de soi que ce vocable ne serait pas employ si, pour dcrire lenvironnement, nous ntions pas dans lobligation de slectionner et sparer les objets qui le composent. La notion de milieu naturel est lexemple mme de la rduction du rel continu des objets gographiques discontinus beaucoup plus simples. Dans son acception la plus large, le milieu naturel correspond chez les gographes et lensemble des naturalistes une entit gographique considre comme homogne, au niveau danalyse choisi, et rsultant dune combinaison particulire dans un espace donn ; combinaison entre certains caractres climatiques, topographiques, pdologiques, gologiques, hydrologiques et botaniques. Cette approche intgre fort mal la dimension temporelle et pose au contraire lhypothse dune grande permanence dans le temps. Un milieu naturel se caractrise donc plutt par sa moyenne que par ses carts. Do son nom : mi-lieu. On le dfinit par un rgime climatique moyen, par des sols qui dans lensemble sont plutt de tel type, une vgtation dominante , etc. Linformation la plus prcise dont disposent les chercheurs pour mettre en vidence la diversit des milieux provient pour lessentiel des relevs et observations de terrain quils ralisent ; profils pdologiques, transects, stations mtorologiques, sondages, etc. Cette information ponctuelle, donc facile localiser, est ensuite tendue par des mthodes dinterpolation ou dextrapolation. On attribue donc les rsultats dune observation localise un objet gographique zonal beaucoup plus vaste. Dans la mesure du possible le chercheur aura cur deffectuer de nouvelles mesures sur le terrain afin de valider cette extension de lobservation localise. Il nen demeure pas moins, comme souvent pour les objets gographiques zonaux et malgr lincertitude des limites, que lon est amen crer des objets gographiques supposs continus partir dune information que la prcision de la localisation ne devrait pas autoriser, sans sentourer de nombreuses prcautions.

66 Ville

Chapitre 3

La ville est un objet formidablement complexe. Un systme, qui pour tre dcrit en terme dobjet gographique, doit tre dcompos en sous ensembles dobjets plus simples : immeubles, monuments, siges sociaux; quartiers, arrondissements, commune ; rseaux de transport, deau de gaz, dlectricit, dgouts ; commerces, industries, banques, services ; rocades, boulevards, avenues, rues, impasses ; ouvriers, fonctionnaires, cadres, ...

Bien sr une ville cest cela, mais cest beaucoup plus que cela. Cest surtout linterrelation et linterdpendance de lensemble de ces objets et de bien dautres encore. Ds lors, la description dune agglomration urbaine ne peut se rduire la seule analyse de ses lments matriels stables et visibles. 3.1.2. Prcision et description De la grande diversit des objets gographiques voqus titre dexemple tentons maintenant de dgager quelques conclusions. Certaines paratront parfaitement videntes, mais il nest pas inutile de les rappeler tant elles sont lourdes de consquences, qui, elles, napparaissent que lorsque lon cherche modliser ou reprsenter la ralit avec un ordinateur. La perception visuelle dun objet dpend la fois de sa dimension et du point de vue de lobservateur. Un observateur plac au bord dune rivire se trouve dans limpossibilit de voir la totalit de cette rivire. Pour contourner cette difficult, la

Modliser 67 seule solution consiste sloigner de cet objet. Ainsi, plus la dimension des objets gographique est importante plus il faut sen loigner pour en apprhender la totalit. Ainsi, on sait quon apprhende mieux les formes, les proportions et laltitude dune montagne vue dune certaine distance que lorsquon a le nez coll la paroi rocheuse. Quel que soit le point de vue de lobservateur, la perception dun objet gographique reste toujours fragmentaire et partielle. En effet, plus on sloigne de la montagne pour lapprhender dans sa totalit plus sestompe le dtail de sa vgtation, de ses valles et ravines, mais plus les principaux lments structurants de cette montagne apparaissent clairement. Ainsi, toute distance par rapport lobjet correspond un niveau particulier de schmatisation de cet objet. Toute description dun objet gographique se traduit par une schmatisation de sa dimension, de sa forme, de sa distance, de sa localisation, de son comportement. La perception de tout objet est fonction de lobjectif poursuivi par lobservateur. Il nexiste en soi ni prcision absolue, ni bonne ni mauvaise prcision. Dans la mesure o lobjet gographique nexiste que par rapport lobservateur, une montagne ou une rivire nont ni plus ni moins de ralit quune rgion, une nation ou toute autre abstraction cre pour les besoins de telle ou telle cause. Ce que bien souvent on nomme chelle correspond une certaine description dun objet gographique. Contrairement la notion dchelle en cartographie (cest--dire le rapport entre un objet rel et sa reprsentation sur la carte), lchelle de description correspond une modlisation du rel, un niveau de description qui lie troitement la prcision de la localisation et les autres critres de la modlisation. 3.2. Pourquoi et comment modliser le monde rel La ralit gographique se rvle donc tre bien difficile modliser : une multitude dobjets, des regards et des points de vue diffrents, une imbrication hirarchique de diverses descriptions, des dtails quil convient doublier pour avoir une vision globale, des limites floues, des interactions multiples entre diffrents lments, une reprsentation multiforme. Loin dune schmatisation naturelle ou universelle, voici le lecteur prvenu : il entre dans le territoire des monstres. 3.2.1. Comment apprhender et reprsenter la ralit pour la traiter avec un ordinateur ? La cartographie et la gographie se sont construites peu peu sur la base de possibilits techniques qui, pendant longtemps, nont pas beaucoup volues.

68

Chapitre 3

Depuis une trentaine dannes, tous ces fondements sont les uns aprs les autres remis en cause par des possibilits techniques indites apportes par le dveloppement de linformatique et le pouvoir de modlisation et de calcul des ordinateurs. Il est donc utile de revenir sur des concepts de bases et notamment sur la question de la schmatisation et de la modlisation du monde rel, lobjectif tant de rpondre un problme donn en utilisant un ordinateur, cest--dire fondamentalement une machine capable de reprsenter et de traiter des connaissances. Laspect calcul de lordinateur est ici secondaire : il doit dabord tre considr comme une machine permettant de conserver et de traiter une reprsentation formelle dune ralit. Face une ralit et un dsir dtudier ou de grer cette ralit dans un certain but, il faut schmatiser cette ralit et exprimer cette schmatisation de manire pouvoir grer les objets qui en dcoulent. Linformation gographique nexiste pas en tant que telle : ce nest que par rapport une vision du monde et face un objectif donn que lon peut modliser le monde rel, en fonction de cet objectif, et que lon va passer de la ralit linformation gographique. La description ne peut tre universelle : elle seffectue toujours par rapport un objectif, avec une prcision donne et des descripteurs qui sont dfinis par rapport cet objectif et cette prcision. Et cest bien souvent la difficult premire laquelle est confront lutilisateur dun SIG : comment les donnes quil va utiliser ont-elle t conues, comment ont-elles t structures, dans quel but, avec quelle prcision, quelle validit, etc. Pour ne pas rendre un SIG inefficace, ou mme dangereux utiliser, il faut pouvoir rpondre ces questions. Il faut pouvoir affirmer que la ralit est devenue information ou connaissance sans que cette transformation ne la vide du sens qui va lui tre donn. Car les transformations sont nombreuses, de la ralit lcran : une interprtation par rapport un contexte, soit culturel, soit procdural, une modlisation par rapport un objectif, une structuration par rapport un modle, une reprsentation en rapport avec des possibilits techniques, une utilisation par rapport un problme donn. Bien sr, de nombreuses reprsentations du rel nous paraissent naturelles, tellement elles font parties de notre socit ou de notre culture. Nous essayerons mme plus tard den rpertorier un certain nombre, de manire les proposer, comme un canevas initial, au concepteur dune base de donnes adhrant cette vision du monde ou devant rpondre un problme relativement universel. Ces classes dobjets, comme nous les appellerons, correspondent la vision habituelle dune structuration de lespace, en fonction de la prcision des donnes initiales et de lchelle des cartes qui servent habituellement les reprsenter graphiquement.

Modliser 69 3.2.2. Ralit et connaissance Nous sommes tout instant confronts une ralit dont notre vision est fortement contextuelle. Nous ne voyons ce qui nous entoure quavec nos possibilits techniques et que par rapport nos besoins, ou plutt nous ne retenons de ce que nous voyons que ce qui sert nos besoins, suivant une schmatisation, un apprentissage, une reprsentation interne naturelle quil est bien difficile de connatre. Lhomme se sert de son fort pouvoir dabstraction et de sa facult doublier, dune faon quasi inconsciente et automatique mais extrmement efficace. Lorsque lon cherche apprhender une ralit, non plus de faon inconsciente, mais suivant des critres et des objectifs donns, nous sommes amens essayer de faire ce mme travail de modlisation et de reprsentation dune ralit par le raisonnement et pour le raisonnement. Par le raisonnement, car il nous faut choisir un nombre fini de critres, de relations, de schmas ncessaires la description et oublier le reste. De plus, on cherche reprsenter et schmatiser non pas seulement des faits, mais des connaissances, puisque un fait rel (incertain) devient un objet de connaissance travers la vision de lhomme (vision qui nest bien sr pas unique, et qui dpend la fois de lhomme et de son contexte). Pour le raisonnement, puisque le but de toute reprsentation du rel est laccs au raisonnement, non plus instinctif, mais structur. Si lon cherche ainsi reprsenter les connaissances, cest essentiellement pour tablir un lien entre des concepts du monde rel ainsi exprims et des modles thoriques permettant davoir accs au raisonnement. 3.2.3. Modliser la connaissance La connaissance comprend ds lors des faits (des objets) et des procdures pour les interprter (des mthodes). Le problme de la dfinition dun modle de reprsentation de la connaissance est donc fondamental. On distingue laspect dclaratif (les concepts ou les objets et leurs descriptions), et laspect procdural (les procdures permettant dinterprter et dutiliser les concepts et les objets). Un schma conceptuel de reprsentation de la connaissance comprend ncessairement les deux aspects. Les connaissances dclaratives semblent naturellement plus faciles exprimer que les connaissances procdurales, mais elles nont en soi aucune valeur smantique. Cest un interprteur procdural (un homme ou un programme, plus gnralement une mthode) qui exprime la faon dont elles vont tre utilises, car toute connaissance est contextuelle, mme si de nombreux efforts ont de tout temps t entrepris pour rendre la connaissance universelle. Plusieurs modles de description de la connaissance ont t proposs [GAR 83] [SCH 89] [DAV 91]. Voici un rapide rsum des principaux :

70

Chapitre 3

- le modle smantique reprsente la connaissance sous forme dun rseau, ensemble de nuds (concepts) et darcs exprimant les relations qui peuvent exister entre ces nuds. Larc est orient et reprsente laction dont lacteur est le nud de dpart, agissant sur le nud darrive. Linterprtation du rseau permet de dcrire des hirarchies dactions entre les concepts. Les concepts peuvent reprsenter des objets rels, comme des situations ou des actions. Mais les concepts ne sont pas dcrits par des attributs ou des variables : ce sont uniquement les nuds et arcs du rseau qui dcrivent la connaissance. Le modle smantique sert surtout dfinir et organiser les concepts et les relations entre concepts. - le modle entit-association dcrit les galement des concepts et des associations entre concepts, mais chaque concept comme chaque association est dcrit par des attributs, qui peuvent tre considrs comme des concepts atomiques. Le concept devient lobjet. - le modle objets complexes est trs proche du modle entit-association. La reprsentation des connaissance est base sur des structures dinformations bien organises, les schmas, en essayant de se rapprocher au maximum du fonctionnement suppos de la mmoire humaine. On distingue alors le prototype (description du schma), des objets eux-mmes, ralisations particulires des prototypes. Un prototype est caractris par un certain nombre dattributs, qui caractrisent les objets et dfinissent ses relations smantiques avec les autres objets. Le modle orient objet est une extension du modle objets complexes enrichi dans laspect procdural. Un objet, en terme dinformation, sera donc par dfinition laspect dun concept dcrit par un nombre fini de critres. Le modle orient objet introduit des relations procdurales entre les objets, qui conversent donc entre eux par des procdures. Les critres retenus pour dcrire un objet peuvent sapparenter de simples donnes mesurables, peuvent prendre leur valeurs dans des espaces plus complexes (un espace mtrique par exemple), comme tre eux-mmes dautres objets, des associations entre objets, ou des vnements qui sappliquent aux objets sous certaines conditions. En fait, il faudra la plupart du temps dfinir de nombreux objets et relations entre ces objets pour dcrire la connaissance que lon cherche reprsenter. 3.2.4. Collection dobjets et gestion Lors de ltude ou de la gestion dun problme, on est amen identifier ou mieux dfinir des objets composant ou dcrivant ce problme. Souvent, la dfinition porte non pas sur un ou plusieurs objets, mais sur des ensembles dobjets, tous les objets dun mme ensemble tant par dfinition dcrits par les mmes critres. On a alors tudier ou grer non pas des objets isols, mais des collections dobjets.

Modliser 71 Cest mme ce que lon sefforce de faire la plupart du temps : sachant que lon ne peut dcrire et tudier tous les lments un un, on cherche une description minimale suffisante pour ltude envisage et avec laquelle on pourra dcrire tous les lments composant le problme tudier. On constitue donc des ensembles dobjets qui sont dcrits par un nombre fini de critres identiques. On cherche galement dcrire et modliser la ralit non pas seulement pour dcrire et caractriser des objets, mais surtout pour comparer et diffrencier plusieurs objets ayant le mme schma de description. Dailleurs, on modlisera souvent la connaissance de manire reprsenter avec un mme schma un ensemble dobjets distincts, sil semble plus simple de regrouper les objets qui se ressemblent en catgories (mais est-ce bien la dmarche naturelle de la mmoire ou de lintelligence ?). On passe donc de la notion dobjet celle densemble dobjets, en introduisant de nouvelles contraintes lies la gestion de ces objets devenus lments. Il devient alors souhaitable de ne considrer que des ensembles dobjets homognes, afin de pouvoir contrler la cohrence des objets les uns par rapport aux autres et afin deffectuer des oprations ensemblistes de manire efficace. Au problme de la reprsentation des connaissances et de description des objets, sajoute donc le problme dune gestion efficace dun ensemble dobjets. Les systmes de gestion de base de donnes sont chargs de la gestion dun ensemble dobjets, et les mthodes employes sont bien sr fonction du modle de reprsentation des objets. Suivant les contraintes que lon simpose pour la gestion, on sera amen choisir tel ou tel modle de reprsentation de la connaissance. Ce sont souvent les contraintes de gestion qui amnent choisir un modle de reprsentation, et non linverse : il est donc fondamental de connatre ces contraintes avant de choisir un modle de reprsentation. Plus la description des objets est complexe, plus une collection dobjets sera difficile grer : toutes les thorie des systmes de gestion de base de donnes, que nous verrons au chapitre 5, reposent sur cette ide. Soit on impose de simplifier la description des objets, et on pourra alors assez facilement les grer, mais au risque de trop simplifier la modlisation du rel ou davoir dfinir de nombreux objets distincts et davoir effectuer de nombreuses oprations entre ces objets pour retrouver une description acceptable de la ralit. Soit on essaye de conserver une modlisation plus complexe, quitte avoir des difficults de gestion et une faible marge de manuvre dans les traitements. Modle de description et modle de gestion sont donc intimement lis. Cest encore une fois essentiellement lapprhension de la ralit et lutilisation de cette modlisation qui va nous amener utiliser un modle de description et de gestion plutt quun autre.

72

Chapitre 3

3.3. La schmatisation du monde rel : de la ralit la gographie La prise en compte de la localisation rpond deux proccupations majeures : reprer pour se reprer, reprer pour dcrire et interprter. Pourquoi l et pas ailleurs ? Comment expliquer la distribution spatiale dun objet ? Comment expliquer la distribution des objets les uns par rapport aux autres ? Ces questions sont, implicitement, au cur de toute question gographique. 3.3.1. La localisation comme attribut : lobjet gographique Nous avons plusieurs reprises employ le terme objet gographique , sans en avoir encore donn une dfinition formelle. Mais de ce qui prcde, nous pouvons dgager un besoin gnral : modliser la ralit pour tudier des situations ou des phnomnes ayant une composante spatiale. Implicitement, on suppose mme que la localisation dans lespace est lune des causes du phnomne tudier, et non une consquence de ce phnomne. Nous appellerons donc dans cet ouvrage objet gographique un objet modlisant un phnomne du monde rel pour lequel la localisation dans lespace a valeur de causalit : autrement dit, on ne pourra avoir au mme endroit deux objets gographiques correspondant deux phnomnes de la mme catgorie. On assure ainsi une dpendance fonctionnelle de lespace et du temps sur le phnomne. Cette schmatisation ne peut tre applique aux objets localiss que sils sont regroups en catgories, que nous appellerons plutt collections. Un objet ne devient donc gographique au sens o nous venons de le dfinir que sil appartient une collection. Cette dfinition de se veut pas gnrale au sens de la gographie, car elle serait alors beaucoup trop simpliste : elle est directement lie notre besoin de modlisation en vue dune gestion relationnelle par collections dobjets du mme type, et est guide par lobligation du respect de la contrainte dunicit : on ne peut avoir deux objets dune mme collection au mme endroit et au mme moment. Le terme collection utilis ici recouvre le concept densemble dobjets dun mme type. Ces objets sont dcrits, en fonction de linterprtation de lobservateur, par des variables lmentaires, appels attributs. Un objet gographique a la particularit dassocier une localisation gographique et quelquefois temporelle lensemble des attributs qui constituent la description non localise de cet objet. Lattribut donnant la localisation est appel attribut de localisation, pour le distinguer des autres attributs qui constituent linformation descriptive. Il est important de noter quil ny a pas de diffrence thorique entre information graphique et information descriptive, toutes deux constituent lensemble des attributs qui servent dcrire un objet de la collection dtermine par lobservateur ou le modlisateur. Par contre, la modlisation impose une dpendance fonctionnelle de lune vers lautre qui motive cette distinction smantique et qui se traduit souvent dans les SIG par la sparation physique et

Modliser 73 conceptuelle du graphique et du descriptif. En effet, la localisation gographique et temporelle dun objet va dterminer lensemble des valeurs des autres attributs de cet objet : implicitement, on ne peut avoir, au mme moment et au mme endroit, des valeurs descriptives diffrentes pour un mme objet dune collection. Nous verrons un peu plus loin dans ce chapitre comment dcrire cet attribut de localisation. Nous pouvons nanmoins dj souligner son caractre relativement universel, puisquil correspond toujours la description dun lieu, dans un espace qui est unique pour tous les objets rencontrs. La difficult, pour modliser le monde rel, se trouve bien dans les rapports entre la description, la schmatisation, la prcision de la localisation dune part, et le contenu smantique de lobjet et les attributs qui servent dcrire ce contenu dautre part. 3.4. La schmatisation de la localisation : de la gographie la gomtrie A partir dune ralit gographique complexe, le besoin de reprsentation graphique rend ncessaire la schmatisation de la localisation. : la transition devient frontire, le lieu devient point... La gomtrie remplace la description gographique, dans un processus de schmatisation trs radical. 3.4.1. Gographie et cartographie : une union agite La ralit gographique est donc complexe, souvent diffuse, et elle est le plus souvent dcrite en utilisant la cartographie. Jusqu prsent, en effet, la carte reste encore le procd le plus efficace de reprsentation puisquil permet de prsenter sur un mme document visuel une reprsentation de lobjet gographique qui combine la fois sa localisation et son contenu. Cependant, comme toute modlisation, la cartographie consiste rduire le rel des faits simplifis et un nombre fini de critres. Le problme qui se pose donc est celui des hypothses et des techniques qui aboutissent cette double schmatisation de la localisation de lobjet et de linformation descriptive qui sy rapporte. Aussi, on ne peut oublier que lobjet gographique est beaucoup plus riche que la carte qui est cense le schmatiser. Il est donc absolument essentiel de comprendre et connatre pas pas les tapes de cette schmatisation, puisque le degr de validit du modle en dpend. La gographie n'a pas toujours su se faire comprendre des cartographes. Cette incomprhension relve bien d'une contradiction fondamentale. Au del de la description du rel qui, chez le gographe, s'exprime le plus souvent par des cartes, celui-ci recherche aussi des modles. Le cartographe quant lui recherche la prcision de la mesure, et ce souci le conduit toujours un choix douloureux entre lirrpressible dsir d'une mesure parfaite et l'invitable altration de la ralit

74

Chapitre 3

induite par la reprsentation cartographique de cette ralit. Dans le mme temps, et c'est pour cette raison que les disciplines sont spares, le gographe, sans que son collgue s'en soit vritablement rendu compte, est pass tout autre chose. Sauf cas rares, il ne cherche plus localiser de faon trs prcise et trs exacte un phnomne, mais en donner une vision simplifie, ou plutt schmatise, qui permette que soit compris sa nature et son fonctionnement dans un espace donn. Les SIG, comme nous le verrons tout au cours de cet ouvrage, permettrons en partie de runir ces deux disciplines, et cest bien ce qui fait lune des forces de ces nouveaux outils. 3.4.2. Cartes de localisation et cartes thmatiques La vertu de toute carte de localisation bien faite est de ne prter le flanc aucune critique en terme d'interprtation. Elle runit sur un plan des objets facilement reprables, donc visibles, localiss les uns par rapport aux autres en fonction de leur distance relative et de leur position par rapport au nord gographique. Ce type de carte introduit une premire relation entre deux informations : la nature de l'objet et sa position dans l'espace. La plupart des cartes sont porteuses d'autres enseignements que la seule localisation. Il est apparu de plus en plus utile de dresser des cartes dont la finalit premire n'est plus de se reprer pour mieux suivre un itinraire, mais plutt de reprer un phnomne dans l'espace pour mieux l'apprhender. Nous en arrivons ainsi la carte thmatique. L'abondance et la varit des cartes thmatiques est telle aujourd'hui qu'il semble qu'on passe sans distinction claire de la carte descriptive la carte interprtative qui prtend avoir valeur de modle. Les premires seraient rapprocher des cartes de localisation dans la mesure o la principale proccupation semble tre de reporter scrupuleusement les observations faites sur le terrain. Les cartes gologiques, celles des sols ou de la vgtation en fournissent de trs beaux exemples. Bien qu'labores par des spcialistes, le choix d'une reprsentation cartographique n'implique pas systmatiquement la recherche de phnomnes complexes qui seraient relier leur position particulire dans l'espace. En effet, le premier objectif, mais aussi la principale qualit de ce type d'entreprise semble tre de restituer au lecteur toute l'information recueillie, qui, l'tat brut, sous forme de carnets de notes et d'chantillons, reste videmment impossible interprter par un non spcialiste.

Modliser 75 3.4.3. La reprsentation gomtrique de la localisation gographique Il va de soi que nous n'aurions nullement besoin de nous interroger sur la reprsentation gomtrique de la ralit gographique si nous n'avions pas fait auparavant le choix de reprsenter cette modlisation par une carte. Mais ds que ce choix est fait nous sommes bien obligs de nous demander comment nous allons figurer et reprsenter les diffrents objets gographiques que l'on souhaite dcrire. Et ce choix va de nouveau fortement influencer notre modlisation du monde rel : par rapport la diversit et la complexit des formes de localisation que prennent les diffrents objets (ville, rgion, terroir, paysage, ...) nous nous trouvons extraordinairement limits dans nos choix puisque selon l'objet, et donc selon l'objectif poursuivi, nous devrons nous rsoudre assimiler celui-ci un lment ou un ensemble dlments gomtriques : un point, une ligne, une zone. Prenons l'exemple des villes. Pour simplifier l'explication on peut, trs schmatiquement, prendre trois orientations diffrentes : - donner une image trs prcise de chaque ville en mettant en vidence sa diversit interne, la spcificit socio-conomique de chaque quartier (1) ; - comparer les attributs descriptifs de l'ensemble des villes d'un territoire (population, activit, etc.) (2) ; - tudier les rapports et les flux (de transports de biens, de personnes, d'information) qui s'tablissent entre l'ensemble des villes d'un territoire (3). (1) Dans le premier cas, ce qui nous intresse est ce qui se passe dans la ville. Cette notion contient deux implications fortes. La premire est qu'on suppose l'existence de fortes diffrences entre ce qui se passe l'intrieur de la ville et ce qui se passe au dehors. Dedans, dehors, la notion de fermeture est implicite et introduit ipso facto la notion de zone. La ville aurait donc une enveloppe, une frontire et cet objet se distingue fondamentalement de ce qui l'entoure. A ce niveau, on pose l'hypothse d'une certaine homognit interne qui contraste avec la priphrie de la ville, suppose galement homogne. Cependant, si nous nous arrtions l, il est vident que le problme pos ne serait pas tant celui de la description de la ville que ce qui la diffrencie de la campagne. On pourrait donc numrer, voire reprsenter graphiquement les diffrences qui opposent ville et campagne, sa population, ses comportements dmographiques et sociaux, etc. Mais, et nous en arrivons la seconde implication, la prcision de la localisation des contours de la ville aurait-elle vritablement un sens ? Ne pourrions-nous pas tout aussi bien reprsenter cette enveloppe par un cercle au centre d'un grand rectangle qui lui, reprsenterait la campagne ? En fait la rponse est plus complexe qu'il y parait car elle est en grande partie fonction de l'intrt port l'objet campagne. Mais, si nous nous en tenons la ville, la prcision choisie pour le trac

76

Chapitre 3

de ses limites n'a de sens que si on considre la ville comme un ensemble lui-mme constitu de sous-ensembles, les quartiers, les rues, .... Comme tout objet auquel nous attribuons une reprsentation zonale, la ville est un ensemble htrogne qui interdit de le considrer comme une zone ; mais parce que c'est aussi un ensemble homogne par rapport ce qui l'entoure on est galement autoris considrer la ville comme une zone. Autrement dit, ou bien je considre la ville dans son contexte englobant et mon objet mrite d'tre assimil une zone, ou bien je ne considre que la ville, son contexte m'indiffre, et je n'apprhenderai celle-ci que comme un ensemble d'objets zonaux, linaires ou ponctuels. La question des limites de la ville ne sera pas pose mais la rponse me sera malgr tout donne par la densit et la proximit des objets que j'aurai reprsentes sur la carte. (2) Si, dans une approche comparative, mais dj trs proche de la notion de rseau urbain , je souhaite reprsenter sur une carte les divers attributs socioconomiques associs aux villes d'un territoire national la question de la localisation change radicalement. La seule question qui mrite d'tre pose est : o se situent les villes dans l'espace national et comment se situent-elles les unes par rapport aux autres ? La forme de chaque ville, sa surface et ses limites ne nous intressent gure, et, supposer que ces attributs descriptifs nous soient d'une quelconque utilit pour cette approche comparative il serait tout fait possible de les ajouter la liste des descripteurs socio-conomiques et de les reprsenter pareillement. La localisation de ces villes sera rapporte sans difficult une liste de points reprs par leurs coordonnes. Pourquoi sans difficult ? Tout simplement parce que la question pose est d'une double nature gographique puisqu'elle s'interroge la fois sur l'ensemble des villes (objets ponctuels) dans le territoire national, objet zonal. (3) Supposons maintenant que cette approche soit juge insuffisante pour dcrire et reprsenter la multiplicit des relations qui unissent les villes entre elles et font de cet ensemble un ensemble hirarchique, un rseau... La nature des liens unissant chaque ville ses voisines est largement fonction de son rang (capitale, mtropole rgionale, villes secondaires, bourgs, ...) et de sa localisation. L'vocation de ces liens fait immdiatement rfrence de nouveaux objets qui, en la circonstance, pourront tre des routes, des lignes de chemin de fer, des flux d'nergie et d'information. Aux objets ponctuels que sont les villes dans l'espace national seront alors associes des lignes (arcs, segments) reprsentant ces liens. Points et lignes, lieux et liens seront donc les deux reprsentations d'un nouvel objet, le rseau. Notons que dans ce cas de figure le point est aussi un nud. Une mme localisation peut donc renvoyer des objets diffrents ; un point peut tre la

Modliser 77 reprsentation d'une ville, mais ce peut tre aussi la reprsentation d'un carrefour routier d'un rseau urbain. Comme ces exemples l'ont montr, la reprsentation cartographique de la ralit gographique introduit d'normes contraintes et, parfois, d'excessives rductions au regard de notre perception, intuitive ou non, de l'objet. Si bon nombre dobjets gographiques sont modliss en utilisant la cartographie, lavnement de linformatique et en particulier le pouvoir de modlisation des ordinateurs permettent de remettre en question cette schmatisation excessive. Faut-il employer la cartographie pour modliser la ralit ? Na-t-on pas maintenant les moyens techniques, grce linformatique, de revenir sur une schmatisation excessivement rductrice de la ralit ? Malheureusement, les SIG nont pas vraiment remis en cause la modlisation de la ralit par la cartographie. Ils se sont contents de reprendre les bases de cette schmatisation pour lamliorer, mais sans vraiment remettre en cause le passage de la gographie la gomtrie, en conservant comme base de la schmatisation de la localisation absolue la reprsentation des objets en zones, lignes, ou points [BOU 82] [SCH 89] [ROU 91] [VOI 92]. Le SIG Savane nchappe pas cette rgle. La reprsentation multi-chelle est la seule avance tangible [SCH 92] [WOR 95]. Elle permet dassocier plusieurs descriptions de la localisation pour un mme objet, sans en changer les attributs descriptifs, et de choisir la description en fonction de la prcision recherche. Elle permet de rsoudre un certain nombre de problmes dutilisation et de reprsentation cartographique, mais ne change pas fondamentalement la description de la localisation des objets en zone, ligne, ou points. Dans le SIG Savane, nous ne conservons quune seule reprsentation de la localisation pour un objet, quitte multiplier les collections dobjet. Nous tentons plutt dapporter des solutions procdurales en dveloppant de nombreuses procdures de transfert dchelle et de changement de type dobjet, lors de lutilisation des objets. Nous verrons ces procdures dans la troisime partie de cet ouvrage. 3.4.4. Dcrire la localisation La localisation peut tre dcrite de manire absolue (par exemple de faon analytique, par des coordonnes dans un espace vectoriel), de manire relative (un objet par rapport un autre, en exprimant des relations spatiales en les objets grce des proprits topologiques ou ensemblistes, comme ladjacence, lintersection), ou de manire indirecte (comme des adresses) [SCH 96]. Nous ne nous intresserons ici qu la description absolue de la localisation. La description relative ou indirecte nest utilise que pour amliorer lefficacit de la reprsentation, et retrouver

78

Chapitre 3

facilement la localisation absolue dun objet partir de la localisation absolue dun autre objet. Lutilisation dune schmatisation cartographique de la localisation absolue nous amne reprsenter cette localisation par des zones, des lignes, ou des points. Nous laissons ici volontairement de cot linformation reprsente des pixels, cest--dire des lments dimage : nous consacrerons un chapitre spcial ce type dobjet (chapitre 6). Dtaillons le passage dune description formelle une reprsentation gomtrique de la localisation. Llment de base de lespace rel est le point (au sens mathmatique), de RnxR, (n=2 ou 3 pour lespace, plus une composante pour le temps) et chaque objet gographique devrait donc logiquement tre un point de RnxR. Cette description formelle est bien sr impossible, car nous sommes confronts des objets physiques, et il est ncessaire de changer despace de reprsentation et dintroduire la notion de prcision. Comme nous lavons vu plus haut, ce passage est la base des problmes de validit et des difficults de traitement de linformation localise : la description dun objet, si ce nest mme sa dfinition, va tre en partie dtermine par les mthodes de reprsentation utilises. Cest en fait exactement ce que fait implicitement le gographe lorsquil dcrit un objet une certaine chelle. Il y a l bien sr confusion avec lchelle de reprsentation cartographique des objets tudis, mais lon voit bien que le choix de la description de la localisation, comme la prcision de cette localisation, est li aux choix des attributs descriptifs, et que lobjet est lui-mme dfini par lensemble de ces attributs. Comme dans tout problme informatique, le choix de lespace de reprsentation et le codage de linformation influencent de manire dterminante la nature mme de linformation reprsente et donc lutilisation qui en sera faite [BEK 92] [GUP 95]. Tout le problme de la reprsentation de lespace est de dfinir un nouvel espace de reprsentation qui permette de rduire la description des objets un nombre fini dlments et de pouvoir grer la prcision gographique de cette reprsentation : il faut passer dune description mathmatique (les lments ou ensembles de lespace mathmatique) des sous-ensembles de cet espace et dcrire la localisation de ces sous-ensembles avec un nombre fini de paramtres. Les entits auront alors comme objets non plus des points, mais des ensembles de points, et les valeurs des attributs descriptifs se rapporteront a ces ensembles. Dans ces conditions, il est vident que la mthode de dfinition de ces sous-ensembles va influencer, sinon dterminer, la dfinition des attributs descriptifs. Comme nous lavons dj largement soulign, le cheminement de linformation est plus complexe que le passage direct du point mathmatique la description

Modliser 79 informatique. Linformation est rarement donne directement en terme despace mathmatique et de donnes brutes, mais seulement aprs ltape schmatisationextrapolation-cartographie : partir de linformation de terrain, la donne est interprte, schmatise pour correspondre au modle du monde rel, puis elle est reprsente sur une carte. Cette carte, reprsentation gomtrique, fait alors lobjet dune reprsentation informatique. Mais si lon veut raisonner en terme de globalit gographique, il est ncessaire de revenir un espace de rfrence qui ne peut tre que lespace mathmatique. Deux mthodes diffrentes sont utilises : la dfinition a priori des sousensembles, et la dfinition des sous-ensembles en fonction des objets de lentit. Avec la premire mthode, la description de la localisation des sous-ensembles est trs simple, car ils sont justement dfinis pour faciliter reprsentation et description, en utilisant le moins de paramtres possible. Par contre, on perd une partie importante de linformation descriptive, les objets ntant plus dfinis par les valeurs descriptives des points mais uniquement par les paramtres de leur localisation dans lespace. Par exemple, si lon prend comme dfinition des sousensembles les cellules dun maillage de lespace, cela revient dire que tous les points (mathmatiques) dune mme cellule auront les mmes valeurs descriptives. Cette mthode utilise principalement le dcoupage de lespace en polygones rguliers : carrs, triangles, hexagones Ces polygones sont en gnral reprs dans lespace par un systme de coordonnes propres leur dfinition (lignecolonne pour les carrs, etc.). Lattribution des valeurs descriptives au maillage prdfini de lespace se fait en gnral par superposition dune grille une carte classique, ou par saisie automatique grce un scanner. Outre la facilit de description de la localisation, les avantages de cette mthode sont essentiellement dus la facilit de traitement qui en dcoule : les oprations ensemblistes se font sur des cellules dont la localisation est fixe pour tous les objets. Les inconvnients sont par contre trs importants : perte dinformation descriptive, taille des objets fixe a priori, important volume de donnes, mme sil existe des mthodes permettant de rduire ce volume, par compactage ou structure arborescente. La seconde mthode de description gomtrique utilise est la dfinition des objets en fonction des valeurs descriptives de lentit. On va ainsi crer des sousensembles que lon classe en zones, lignes, points [BOU 81] [DAV 91]. Les points correspondent au point mathmatique : on assimile donc la localisation de lobjet un point de lespace mathmatique. Les lignes sont des sous-ensembles de dimension 1, les zones des sous-ensembles de dimension 2, ferms et borns. La connexit nest pas requise dans cette dfinition. De mme, nous ne parlons pas ici de polygone : cet lment nintervient en fait que dans la reprsentation

80

Chapitre 3

informatique de ces lments gomtriques, alors que nous ne sommes ici que dans une reprsentation gomtrique de la localisation. 3.4.5. Les limites du modle gomtrique La description gomtrique en zone, ligne, point est-elle suffisante pour dcrire de manire satisfaisante les objets gographiques ? Oui et non. Si lon dcide de modliser la ralit avec des cartes, oui. Mais lon a vu combien cette modlisation peut tre rductrice et combien elle simplifie la ralit. La gomtrie introduit des discontinuits dans la ralit, et la prcision ou lincertitude nest pas traite par ce modle de description. Ds lors, les traitements appliqus aux objets gographiques dans les SIG ne sont-ils pas trop sophistiqus par rapport la validit de la schmatisation de la ralit ? 3.5. De la gomtrie linformatique : la reprsentation informatique de la localisation La description informatique se base sur la description gomtrique. Il sagit maintenant de reprsenter cette description gomtrique par un ordinateur, et donc par un nombre fini de descripteurs. Cest en effet ce qui caractrise cette nouvelle tape : l o en mathmatique on peut nommer, en informatique il faut reprsenter. Nous allons rappeler rapidement comment reprsenter des lments gomtriques avec un nombre fini de paramtres, et quelles sont les structures informatiques qui permettent de conserver efficacement cette reprsentation. 3.5.1. La reprsentation en maille La reprsentation en maille est trs proche dune reprsentation informatique. Cest dailleurs essentiellement pour cela quelle est employe. Comme le nombre de maille peut tre lev, le seul vrai problme de la reprsentation par maille consiste trouver des structures de reprsentation interne permettant de rduire lespace de stockage. Nous aborderons rapidement cet aspect un peu plus loin. 3.5.2. La reprsentation vectorielle On nomme reprsentation vectorielle la reprsentation informatique des zones, lignes, et points qui conserve cette structure gomtrique. La reprsentation de points est immdiate : ils sont dcrits tout simplement par leurs coordonnes dans un systme de rfrence choisi (nous consacrerons

Modliser 81 nanmoins le chapitre suivant au simplement). Les coordonnes sphriques, qui correspondent la longitude et latitude, sont souvent utilises. La prcision informatique des coordonnes est un facteur important du codage, car il peut influencer la validit des donnes graphiques. Les lignes sont dcrites par un ensemble de points, appels sommets : la ligne est alors reprsente graphiquement par lensemble des segments dfinis par ces sommets. Bien sr, il y a perte dinformation entre la reprsentation mathmatique de la courbe et sa reprsentation informatique. Ici, le nombre de sommets en fonction du rayon de courbure dtermine la prcision du codage : elle dpend la fois de la mthode de saisie (lopration qui permet de passer de la gomtrie linformatique), des matriels utiliss et de loprateur, sil existe. Les zones sont repres par leur contour, qui est considr soit comme propre chaque zone, soit comme un ensemble de frontire. Dans le premier cas, la zone est dcrite graphiquement par un ensemble de lignes fermes, appeles boucles. Si lon conserve ces lignes telles quelles, il y a duplication dune partie de linformation graphique, un contour tant en gnral commun deux zones : globalement, ces lignes sont alors stockes deux fois. Le problme des trous et des zones incluses imposent habituellement ce type de reprsentation de conserver le sens des arcs. Dans le second cas, les contours sont considrs comme un ensemble de frontires, chaque frontire tant dcrite par une ligne. Les extrmits de chaque ligne sont appeles nuds, les lignes elles-mme tant nommes arcs. Chaque nud appartient au moins deux arcs, et lensemble des arcs dune zone doit constituer une courbe ferme. Notons quil est important de pouvoir reconstituer facilement le contour dune zone partir de ses frontires. Nous prsenterons plus loin un algorithme permettant deffectuer cette opration (A.2.2.6.). Des entits plus complexes peuvent tre dfinies partir dentits dont les objets sont des points, des lignes, ou des zones. Par exemple, on peut dfinir des entits dont les objets sont des couples dlments dautres entits. La reprsentation de ces objets est donc un peu plus complexe, car elle fait appel non seulement la description graphique des lments, mais galement la description des relations qui dfinissent les objets. Lexemple le plus courant est celui dune collection dont les objets sont des couples ordonns de points (description de flux, migrations, rseaux linaires, etc.). La description de la collection sapparente alors celle dun graphe. Les structures de reprsentation de linformation localise ne sont donc pas simples : elles dpendent du type de lobjet, et pour chaque type, elles comprennent la fois une description de la localisation absolue utilisant un nombre fini de points de lespace et des relations entre ces diffrents ensemble de points [EGE 90].

82

Chapitre 3

3.5.3. Les structures de reprsentation de linformation localise Nous reviendrons en dtail au chapitre 7 sur les modles de reprsentation de la gomtrie. En effet, ces modles sont directement lis aux mthodes de saisie graphique, ainsi quaux contraintes que lon impose pour assurer lintgrit de la reprsentation. Ils sont mme pour la plupart construits pour permettre les contrles de cohrence et dintgrit. Mais nous pouvons ds prsent dcrire les principes de cette structuration. Le choix de la structure de reprsentation se pose pour tout type de donne : il doit tre effectu en fonction des besoins ultrieurs et leur tre adapt. Pour la partie graphique de linformation gographique, cette structure est surtout fonction de trois critres : facilit des manipulations (ensemblistes, mtriques et topologiques), compacit, structuration. Plusieurs niveaux de reprsentation peuvent ainsi tre ncessaires suivant les traitements effectuer. Des procdures didentification et de reconnaissance permettent de passer dun niveau de reprsentation un autre, suivant une hirarchie doprateurs de reconnaissance (de lensemble des points au contour, de la courbe la zone, de la courbe la forme caractristique, etc.), qui permettent galement de passer dun ensemble de reprsentation infini un ensemble fini. Le premier niveau de reprsentation que nous avons vu au paragraphe prcdent correspond aux coordonnes des points de lespace dcrivant les objets (par exemple, pour une ligne, lensemble des points qui permettent lapproximation des lments graphiques une prcision donne). A un niveau suprieur, la reprsentation des lments fait appel des relations entre ces lments, relations qui doivent, en principe, donner lensemble de linformation ncessaire aux problmes rsoudre ultrieurement [EGE 89]. On distingue ainsi : - les relations unaires, ou formes primitives, qui donnent le type de llment et ses paramtres (trait et longueur ou orientation, par exemple) ; - les relations binaires, qui peuvent tre soit numriques (bases sur des indices de ressemblance ou de dissemblance, ou sur des relations mtriques), soit topologiques (bases sur les notions de voisinage, de position, etc.). La reprsentation est souvent donne sous forme de graphe dont les sommets sont les lments, et les arcs entre sommets crs si la relation est vraie. Dans le cas numrique, les artes sont values par les distances entre les sommets. Si le nombre de forme primitives est faible, le nombre de relations binaires ou n-aires possibles pour dcrire les lments graphiques est trs grand : tout le problme consiste alors choisir les bonnes relations permettant une description minimum, en fonction du

Modliser 83 but poursuivi. La description dlments caractre gographique utilise de prfrence des relations invariantes par transformation isomtrique. Voici par exemple un certain nombre doprateurs permettant dexprimer des caractristiques ou des relations entre objets : - des oprateurs ensemblistes : galit, appartenance, inclusion, intersection, union, diffrence, cardinal ; - des oprateurs topologiques : fermeture, frontire, voisinage, recouvrement, compacit, connexit ; - des oprateurs mtriques : distance, angle, longueur, primtre, surface, centrode. Le problme de la reprsentation se pose pour tous les types dobjets graphiques, mais plus spcialement pour les lignes et pour les zones. Un objet de type ligne peut en effet tre constitu de plusieurs arcs ; les extrmits des arcs peuvent jouer un rle particulier dans la description de lobjet ; la position de chaque arc par rapport aux autres galement. Un objet de type zone peut tre constitu de plusieurs taches non connexes (composantes connexes) ; chaque tache peut comporter des trous (genre). Ainsi, de nombreux systmes emploient la terminologie de polygone , et il est courant de confondre zone et polygone dans un souci de simplicit. Mais cest alors confondre la description dun modle (la zone reprsente un objet), et la description de la reprsentation interne de la gomtrie des objets. Et cest une trs forte limitation que dimposer aux zones dtre des ensembles connexes de genre 1, limitation qui engendre souvent des problmes concrets (les zones incluses disparaissent, par exemple). 3.5.4. Les mthodes de compactage Un SIG peut contenir une grande quantit dinformations graphiques. Il est donc important que la structure de reprsentation choisie permette de compacter cette information pour pouvoir la stocker sur le moins de place possible, sans nanmoins que lopration de transformation naltre les performances du systme [BOU 81]. Les mthodes de compactage sont videmment fonction des mthodes de reprsentation de linformation graphique (maille ou vecteur), et doivent si possible permettre dans la forme compacte des manipulations graphiques ou des calculs mtriques lmentaires. Dautre part, linterrogation des donnes dans un SIG consiste essentiellement en une opration de recherche et de slection sur la localisation : slection dlments dans une fentre, dans le voisinage dun objet, etc. Il est donc ncessaire dorganiser et de structurer les objets par rapport leur localisation, de manire ce que ces oprations soient excutables en un temps acceptable par lutilisateur. Ce sont ces trois critres (facilit de manipulation

84

Chapitre 3

graphique, compacit, structuration) qui vont guider le choix des mthodes de reprsentation des lments graphiques. Dans la reprsentation des objets en points, lignes, zones, nous avons vu que, si les points ne posent pas de problmes particuliers (leurs coordonnes sont conserves directement), pour deux les autres types dobjet les lments graphiques prendre en compte sont des courbes, habituellement reprsentes par des suites de points dont on connat les coordonnes. Les mthodes de compactage consistent rduire lespace ncessaire au stockage direct des coordonnes de lensemble de points. Dans la plupart des cas, le stockage direct sans compactage est nanmoins maintenant une solution satisfaisante. Nous ne rappellerons ces mthodes de compactage que par souci historique.
Les mthodes de compactage de reprsentation de courbes sont bases pour la plupart sur un codage incrmental, appel encore codage en chane : les courbes sont approches par un ensemble de points o chaque point est dduit du prcdent par la donne dun paramtre (angle, distance, courbure, etc.). le plus connu de ce type de codage est celui de Freeman, bas sur un ensemble de huit vecteurs cods de 0 7 [FRE 61]. Chaque point est dduit du prcdent par translation dun de ces huit vecteurs. Le codage dune courbe comprend donc les coordonnes du premier point puis la suite des codes de Freeman pour la meilleure approximation. Des algorithmes trs usits ont t dvelopps pour calculer ces approximations (par exemple lalgorithme de Bresenham pour les lignes droites). Dautres codages en chane ont galement t employs : codage quatre directions, par incrment de courbures, par vecteurs de type Freeman mais de norme variable. Ces codes induisent des grammaires qui peuvent servir la gnration et la manipulation des lments cods. Le principal inconvnient du codage en chane provient de son caractre relatif : les coordonnes dun point doivent tre calcules partir du dbut de la chane. Ceci complique ou rend impossible a priori les manipulations graphiques sur les lments cods (intersection, inclusion, calculs topologiques et mtriques, etc.). Pour remdier cette difficult, on rajoute des informations, notamment sur les caractristiques topologiques, le plus souvent sous forme de relations binaires entre primitives graphiques (la courbe est frontire de telles zones, deux zones sont connexes, etc.) [EGE 89]. Ainsi, dans le cas des courbes fermes, on peut indiquer par pointeur les relations entre les arcs, ou reprsenter les inclusions de zones par un graphe, ainsi que chaner les arcs pour retrouver rapidement la structure de courbe ferme. Le systme DIME a t lun des premiers avoir incorpor des structures topologiques [DIM 70]. Dans le cas de courbes fermes, dautres mthodes ont t dveloppes, consistant ne conserver que lintersection du contour avec un balayage horizontal : certaines oprations mtriques sont rendues plus simples avec cette reprsentation [AMI 71] [AOK 79].

Modliser 85
La reprsentation de lespace gographique par un dcoupage arbitraire, qui est encore utilise dans de nombreux systmes (dits raster), produit un important volume dinformation car le nombre de cellules cres est grand, ds que lespace dtude devient significatif. Le compactage consiste ici essayer de regrouper les cellules de mme valeur. La mthode lmentaire de compactage dune grille de cellules consiste balayer cette grille ligne par ligne, et pour chaque ligne de ne conserver que les squences de cellules de mme valeur. La mthode peut tre amliore en testant plusieurs orientations de balayage, car les donnes peuvent tre agences suivant une direction privilgie qui produira un compactage beaucoup plus performant. La qualit du compactage dpend bien sr de la complexit de linformation graphique, savoir le nombre de composantes connexes. De nombreux autres algorithmes de compactage par compression ont t dvelopps ces dernires annes pour amliorer le volume de stockage des images. On peut galement compacter les donnes raster en utilisant des mthodes arborescentes par subdivision successive de lespace (quadtree) [ABE 84] [SAM 80], ou en essayant de reprsenter le contour de mailles identiques (mthodes ensemblistes) [CAP 84] [COO 67].

3.6. Les sources d'information gographique : nature et validit 3.6.1. Les moyens dacquisition pour les donnes localises A la base de toute donne gographique ou de toute schmatisation cartographique existent des moyens dacquisition. Rappelons trs rapidement : - le relev de terrain ou lev topographique. Le lev topographique permet de mesurer la position dun point sur la surface terrestre. Les mesures sont effectues soit par triangulation, soit grce des systmes de positionnement par satellite. Le relev de terrain permet dassocier des caractristiques un lieu de la surface terrestre ; - enqutes et recensements, registres administratifs, tat civil, archives. Les enqutes et recensements sont une source de donnes trs importante. Bien sr, ces donnes ne sont pas objectives et relvent dj dune modlisation. Le schma en est dailleurs toujours accessible, il est constitu de lensemble des attributs. Il est nanmoins toujours important de connatre les contraintes et limites de validit de ce type dinformation ; - photographies ariennes et tldtection spatiale. Les images fournies par des capteurs ariens ou spatiaux sont une source importante dinformation. Linterprtation initiale est en quelle que sorte due aux limites techniques du capteur employ. De nombreux traitements spcifiques permettent de driver dautres informations partir des donnes brutes.

86

Chapitre 3

3.6.2. La validit de linformation L'information gographique est extraordinairement riche et varie, tant par sa nature que par sa prcision et sa validit gographique. Les sources sont innombrables et l'nergie et l'ingniosit dployes pour dnicher l'information recherche mrite d'tre souligne. On trouvera des gographes passionns par leurs sujets dans tous les domaines : archives, journaux, cadastre, services techniques, mairies, syndicats, entreprises, enqutes, recensements, photographies et images ariennes, relevs de terrain. L'information, sa prcision, sa validit smantique, spatiale et temporelle est fonction de son metteur, donc de sa source. Quel que soit le protocole adopt pour construire ou recueillir l'information dont on a besoin, le rsultat final prend toujours la forme d'une liste d'objets dcrits par leur quantit ou leur qualit. Cette liste prend diverses formes ; il peut s'agir d'enqutes, de recensements, de notes d'archives, d'chantillons, de mesures... En fonction du but recherch, des difficults inhrentes toute description et d'un certain nombre de difficults techniques, on emploiera soit des mthodes visant l'exhaustivit, soit des mthodes par sondage. En fait, la mesure exhaustive, parfaite et indiscutable, sera toujours un leurre. Il reste que c'est encore le devoir et la charge principale de travail de nombreuses disciplines et de nombreux services techniques que de tendre cette perfection . Dans de nombreux cas, la question d'une mesure exhaustive ne se pose mme pas ds lors qu'il est matriellement impossible de prtendre parvenir un rsultat satisfaisant et fiable par cette voie. La mesure du dbit du Nil ou du Rhne, phnomne continu par excellence, restera toujours une mesure approche par des mthodes de mesures ponctuelles. Dans la pratique, l'laboration de l'information procde le plus souvent de mesures ou d'observations par sondage: stations mtorologiques ou hydrologiques, profils pdologiques, ballons, sondes, carottes, enqutes d'opinion, etc. Parce que l'information est trs souvent insuffisante par rapport l'objectif qu'on se fixe, il est essentiel de pouvoir accder une information dont la forme et la prsentation permettent d'tablir les relations que nous recherchons ou dont nous supposons l'existence. Cette exigence suppose d'avoir accs une information aussi dtaille et aussi dsagrge que possible. C'est pourquoi une information brute est toujours plus riche de sens que sa prsentation agrge, et donc, schmatise.

Modliser 87 3.7. Structure gomtrique des objets dans le systme SAVANE Nous allons prsenter dans ce paragraphe comment les objets gographiques sont reprsents dans le systme SAVANE. 3.7.1. Le modle gomtrique Le systme SAVANE utilise le modle gomtrique pour reprsenter les objets localiss. On utilise donc la classification habituelle en zone, ligne, point. La localisation dun point utilise directement les coordonnes du point. Les lignes et les zones sont dcrites par des arcs. La topologie, cest--dire les relations entre les arcs pour former un objet gomtrique, est cre lors de la saisie des objets par le module SAVEDIT, que nous verrons en dtail au chapitre 7. Les donnes provenant de la tldtection (photographie arienne scanne, tldtection spatiale) peuvent tre assimiles des zones, mais elles se prsentent toujours comme des images raster, car la forme de ces zones est lmentaire et identique pour tous les objets. La reprsentation interne de ce type de donnes est donc diffrente des autres types de zones : nous lui consacrerons un chapitre spcial (chapitre 6). Le systme SAVANE gre non pas des objets isols, mais des collections dobjets. La structure de reprsentation gomtrique des objets est construite de manire amliorer la gestion de ces collections, et nous la verrons en dtail au chapitre 5. Nanmoins, nous pouvons dj en donner une description rapide. Les objets sont regroups en collections suivant une schmatisation qui correspond la fois la modlisation du monde rel en entits et au modle de donnes impos par le systme de gestion des collections, savoir le modle relationnel. Quatre types de collections peuvent tre dfinies, suivant la localisation des objets : les trois types gomtriques classiques (zone, ligne, point), et le type pixel, dont la reprsentation interne diffre du type zone. La reprsentation interne de la localisation nutilise que le premier niveau de description pour les points (leurs coordonnes). Elle relie les objets lignes avec un arc, sans utiliser de relation sur les nuds. Nous avons en effet privilgi la simplicit de la structure : les relations entre lments seront soit vrifies lors de la constitution des collections (par des contraintes dintgrit), soit recalcules par un traitement procdural. Ainsi, la reprsentation des zones utilise des arcs (premier niveau de description), et les relations des arcs avec les zones dont ils sont frontires (second niveau). Cette description est suffisante pour retrouver le contour dune zone, connatre les zones incluses, les trous, les relations dadjacence entre zones, entre arcs, etc. Mais ces proprits ne sont pas inscrites dans la structure de reprsentation, comme cest le

88

Chapitre 3

cas pour dautres systmes, qui maintiennent plus dinformation (le sens des arcs par exemple). Elles peuvent toutes tre retrouves par des procdures (nous en donnerons quelques exemples dans la suite), condition que la validit topologique de lensemble soit assure : le respect des contraintes dintgrit est essentiel pour une bonne utilisation de ce modle de reprsentation. 3.7.2. La classe CArc Nous pouvons ds prsent prsenter la classe CArc (A.2.2.1.) qui encapsule donnes et mthodes propres aux arcs gomtriques, ainsi quun certain nombre dalgorithmes graphiques utiliss pour rsoudre des problmes gomtriques : intersections darcs, distance dun point un arc, intersection ou union de zones, chanage des arcs pour passer dune reprsentation interne par frontires une reprsentation interne par boucles, appartenance dun point une zone, etc. (A.2.2.). Les coordonnes sont lues et stockes dans un tableau (maximum 2500 points pour un arc). La structure comprend le plus petit rectangle englobant larc, et des mthodes pour le calculer (CalculBBox()). Ce rectangle permet damliorer considrablement la vitesse de certains algorithmes utilisant des arcs, en liminant les arcs qui ne peuvent, de par leur position, tre candidats la proprit choisie. Les procdures de calcul dintersection darcs ou de distance dun point un arc (A.2.2.1, A.2.2.5) interviennent dans de nombreuses fonctions. Toutes ces procdures utilisent les segments des arcs, en cartant les segments qui ne peuvent rpondre la question. Comparer deux arcs pour trouver les intersections peut tre long : pour amliorer les performances, il est utile de trier les segments de chaque arc suivant lun des axes. 3.7.3. Les changements de reprsentation interne Pour les objets de type zone, il est parfois ncessaire de changer de reprsentation interne, et de passer de la reprsentation par arcs frontire la reprsentation par contour ferm. Le chanage des arcs pour obtenir des courbes fermes est simple, dautant plus que lon suppose la topologie sans faille (pas de darc dit pendant , cest--dire sans un autre arc qui sy rattache). Pour crer le contour dune zone, il suffit de slectionner les arcs de la zone, puis de chaner les arcs les uns aux autres. Bien sr, une attention particulire doit tre apporte aux bouts multiples (plusieurs arcs se joignent sur un mme bout). Une zone peut tre constitue de plusieurs taches , chaque tache pouvant avoir des trous . On retrouve ici la notion de polygone employe dans la reprsentation interne de

Modliser 89 nombreux systmes. Le polygone ne correspond en fait qu la notion de courbe ferme. Le changement de reprsentation peut parfois se limiter la cration de courbes fermes, sans se proccuper du problme de lintrieur de la zone. Par exemple, le langage PostScript utilise ce modle et permet de dessiner les zones sans problme, car il prend lui-mme en charge la dtermination des zones incluses partir du contour en courbes fermes. Dautres systmes sont plus exigeants. Ainsi, le format Shapefile dARCVIEW impose une description des zones en courbes fermes avec indication de lintrieur de la zone. Le sens des arcs est utilis cet effet ( gauche lintrieur, droite lextrieur). Le changement de reprsentation doit donc reconstituer la zone en donnant un sens chaque arc. Voici les principes de la mthode employe dans le systme SAVANE : - pour chaque zone, chanage des arcs pour former des taches fermes (polygones) ; - On cherche ensuite lordre des taches si la zone est forme de plusieurs polygones. Pour les zones formes de deux polygones, on calcule la surface de chaque tache puis, sil y a possibilit dintersection entre les deux taches, on teste lappartenance dun point de la plus petite tache dans la plus grande, pour tester sil y a inclusion de lune dans lautre. Le point intrieur est trouv en cherchant le centre du premier triangle form de trois points du contour et inclus dans le polygone . Pour les zones formes de plus de deux polygones, le traitement est un peu plus complexe : on calcule la surface de toutes les taches, on trie ces surfaces, et, en partant de la plus petite tache, on cherche le premier incluant, ceci pour chaque tache. Enfin, on change le sens des taches en partant de la plus grande, et en descendant dans le chanage ainsi construit. Pour ces procdures, nous avons construit deux classes, lune pour reprsenter les zones (CZone, A.2.2.6.), lautre pour reprsenter les taches (CTache, A.2.2.6). 3.8. Conclusion Ce chapitre prsente les bases conceptuelles de la schmatisation du monde rel utilise dans le systme SAVANE. Il est, ce titre, fondamental, car cette schmatisation dtermine la fois la structure logique et la structure interne du SIG. Elle est galement dterminante sur les fonctionnalits du SIG en terme de programme dapplication : au-del de la modlisation du monde rel et de la gestion de donnes qui en dcoule, lefficacit conceptuelle des fonctionnalits du SIG dpend directement de la manire dont le monde rel a t modlis et schmatis pour tre manipul par le systme dinformation. Les mthodes dexploitation qui

90

Chapitre 3

utilisent la localisation des objets doivent prendre en compte les limitations dues cette schmatisation. La modlisation utilise dans le systme SAVANE (modlisation gomtrique en zone, ligne, point, pixel) privilgie la simplicit du modle sur la simplicit des algorithmes de traitements ultrieurs. Ce modle est simple, dans sa schmatisation du rel comme dans sa structure interne. Il ne peut tre utilis efficacement qu condition de vrifier certaines contraintes dintgrit, auxquelles nous consacrerons le chapitre 7.

Modliser 91

Bibliographie

[ABE 84] ABEL D.J., A B+-Tree Structure for Quadtrees, Computer Vision, Graphics, and Image Processing, 1984, vol. 27, n 1, p. 19-31 [AOK 79] AOKI M., Rectangular region coding for image data compression, Pattern Recognition, 1979, vol. 11, p. 297-312 [AMI 71] AMIDON E.L. AND ATKIN G.S., Algorithmic selection of the best method for compressing map data string : Communications, ACM, 1971, vol. 14, n 12, p. 769-774 [BEK 92] BEKKER J.H., Semantic Data Modeling, Prentice-Hall, 1992, New-York [BOU 81], BOURSIER P., Reprsentation compacte des cartes dans les systmes dinformation gographique, Thse de 3-ime cycle, Universit Paris VI, 1981, [BOU 82] BOURSIER P. ET SCHOLL M., Performance Analysis of compaction techniques for map representation in geographic data cases, Computer and Graphics, 1982, vol. 6, p. 73-81 [BRE 65] BRESENHAM J.E., Algorithm for computer control of a digital plotter, IBM System Journal, 1965, vol. 14, n 1, p.44-50 [CAP 84] CAPSON D.W., An improved algorithm for the sequential extraction of boundaries from a raster scan, Computer Vision, Graphics, and Image Processing, 1984, vol. 28, n1, p. 109-125 [COO 67] COOK B.G., A Computer Representation of plane Region Boundaries, Autralian Computer Journal, 1967, vol. 1, n1, p.44-50 [DAV 91] DAVID B., Modlisation, reprsentation et gestion dinformation gographique, un approche en relationnel tendu. Thse de doctorat, Universit Paris VI, 1991 [DIM 70] DIME, Technical Description of the DIME System, US Bureau of Census : Census use study, the DIME Geocoding System, Report n4, 1970, Washington DC, p.25-30

92

Chapitre 3

[EGE 89] EGENHOFER M.J., A formal definition of binary topological relationships, Proceedings of the third International Conference FODO, Paris, Lecture Notes in Computer Science 367, 1989, Sprinter Verlag, Berlin, p.457-472 [EGE 90] EGENHOFER M.J. AND HERRING J.R., A mathematical framework for the definition of topological relationships, Proceedings of the 4th International symposium on Spatial Data Handling, 1990, Zurich p. 803-813 [FRE 61] FREEMAN H., On the Encoding of arbitrary geometric Configuration, Inst. Radio Engineers Trans. Elec. Computers, 1961, vol. EG 10, p. 260-268 [FRE 75] FREEMAN J., The modelling of spatial relations, Computer Graphics and Image Processing, 1975, vol. 4, p. 156-171 [GUP 95] GUPPTILL S.C. Science, 1995
AND

MORISSON J.L., Elements of Spatial Data Quality, Elsevier

[MAT 84] MATSUYAMA T., LE VIET H., NAGAO M., A File Organisation for Geographic Information System based on Spatial Proximity, Computer Vision, Graphics, and Image Processing, 1984, vol. 26, n3, p.303-318 [MER 73] MERRILL R.D., Representation of contours and region for efficient computer search, Communication ACM, 1973, vol. 16, n2, p. 69-82 [ROS 80] ROSENFELD A. AND SAMET H., Tree structure for region representation, Aangeenburg, Autocarto 4, 1980, vol. 1, p. 108-118 [ROU 91] ROUET P., Les donnes dans les systmes dinformation Gographique. Trait des nouvelles technologies, srie Gomatique, 1991, Herms, Paris [SAM 80] SAMET H., Region Representation : quadtrees from boundaries codes, Communication ACM, 1980, vol. 23, n3,p. 163-170 [SAM 90] SAMET H., Applications of Spatial Data Structures, Addison-Wesley, 1990 [SCH 89] SCHOLL M., VOISARD A., Thematic map Modeling, Int. Symposium on Large Spatial Databases, 1989, LNCS n409, p. 167-192 [SCH 96] SCHOLL M., VOISARD A., PELOUX J.P., RAYNAL L., RIGAUX P., SGBD Gographiques, Spcificits, Thomson Publishing, 1996, Paris [SHA 78] SHAMOS M., Computational Geometry, PHD, 1978, Yale University [SHL 88] SHLAER S, MELLOR S-J., Objet Oriented System Analysis : Modelling the World in Data, Englewood Cliffs, 1988, Prentice-Hall [VOI 92] VOISARD A., Bases de donnes gographiques : du modle de donnes linterface utilisateur. Thse de doctorat, Universit dOrsay, 1992 [WOR 95] WORBOYS M.F., GIS, a Computer Perspective, 1995, Taylor&Francis

Modliser 93

Chapitre 4

Mesurer la localisation

Dans ce chapitre, nous allons dcrire les principes de mesure et de reprsentation de la localisation dun lieu, du globe terrestre la carte. La prcision de la mesure est essentielle car la notion de prcision est omniprsente dans la dfinition conceptuelle dun objet gographique. 4.1. Introduction Pour localiser un point sur la Terre, pour mesurer un lment ou un morceau de la surface du globe terrestre et pour le reprsenter sur une feuille ou un cran (dans tous les cas sur une surface plane), nous sommes confronts deux problmes distincts : dune part connatre et mesurer la forme de la Terre pour pouvoir facilement localiser un point sa surface, et dautre part reprsenter cette surface curviligne sur une surface plane. La godsie est la discipline dont lobjet est la mesure de la forme de la Terre. La godsie utilise presque constamment la notion de verticale, et donc ncessite la connaissance de la gravit : on ne peut parler de godsie sans introduire le gode gravimtrique terrestre, surface quipotentielle pour la gravit, et nous parlerons donc galement de gravimtrie (discipline qui traite de la gravit terrestre). Puisque ces deux surfaces, Terre et gode, sont complexes, il faut dfinir une surface mathmatique de rfrence dont on connat lquation (ce sera en loccurrence un ellipsode de rvolution) et se rapprochant au mieux de lune ou de lautre pour pouvoir dcrire facilement une position sur le globe terrestre et la reprsenter sur une feuille, par une opration de projection cartographique. La projection cartographique elle-mme va introduire des dformations, mais elles seront connues et quantifiables puisque lon est ramen ici un problme de calcul et non plus de mesure.

96

Chapitre 4

Toutes les mthodes de positionnement et de mesure en godsie ont t profondment modifies par lavnement des systmes de positionnement par satellite. Paradoxalement, avec la possibilit actuelle de mesurer facilement et avec grande prcision toute position dans les trois dimensions, grce aux systmes de positionnement globaux de type GPS, il devient ncessaire de connatre les principes gnraux de la godsie et de la gravimtrie pour estimer la prcision des mesures. Les mthodes de projection gographique nont pas t modifies par cette rvolution technologique, mais elles utilisent les rsultats de la godsie. De plus, les moyens de calcul offerts par les ordinateurs en banalisent lutilisation. Dans ce chapitre, nous aborderons donc les principes de la mesure de la forme de la Terre, de la mesure dun lieu, puis les principes de la reprsentation de ces lieux sur une surface plane. 4.2. Forme et mesure de la Terre : godsie et gravimtrie 4.2.1. Mesurer la forme de la Terre : la godsie On sait depuis lantiquit que la Terre est un corps peu prs sphrique, tournant sur lui-mme et tournant autour du soleil, avec sa surface quelques rugosits peine sensibles par rapport au rayon. Bien sr, on ne peut se contenter dune telle approximation. La surface relle de la Terre comporte des valles et des montagnes, des creux et des bosses, que lon ne connat pas et que lon essaye de mesurer. Les valles et les montagnes sont nanmoins ngligeables par rapport la taille de la Terre. Le problme majeur est donc de trouver une surface de forme gomtrique simple, reprsentant la forme globale de la Terre, et qui permette le plus simplement possible de situer un lieu de la surface de la Terre dans deux dimensions par sa projection orthogonale sur cette surface (fig 4.1). On pourra exprimer ensuite la troisime dimension (laltitude par rapport cette surface) sur la normale au lieu projet.
z P z P b O y P h

P h

O x

fig. 4.1 : coordonnes godsiques, et projection dun point sur un ellipsode de rvolution

Mesurer la localisation 97 On chercha donc depuis trs longtemps dcrire et mesurer la surface du globe terrestre, pour en trouver la forme gomtrique la plus proche [LEV 88]. Les mesures sont difficiles, non seulement parce que lon cherche mesurer un corps sur lequel on se trouve, mais aussi parce que ce corps est entour dune atmosphre qui trouble les mesures optiques quand on vise les toiles. Ces toiles, utilises depuis lantiquit, sont censes tre des corps immobiles : elles sont trop loignes de la Terre pour que leurs mouvements propres soient sensibles - le rapport [mouvements propres/distance par rapport au soleil] est ngligeable -, et aient une quelconque influence par rapport au mouvement de la Terre. Elles sont donc considres comme des corps fixes et permettent de dfinir des repres absolus. On se heurtait, avant lavnement des satellites artificiels, un problme majeur : ne connaissant pas la forme gomtrique exacte de la Terre (puisque cest justement ce que lon cherche), on ne pouvait effectuer de mesure absolue lie cette forme. Le seul moyen tait donc, partir dun point de rfrence, de mesurer de proche en proche le lieu dautres points. En thorie, la mesure de la distance entre deux points et de la direction par rapport aux toiles fixes permet, partir dun point connu, de dcrire nimporte quel autre point du globe par ses trois coordonnes dans un repre fixe li aux toiles. Mais voil, latmosphre fausse les mesures optiques car la prsence dair courbe les rayons lumineux (par rfraction), et ce phnomne est quasiment impossible mesurer car il dpend des conditions mtorologiques le long du trajet suivi par la lumire, conditions qui changent le long du parcours et que lon ne peut prvoir dans le temps. Cette mthode directe ntant pas utilisable, il fut ncessaire de trouver autre chose. Tout naturellement, une direction simpose en chaque point du globe : cest la verticale, toujours mesurable, qui peut facilement tre mise en vidence par un fil plomb ou un niveau bulle, ces objets matrialisant la direction du champ de force li la gravitation universelle. Si lon dfinit (ou plutt si lon connat) une surface mathmatique simple dont les normales se confondent avec les verticales au globe terrestre, on peut projeter chaque point du globe sur cette surface de faon biunivoque. Si lon peut situer sur le globe terrestre une verticale, on peut alors situer le point correspondant sur cette surface : le problme est rsolu pour deux des trois coordonnes. De plus, si lon arrive mesurer sur laxe des verticales les diffrences de niveaux entre deux points du globe (en suivant la courbure de la surface de rfrence), on a la coordonne manquante, et on peut donc dcrire compltement la position dun point par rapport un autre. De proche en proche, on peut ainsi connatre la forme gomtrique relle de la surface terrestre. Mais voil, on ne connat pas non plus cette surface le gode gravitationnel-, qui sest avre complexe car dpendant de multiples facteurs, comme par exemple de la position interne des masses dans la Terre [GEO ] [CAZ 94]. La verticale est la normale cette surface de forme complexe. En tant sur un point du globe terrestre,

98

Chapitre 4

on na donc pas de moyen simple de trouver, par projection orthogonale, le point correspondant sur une surface mathmatique simple servant de rfrence et approchant au mieux la surface relle. On a un moyen simple de trouver sa position sur une autre surface, le gode, mais malheureusement on ne connat pas cette surface a priori, puisquelle dpend de la valeur de la gravit, qui nest pas constante sur le globe. La triangulation est une mthode simple pour trouver, partir de deux points, la mesure du lieu de la verticale un troisime. Application directe de la trigonomtrie, elle a t invente par Snellius au XVIIe sicle et a servi de base toutes les mesures godsiques, de la mesure de larc de mridien par Picard et Cassini au XVIIe sicle jusqu lavnement des satellites... On se sert en chaque point de la verticale relle, alors que les mesures dangles devraient tre effectues en utilisant la normale la surface de rfrence pour projeter le point sur cette surface. Mais si les diffrences de direction entre ces deux verticales sont suffisamment faibles, les corrections apporter aux mesures sont ngligeables par rapport la prcision de ces mesures.

fig. 4.2 : un thodolite et son utilisation en godsie Supposons connue la position de deux points (un clocher et un chteau deau). On a plac une mire sur le point dont on cherche la position. On va sur le chteau deau, et laide dun thodolite (lunette tournant autour de la verticale et permettant de mesurer des angles, invente par Galile), on vise le clocher, puis la mire; on rpte lopration partir du clocher, en visant le chteau deau puis la mire (fig. 4.2). On dfinit ainsi deux plans, lun passant par la verticale au chteau deau et par la mire, lautre passant par la verticale au clocher et par la mire. Lintersection de ces deux plans donne donc une droite passant par la mire. Lintersection de cette droite avec la surface de rfrence donne le point recherch sur cette surface. La mesure est assez simple puisquelle ne fait intervenir que les angles des

Mesurer la localisation 99
vises, et la position des deux points dorigine, le chteau deau et le clocher, sur la surface de rfrence. Connaissant la position de la mire, on peut rpter lopration en utilisant ce nouveau point et le clocher pour dterminer la position dun quatrime point, et de proche en proche, on dfinit sur la surface de rfrence une triangulation dont la position de chaque point est connue. La prcision de la mesure de la position des deux premiers points est fondamentale puisquelle dtermine la prcision de toutes les mesures qui suivent.

Le nivellement cherche quant lui mesurer les diffrences daltitude entre deux points, mais le problme est plus complexe quil ny parat : utilisant dans toutes les mesures la notion dhorizontale, le nivellement ne permet que de mesurer la cote dun point au-dessus du gode, surface quipotentielle pour la gravit. Pour rester indpendant du relief lui-mme (ce que lon cherche mesurer), on calcule des diffrences de travail partir des diffrences de niveau. En effet, la mesure par nivellement met en vidence deux surfaces quipotentielles pour la gravit, et la distance (suivant la normale) entre ces deux surfaces nest pas constante : les mesures de niveaux dpendent donc du chemin suivi. Par contre, le travail effectu par la chute dune masse dune surface lautre est le mme, quel que soit lendroit (par dfinition mme des deux surfaces). Il faut donc connatre, en chaque point mesur, la valeur de la gravit, appele cote orthomtrique, altitude du point audessus dune surface quipotentielle de rfrence pour la gravit, le gode.

Terre P Ellipsode Gode

Pour mesurer la diffrence daltitude entre deux points loigns, on est oblig deffectuer des mesures successives entre points plus rapprochs pour viter les problmes de rfraction. Entre deux points rapprochs (moins de cent mtres), on lit directement les dnivels grce deux mires verticales gradues, chacune place en un des deux points. La lecture se fait par une lunette dont lhorizontalit est assure par un niveau plac gale distance des deux mires. On chemine ainsi le long dun parcours. Bien sr, la mesure finale doit tre indpendante du chemin suivi : on ramne donc la valeur du dnivel une diffrence de travail (produit du dnivel par la valeur de la gravit) en mesurant la cote orthomtrique en chaque point du cheminement.

On a donc dplac et largi le problme : il sagit de trouver une surface mathmatique simple approchant au mieux la forme de la Terre et dont les normales concident au mieux avec la direction de la pesanteur la surface terrestre, et il

100

Chapitre 4

sagit galement de dterminer une surface approchant au mieux une surface quipotentielle pour la pesanteur (le gode terrestre). On a maintenant deux approches pour rsoudre le problme de la mesure de la surface terrestre, deux approches intimement lies et complmentaires : lapproche gomtrique et lapproche gravimtrique. 4.2.2. Lapproche gomtrique La premire approche est purement gomtrique : ds le XVIIIe sicle, des mesures la surface de la Terre ont permis de choisir lellipsode de rvolution aplati aux ples comme une surface mathmatique rpondant peu prs la question de la forme de la Terre.
On a cherch depuis lantiquit mesurer le rayon de la Terre (la premire mesure connue est due Erathostne vers 250 avant J.C. en gypte), mais cest au XVIIe sicle que les avances se prcipitent. De la mesure du rayon, on est pass la mesure de larc intercept la surface de la Terre par un angle au centre de un degr, ce qui permet bien sr de calculer le rayon correspondant. La Terre tait alors considre comme un solide de rvolution tournant autour de laxe des ples, et assimile une sphre. En 1617, Snellius, abb hollandais, invente la triangulation et mesure un arc de mridien. Son rsultat, 107 km par degr, est mauvais. En 1669, un autre abb, Picard, ralise un thodolite (grce une lunette de Galile) et obtient une valeur excellente pour la mesure du degr quil calcule par triangulation prs de Paris (111,212 km, soit une erreur de 1 pour mille). Mais en 1672, on constate quune horloge bien rgle Paris retarde de 2 mn 30 par jour Cayenne. Huygens et surtout Newton, qui avait dj labor sa loi de gravitation mais qui ne lavait pas encore publie, attribuent ce retard une diminution de lattraction terrestre, et donc une augmentation de la force centrifuge : la Terre ne doit pas tre une sphre mais un ellipsode de rvolution aplati aux ples. Les astronomes Cassini (pre puis fils) avaient t chargs par la France de raliser une carte prcise, et ils obtinrent des rsultats contraires aux intuitions de Newton. Louis XV ordonna donc deux mesures de larc de mridien : lune prs du ple (expdition de Clairaut et Maupertuis en Laponie), lautre prs de lquateur (expdition de La Condamine et Bouguer en quateur, alors le Prou). Les rsultats confirmrent bien sr la thse de Newton. A partir de cette date, de nombreuses mesures ont t effectues et de nombreux ellipsodes de rvolution ont t proposs pour approcher au mieux la forme de la Terre. Le dernier date dune dizaine dannes.

Lellipsode de rvolution est une surface mathmatique simple. Elle est caractrise dans un repre cartsien par la position de son centre, par son grand cot (habituellement dsign par a), et par son petit cot (habituellement dsign par b). Souvent, un ellipsode est caractris par son grand cot et par son aplatissement (f=(a-b)/a) ou par le carr de son excentricit (e2=(a2-b2)/a2).

Mesurer la localisation 101 Tout point dun ellipsode de rvolution peut tre caractris par deux des coordonnes sphriques (la longitude et la colatitude), la troisime coordonne tant donne implicitement par lappartenance du point lellipsode. Profitons de ce paragraphe pour dfinir avec exactitude la terminologie employe pour positionner un point dans lespace. Le repre naturel est un repre cartsien, de centre O et daxes orthonorms i,j,k. Tout point de lespace peut tre dfini par ses coordonnes cartsiennes dans ce repre, habituellement nommes x,y,z. Le point peut galement tre dfini par ses coordonnes sphriques : (angle iOP, o P reprsente la projection orthogonale du point P dans le plan (i,j)), (angle kOP), R (distance OP). Les coordonnes godsiques, ou gographiques, ne sont autres que les coordonnes sphriques, en supposant que lellipsode de rvolution qui reprsente la Terre soit centr sur lorigine de ce repre. Le rayon est omis, puisque le point se trouve par dfinition sur lellipsode : on peut donc le calculer en connaissant la forme de lellipsode. La longitude correspond , la colatitude . Le nord gomtrique correspond au point de coordonnes (0,0) sur lellipsode. Le nord magntique correspond au champ magntique et non au champ gravitationnel. Le nord indiqu par une boussole nest donc pas le nord gographique. La dviation est fonction du champ magntique, elle varie en fonction du temps et du lieu. En godsie classique, on opre en fait de faon inverse : la forme de lellipsode de rfrence est dtermine par la mesure godsique, la position du centre de lellipsode par rapport au gode est dtermine par une condition de tangence en un point (le point fondamental). Une fois lellipsode ainsi plac, on dfinit un repre cartsien : lorigine du repre est le centre de lellipsode, laxe des z passe par les ples de lellipsode, laxe des x est plac de faon fixer la longitude dun point donn (par exemple, 0 pour Greenwich ou Paris). De nombreux ellipsodes de rvolution ont t dfinis pour approcher au mieux la forme de la Terre une latitude donne. Ainsi, chaque service godsique a dfini une forme dellipsode se rapprochant au mieux de la courbure de la Terre la latitude de son pays, pour minimiser les dformations entre gode et ellipsode et pouvoir utiliser la verticale sans induire trop derreur. Une fois la forme de lellipsode dtermine, encore faut-il positionner cette surface par rapport la Terre. Quel que soit lellipsode de rvolution considr, des diffrences existent entre la normale au gode (cest--dire la verticale au globe terrestre) et la normale lellipsode, sauf peut-tre en un point. Comme toute

102

Chapitre 4

triangulation part dun point fondamental dont la position est calcule avec beaucoup de prcision, chaque service godsique a choisi de positionner lellipsode en le rapprochant au mieux de la verticale corrige au point fondamental (verticale observe corrige de linfluence des mouvements de la Terre et de lattraction des autres astres) en imposant donc quen ce point, ellipsode et gode soient tangents au mme plan. La position de lellipsode par rapport la Terre est dtermin par cette condition. Lensemble des paramtres - forme et position de lellipsode - est appel datum. Toute mesure dun point sur la Terre (donne par exemple en longitude-latitude) dpend donc du datum auquel elle se rapporte. Nous verrons plus loin comment passer dun datum un autre. De nombreux ellipsodes ont t ainsi dfinis. Par exemple, la triangulation qui couvre la France entire a t rapporte lellipsode de Clarke 1880 (a=6 378 249 m, (a-b)/a =1/293,5) avec comme point fondamental la croix du Panthon Paris. LAssociation Internationale de Godsie a dfini en 1909 puis en 1924 un ellipsode particulier pour toutes les tudes internationales, appel pour cela ellipsode international (Hayford, 1909 ou 1924 : a=6 378 388, (a-b)/a =1/297). Un ellipsode de rvolution est caractris par son grand cot -a- et son petit cot -b-. En godsie, on considre plutt le grand cot et laplatissement (a-b/a) ou le carr de lexcentricit (e2=(a2-b2)/a2). Nous verrons plus loin comment les problmes lis la bonne projection dun ellipsode sur un plan ont influenc le dveloppement des mathmatiques dans beaucoup de ses domaines modernes (calcul diffrentiel, gomtrie analytique). Voici les ellipsodes les plus couramment utiliss [MAG 97] :
Nom Airy 1830 Australian National Bessel 1841 (Ethiopie, Indonesie, Japon, Core) Bessel 1841 (Namibie) Clarke 1866 Clarke 1880 Everest Brunei, Malaisie orientale (Sabah, Sarawak) Everest India 1830 Everest India 1956 Everest Malaisie occidentale, Singapour 6377276.345 6377301.243 6377304.063 1/300.8017 1/300.8017 1/300.8017 a (mtres) 6377563.396 6378160 6377397.155 6377483.865 6378206.4 6378249.145 6377298.556 Aplatissement (a-b)/a 1/299.3249646 1/298.25 1/299.1528128 1/299.1528128 1/294.9786982 1/293.465 1/300.8017

Mesurer la localisation 103

Everest, Malaisie orientale 1969 Geodetic Reference System 1980 Helmert 1906 Hough 1960 International 1924 Krassowsky 1940 Modified Airy Modified Ficher 1960 South American 1969 WGS 72 WGS 84 6377295.664 6378137 6378200 6378270 6378388 6378245 6377340.189 6378155 6378160 6378135 6378137 1/300.8017 1/298.257222101 1/298.3 1/297 1/297 1/298.3 1/299.3249646 1/298.3 1/298.25 1/298.26 1/298.257223563

Les ellipsodes de rvolution utiliss en pratique nont malheureusement pas le mme centre, puisque leur position est dfinie par un point de tangence entre le gode et lellipsode (le point fondamental). Si lon ne connat pas la position relative dun point de tangence par rapport un autre, on ne pourra passer dun systme godsique un autre. Pour comparer la localisation de deux points, il faut que cette localisation ait t mesure dans le mme datum. Des coordonnes dun point de la Terre exprimes en longitude et latitude ne sont donc pas absolues : elles dpendent du datum utilis. Linfluence du datum peut atteindre plusieurs secondes darc, soit plusieurs centaines de mtres aprs projection dans un plan. La ncessit davoir un systme global est rapidement apparue pour les applications intercontinentales, comme la balistique civile ou militaire. Plusieurs datum globaux ont ainsi t dfinis (WGS 60, WGS 66, WGS 72, WGS 84), mais les positions ne peuvent tre dtermines dans ces datum que par calcul (changement de datum partir dune position donne dans un datum local) ou positionnement global par GPS. Nous verrons plus loin mthodes et programmes pour changer de datum. Notons galement que lon parle de datum vertical car, si la condition de tangence est impose, laltitude du point de tangence nest pas fixe, et lorigine sur laxe des z est choisie par chaque service cartographique. Ainsi, on a souvent une diffrence dans le calcul de laltitude entre cartographie terrestre et cartographie marine. Avant lapparition des satellites artificiels et des mthodes de positionnement global, il tait difficile de relier deux triangulations ne partant pas du mme point fondamental si ces deux triangulations ne pouvaient se rejoindre. Cest bien sr le cas des les et des continents, puisque lon ne peut trianguler sur la mer quavec des techniques particulires. Pour cette raison, la cartographie des les a toujours t difficile relier la cartographie des continents, car chaque le loigne avait besoin dun datum propre. Les problmes de ce type ont t rsolus grce aux satellites artificiels et la gravimtrie qui permet davoir une approche globale.

104

Chapitre 4

Chaque point dun ellipsode de rvolution (et donc le point de la surface terrestre auquel il correspond) peut tre repr par rapport au centre de lellipsode par des coordonnes sphriques : la longitude et la latitude. Lorigine des longitudes est dtermine de faon arbitraire : on prend le plus souvent le mridien passant par la projection sur lellipsode de la ville de Greenwich (Angleterre), quelquefois celui passant par celle de Paris (Observatoire de MontSouris). Lorigine des colatitudes est le ple nord. Le plus souvent, on parle de latitude nord ou sud, en prenant comme origine lquateur (ligne de colatitude 90), et de longitude est ou ouest, suivant le sens dans lequel on tourne, en mettant le nord en haut. Toutes ces conventions nous viennent bien sr de lantiquit. Lunit est le degr (2/360) ou le grade (2/400). La diffrence entre le mridien de Greenwich et celui de Paris est de 2 20 14,02500. 4.2.3. Lapproche gophysique Lautre approche, pour dterminer la forme de lellipsode, est gophysique. Elle cherche dterminer la forme du gode et en dduire directement la forme de lellipsode. Elle fait donc appel ltude du champ de pesanteur la surface du globe. On dispose donc ici dun outillage mathmatique beaucoup plus important qui laisse esprer une rsolution thorique globale du problme : dterminer lquation complte de la surface quipotentielle recherche, le gode. Mais comme on le verra, subsiste une certaine ambigut : la mesure de laltitude au-dessus de lellipsode ncessite la connaissance du gode, et la dtermination exacte du gode ne peut se faire quavec la connaissance du relief. Mais heureusement, les deux disciplines se compltent car les chelles de prcision requises ne sont pas du mme ordre dans chaque domaine, et les avances de lune servent amliorer les mesures de lautre. Le dveloppement des techniques (notamment spatiales) a considrablement enrichi les possibilits de mesures, en arrachant enfin le godsien de la surface quil doit mesurer. 4.2.3.1. Gravit et gode. On ne peut donc tablir de mesure de la forme de la surface terrestre sans connatre la gravit. Grce la loi dattraction universelle, on sait que la force de pesanteur drive dune fonction de force, et donc quil existe une famille de surfaces (toutes homothtiques par rapport au centre de gravit des masses) qui sont perpendiculaires en tous leurs points la direction de la pesanteur. Ces surfaces sont appeles quipotentielles (La valeur de la gravit nest pas la mme en tout point dune surface quipotentielle : ce nest vrai que pour le potentiel dont elle drive). On montre galement que la surface dun fluide homogne en quilibre concide avec une quipotentielle de pesanteur. Le niveau moyen des mers et ocans suit donc une telle quipotentielle : cette surface particulire est appele gode [CAZ

Mesurer la localisation 105 94] [BAL 98]. En dehors des mers et ocans, elle passe sous la surface terrestre. Dautre part, on montre facilement que la forme de la surface dun fluide homogne en rotation uniforme autour dun axe et soumis lattraction universelle est, en quilibre, un ellipsode aplati aux ples. On retrouve la forme approche de la Terre connue depuis le XVIIIe sicle. Il aurait t bien agrable de ramener toutes les mesures godsiques et gravimtriques au gode, si celui-ci avait prsent une forme simple. Mais cette forme nest pas connue et na aucune raison dtre une forme simple puisque la Terre et la rpartition des masses qui la composent sont complexes. On ramne donc les mesures un ellipsode de rvolution qui sera pris comme surface thorique de rfrence pour la gravit. Pour un godsien, le gode correspond la dviation de la verticale, cest-dire la diffrence entre la verticale observe la surface et la verticale lellipsode de rfrence. On a donc mesur cette dviation sur un certain nombre de points (en sappuyant sur les astres). En interpolant de faon linaire dans les triangles obtenus en reliant tous ces points, on obtient une surface appele gode astrogodsique, qui permet dvaluer la cote du gode par rapport lellipsode de rfrence. On dmontre que la forme dune surface quipotentielle, lintrieur de laquelle se trouvent toutes les masses, est dtermine si on connat en tous ses points lintensit de la pesanteur. Do une seconde mthode, gophysique et non gomtrique, pour la dtermination du gode : la prospection gravimtrique, consistant mesurer la pesanteur en un rseau dense de points de la surface. On calcule en fait les anomalies de la gravit, diffrence entre la gravit mesure puis corrige et la gravit thorique sur lellipsode de rfrence. A partir du gode, surface quipotentielle, on pourra thoriquement dduire le potentiel de gravit dans tout lespace extrieur. La prospection sur la mer est difficile, mais le lancement de satellites capables de mesurer directement par radar laltitude relative sur la mer avec une prcision du centimtre (SEASAT, Posedon, ERS1) a rsolu le problme. On calcule facilement la gravit thorique la surface dun ellipsode en rotation partir de ses caractristiques gomtriques : g=ge(1+sin2) Quelle que soit la densit, on a toujours applatissement+=5/2(w2a/ge), w tant la rotation de lellipsode. Lassociation Internationale de Godsie a donc fix la valeur de la gravit la surface de lellipsode de Hayford : g=978.049(1 + 0.005 288 4sin - 0.0000059sin2).

106

Chapitre 4

Pour trouver la forme du gode, on peut utiliser la formule de Stockes si lon connat la diffrence entre la gravit thorique sur lellipsode et la gravit sur le gode, condition de supposer que le gode contient toutes les masses. Or on part dune mesure effectue au sol, au-dessus du gode. On doit donc, pour estimer la valeur de la gravit sur le gode, effectuer plusieurs corrections : - une correction daltitude, puisque le point mesur est plus haut que le gode. On obtient une diminution de 30.8 mgals pour 100 m dlvation (la correction se calcule bien sr par rapport la pesanteur thorique). - une correction de plateau, consistant corriger lexistence de matire extrieure au gode alors quon la suppos contenir toutes les masses : on comble lespace entre le point de mesure et le gode par de la matire et on en calcule linfluence gravitationnelle. - une correction topographique, pour tenir compte du model du relief au voisinage du point de mesure. La somme de ces trois corrections est appele correction de Bouguer. Les anomalies de Bouguer sont donnes par la diffrence entre gravit mesure et gravit thorique moins la correction de Bouguer. La forme systmatique de ces anomalies par rapport au relief a donn lieu lintroduction dune force de compensation dpendant vraisemblablement de la densit de la crote terrestre et de sa raction sculaire et lastique la surcharge, appele isostasie. La troisime mthode est plus gnrale, et consiste, linverse, rechercher directement lexpression mathmatique du potentiel dans tout lespace et den dduire la forme du gode. La fonction de force dfinissant la gravit est dfinie par lquation diffrentielle indiquant lannulation du Laplacien en dehors des masses : la forme des solutions de cette quation est connue et peut tre exprime en srie de fonctions sphriques, mais les coefficients sont dterminer par lexprience. Pour cela, on suit le mouvement des satellites artificiels par laser, partir dun certain nombre de stations au sol. On approche la valeur des coefficients de chaque terme de la srie grce aux caractristiques de ces trajectoires, corriges de linfluence des autres astres et de latmosphre. Les rsultats obtenus par gravimtrie sont galement utiliss pour affiner le calcul des coefficients dont les effets sont trs faibles. Les solutions de lquation diffrentielle indiquant lannulation du Laplacien sont constitues des fonctions harmoniques, qui elles-mmes peuvent tre dveloppes en srie de fonctions sphriques, cest--dire fonctions des puissances de 1/r. A la distance r du centre de gravit des masses, dans la direction ,, le potentiel de pesanteur est donn par une expression de la forme : v=GM/r(1+J1P1(,)(a/r)2 + J2P2(,)(a/r)3 + ...)

Mesurer la localisation 107 o a reprsente le rayon quatorial de la Terre, M la masse de la Terre, G la constante de gravitation universelle, Pn(,) des fonctions de la direction (,) du point dobservation par rapport au centre de gravit. reprsente lorientation, linclinaison. Ce dveloppement a une interprtation physique immdiate : linfluence de chaque terme apparat au fur et mesure que lon se rapproche de la Terre. En ngligeant tous les coefficients, le potentiel est celui dune sphre, cest ce qui se passe si r est grand. En ne ngligeant plus J1, on obtient lquation dun ellipsode aplati : le terme est proportionnel (1/r3)(3cos2 -1)/2, J1 est de lordre de 1/1000, puisque laplatissement de la Terre est de lordre de 1/300. Grce aux autres termes (qui sont de lordre de 1/1000000) on obtient des carts locaux avec lellipsode pouvant aller jusqu 100 mtres. En 1982, la NASA a calcul un modle de gode en dterminant 20 termes, exclusivement bas sur des donnes de poursuite de satellites. La prcision est de lordre du centimtre pour les coefficients dordre deux, et de lordre du mtre lordre 20. Depuis, dautres modles ont utilis plus de trente termes, en intgrant des donnes daltimtrie sur les ocans et de gravimtrie au sol. La connaissance de la valeur de la pesanteur en tout point de lespace est dune importance primordiale en science spatiale et en balistique : elle permet, entre autre, de prvoir la trajectoire exacte dun satellite artificiel ou dun missile (fig. 4.3).

fig. 4.3 : dformation du gode terrestre, lchelle 10000 (daprs [CAZ 94])

4.2.3.2. De nouveaux ellipsodes Lellipsode de rfrence, depuis toujours dtermin par des considrations gomtriques, peut maintenant tre dfini par une simplification de lexpression du

108

Chapitre 4

potentiel, en se limitant au terme en (1/r)3 dans lquation fondamentale du gode (on obtient des valeurs proches de 6 378 160 m, avec un aplatissement de 1/298,25). Ainsi ont t dfinis successivement les systmes godsiques mondiaux WGS 60, WGS 66, WGS 72, WGS 84. Les modifications successives correspondent aux avances dans la recherche de la forme du gode gravitationnel, notamment par les mesures de poursuite de satellites artificiels. La position de lellipsode est en gnral donne en fixant le centre de lellipsode au centre de gravit des masses de la Terre (indpendamment dune condition de tangence en un point). 4.2.4. Nouveaux instruments, nouvelles mesures, nouvelles prcisions Si nous avons prsent triangulation, nivellement et autre mthodes de mesure, cest que la plupart des travaux en cartographie et reprsentation de la Terre sont encore attachs ces techniques, malgr lmergence dinstruments nouveaux qui ont rvolutionn la godsie et la gravimtrie. Dans le domaine de mesures de distances, on est pass du fil talonn au telluromtre (mesure du temps daller et retour dune onde lectromagntique), puis au godimtre laser (mme chose mais avec une onde lumineuse cohrente). Les mesures dangles, la base de la triangulation, peuvent tre remplaces par des mesures de distances. Les angles taient mesurs au thodolite avec une prcision relative de 1/200000, celle des distances est maintenant suprieure 1/500000. Dans le domaine du positionnement, la godsie spatiale permet maintenant de connatre le lieu dun point indpendamment de la notion de verticale. Les mesures prennent appui sur un certain nombre de stations au sol dont la position est connue de faon trs prcise par des mesures sur des signaux intergalactiques. Le principe de base est simple : partir de deux points connus, on peut dterminer la position exacte du satellite linstant t. Si au mme instant t, on repre partir dun point inconnu la position du satellite par rapport aux toiles, on peut en dduire la position de ce point. Actuellement, on calcule directement la position du point inconnu par rapport aux satellites. 4.2.4.1. Le systme GPS Le systme GPS fonctionne sur ce principe, mais avec un rseau de plusieurs satellites en ne prenant en compte que la distance et non la direction. Chaque satellite met en continu des signaux qui permettent un point rcepteur dvaluer la distance qui le spare du satellite, en mesurant le temps de rception du signal (pour cela, chaque satellite est quip dune horloge atomique trs prcise) [BOT 98]. La position de chaque satellite est repre grce un rseau de stations au sol; cette position est galement transmise au point rcepteur via le satellite, qui met de

Mesurer la localisation 109 plus des informations sur sa trajectoire et sur les conditions atmosphriques de transport des signaux. La rception de la position de trois satellites permet un point rcepteur de calculer sa position sur un ellipsode. Avec quatre, on peut galement avoir laltitude. La prcision dpend principalement de la gomtrie du polydre form par les satellites et le point rcepteur, de la position des artes par rapport latmosphre et lionosphre (les erreurs sont dautant plus fortes que llvation du satellite par rapport lhorizon est faible), de la qualit de la synchronisation des horloges, de la densit des signaux rflchis, du type de rcepteur employ. Pour les coordonnes horizontales, la prcision, en mesure absolue, varie de quelques dizaines de mtres un mtre; en mesure relative (on mesure alors la phase des signaux), elle peut tre suprieure au centimtre. La mesure de laltitude est bien sr plus dlicate, et dune moindre prcision. Le rseau comprend, en 2000, 28 satellites, dont 6 de rserve, ce qui permet datteindre chaque point du globe tout moment. La connexion des satellites russes au rseau amricain permet dobtenir des configurations gomtriques encore meilleures, donc une amlioration du temps et de la prcision des mesures. La plus grande prcision est obtenue par les mesures diffrentielles : plutt que de mesurer une position absolue, on mesure la diffrence entre un point connu et le point dterminer. La simultanit des mesures permet dliminer la plupart des sources dimprcision, et datteindre ainsi en relatif une prcision infrieure au centimtre. Lors dune mesure par GPS, la position du point est donne par rapport une surface de rfrence, gode ou ellipsode. Lorsque lon utilise un ellipsode, le datum est important, puisque le GPS peut donner la mesure suivant plusieurs datum. La connaissance de toutes ces notions est donc fondamentale pour une bonne utilisation de ces instruments, surtout lorsque les mesures effectues doivent tre intgres dans un systme dinformation.
Le systme GPS (Global Positioning System) est un systme de navigation et de positionnement mondial utilisant une constellation de 28 satellites. Son tude, son financement et son entretien sont entirement assurs par le Dpartement de la Dfense des Etats-Unis, qui se rserve le droit de dgrader le signal pour des raisons stratgiques et militaires. Les satellites GPS voluent sur des orbites circulaires une distance de lordre de 20200 km de la Terre, ce qui correspond une priode de rotation de lordre de 12 heures. Les rcepteurs GPS permettent de capter et traiter les signaux envoys par les satellites. La disponibilit du systme dpend du nombre de satellites observables durant les mesures et de leur positionnement gomtrique qui influe sur la qualit des rsultats. Le mode absolu

110

Chapitre 4

Dans un mode dutilisation o le rcepteur GPS fournit des coordonnes de manire instantane et de faon autonome (mode absolu), le GPS permet de fournir une position quelques mtres prs. Cette prcision assez modeste est la consquence de plusieurs facteurs : erreurs du segment spatial : erreur sur les paramtres orbitaux des satellites (20 m), erreur sur lhorloge propre du satellite par rapport au temps GPS (quelques mtres). erreur de propagation : le signal GPS se propage depuis le satellite vers lantenne du rcepteur. Il traverse ainsi la totalit de latmosphre terrestre et subit les influences des diffrentes couches. Lionosphre retarde le signal en fonction de lactivit solaire et de la situation gographique (erreur entre 0 et 50 m). La troposphre influence la propagation du signal par lintermdiaire de phnomnes de rfraction. Cette erreur est trs sensible aux basses lvations du satellite (erreur entre 2 et 5 m). erreur de multi-trajets : le signal GPS peut subir, lapproche de toute surface proche de lantenne de rception, une rflexion qui rallonge le chemin optique parcouru. Cet effet est connu sous le terme de multi-trajets. On peut lliminer en loignant lantenne de toute surface mtallique proche et en lquipant dun plan de masse absorbant les signaux rflchis par le sol. erreur due la prcision de lhorloge du rcepteur (lhorloge du rcepteur sert mesurer des diffrences de temps). Cette erreur est plus importante que celle induite par lhorloge du satellite car la qualit de lhorloge dtermine directement le cot du rcepteur (environ 20 m). Le mode diffrentiel Comme la prcision de la localisation GPS absolue est parfois insuffisante, il est possible de contourner le problme et deffectuer la localisation relative dun point par rapport une rfrence connue : deux rcepteurs GPS vont faire des mesures simultanes sur les mmes satellites, pour permettre de dterminer les diffrences de coordonnes entre les deux stations. On parle alors de GPS diffrentiel. Le calcul des coordonnes se fait en post-traitement aprs dchargement sur un ordinateur des mesures enregistres par les deux rcepteurs. Il sagit dun positionnement relatif par rapport une station de rfrence place sur un point connu. On doit donc disposer de deux rcepteurs qui effectuent des mesures simultanes, lun sur le point dterminer, lautre sur la station de rfrence. Le principe du diffrentiel consiste retirer les erreurs systmatiques corrles entre la station de rfrence et la station mobile. Le bilan derreur va tre considrablement rduit : lerreur dhorloge du satellite va sannuler lors du traitement des observations simultanes. les erreurs dorbite vont tre rsiduelles ou ngligeables, lerreur de propagation ionosphrique sera considrablement rduite si les deux rcepteurs ne sont pas loigns de plus de 20 km environ, lerreur de propagation troposphrique sera galement diminue, surtout sil nexiste pas une trop grande diffrence entre les conditions mto chaque rcepteur (attention aux grandes diffrences daltitude), en revanche, les erreurs multi-trajets sajoutent les unes aux autres, lerreur due lhorloge du rcepteur sera du mme ordre que pour le positionnement absolu, mais peut tre rduite par les mthodes de double diffrence. La prcision du positionnement relatif varie entre 0.1 et 5 m environ, et dpend essentiellement de la qualit des rcepteurs et du nombre de mesures effectues sur le point

Mesurer la localisation 111

mesurer. Dans le cadre dun GPS diffrentiel post-trait, la station de rfrence sera quipe dune mmoire lui permettant denregistrer les mesures ralises. Les mesures seront rcupres ultrieurement par lutilisateur sur un ordinateur par connexion directe ou par modem. La station mobile enregistre galement les mesures propres chaque point. Le logiciel de post-traitement permet de traiter les mesures et de calculer les positions des points avec la prcision requise. Plus le nombre de mesures augmente meilleure est la prcision. Il faut au minimum une centaine de mesures pour permettre un calcul diffrentiel sur un point fixe.

4.2.4.2 Les changements de datum Avec les techniques gomtriques, toute nouvelle mesure sappuyait sur un point connu de la triangulation, et utilisait donc le datum local. Avec lavnement du GPS, des mesures peuvent tre effectues indpendamment du datum normalement utilis localement. Lorsque toutes ces mesures doivent tre intgres dans un mme systme, il devient ncessaire de savoir comment transformer les coordonnes sphriques (longitude, latitude) dun datum un autre. Les coordonnes dans des datum diffrents dun mme point physique peuvent donner des diffrences de plusieurs dizaines de mtre aprs projection. Les ellipsodes dfinis au cours du temps pour approcher la Terre et positionner un point diffrent par leur forme ou leur centre, ou les deux. Pour passer des coordonnes gographiques dun point par rapport un datum aux coordonnes du mme point par rapport un autre datum, il faut donc connatre les formes des deux ellipsodes de rvolution et les carts de position entre les deux centres. Cest encore grce ltude du mouvement de satellites artificiels que lon a pu mesurer les carts de position du centre de la plupart des datum avec le centre des masses de la Terre, qui est par dfinition le centre du datum WGS84. Ces carts de position ont une prcision qui varie selon les datum, de quelques mtres quelques dizaine de mtres. Beaucoup de datum utilisent lellipsode international dfini en 1924.
Exemples de datum et des valeurs DX,DY,DZ par rapport WGS84 : PROVISIONAL SOUTH CHILEAN 1963 (Southern Chile): Ellipsode : International 1924; DeltaX=16.; DeltaY=196.; DeltaZ=93.; PUERTO RICO: Ellipsode : Clarke 1866; DeltaX=11.; DeltaY=72.; DeltaZ=-101.; QATAR NATIONAL: Ellipsode : International 1924; DeltaX=-128.; DeltaY=-283.; DeltaZ=22.; SCHWARZECK (Namibie) : Ellipsode : Bessel 1841 Japan; DeltaX=616.; DeltaY=97.; DeltaZ=-251.;

112

Chapitre 4

Deux principales mthodes permettent deffectuer cette transformation. La plus connue utilise la formule de Molodensky. Cette formule correspond un calcul approch, si bien que la transformation a une prcision limite (environ 3 mtres), et quelle nest pas utilisable prs des ples. L implmentation en C++, utilise dans le module SAVEDIT (voir chapitre 7), est donne dans la classe CMolodensky (A.2.3.3.). La seconde mthode est base sur la recherche des coefficients par suivi de la trajectoire de satellites. 4.2.5. Prcision des mesures Il est essentiel de parler de la prcision des techniques et des mesures que nous avons mentionnes, dautant plus que la reprsentation cartographique va induire dautres dformations. On a souvent tendance perdre de vue le domaine de validit dune mesure, mlanger des chelles de prcision diverses et souvent incompatibles. Par exemple, un changement dellipsode de rfrence induit des diffrences de latitude largement suprieures aux erreurs dobservation (sur une distance de mille kilomtres, du nord au sud de la France, la diffrence reprsente un cart de lordre de quatre dcimilligrades). Bien sr, cela concernait plus le gomtre que le gographe, mais le dveloppement du stockage informatique et des systmes dinformation gographique rend cette question importante, car le systme facilite laccessibilit de mmes donnes plusieurs groupes dutilisateur qui nont pas forcment les mmes besoins de prcision, ou qui ne savent plus valuer, ni ce dont ils ont ou auront besoin, ni ce quils utilisent vraiment. 4.3. Reprsenter lellipsode sur une surface plane : cartographie et projections On sait maintenant ramener la position dun point dans lespace gographique (dans les trois dimensions) sa position par rapport un ellipsode de rvolution. Pour reprsenter un bout de cette surface sur une feuille (cest dire une surface plane) ou sur un cran dordinateur (ou plutt sur la mmoire graphique correspondante, qui peut tre galement considre comme une surface plane, alors que certains crans sont encore un peu bombs), il faut passer de la surface curviligne dun corps dans un espace trois dimensions une surface plane deux dimensions. Comme les ellipsodes ne sont pas dveloppables sur un plan (un cylindre ou un cne peuvent tre dvelopps sur un plan; la surface dune sphre, dun ellipsode de rvolution ne peut pas ltre sans dchirement), il faut utiliser une fonction mathmatique, que lon veut bijective, pour effectuer cette transformation : cette fonction sappelle une projection cartographique. Elle sapplique aux points comme aux lments linaires et surfaciques.

Mesurer la localisation 113 Passer dune surface curviligne non dveloppable une surface plane implique des dformations, dont on cherche au mieux matriser les caractristiques suivant le but recherch de la reprsentation cartographique : conserver les formes, les distances, les surfaces, les angles... Choisir la fonction de projection permet de choisir les caractristiques de la dformation. La projection nest donc plus un problme de mesure mais seulement de calcul, puisque lon part de lellipsode et que toutes les mesures ont t effectues auparavant. La prcision est donc lie au calcul, alors quelle tait principalement lie aux mesures dans les problmes prcdents, en godsie comme en gravimtrie. De mme, connatre la dformation induite par la projection nest quun problme de calcul, et la prcision en est donne par la prcision du calcul utilis. 4.3.1. Les dformations Revenons au problme de la projection : reprsenter une partie de lellipsode de rfrence sur une surface plane en matrisant les paramtres de la dformation. Notons tout de suite que le terme projection est mal choisi, car il peut faire croire une transformation surjective, alors que dans son domaine de dfinition, la transformation sera toujours une application bijective : on pourra toujours dfinir la projection inverse dune projection donne. Les dformations introduites par la projection sont dfinies par les relations entre lments correspondants sur les deux surfaces, lellipsode et le plan, et essentiellement par ltude diffrentielle de la dformation, cest dire ltude de la dformation en un point et au voisinage (infinitsimal) de ce point suivant une direction donne. On a lhabitude de classer les dformations suivant trois groupes : - les dformations linaires : au voisinage dun point, on compare la longueur dun segment sur lellipsode et la longueur du segment projet sur le plan. En gnral, le rapport des longueurs (appel module de dformation linaire ou chelle locale) varie avec le point et avec la direction du segment. En tudiant la distribution du module de dformation linaire dans le plan de projection, on peut y dfinir des lignes isomtriques (tous les points de la ligne ont mme chelle locale). Si le module linaire est gal 1, il ny a aucune dformation linaire quelque soit la direction considre. On dfinit galement les lignes automcoques : le module de dformation linaire est gal 1 mais seulement dans la direction de la ligne. Aucune projection ne conserve les distances en tout point : une telle proprit impliquerait labsence totale de dformation. Les lignes automcoques sont importantes, car sur ces lignes, les distances (planes) dans le plan de projection correspondent aux distances (curvilignes) sur lellipsode. Elles permettent donc de fixer une unit de longueur dans le plan de projection.

114

Chapitre 4

- les dformations surfaciques : on considre au voisinage dun point un lment de surface et la projection de cet lment dans le plan. Si le module de dformation des superficies est gal 1 en tout point, la projection sera dite quivalente. - les dformations angulaires : au voisinage dun point, on considre deux lments linaires formant un angle . Ces deux lments se transforment en deux lments dans le plan, formant un angle . On appelle dformation angulaire la diffrence des angles -. Les projections conformes ont comme proprit de conserver les angles (la dformation angulaire est nulle en tout point). La connaissance des dformations induites par la projection est importante lorsque lon veut retrouver une valeur curviligne (sur lellipsode, et donc sur la surface terrestre) partir dune mesure sur une carte : on souhaite minimiser les calculs effectuer entre la mesure sur la carte et la correspondance sur lellipsode. Par exemple, une projection conforme conserve les angles : on peut donc mesurer directement un angle sur une carte utilisant une projection de ce type, cet angle sera le mme sur lellipsode (les projections conformes sont trs utilises en balistique et en navigation). Le calcul dune distance est plus difficile, car aucune projection ne permet de conserver les distances entre deux points quelconques. Avant le dveloppement des ordinateurs, on utilisait des tables dinterpolation pour ces calculs, et la prcision de linterpolation donnait la prcision du calcul. Lautomatisation des calculs grce aux ordinateurs et la cartographie numrique ont rendu ces tables dinterpolation quelque peu obsoltes. Dautres proprits peuvent tre importantes. Par exemple, la projection Mercator est non seulement conforme, elle a galement lavantage de transformer les loxodromies (routes cap constant) en des droites, ce qui facilite la navigation sur de courtes distances. Beaucoup de concepts mathmatiques proviennent de problmes cartographiques, ou plus gnralement de problmes de reprsentation de la Terre. Ces problmes ont t depuis lantiquit un moteur du dveloppement thorique : fonctions analytiques, calcul diffrentiel, etc. Par exemple, la condition de conformit est identique la condition dholomorphisme pour les fonctions analytiques (quations de Cauchy-Riemann). 4.3.2. Les surfaces dveloppables Les projections peuvent galement tre classes dune autre faon, en utilisant une surface intermdiaire dveloppable sur laquelle on effectue une premire projection. La forme de cette surface intermdiaire dtermine :

Mesurer la localisation 115 - les projection coniques, tangentes ou scantes : on choisit un cne tangent ou scant lellipsode. La projection Lambert est la plus clbre des projections coniques conformes ; - les projections cylindriques : cest un cylindre qui est tangent lellipsode ; - les projections planes (ou perspectives), en projetant directement sur un plan tangent la surface de lellipsode (par exemple dans les projections utilises aux ples). Suivant la position de laxe de la surface par rapport laxe de lellipsode, on parle galement de : - projections directes : laxe de la surface dveloppable est identique laxe de rotation de lellipsode (Lambert, Mercator,...) ; - projections transverses : laxe de la surface est perpendiculaire laxe de rotation (par exemple, la projection Universal Transverse Mercator) ; - projections obliques ou horizontales, si laxe est un diamtre quelconque de lellipsode. 4.3.3. Coordonnes et espace de projection La projection transforme un point de coordonnes (,) de lellipsode en un point dun plan dans un repre orthonorm (O,i,j), dorigine O. On a le choix de lorigine et de lunit dans le plan. Lorigine est le plus souvent choisie en prenant un point Po de coordonnes (0,0) sur lellipsode, et en fixant des coordonnes (X0,Y0) du point projet dans le plan (O,i,j). On sarrange en fait pour choisir (X0,Y0) de manire ne pas avoir de coordonnes ngatives pour le domaine projet, pour la partie de lellipsode laquelle on sintresse. 0 sappelle alors le mridien central, X0 le faux nord (FALSE NORTHING), Y0 le faux est (FALSE EASTING). Par exemple, pour la projection UTM, on fixe 500000 la valeur de X0, abscisse de la valeur projet du point P0 de coordonnes sphriques (0,0). Lunit est toujours le mtre. On essaye l aussi davoir la meilleure correspondance entre la distance curviligne (distance mesure sur lellipsode entre deux points, cest dire longueur de larc) et la distance entre les points projets dans le plan. Les projection ne conservent pas les distances, comme nous lavons vu plus haut, sauf sur les lignes isomtriques ou automcoques o les distances sont conserves. La dfinition de lunit utilise lune de ces lignes, en prenant en compte la valeur du module linaire correspondant la ligne (pour cela appel facteur dchelle locale). Si on utilise une ligne automcoque pour dfinir lunit de la projection, on aura sur cette ligne conservation des distances, dans la mme unit. Nous verrons dans les exemples de projections, plus loin dans ce chapitre, quelles sont les lignes automcoques utilises pour dfinir lunit de la projection.

116

Chapitre 4

Par exemple, les ordonnes dune projection UTM, exprimes en mtres, vont de 0 10 000 000 dans chaque hmisphre. On peut se demander par quel miracle la distance curviligne entre lquateur et le ple dun ellipsode de rvolution approchant la Terre mesure exactement dix millions de mtres (en approchant lellipsode par un cercle, on a d=*R, ou R est le rayon du cercle, =90=/2 radian. 6 400 000*3.14159/2=10 000 000 !). La rponse est toute simple : cest ainsi qua t dfini le mtre au XVIIIe sicle. Alors que les units utilises variaient entre la lieue, la verge, et un grand nombre de valeurs du pied, le dveloppement de la cartographie et des mesures de larc ont incit les scientifiques de lpoque dfinir une unit unique facile utiliser pour les calculs de projections et de distances. On a donc dfini le mtre comme la 10 000 000-ime partie de larc allant de lquateur au ple sur lellipsode de Picard (loi du 19 Frimaire an VIII - 10 dcembre 1799), tout en dfinissant le grade comme la 100-ime partie de langle au centre correspondant (90). LUTM ayant un mridien comme ligne automcoque (le mridien central), les coordonnes dans la projection vont galement de 0 10 000 000, exprimes dans cette nouvelle unit, le mtre.

Notons encore que les rosaces indiquant le nord gographique indiquent en fait la direction du nord sur le mridien central de la projection : les projections des mridiens ne sont parallles que dans certaines projections. 4.3.4. chelles et cartes Nous navons pas encore parl dchelle, car cette notion nintervient pas dans la propre action de projeter sur un plan. Dans le plan de projection, les distances sont sensiblement les mmes que sur lellipsode, comme nous lavons vu plus haut. Impossible bien sr de reprsenter ce plan de projection sur une feuille de papier, il faut rduire la taille des lments. On va donc effectuer une homothtie de rapport infrieur 1 par rapport lorigine du plan de projection. Dun domaine trs grand, on arrivera donc une surface plus petite, permettant dattendre la taille dune feuille de papier : la carte. Lchelle indique le rapport utilis pour lhomothtie. Lorsquun point est projet puis mis lchelle par homothtie, les coordonnes indiques sur la carte sur laquelle on la dessin sont soit des coordonnes aprs projection mais avant homothtie (les coordonnes du point dans le plan de projection), soit des coordonnes gographiques (on indique donc la longitude et la latitude du point sur lellipsode, avant sa projection puis sa mise lchelle ; on a dailleurs lhabitude de reprsenter sur une carte des points correspondant des valeurs entires des coordonnes sphriques : ce sont les amorces de la projection). Bien sr, ces coordonnes ne correspondent pas lunit de la carte aprs mise lchelle, mais les coordonnes ne sont jamais exprimes dans cette unit. Lchelle de restitution cartographique est donc une pure transformation mathmatique, elle nest pas directement lie la prcision. Ainsi, quelle que soit lchelle, la dformation lie la projection est la mme (puisque la projection ne

Mesurer la localisation 117 dpend pas de lchelle). Si lon mesure cette dformation sur une carte, sa valeur absolue sera bien sr divise par lchelle de la carte, comme tous les lments reprsents. La valeur relative entre un objet et la dformation lie la projection reste donc la mme quelque soit lchelle utilise. Par exemple, on dit souvent qu partir dune certaine chelle (pour le cadastre par exemple), la projection gographique peut tre nglige car la dformation due la projection devient trs faible, et lespace tudi assimilable un plan. En fait, cest la faiblesse de la dformation par rapport la taille ou la prcision de mesure des objets reprsents qui importe. Et puis il ne faut pas oublier non plus tout ce que lon a dit auparavant sur le passage de la Terre lellipsode : les grandeurs relatives des erreurs doivent tre compares pour pouvoir ngliger lune ou lautre. Si lon a pas besoin de rduire la taille du document (virtuel bien sr), on peut conserver des coordonnes projetes sans facteur de rduction - ou plutt avec un facteur 1. Cest ce que lon fait dans tous les systmes numriques, o la description de la localisation est conserve soit en coordonnes sphriques sur un ellipsode, soit en coordonnes projetes, et o la mise lchelle ne se fait que lorsque lon en a besoin (pour visualiser des rsultats). 4.3.5. chelle, projection, prcision Au cours de ce qui prcde, nous avons parl plusieurs reprises de prcision, et il est intressant de revenir sur ce sujet car il est dune importance capitale dans la conception et dans lutilisation des bases de donnes localises. La prcision nest jamais indique sur une carte. Elle est, dans lesprit de tous, implicitement donne par lchelle : on entend souvent dire quune carte au 1:1000000 est moins prcise quune carte au 1:1000. Qutant donn que le micron nest pas visible lil nu, il ne sert rien de chercher reprsenter une prcision dun mtre terrain lchelle 1:1000000. Que si cest pour les reprsenter une petite chelle, il est inutile de chercher une trop grande prcision. Et quimplicitement, cest en fonction des possibilits de reprsentation de la carte que lon va fixer la prcision des objets... Mais ce serait bien sr prendre le problme fondamental de la prcision lenvers. Comme dans toute science physique, la dfinition dun objet ne peut tre spar de la prcision de la mesure des attributs servant le dcrire. Les objets traits en gographie et en cartographie nexistent pas a priori, comme nous lavons soulign dans le chapitre prcdent : entre autre, la prcision apporte la description de la localisation est fondamentale dans la dfinition smantique de lobjet et donc dans lutilisation gographique ou cartographique qui peut en tre faite. La confusion vient de ce quimplicitement on sarrangeait, avant lavnement du numrique, pour

118

Chapitre 4

que toutes les cartes aient grosso modo le mme degr de prcision mesur sur la carte. La valeur absolue de cette prcision dpendait donc de lchelle de la carte. Comme toutes les cartes en papier ont peu prs les mmes dimensions, quelque soit lchelle qui, elle, varie considrablement, les objets que lon y reprsente sont finalement peu prs de la mme taille - sur la carte - et le rapport taille de lobjet/prcision de la localisation reste peu prs le mme. Mais - et cest fondamental quand il faut dfinir lobjet gographique - la prcision gographique absolue de la localisation est la seule notion vraiment importante, la seule intimement lie la dfinition des attributs de lobjet, et la seule qui puisse tre indique dans un systme informatique o la localisation est conserve indpendamment de la notion dchelle cartographique. La projection apporte une erreur systmatique et connue (ou plutt une dformation contrle), et la prcision du calcul de la dformation peut tre trs grande et adapte aux besoins. La rduction ou mise lchelle napporte aucune erreur. Ces oprations ne jouent donc aucun rle dans la prcision de donnes gographiques. La seule prcision vient donc de la mesure, et cette prcision doit tre dfinie lorsque lobjet gographique et son champ dapplication sont eux-mmes dfinis. Les instruments de mesure doivent tre compatibles avec cette prcision (par exemple, le capteur dun satellite, lobjectif dun appareil de photographie arienne, les mesures des gomtres, les GPS, la restitution photogrammtrique, etc.). Lorsque les objets sont thmatiques (pdologie, vgtation, ...), la prcision de leur localisation dpend de deux critres : un fond de carte, dont on peut estimer la prcision avec les critres prcdents, et la dfinition mme des objets, qui dpend en gnral de lchelle laquelle travaille celui qui labore linformation, et que nous appelons plutt dfinition smantique ou chelle de description. Plus quune notion dchelle, cette notion correspond bien un niveau de prcision et une vision de la ralit propre cette prcision. Elle est directement lie la vision de la ralit et sa modlisation.
La gnralisation est un processus cartographique qui permet de modifier la prcision de la localisation, par simplification, aprs avoir modifi la schmatisation conceptuelle des objets lorsque lon effectue un changement dchelle de description. Cette opration, prsente souvent comme purement cartographique, permet dadapter le dessin dune carte son chelle, pour ne pas avoir une prcision excessive qui napporte plus dinformation lchelle laquelle on reprsente les objets. En fait, elle montre bien lexigence dune bonne cohrence entre prcision de la localisation et validit des descripteurs des objets que lon veut reprsenter. La gnralisation des contours est une opration difficile automatiser, puisquelle fait partie dun processus de redfinition conceptuelle des objets. Il ne faut pas la confondre avec les oprations de filtrage, qui sont seulement destines rduire le nombre de

Mesurer la localisation 119

points ncessaires la description darcs, sans en modifier la forme ou lapparence. Nous verrons au chapitre 9 la description de lalgorithme de gnralisation de Douglas-Peucker.

Les SIG remettent en cause les mthodes de travail classiques pour llaboration de linformation localise : le critre fondamental pour la prcision des objets nest plus lchelle dune carte, considre comme document final, et o lon mlange prcision de la mesure, prcision smantique, et prcision du dessin. Cest uniquement la dfinition smantique des objets qui donne la prcision laquelle on doit envisager de dcrire la localisation de ces objets, puisque les SIG permettent de conserver les objets sans la notion dchelle de restitution. Et on retrouve bien sr ici tous les problmes lis la modlisation de lespace en zones homognes : rien ne sert de dcrire avec trop de prcision des zones alors que la validit de linformation ny est pas assure cette prcision. Il serait beaucoup plus efficace de dfinir un modle permettant de prendre en compte et de quantifier cette imprcision. Pour le moment, les mthodes classiques de reprsentation de lespace en zone, ligne, point, mthodes hrites de lre pr-numrique et des exigences de la cartographie ddition, nont pas vraiment t remises en cause par les SIG. Il ne faut jamais perdre de vue ces limitations lorsque lon utilise un SIG, et bon nombre de traitements possibles sont souvent inutilisables pour des problmes de prcision et de modle de reprsentation de la ralit. 4.4. Exemples de projections Nous allons prsenter trois exemples de projections gographiques qui sont parmi les plus utilises : la projection Mercator, la projection UTM, la projection conique Lambert. Toutes trois sont conformes (elles conservent les angles), cette proprit tant de loin la plus intressante pour la navigation ou la balistique. Nous avons dfini une classe CProjection qui contient comme membres tous les paramtres ncessaires au calcul, quelque soit la projection utilise (A.2.3.2.). 4.4.1. La projection Mercator La projection Mercator est une projection cylindrique directe, contrairement aux projections TM et UTM qui sont transverses. Cette projection est trs utilise en navigation, car, outre la conformit, elle a lavantage de transformer les routes cap constant en des droites sur la carte. Elle a longtemps t utilise pour les planisphres, malgr les considrables dformations quelle introduit ds que lon sapproche des latitudes leves. De plus, les projections conformes ne sont pas quivalentes : elles ne conservent pas les surfaces. La projection Mercator augmente les surfaces ds que lon sloigne de lquateur : le poids visuel de lEurope, de

120

Chapitre 4

lAsie du nord, de lAmrique du nord, de lOcanie augmente au dtriment de lAfrique, de lAsie centrale, de lAsie du sud et de lAmrique du sud. 4.4.2. La projection UTM (Universal Transverse Mercator) La projection UTM est une projection cylindrique transverse : le cylindre de projection est tangent lellipsode suivant une ellipse passant par les ples. La position de cette ellipse correspond au mridien central de la projection. La dformation devient importante si lon sloigne trop de ce mridien : la projection UTM nest utilise que pour reprsenter des rgions proches du mridien central (au maximum trois quatre degrs de part et dautre). Des mridiens centraux ont donc t dfinis une fois pour toute pour couvrir lensemble du globe, dcoup en zones : le premier est 3 et les suivants se suivent 6. Lindication de la zone UTM sur une carte permet de retrouver le mridien central correspondant :
zone 1 est : de 0 6 est, mridien central 3 est; zone 2 est : de 6 12 est, mridien central 9 est; zone 3 est : de 12 18 est, mridien central 15 est; ... zone 30 est : de 174 180 est, mridien central 177 est; zone 1 ouest : de 174 180 ouest, mridien central 177 ouest; zone 2 ouest : de 168 174 ouest, mridien central 171 ouest; ... zone 30 ouest : de 6 ouest 0 ouest, mridien central 3 ouest;

La projection est dite universelle car elle utilise un mme point de tangence par continent. Lorsque cette condition nest pas respecte, la projection devient TM (transverse Mercator). La seule ligne automcoque est une droite qui correspond la projection du mridien central. Cette ligne permet de dfinir lunit de la projection. Comme le mtre a t dfini comme la 10 000000-ime partie de la projection du mridien central (de lquateur au ple), lunit naturelle de la projection UTM est le mtre. On applique nanmoins un facteur dchelle pour rattraper les modifications dues lellipsode utilis (le mtre a t dfini avec lellipsode de Picard) et laltitude : un mtre mesur au sol sur le mridien central correspond alors exactement un mtre aprs calcul de projection. Ce facteur dchelle est toujours trs proche de 1. Comme pour beaucoup de projections, le calcul inverse ncessite le calcul dun arc de mridien sur lellipsode. Ce calcul est effectu par approximations successives (CProjection::SetEllipse()), ce qui influence la prcision de la transformation. Cette prcision est de lordre du centimtre.

Mesurer la localisation 121 Les coordonnes UTM ont le dfaut de ne pas diffrencier lhmisphre : il y a donc une rupture au niveau de lquateur, o lon passe de 9 999 999 0. Pour viter cette rupture, nous avons choisi dajouter 10 000 000 dans lhmisphre nord. Les mthodes UTMToGeo() et GeoToUtm() donne limplantation du calcul de la projection UTM dans la classe CProjection. 4.4.3. La projection conique de Lambert La projection Lambert est une conique conforme qui permet de reprsenter des surfaces plus importantes que la projection UTM et convient particulirement aux latitudes moyennes. Elle a t particulirement utilise pour la France, lAfrique du Nord, lAmrique du Nord. La projection Lambert admet de nombreux paramtres : le cne peut tre tangent ou scant; le choix du mridien central permet de fixer la ligne automcoque et lorigine de la projection. Certaines Lambert portent un nom, et tous les paramtres sont alors fixs. Par exemple :
Lambert I Nord (tangente) :
Mridien central : 220 14.025",EST; Parallle tangent : 49 30 0.",NORD; Ellipsoide(6378249.2,0.00680348765); Facteur dchelle : 0.99987734; Coordonnes au point dorigine : 600000.,200000.;

Lambert II Centre (tangente) :

Mridien central : 2 20 14.025",EST; Parallle tangent : 46 48 0.",NORD; Ellipsoide(6378249.2,0.00680348765); Facteur dchelle : 0.99987742; Coordonnes au point dorigine : 600000.,200000.;

Lambert III Sud (tangente) :

Mridien central : 2 20 14.025",EST; Parallle tangent : 44 6 0.",NORD; Ellipsoide(6378249.2,0.00680348765); Facteur dchelle : 0.99987750; Coordonnes au point dorigine : 600000.,200000.;

Lambert IV Corse (tangente) :

Mridien central : 2 20 14.025",EST; Parallle tangent : 42 9 54.",NORD; Ellipsoide(6378249.2,0.00680348765); Facteur dchelle : 0.99987771; Coordonnes au point dorigine : 234.358,185361.369;

Eurolambert (tangente) :
Mridien central : 2 20 14.025",EST; Parallle tangent : 46 48 0.",NORD; Ellipsoide(6378388.2000,0.00672267002); Facteur dchelle : 0.99987750; Coordonnes au point dorigine : 600000.,2200000.;

Lambert Etendu (tangente) :

Mridien central : 2 20 14.025",EST; Parallle tangent : 46 48 0.",NORD; Ellipsoide(6378249.0000,0.00680348765); Facteur dchelle : 0.99987742; Coordonnes au point dorigine : 600000.,2200000.;

Lambert Mexique (scante) :

Mridien central : 102 0 0.,OUEST; Parallle du point dorigine : 24 0 0.",NORD; Parallle 1 : 17 30 0.",NORD; Parallle 2 : 29 30 0.",NORD; Ellipsoide(6378206.4000,0.006768657997); Coordonnes au point dorigine : 2000000.,2000000.;

122

Chapitre 4

Linitialisation des paramtres est diffrente selon les types de projection Lambert (tangente ou scante). Le calcul de projection est ensuite identique. Les diverses mthodes de la classe CProjection correspondant la projection Lambert peuvent tre consultes dans lannexe (A.2.3.2.). 4.5. SAVANE, datum et projections Le systme SAVANE conserve lensemble des coordonnes gographiques sous la forme longitude-colatitude dans un datum donn. Le datum doit tre identique pour lensemble des objets dune mme base de donnes. Nous avons donc deux besoins fondamentaux pour intgrer des objets dans une base de donnes SAVANE : pouvoir passer de coordonnes donnes suivant une projection aux coordonnes gographiques du mme point, par projection inverse, et pouvoir changer de datum. Lensemble de ces procdures est disponible dans la classe CProjection. Cette classe est galement utilise dans lutilitaire GLOBE qui permet de faire des calculs de changement de projection :

fig. 4.4 : le programme Globe

4.5.1. Provenance des donnes en entre Il ny a en fait que peu de sources de donnes pour la localisation : relevs de terrain, images ariennes ou spatiales, cartes topographiques ou toponymiques en forment limmense majorit. Les images ariennes ou spatiales sont redresses et mises en conformit gographique, suivant une projection, grce notamment des

Mesurer la localisation 123 mesures de localisation et daltitude. Les cartes sont ralises partir dimages ariennes et de mesures de terrain. Les mesures de terrain, longtemps effectues par triangulation, sont maintenant le plus souvent effectues par GPS. Les donnes de localisation servant constituer une base de donnes localises proviennent de ces documents. Le systme doit donc tre en mesure de fournir les outils permettant la saisie graphique de ces documents. La source principale de donnes est donc constitue de cartes, ralises avec une certaine prcision, selon une projection gographique et sur un datum de rfrence. Le systme SAVANE permet la saisie sur cran partir de ces cartes scannes et gorfrences grce au module SAVEDIT. Il permet galement limportation directe de donnes de positionnement provenant de relevs de terrain. 4.5.2. Fonctionnement de SAVEDIT pour les projections inverses et le datum La saisie graphique sur cran avec SAVEDIT seffectue en utilisant la fentre du programme comme espace de digitalisation. Cette espace correspond une fentre ouverte sur un espace gographique. Il est important de bien matriser les paramtres de cet espace gographique. En voici les principes. La surface de lcran de saisie de SAVEDIT correspond un espace muni dun repre orthonorm : on peut donc passer des coordonnes cran aux coordonnes dune projection gographique, par une simple translation-homothtie dpendant seulement de lespace visualis sur lcran. On peut ensuite retrouver les coordonnes sphriques (longitude, latitude), dans un datum donn, par projection inverse. Pour faire cette transformation, SAVEDIT doit seulement connatre la projection gographique et lespace de travail correspondant la fentre de visualisation : lutilisateur du programme doit prciser ces paramtres lorsquil rentre dans le systme, de manire initialiser lespace de travail. Lorsque la saisie se fait partir dune carte scanne ou dune image gorfrence par SAVAMER, le chargement de la projection correspondant au gorfrencement de la carte ou de limage est tout fait naturel. Lors de limportation dun fichier externe, les coordonnes du document sadaptent automatiquement la projection de visualisation. Lutilisateur doit seulement prciser la projection initiale du document, de manire convertir les coordonnes de projection en coordonnes sphriques. Lespace de travail est choisi tout aussi naturellement. Au dpart, lutilisateur le choisit en fonction du support de la digitalisation (espace dune carte ou dune image go-rfrence, espace complet dun document, visualisation dlments de la base de donnes), ensuite, il peut le modifier en fonction des besoins de visualisation ou de saisie.

124

Chapitre 4

Tout document digitalis est conserv en coordonnes gographiques, dans un datum donn. Lors du processus de digitalisation, SAVEDIT convertit chaque point saisi sur lcran en coordonnes sphriques, en fonction de la fentre de visualisation et de la projection gographique inverse. Sil est ouvert avec une autre projection, il sera trac dans la fentre de visualisation selon cette autre projection, sans aucun problme. Le fonctionnement de SAVEDIT est donc diffrent de la plupart des logiciels de saisie graphique. Dans SAVEDIT, lespace de travail, celui qui est visualis sur lcran, correspond toujours un espace gographique trac selon une projection gographique connue (par dfaut, le systme utilise la projection dite gographique, avec un mridien central centr sur la base de donne ouverte). Chaque point de lcran peut tre repr par ses coordonnes dans les divers systmes (projection, ellipsode, cran) grce la fentre de navigation. Lors de la saisie, la prcision sera dautant plus grande que la fentre de visualisation sera troite, puisqu la taille du pixel correspondra alors un espace plus petit dans la ralit. Lorsque lon cre un document avec SAVEDIT, on peut indiquer son datum. Cette indication nest pas toujours indispensable, et elle ne change en rien les coordonnes des points saisir. Par contre, on peut changer le datum dun document par la suite, et si les coordonnes des points saisis doivent tre modifis pour prendre en compte le dplacement de lellipsode de rfrence, chaque coordonne est modifie pour reflter ce changement (le programme utilise la formule de Molodensky). Ce problme est courant lorsque des donnes saisies avec un GPS dans un datum doivent tre intgres avec des donnes conserves selon un autre datum. Il est ncessaire, aprs avoir import les points dans SAVEDIT, de spcifier le datum initial des points GPS puis de modifier ce datum en modifiant les coordonnes des points. Nombreux sont ceux qui ont eu le dsagrment, en reportant sur une carte leurs points saisis avec prcision sur le rivage, de les retrouver loin dans la mer ou dans un lac Question de datum ! La classe CProjection est utilise pour les calculs de transformation de projection dans SAVEDIT (A.2.3.2.). La classe CWind de SAVEDIT contient la description de la fentre de travail, et quelques fonctions permettant de modifier cette fentre. Par exemple, la fonction NouvelleFenetreProj() permet de modifier la fentre de travail correspondant lcran en donnant les coordonnes de projection de cette fentre. Quelques fonctions globales permettent deffectuer les transformations cran-espace de projection-datum.

Mesurer la localisation 125 La classe CMolodensky, que nous avons dcrite au dbut de ce chapitre, permet deffectuer les transformations de datum en utilisant la formule de Molodensky (A.2.3.3.). 4.5.3. Fonctionnement de SAVANE pour les projections dans un cadre Une requte dans SAVANE correspond un espace de travail dans une carte. Pour la visualisation des rsultats de cette requte, SAVANE utilise un cadre et une opration de cartographie. Chaque cadre a donc des paramtres de projection gographique, de coordonnes correspondant lespace visualiser, dchelle de restitution. Toutes les donnes graphiques sont conserves en coordonnes gographiques dans SAVANE, selon un datum identique pour tous les objets dune mme base de donnes. La visualisation dun cadre utilise donc : la position du cadre dans la carte lchelle du cadre la fentre gographique du cadre (le cadre est comme une fentre ouverte sur la base de donnes gographique) la projection gographique choisie lorsque la visualisation se fait sur un cran, il faut galement prendre en compte la position de la carte dans lcran. Lorsque lon dmarre une requte dans SAVANE, tous les paramtres du cadre par dfaut sont dfinis par dfaut. Il faut agir sur les boutons CADRE, MAP et WIND pour modifier ces paramtres. La classe CCadre (A.2.4.4.) contient un certain nombre de variables membres correspondant ces paramtres. Les classes CProjection (A.2.3.2.) et CWind (A.2.3.1.) sont identiques aux classes du mme nom dans SAVEDIT. 4.6. Conclusion Mesurer la localisation savre tre une opration complexe si lon veut en matriser la prcision et lincertitude. Tous les paramtres de la mesure interviennent lors de la ralisation dun SIG. Dans le systme SAVANE, nous avons choisi de conserver les coordonnes des points dcrivant la localisation des objets gographiques en coordonnes sphriques (longitude, colatitude) dans un mme datum. Il est donc important de pouvoir passer dun datum un autre, et de pouvoir passer de coordonnes projetes des coordonnes sphriques. La projection gographique est utilise lors de la constitution de la base de donnes, lors de la

126

Chapitre 4

saisie graphique, et lors de lexploitation des donnes et de la cartographie des rsultats, de faon interactive. Des objets gographiques ne peut tre intgrs une base de donnes que sils sont gorfrencs avec la prcision correspondant leur dfinition smantique. Si tel nest pas le cas, la dfinition elle-mme des objets doit tre remise en cause. Dans le cas contraire, certains traitements ou mise en relation dobjets pourraient amener des rsultats non valides, notamment en analyse spatiale.

Mesurer la localisation 127

128

Chapitre 4

Bibliographie

[BAL 98] BALMINO G., Champ de pesanteur terrestre et gode. Principes, progrs et connaissance actuelle, 1998, Bureau Gravimtrique International, Toulouse, France [BEG 94] BEGUIN M., PUMAIN D., La reprsentation des donnes gographiques, 1994, CURSUS-Armand Colin, Paris [BOT 98] BOTTON S ., DUQUENNE F., EGELS Y., EVEN M., WILLIS P., GPS, localisation et navigation, 1998, Herms, Paris [CAZ 94] CAZENAVE A., FEIGL K., Formes et mouvements de la Terre, 1994, Ed.Belin-CNRS [DUF 98] DUFOUR J.P., Cours dintroduction la godsie, Ecole nationale des sciences gographiques,1998, IGN-ENSG [GEO 71] Gophysique, Encyclopdie de la Pliade, sous la direction de Jean Goguel, Gallimard, 1971, Paris [LEV 88] LEVALLOIS J.J., BOUCHER C., BOURGOIN J., COMOLET-TIRMAN A., ROBERTOU A., Mesurer la Terre : 300 ans de godsie franaise, De la toise du Chtelet au satellite, 1988, Association franaise de topographie, Presse de lEcole Nationale des Ponts et Chausses, AFT, Paris [MAG 97] MAGELLAN SYSTEMS CORPORATION, User guide for the Magellan GPS ProMARK X-CM, 1997

Chapitre 5

De l'objet la collection d'objet : les SGBD

5.1. Introduction Jusqu' prsent, nous avons tudi la manire de schmatiser et reprsenter la ralit par des objets, sans tenir compte du problme de la collection. Dans beaucoup de situations, et notamment en gographie, la ralit tudier ne peut se schmatiser par quelques objets distincts, ou alors ces objets seraient tellement complexes qu'ils en deviendraient difficilement utilisables pour un objectif autre qu'une pure description. En particulier, on ne pourrait pas les comparer entre eux et utiliser tout l'arsenal de la statistique pour les tudier, les analyser, et en extraire des caractristiques. On cherche donc plutt dfinir des objets assez simples, et reprsenter la ralit par des collections de ces objets. L'ensemble des collections schmatisant une ralit tudier est appel une base de donnes. La gestion efficace de ces collections d'objets est ncessaire, car les objets peuvent tre trs nombreux, mme si leur description individuelle est assez simple. Pour grer efficacement ces collections d'objets indpendamment des programmes qui vont les utiliser, il faut des systmes de gestion de bases de donnes. Plusieurs modles de description ont t dfinis pour passer d'une schmatisation en objets une schmatisation en collections d'objets, non plus seulement en fonction de critres de description, mais galement en fonction de critres de gestion et de la difficult grer ces collections d'objets. Nous reviendrons donc galement sur les problmes de schmatisation et de reprsentation de la ralit. La mise en base de donnes n'est pas toujours ncessaire, notamment lorsque l'objectif est la description de quelques objets distincts : ainsi, la description de paysages rentre difficilement dans le cadre contraignant d'une schmatisation de la

130

Chapitre 5

ralit, car l'objectif est alors la description dtaille d'un seul ou de quelques objets, chaque objet ayant des attributs qui lui sont propres. La difficult vient bien de l'objectif recherch, et non pas de la technologie des bases de donnes. 5.2. Notions classiques sur les SGBD Le problme de la gestion des donnes se pose lorsque les applications ont besoin de grands volumes d'information, c'est--dire de grandes collections d'objets dcrits de faon complexe par de nombreux attributs. La cration, la disponibilit, l'utilisation de ces grandes collections est trs coteuse pour une seule application. On a donc cherch mettre en commun ces objets, en les dfinissant de faon intrinsque et en les mettant dans des bases de donnes entirement gres par des programmes spcialiss, qui ne font que a : les systmes de gestion de bases de donnes (SGBD) [GAR 83] [ULL 88]. Un SGBD, c'est une interface entre l'usager (un utilisateur, un programme) et les mmoires de stockage, lui donnant l'illusion d'avoir sa disposition des donnes stockes et assembles comme il le souhaite, d'tre le seul les utiliser, et de pouvoir les manipuler sa guise grce un langage spcial. C'est un outil de gestion efficace permettant de rechercher, modifier, ajouter des donnes dans une grande masse d'information, partage par tous les usagers suivant leurs droits d'accs, chacun travaillant sur sa vision et sa propre structuration de l'information. 5.2.1. Les problmes soulevs par l'utilisation de fichiers traditionnels : dpendance, redondance, intgrit, scurit A l'origine de l'informatique, les donnes utilises par une application taient toujours lies cette application, et utilises sous forme de fichiers traditionnels. Ces fichiers reprsentaient des collections d'objets dcrites par des attributs, mais ces objets et leur description taient en gnral dfinis uniquement pour l'application. Lorsqu'un programme utilise des donnes sous forme de fichier traditionnel, donnes et programme sont dpendants : le fichier est conu pour le programme ou le programme pour le fichier, et les structures logiques (description pour les objets, excution pour le programme) sont dpendantes l'une de l'autre. Nous n'avions donc pas de problmes de description et de reprsentation du monde rel, et la dfinition, description et reprsentation des objets dcoulaient naturellement de l'analyse du problme tudi et de sa rsolution algorithmique et informatique. Cette organisation, optimale dans certains cas, est dsastreuse dans d'autres, notamment quand les mmes donnes sont utilises par plusieurs applications diffrentes, car on est alors rapidement confront des problmes de redondance et de cohrence entre fichiers : si plusieurs programmes utilisent les mmes donnes dans des fichiers diffrents, rien ne garantit en effet que ces

De lobjet la collection dobjets 131 donnes soient quivalentes et que les mmes contrles soient effectus. On est confront de nombreux problmes lorsque plusieurs programmes veulent utiliser le mme fichier : problmes de redondance ou de stockage, problmes d'accs pour unifier les modifications et mises jour. La cration de fichiers rservs une seule application est trs coteuse : en volume, en cot de dveloppement informatique, en disponibilit des donnes, en problmes de cohrence et de scurit, en fiabilit, en accs aux donnes par des non-informaticiens. L'ide toute simple et qui est l'origine des SGBD, c'est de sparer donnes et applications en crant des ensembles cohrents de donnes indpendants des applications et en utilisant des programmes spcialiss pour les grer et les manipuler, et d'offrir aux programmes d'applications ces donnes dj structures et ces utilitaires pour y accder le plus facilement possible. Les donnes classiques deviennent donc peu peu des collections d'objets (c'est--dire des donnes qui ont une dfinition smantique propre, indpendante de l'utilisation qui en est faite) dfinies de manire intrinsque par schmatisation du monde rel suivant un modle de description et des rgles bien prcises. Dfinis de manire statique dans la plupart des cas, les objets peuvent devenir plus dynamiques par l'introduction dans leur dfinition d'autres objets ou de procdures et de fonctions que l'on peut leur appliquer et qui permettent de modifier leur description. Le travail d'un programme d'application utilisant de tels objets est fortement modifi : on passe de la dfinition des donnes et des procdures (programmation classique) l'utilisation d'objets et au choix des procdures offertes par le schma de donnes sur ces objets (programmation objet). 5.2.2. L'objectif des SGBD Tous les SGBD ne prsentent pas les mmes possibilits, et les modles ont volus depuis leur apparition il y a quelques dizaines d'annes. Mais l'objectif gnral de tous les SGBD peut se rsumer en plusieurs points [GAR 83] : - garantir l'indpendance physique et logique entre les donnes et les programmes d'application, - assurer la persistance des donnes, - permettre une administration centralise des donnes, - grer la mmoire de faon optimale et assurer l'efficacit de l'accs aux donnes, - grer le partage des donnes entre utilisateurs et les accs concurrents, - assurer la fiabilit, l'intgrit et la cohrence des donnes, viter les redondances, - assurer la scurit des donnes,

132 -

Chapitre 5 assurer les interrogations interactives, la consultation dclarative, et l'accs de non-informaticiens.

L'indpendance entre les donnes et les programmes d'application : les donnes et les programmes tant spars, ce ne sont plus les applications qui sont charges de structurer, d'organiser et de vrifier les donnes et de les stocker dans des fichiers. Les donnes sont dfinies et structures par le SGBD qui offre cette structure aux applications. L'indpendance est la fois logique (au niveau de la dfinition des donnes) et physique (au niveau du stockage et de la gestion de la mmoire). Le SGBD assure la persistance des donnes : alors que les rsultats d'une application sont lis l'excution de l'application, l'existence des donnes d'une base est assure indpendamment de leur utilisation. Les donnes d'une base ont donc une dure de vie suprieure la dure de vie du programme qui les cre ou qui les utilise. L'administration centralise des donnes : une des fonctions essentielles des SGBD est la dfinition des structures de donnes, la dfinition et l'organisation des structures de stockage, les modifications de ces structures, les contrles de validit et de cohrence. Il est essentiel de centraliser ces fonctions : c'est l'administrateur du systme qui gre l'ensemble des donnes, indpendamment de leur utilisation et des applications. Les usagers ou les applications sont dchargs de toute tche d'administration, et peuvent utiliser les donnes de la base sans se proccuper de l'administration de ces donnes tout en tant assurs de leur validit et leur cohrence. Un SGBD permet d'optimiser l'administration des donnes en centralisant ces tches dans l'entreprise. Grer la mmoire de faon optimale : chaque SGBD optimise le stockage et l'accs aux donnes, en utilisant des techniques complexes inaccessibles aux programmes d'application eux-mmes. En vitant les redondances, il optimise galement le volume des donnes stockes. Avec un SGBD, on est donc sr d'avoir accs de volumineux ensembles de donnes de manire efficace. Grer le partage des donnes entre usagers : c'est le SGBD qui va se charger de grer les accs concurrents, les mises jour, le tout en fonction des droits de chacun. Chaque usager aura l'illusion d'tre seul utiliser les donnes de la base, qu'il verra assembles et structures comme il le souhaite. Assurer la fiabilit, l'intgrit, la cohrence : la description du schma des donnes contient un certain nombre de rgles qui permettent de vrifier la fiabilit, l'intgrit, la cohrence de tous les objets prsents dans la base (par exemple, lge d'une personne doit tre compris entre 0 et 120; lge d'un enfant ne peut tre

De lobjet la collection dobjets 133 suprieur celui de ses parents, etc.). Le SGBD contient des procdures spciales permettant d'effectuer l'ensemble de ces tests. Par exemple, les contraintes d'intgrit sont des rgles qui prcisent la cohrence smantique des donnes entre elles. Scurit des donnes : tous les utilisateurs d'une mme base n'ont pas ncessairement les mmes droits d'accs aux donnes. Il est utile de pouvoir dfinir de tels droits pour assurer la scurit de certaines donnes confidentielles et rserves certains groupes d'utilisateurs. Assurer les interrogations interactives et l'accs aux non-informaticiens : les donnes de la base sont bien gres et bien organises. Il ne reste plus qu' les consulter, objectif initial de toute la dmarche, sans avoir se proccuper du stockage ou de l'organisation interne. Le SGBD offre un certain nombre de fonctions pour accder aux donnes de faon dclarative, aussi bien pour les programmes d'applications que pour l'usager, sans avoir effectuer le moindre dveloppement informatique particulier. L'architecture client-serveur est la plus efficace pour rpondre aux objectifs d'indpendance physique et logique, de partage entre usagers, d'interrogation interactive, dans le cadre des rseaux et de l'informatique dcentralise. Le serveur gre toutes les transactions avec les clients et rpond leurs requtes, et est ddi ces tches. Cette architecture permet de nombreux clients d'accder partir de petites machines de grandes bases de donnes, de manire trs efficace. 5.2.3. La modlisation de la ralit dans les SGBD Puisqu'il y a indpendance entre donnes et application, le SGBD doit galement proposer un modle pour crer et dcrire des objets partir de la vision de la ralit en collections d'objets, indpendamment de leur utilisation par les programmes ou les applications. Ce formalisme permet de dfinir la structure des donnes et offre un ensemble d'oprateurs destins manipuler ces donnes. De nombreux modles ont t dfinis : hirarchique, rseau, relationnel, objet. 5.2.3.1. Les diffrents modles de donnes Sparer donnes et applications nous oblige passer du concept de donnes celui d'objet, entit schmatisant la ralit et ayant une dfinition smantique intrinsque. Comme nous l'avons dj vu, il n'y a pas de vision universelle de la ralit lorsqu'il s'agit de dfinir des objets par leur contenu smantique. C'est chaque domaine d'application qui dtermine la modlisation du rel en objets de faon contextuelle, mais malgr tout d'une manire beaucoup plus globale que lorsqu'il s'agit d'utiliser des donnes pour une seule application. Le SGBD offre un formalisme de description et des utilitaires permettant d'aboutir un ensemble

134

Chapitre 5

cohrent d'objets bien structurs, et propose un ensemble d'oprateurs destins manipuler ces objets. Chaque application du domaine concern par cette vision du rel devra choisir ses donnes parmi les objets que lui propose le SGBD. C'est la diffrence de ces formalismes, ou modles de donnes, qui fait la diffrence entre les SGBD. Il ne s'agit pas de dcrire des objets en particulier, mais les proprits d'ensembles d'objets, puisque ce sont les collections d'objets qui nous intressent et non plus les objets isols. On appelle type d'objet un ensemble d'objets possdant des caractristiques similaires et manipulables par des oprations identiques. Un objet sera donc vu ici comme un lment d'un ensemble d'objets. Un modle de description, c'est un ensemble de concepts et de rgles de composition de ces concepts permettant de dcrire des ensembles d'objets. Toute description s'effectue au niveau du type, l'aide d'un ensemble d'lments descriptifs permettant d'exprimer les proprits d'ensembles d'objets et composant un modle de description de donnes. Un modle de description de donnes est mis en uvre l'aide d'un langage de description de donnes. Si le modle de donnes est simple, il sera facile utiliser mais risque de trop simplifier la description du rel, ou de ne pas permettre cette description dans certains domaines, lorsque les structures adquates et les oprateurs associs n'ont pas t prvus. S'il est complexe, les objectifs des SGBD seront difficiles assurer, notamment en ce qui concerne la fiabilit, la cohrence, et la facilit d'utilisation par de non-informaticiens. De nombreux modles de description ont t dfinis. Les principaux sont le modle hirarchique, le modle rseau, le modle relationnel et le modle objet. 5.2.3.2. Les niveaux de description Quelque soit le modle de donnes, on distingue trois niveaux de description (fig. 5.1) : - le niveau conceptuel, dont nous avons dj longuement parl au chapitre prcdent, et qui correspond la conception des objets, c'est--dire la structure smantique des donnes, sans aucun souci d'implantation en machine. On distingue plusieurs types de donnes pour dcrire des objets : les types lmentaires, prenant leur valeurs dans un ensemble bien dfini (N, Z, R, R2, R3, C, ...), les mthodes (fonctions ou plus gnralement relation sur les types prcdents), et les types complexes (prenant leurs valeurs dans des ensembles d'objets). - le niveau interne, qui correspond la structure de stockage supportant les donnes (fichiers, structures, organisation et chemin d'accs), en gnral inaccessible aux usagers, uniquement grs par le SGBD,

De lobjet la collection dobjets 135 - le niveau externe, correspondant aux descriptions du rel perues par les applications ou groupes d'utilisateurs du domaine, et qui correspondent des vues partielles des objets dduites du niveau conceptuel.

Externe Externe

Externe

Externe

Externe

Niveau conceptuel Niveau interne

fig. 5.1 : les diffrents niveaux de description

C'est le SGBD qui fait le lien entre les diffrents niveaux de description : il a besoin pour cela de toutes les descriptions et des rgles de correspondance entre ces descriptions, qui sont conserves dans ce que l'on appelle le dictionnaire des donnes. La dfinition des diffrents schmas est thoriquement assure par un administrateur de donnes. Les schmas, les rgles associes, la description smantique sont stockes dans le dictionnaires des donnes, et qui peut lui-mme tre organis comme une base de donnes. Si lon prend lexemple du cadastre, les entits clairement identifiables sont : les parcelles, les constructions, les proprits, les propritaires, les transactions. Les transactions sont des associations entre propritaires et proprits, avec des attributs comme la date dachat, le prix, etc. Nous allons dcrire rapidement les modles hirarchique et rseau, et plus en dtail le modle relationnel et le modle objet. Nous verrons ensuite comment utiliser ces deux derniers modles pour grer et manipuler des objets gographiques. 5.2.4. Les modles hirarchique et rseau Ces deux modles datent des annes soixante. Le modle hirarchique permet de dcrire des liens hirarchiques entre objets : le schma entre objets est construit

136

Chapitre 5

uniquement grce ces liens hirarchiques. Dans le modle rseau, on peut tablir des liens entre objets, dans tous les sens. Dans ces deux modles, l'indpendance entre structure logique et structure physique n'est pas vraiment respecte, et les possibilits des structures logiques sont calques sur les problmes d'implantation physique et d'accs aux donnes. Les structures logiques et les relations entre objets ne sont que la reprsentation logique de pointeurs entre objets (physiquement des tables d'index reliant les enregistrements de diffrents fichiers), et tout le formalisme des modles repose sur la navigation dans la base grce ces pointeurs : le formalisme d'interrogation (d'ailleurs souvent complexe) repose sur la connaissance de l'existence de ces pointeurs et donc sur des ordres lmentaires de navigation, et non sur un langage de plus haut niveau permettant de s'affranchir des liens physiques entre objets. Les objectifs des SGBD, au niveau de lintgrit et de la cohrence des donnes, et de lindpendance physique et logique entre donnes et programmes dapplications, ne sont pas assurs par ce modle. 5.2.5. Le modle relationnel 5.2.5.1. Les principes du relationnel Le modle relationnel a t introduit dans les annes soixante-dix pour avoir une totale indpendance entre les structures logiques et physiques, ce qui n'tait pas le cas avec les modles antrieurs (hirarchique et rseau). Il utilise un modle de description trs simple, mais rigoureusement dfini et permettant ainsi de remplir un bon nombre des objectifs des SGBD. Les objets sont dcrits par des attributs simples, qui prennent chacun leurs valeurs dans un ensemble de valeurs appel domaine. Les attributs sont simples : les domaines sont soit des ensembles finis, soit des valeurs entires ou relles (N, Z ou R). Un type d'objet peut tre dcrit par des attributs, et est appel une relation. Puisque chaque attribut est de type simple, les objets d'une relation peuvent tre reprsents par une table donnant les valeurs des attributs pour chaque objet (appel alors tuple). Les oprateurs de manipulation des objets n'utilisent que des oprations lies aux domaines des attributs : soit des oprations ensemblistes (pour les domaines finis), soit des oprations lies l'ordre naturel dans N, Z ou R. Le terme de relation vient de la dfinition mathmatique du modle : les objets d'un type d'objets correspondent un sous-ensemble du produit cartsien d'un ensemble de domaines, ce qui peut tre vu comme une relation entre ces ensembles. Le modle de description est donc trs simple : pas de types complexes, pas de dfinition rcursive, pas de mthodes ou fonctions. Tous les attributs prennent leurs valeurs dans des ensembles finis ou ordonns de dimension 1. Les oprateurs associs pour valider ou manipuler les tuples vont tous tre dvelopps sur cette

De lobjet la collection dobjets 137 simplicit de description. Le succs du relationnel vient en grande partie de cette simplicit, qui a permis la mise en uvre effective de la plupart des objectifs des SGBD. Les oprateurs lis au formalisme de description sont galement simples. Ils se divisent en deux grandes familles : les oprateurs de description (thorie de la normalisation), et les oprateurs de manipulation (algbre relationnelle). L'inconvnient majeur du relationnel, c'est qu'il est difficile sinon impossible de modliser des objets complexes : les objets gographiques en fournissent de nombreux exemples (par exemple, aucun formalisme ne permet d'utiliser une distance pour mettre en relation deux objets). 5.2.5.2. La notion de cl et la thorie de la normalisation Une mauvaise perception de la ralit, une mauvaise conception des entits et associations conduit des relations qui souffrent d'anomalies et prsentent le plus souvent des redondances. Ces redondances conduisent des risques d'incohrences lors des mises jour. Pour viter cette mauvaise perception, le modle relationnel propose un certain nombre de notions qui permettent d'aboutir, par dcomposition partir de l'ensemble des attributs, des relations ne souffrant pas d'anomalies. Il est ncessaire pour bien dfinir les relations d'tudier les proprits smantiques des attributs et de dfinir les dpendances entre attributs qui rsultent de ces proprits. Ces dpendances sont classes en trois types : - les dpendances fonctionnelles : un attribut b dpend fonctionnellement d'un attribut a si toute valeur de a correspond une valeur unique de b : A B ((xy R et xy' R) y = y') On introduit la notion fondamentale de cl partir de la notion de dpendance fonctionnelle : une cl est un ensemble minimum d'attributs qui dtermine tous les autres (tous les attributs sont en dpendance fonctionnelle avec la cl). - les dpendances multivalues qui caractrisent l'indpendance de deux ensembles d'attributs corrls un mme troisime : b dpend de a si toute valeur de a dtermine un ensemble de valeurs de b indpendamment des autres attributs de la relation : A B ((xyz R et xy'z' R) (xy'z R et xyz' R)) - les dpendances de jointures qui permettent de dcrire les relations entre sousensembles d'attributs d'une relation. A partir de l'ensemble des attributs et de leurs dpendances, des algorithmes pourront dterminer les entits et les associations canoniques, et fournir des relations qui ne souffrent pas d'anomalies : cette opration se fera par dcomposition successive jusqu' l'obtention de relations dites normalises.

138

Chapitre 5

La thorie de la normalisation dfinit cinq formes normales pour les relations : - une relation est en premire forme normale si tout attribut contient une valeur atomique. - une relation est en deuxime forme normale si elle est en premire forme et si tout attribut n'appartenant pas une cl ne dpend pas que d'une partie de cette cl. - une relation est en troisime forme normale si elle est en deuxime forme et si tout attribut n'appartenant pas une cl ne dpend pas d'un attribut non cl. - une relation est en quatrime forme normale si et seulement si les seules dpendances multivalues lmentaires sont celles dans lesquelles une cl dtermine un attribut. - une relation est en cinquime forme normale si et seulement si toute dpendance de jointure est implique par les cls candidates de la relation.

La thorie de la normalisation est peu applique en pratique dans les SIG, alors que la complexit des objets engendre souvent une mauvaise perception du rel et une mauvaise conception des relations. 5.2.5.3. L'algbre relationnelle Une fois la base de donnes constitue, il faut pouvoir l'interroger et la modifier grce un langage, lui-mme bas sur un ensemble d'oprations lmentaires. Dans le cas du modle relationnel, ces oprations formelles s'appliquent aux relations et leur attributs. Les oprations de base sont : - l'union de deux relations A et B de mme schma : la relation rsultante est de mme schma que A et B et a pour tuples l'union des tuples de A et B. - la diffrence de deux relations A et B de mme schma : la relation rsultante est de mme schma que A et B et a pour tuples la diffrence ensembliste des tuples de A et B. - le produit cartsien de deux relations de schmas quelconques : la relation rsultante a pour schma la concatnation des schmas de A et de B et pour tuples le produit cartsien des deux ensembles de tuples de A et B. Cette opration comme on peut s'en douter, est des plus coteuses. - la projection d'une relation sur un certain nombre de ses attributs : la relation rsultante a pour schma les attributs sur lesquels la projection est faite, les tuples tant obtenus par limination des valeurs d'attributs n'appartenant pas au schma rsultant, ainsi que par limination des tuples en double. - la restriction d'une relation A par une qualification Q : la relation rsultante est de mme schma et a pour tuples les tuples de A qui satisfont la qualification Q. - la jointure de deux relations A et B selon une qualification Q : la relation rsultante est la restriction du produit cartsien de A et B sur la qualification Q. Cette opration est fondamentale, car elle permet de relier deux relations sur un ou plusieurs de leurs attributs et de crer une troisime relation rsultant du croisement.

De lobjet la collection dobjets 139 Il est important de noter que la jointure ne conserve pas la notion de cl : si A1 est cl de la relation R1 et A2 cl de la relation R2, A1 ne sera vraisemblablement plus cl de la relation R3 rsultat d'une jointure entre R1 et R2. L'ensemble (A1,A2) sera une cl de la relation R3 s'il fait partie de cette nouvelle relation. Il est possible de rpondre la plupart des questions que l'on peut poser une base de donnes relationnelle par un enchanement d'oprations de base, que lon appelle alors une requte. Les interrogations d'une base de donnes relationnelle peuvent tre exprimes directement en terme d'oprations relationnelles, ou grce des langages d'interrogations bass sur la vrification de formules dont les variables sont soit des tuples, soit des valeurs d'attributs. 5.2.5.4. Puissance et limite du modle relationnel La puissance du modle vient surtout de la rigueur de ses concepts et de leur simplicit, deux choses qui permettent une vritable mise en uvre des objectifs assigns aux SGBD, alors que c'est difficilement ralisable sur les modles hirarchique et rseau, et mme orient objet. Les limites du modle relationnel sont inhrentes sa dfinition mme : il ne concerne que des types d'attributs simples. Si les objets ne peuvent tre dcrits l'aide d'attributs de type simple, le modle fonctionne mal ou ne fonctionne pas du tout. Par exemple, il n'est pas prvu de dcrire des images ou d'utiliser des donnes bidimensionnelles; il n'est prvu aucun oprateur d'interrogation li une distance entre deux objets. Le modle gre mal la hirarchie, ou alors au prix de coteuses jointures. Il ne propose aucune mthode sur les donnes, laissant aux applications le soin d'utiliser le contenu smantique des relations. 5.2.6. Le modle objet Le modle objet prend justement la dmarche inverse. La description est la plus complexe possible, quitte abandonner les objectifs principaux des SGBD, sauf celui d'indpendance entre structure physique et structure logique [BER 93] [DEL 91]. 5.2.6.1. Lapproche objet : donnes et mthodes, encapsulation et hritage Prenant une dmarche inverse la dcomposition en relation disjointe, lapproche objet tente de reprsenter de faon naturelle des objets dans toute leur complexit, aussi bien descriptive que procdurale. Un objet permet de regrouper sous un mme lment une structure de description (des attributs) et un comportement (sa faon dagir ou de ragir, dcrit par des mthodes). Les attributs

140

Chapitre 5

peuvent tre lmentaires, cest--dire dun type simple (entier, rel, date, etc.), mais peuvent galement tre dautres objets. Lun des intrts majeurs de lapproche objet consiste dans sa capacit dcrire et grer les entits du monde rel en un formalisme hirarchique (des attributs sont eux-mmes des objets), et en associant donnes et procdures. La notion de classe correspond au schma dun objet (description des attributs et des mthodes). Un objet est alors considr comme linstance dune classe. Les systmes objets implmentent la notion didentit dobjet, qui permet de didentifier un objet indpendamment des valeurs de ses attributs. Cet identificateur interne est unique pour chaque objet, il permet de sparer lexistence de lobjet de la valeur de ses attributs. Cette notion est importante dans la gestion des attributs complexes, puisque la valeur de lattribut dune classe peut tre un objet dune autre classe, objet qui doit donc pouvoir tre point indpendamment de ses valeurs qui, elles, peuvent changer. Nous retrouverons rapidement cette notion dans les SIG, qui ont souvent besoin didentifier un objet indpendamment de la valeur de ses attributs. Lencapsulation est le concept permettant de regrouper dans une mme classe des attributs et des mthodes, et de ne permettre la manipulation dun objet que par les mthodes dfinies dans la classe laquelle il appartient. Lencapsulation induit donc deux niveaux de perception et de reprsentation dun objet : le niveau externe, accessible par les utilisateurs, et le niveau interne, accessible uniquement par les mthodes. Elle garantit en principe lintgrit des objets, qui ne peuvent tre manipuls par des lments extrieurs que via des mthodes que la classe propose. Lhritage est galement un concept important implment par le modle objet : il permet de modliser la hirarchie de classes. Une classe drive dune autre hrite de lensemble de ses attributs et de ses mthodes. Lhritage peut tre simple (une classe drive dune seule classe) ou multiple (une classe drive de plusieurs classes, et regroupe donnes et mthodes de plusieurs classes). Lutilisation du modle orient objet stend des domaines trs varis, sappliquant aux langages de programmation, la reprsentation des connaissances, aux modles et bases de donnes. 5.2.6.2. les SGBD objets Les systmes de gestion de bases de donnes orient objet tentent de combiner les possibilits des SGBD classiques et les avantages de la modlisation objet, trs riche dans laspect procdural et plus proche du rel par lintroduction de types complexes pour les attributs. Un SGBDOO est construit pour grer des collections dobjets, suivant un schma de donnes correspondant la dfinition de classes

De lobjet la collection dobjets 141 dobjets. Un SGBDOO regroupe donc des caractristiques des SGBD (persistance des objets, scurit des accs, etc.) et les avantages de lapproche objet (identit dobjet, encapsulation, objet complexe, hritage, etc.). Mais lintroduction de certaines de ces caractristiques sont peu compatibles avec les objectifs des SGBD tels que nous les avions exprims au dbut de ce chapitre : - le comportement des objets nest plus du seul ressort des programmes dapplications. Le SGBD redevient ainsi peu peu un vritable programme dapplication, mme si la persistance des objets et gestion des collections est assure indpendamment du schma des objets. Il ny a plus vraiment indpendance entre les donnes et les programmes dapplications, puisque les objets ne peuvent tre manipuls quau travers de leurs mthodes; - lintgrit et la cohrence des donnes devient difficile assurer dans un modle ou des attributs font rfrences dautres objets complexes. Malgr ces inconvnients, les SGBDOO reprsentent une avance conceptuelle importante, mme si les systmes relationnels restent de loin les systmes les plus employs aujourdhui. Une approche hybride dextension du relationnel par certains concepts objet peut tre trs bnfique. Cest lapproche que nous dvelopperons dans la suite de ce chapitre, avec dans un premier temps lintroduction de types gnriques dobjets et dattributs complexes. Les SIG introduisent naturellement la notion dobjet, car lutilisation du modle cartographique pour la modlisation des donnes gographiques introduit des types diffrents pour les objets. Chaque classe de base possde des mthodes qui lui sont propres (par exemple, la surface ou le primtre pour le type zone, le plus court chemin dans un rseau pour le type ligne, etc.). Le modle objet ne permet pas dassurer les contraintes dintgrit comme le fait le modle relationnel, mais il permet de rpondre une modlisation plus complexe en introduisant des types dobjet et des attributs complexes : il correspond mieux la ncessit de modlisation de linformation gographique, et semblerait mieux adapt aux diffrents problmes de modlisation que nous avons rencontrs au chapitre 3. 5.3. SGBD et objets gographiques : l'extension du modle relationnel Intgrer l'attribut de localisation dans le schma relationnel permettrait de bnficier sur cet attribut de toute la puissance du modle, de simplifier les oprations de manipulation et les interrogations utilisant la localisation dans l'espace en mettant ces oprations au mme niveau que les oprations sur les relations non localises.

142

Chapitre 5

5.3.1. Objectifs Nous allons donc tendre le modle relationnel aux attributs prenant leurs valeurs dans un espace de dimension deux ou trois, et aux objets reprsentant soit un lment de cet espace, soit un ensemble dlments (sous-ensembles de dimension 0, 1 ou 2). Nous allons galement complter l'algbre relationnelle par de nouvelles oprations algbriques lies au caractre multidimensionnel de l'attribut de localisation : - la restriction spatiale, qui correspond la slection d'objets par rapport leur localisation - la jointure spatiale, qui correspond la mise en relation de deux objets par rapport leur localisations respectives - la projection spatiale, qui correspond l'opration d'impression de l'attribut de localisation et qui devient ici une opration de cartographie Ces nouvelles oprations, et surtout les deux premires, vont permettre de manipuler la localisation grce des oprations algbriques et logiques : c'est dans ce sens que la localisation, considre habituellement comme un rsultat graphique, va devenir galement le rsultat intermdiaire d'une squence d'oprations de gestion et de manipulation de donnes qui peut trs bien ne pas avoir de rsultats finals graphiques. Le caractre relativement universel de la localisation permet d'envisager de nombreuses mises en relation d'objets par opration une jointure spatiale en relations localises, et ceci indpendamment du codage ou de la mthode de reprsentation de la localisation. La seule restriction, et elle est de taille, provient de la prcision smantique lie cette localisation, et de la modlisation de la ralit, comme nous lavons vu au chapitre 3. L'intgration de la localisation dans le schma relationnel est donc trs riche, aussi bien par la puissance de manipulation qu'elle apporte que par les contraintes et les problmes de reprsentation et de validit de l'information localise qu'elle met en vidence. 5.3.2. Lextension du modle relationnel 5.3.2.1. Les principes de lextension du modle Le modle relationnel ne concerne que des types d'attributs simples. Ces attributs prennent leurs valeurs dans un ensemble fini ou ordonn de dimension un. Les oprations classiques de l'algbre relationnelle sont limites aux attributs de type simple, et sont lies la structure d'ordre canonique des ensembles de dfinition.

De lobjet la collection dobjets 143 La localisation spatiale ne rentre pas dans le cadre des attributs simples, puisque cet attribut prend ses valeurs dans un espace de dimension 2 ou 3. Il faut donc tendre le modle relationnel classique pour qu'il puisse grer des objets localiss en en conservant la structure multidimensionnelle [SOU 86]. Il n'existe pas de structure d'ordre canonique dans un espace de dimension suprieure 1 qui puisse tre utilise dans la rsolution de problmes spatiaux lis la proximit ou la distance : la structure d'ordre canonique de la dimension 1 doit tre remplace par une structure topologique ou une structure mtrique. Les oprations de l'algbre relationnelle lies l'attribut de localisation ne sont plus dfinies dans un espace une dimension, mais deux ou trois. Les relations entre objets ne s'expriment donc plus partir d'une relation d'ordre, mais partir d'une topologie ou d'une distance. Ainsi, un domaine de restriction ne sera plus une valeur ou un intervalle, mais un domaine de l'espace mtrique. Un critre de jointure gographique ne sera plus une relation entre les valeurs des objets eux-mmes, mais une relation ensembliste ou une relation entre les valeurs des distances entre les objets [SOU 86]. D'une manire classique, la localisation des objets gographiques s'exprime soit par des lments de l'espace (pour les objets dont la localisation peut tre ramene un point), soit par des sous-ensembles de l'espace (lignes ou zones). L'extension du modle relationnel ne concerne donc pas seulement le domaine de dfinition des attributs (l'espace de dimension 2 ou 3) : il introduit galement des types dans la dfinition des relations, se rapprochant ainsi du modle objet. Les contraintes d'intgrit ne seront pas les mmes suivant le type des objets. Nous leur consacrons un chapitre spcial. La schmatisation gomtrique de la localisation des objets gographiques en zone, ligne, point, pixel tablit une classification naturelle sur laquelle repose la fois l'extension du modle relationnel et la dfinition de classes d'objets gographiques pour le modle objet. Cette classification est trs discriminante, elle sera donc prsente trs rapidement comme membre des objets gographiques. Pour l'extension du relationnel, elle intervient au niveau de la dfinition des relations, puisque d'elle dpend la mise en uvre des oprations de l'algbre relationnelle. Pour le modle objet, peu de classes d'objets non localiss peuvent prtendre encapsuler des classes d'objets gographiques localiss. Toutes les considrations ultrieures seront donc bases sur la classification suivante, que nous avons dj vue au chapitre prcdent et qui permet de schmatiser la gomtrie des objets gographiques et de dfinir des collections dobjet du mme type : les objets point, dont la localisation est un point de l'espace,

144

Chapitre 5

les objets ligne, dont la localisation est un sous-ensemble de dimension 1 de l'espace, en gnral schmatise par un pour plusieurs arcs (ligne brise entre des points), les objets zone, dont la localisation est un sous-ensemble de dimension 2 de l'espace, en gnral dfini par un ensemble d'arc (schmatisant le contour de la zone), les objets pixel, dont la localisation est un sous-ensemble de dimension 2 de l'espace dfinie par un point (tous les pixels ont une gomtrie identique - maille carre, hexagonale, etc.). Un arc n'est pas un objet gographique, mais seulement un objet gomtrique. Les contraintes d'intgrit gomtriques seront exprimes sur les points et les arcs, c'est--dire sur les objets gomtriques qui permettent de dfinir la localisation des objets gographiques. 5.3.2.2. Relations localises et notion de cl gographique Rappelons la dfinition dune cl dans le cas dun attribut de dimension 1 : une cl est un ensemble minimum d'attributs qui dtermine tous les autres. On peut donc introduire la notion de cl gographique, lorsque, dans une relation contenant un attribut de dimension deux, cet attribut de localisation dtermine la valeur de tous les autres attributs descriptifs. En fait, on rige cette dpendance en contrainte : par dfinition, une relation est dite localise si et seulement si lattribut de localisation est une cl pour les attributs descriptifs. Dans une relation localise, on a donc lassurance que deux objets distincts ne partagent pas le mme espace : il y a unicit dun phnomne en un lieu. Les objets dune relation localise sont appels objets localiss. Seuls les objets localiss contiennent une description explicite de leur localisation (telle que nous lavons vue au chapitre 3). Lorsque la localisation nest pas une cl gographique (donc dans une relation non localise), elle peut tre ramene un attribut descriptif classique (nominal, de dimension un) faisant rfrence la localisation relle. Par exemple, une relation dcrivant des dpartements, avec la localisation comme cl gographique, va contenir un attribut de localisation qui sera dcrit de faon interne par des points et des arcs. Cette relation est localise, et les objets sont des objets localiss. Chaque dpartement a un nom : cet attribut descriptif nominal est galement cl de la relation. Une relation dcrivant des personnes, avec un attribut donnant le dpartement de naissance, nest pas une relation localise, mme si elle contient un attribut donnant une localisation (le dpartement), car cette localisation nest pas une cl de la relation. Dailleurs, dans ce cas, la localisation ne va pas utiliser des points et des arcs, mais bien un attribut descriptif classique donnant le nom du dpartement. On pourra retrouver la description de la localisation

De lobjet la collection dobjets 145 (cest--dire lattribut spatial de localisation, et son expression en points et arcs) en utilisant une semi-jointure classique sur cet attribut descriptif. La notion de cl gographique est trs importante : elle est la base de lextension du modle relationnel que nous proposons. En effet, il ne serait pas possible de bien grer un modle dans lequel la description de la localisation des objets serait donne quelle que soit lattribut (cl ou non). 5.3.3. Les extensions de l'algbre relationnelle Toutes les oprations que nous allons ajouter l'algbre relationnelle portent sur l'expression de la localisation dans l'espace, et donc intrinsquement sur le mme attribut. Si l'on dispose d'une rfrence unique pour l'attribut de localisation, et pour chaque relation de la description de la localisation des objets par rapport cette rfrence, tout objet pourra tre mis en relation avec n'importe quel autre objet ainsi localis, indpendamment d'un systme de rfrence attach telle ou telle entit. Le systme de rfrence unique est bien sr l'espace mathmatique euclidien : l'attribut de localisation est alors de dimension deux ou trois, sans relation d'ordre canonique (lie la mtrique dfinissant la structure de l'espace). La qualification des oprations de restriction ou de jointure porte sur un attribut de dimension deux ou trois. Elle n'est plus lie une structure d'ordre mais la structure mtrique de l'espace euclidien. Quel que soit le type de reprsentation utilise pour la localisation, il va falloir formellement passer de nouveau par l'espace euclidien pour mettre les objets en relation sur leur localisation : il s'agit maintenant de repasser de l'espace de reprsentation l'espace euclidien, de l'entit drive l'entit initiale, l'inverse de la dmarche expose dans le chapitre prcdent. L'attribut formel de localisation sera not loc dans la suite, et sa valeur reprsente l'ensemble des points de l'espace euclidien attach un objet. Il est, de par son caractre formel, indpendant du type de reprsentation utilis pour la localisation des objets dans la base et des mthodes effectives de ralisation des oprations algbriques. Cet attribut formel, associ s'il y a lieu un attribut temporel, dtermine l'ensemble des attributs descriptifs de la relation : la localisation spatio-temporelle constitue toujours une cl d'une relation localise. Nous allons complter l'algbre relationnelle par de nouvelles oprations algbriques concernant l'attribut multidimensionnel de localisation : la restriction spatiale, la jointure spatiale, la projection spatiale.

146

Chapitre 5

5.3.3.1. La restriction spatiale C'est l'opration correspondant la slection des objets par rapport un domaine dfini de l'espace, not D. Ce domaine peut tre dfini soit directement (fentre d'tude, domaine dfini par lutilisateur en coordonnes ou sur un cran, etc.), soit par rapport aux objets dune autre relation : zone autour dun point, espace autour dune ligne ou dune zone. Nous verrons plus tard comment le concept de masque permet de manipuler facilement ces domaines de restriction. Plusieurs types dopration de restriction spatiale peuvent tre envisags quand les objets sont des ensembles de points, en prenant une qualification ensembliste plutt que mtrique. La qualification peut utiliser lensemble des points de lobjet (inclusion, intersection), ou un point particulier de lobjet (appartenance). Le point particulier de lobjet est appel centrode : il peut tre choisi manuellement lors de la dfinition gomtrique de lobjet, ou automatiquement partir de la gomtrie de lobjet. Si A dsigne un objet et D le domaine de restriction, on peut ainsi dfinir les diffrentes oprations de restriction spatiale : A D lobjet A est inclus dans le domaine D A D lobjet A a une intersection non vide avec le domaine D A D = restriction par exclusion, si A et D sont disjoints a D le centrode de A appartient D

Contrairement la restriction classique, la restriction spatiale peut modifier les objets lorsquil sagit dune qualification ensembliste concernant lintersection. En effet, le rsultat de la restriction peut tre lobjet lui-mme (pas de modification de la localisation) ou lintersection de lobjet et du domaine de restriction. Dans ce cas, il y a modification de lattribut de localisation. Par contre, il ny a pas modification du type dobjet (une zone reste une zone, une ligne reste une ligne). Les attributs descriptifs ne sont jamais modifis par une opration de restriction. 5.3.3.2. La jointure spatiale De toutes les oprations algbriques, la jointure est certes la plus importante en pratique, car, comme nous lavons soulign, cest elle qui permet la mise en relation de deux tuples par le biais dun attribut commun, en crant ainsi un nouvel objet ayant les caractristiques des deux objets rpondant la qualification de jointure, et correspondant dans la nouvelle relation un tuple form de valeurs dattributs des deux tuples mis en relation. La jointure spatiale est donc lopration de jointure portant sur lattribut de localisation. La qualification de jointure sexprime soit par rapport la distance entre deux objets : a1 d(O1,O2) a2

De lobjet la collection dobjets 147 soit par rapport une relation ensembliste entre les objets : O1 O2 = O1 O2 O1 O2 O1 O2 Par exemple, a2 = 0 (d(O1,O2) = 0) signifie que deux points de lespace sont mis en relation sils ont la mme localisation . On parle alors dquijointure gomtrique. Pour bien dfinir cette opration, il est ncessaire de revenir lespace gomtrique de rfrence et de repasser du type de reprsentation des objets en zones, lignes, points aux objets lmentaires que sont les points de lespace euclidien avec leur localisation intrinsque. Lopration de jointure spatiale seffectue, en thorie, en considrant que les seuls objets logiques sont les points de lespace. Le rsultat de lopration de jointure pourra nouveau faire lobjet dun changement de reprsentation, du type passage entit principale-entit drive. Le cheminement thorique dune jointure spatiale est donc : Espace de reprsentation Espace euclidien Jointure sur les points de lespace euclidien Espace de reprsentation (si ncessaire). La jointure spatiale cre de nouveaux objets. La description de la localisation de ces objets pose les mmes problmes que la description de la localisation des objets initiaux : les nouveaux objets sont des points ou des ensembles de points de lespace euclidien, quil est ncessaire de regrouper et de dcrire dune manire ensembliste avec les choix possibles que nous avons vus au chapitre 3. Bien sr, les mthodes de ralisation de la jointure et de la description de la localisation des rsultats seront fonction du type de description des objets initiaux. La jointure spatiale est une opration trs intressante dans la mesure o elle permet de comparer des objets sur leur localisation, sans avoir spcifier et dcrire cette localisation. Le rsultat peut dailleurs tre considr davantage au niveau de cette mise en relation, plutt quau niveau du rsultat graphique form par les tuples de la nouvelle relation. Ainsi par exemple, on pourrait mettre en relation la relation

148

Chapitre 5

Parcelle (numro, nom de propritaire, nombre de construction,) et la relation Bornes dincendie (numro, dbit) sur la qualification d(O1,O2) < 100 mtres pour avoir la liste des numros de parcelles et le nombre de constructions associes une borne plutt quune carte des parcelles ou portions de parcelles et bornes rsultant de la jointure. Les jointure du type d(01,O2) = 0 sont appeles des qui-jointures gomtriques. Si la qualification de jointure est d(O1,O2) < a, les rsultat est plus complexe puisquil correspond un ensemble dobjets pour lesquels la localisation ne constitue plus une cl : un point peut apparatre plusieurs fois avec des descripteurs diffrents sil rpond la qualification de jointure pour plusieurs objets de chaque relation. La notion de cl de localisation nest pas conserve par la jointure spatiale, comme cest dailleurs le cas pour le rsultat dune jointure classique. Dans ce cas, le rsultat sera une relation non localise, et le rsultat sera impossible reprsenter cartographiquement car nous navons plus de dpendance fonctionnelle des attributs descriptifs par rapport la localisation : on peut avoir des tuples forms du mme ensemble de points mais ayant des valeurs descriptives diffrentes.
P1 profils P2 P3 P1 P2 P3 Z1 Z2 Z3 couleur rouge jaune ocre pente 10-20 20-30 10-20 Ph 7.5 5.8 6.5 pierrosit faible moyenne trs faible salinit faible trs faible moyenne

Z1 potentialits

Z3 Z2

jointure

Q2 Q1

Le rsultat de la jointure est compos des points Q1 et Q2 : Q1 Q2 couleur Ph rouge 7.5 jaune 5.8 pente 10-20 10-20 pierrosit faible trs faible salinit faible moyenne

fig. 5.2 : jointure entre zones et points sur la qualification d(O1,O2)=0

De lobjet la collection dobjets 149

zone

z1

z2

z1

zone

z1-z1

jointure

z2-z1

fig. 5.3 : jointure entre zones sur la qualification d(O1,O2)=0

Des exemples de jointures entre relations de type zone sont donns par les figures 5.2 et 5.3. La qualification d(O1,O2) = 0 correspond lintersection des zones et conserve la localisation comme cl de la relation rsultante. La qualification a < d(O1,O2) < b, avec a non nul, donne un rsultat plus complexe et difficile reprsenter graphiquement dans son intgralit, puisque la localisation nest plus une cl de la relation rsultante. La jointure spatiale est une opration dangereuse si les objets mis en relation nont pas la mme chelle de validit, ou si la validit de la localisation par rapport aux donnes descriptives est trop faibles pour permettre le passage de lespace de reprsentation lespace euclidien (pour des donnes caractre statistique par exemple, ou nayant quun intrt de reprsentation graphique). Ainsi, des logiciels proposent des oprations graphiques pour liminer les problmes rsultant de diffrentes prcisions sur les collections dobjets mis en relation (limination de petites zones par exemple). Nous prsenterons au chapitre 8 dautres oprations de mise en relation dobjet, bases sur la jointure spatiale, mais permettant de prendre en compte ces problmes de prcision et de grer les transferts dchelle notamment avec lintroduction de procdures dagrgation spatiale. 5.3.3.3. La projection spatiale La projection spatiale correspond lopration de projection dattributs de lalgbre relationnelle classique (elle na donc rien voir avec les projections gographiques de type UTM ou Mercator). Projeter lattribut de localisation correspond donc une opration de cartographie, exactement comme une projection

150

Chapitre 5

dattributs descriptifs a pour objet la reprsentation en liste des valeurs de ces attributs. Si lobjectif dune requte est purement graphique, on peut donc prsenter lopration de cartographie comme une projection de lattribut de localisation, dans le cadre de lalgbre relationnelle tendue la localisation. Nous verrons au chapitre 9 les nombreuses possibilits de reprsentation graphique lies cette opration. 5.3.3.4 Masques et semi-jointures gomtriques Certaines oprations que nous avons dfinies comme des oprations de restriction sont en fait des jointures : la restriction dune relation sur la localisation des objets dune autre relation est en fait une semi-jointure avec la qualification d(O1,O2) = 0 : on connat a priori lensemble des valeurs de lattribut de qualification, reprsent par le domaine D. Mais lintrt de cette opration rside plus dans la restriction apporte lune des relations que dans la mise en relation effective des attributs des deux relations. Cest pour cela que nous lavons classe comme restriction spatiale : Slection dans la relation R1 Dfinition dun domaine D partir des objets de la relation R2 Jointure de R1 et R2 par rapport D Projection de la jointure sur les attributs de R1 Ces semi-jointures sont intressantes dans la mesure o elles ne font pas perdre la cl de localisation : on conserve donc, comme dans toute restriction, la possibilit dutiliser la localisation dans une opration ultrieure ou de cartographier le rsultat. La dfinition dun domaine de lespace partir des objets dune relation prend donc un caractre particulirement intressant. Cest pour cela que nous avons nomm masque ce type de domaine. Un masque est donc un domaine de lespace qui nintervient dans le processus relationnel que par sa localisation. Des oprations ensemblistes, mtriques ou morphologiques peuvent tre appliques ces domaines de lespace : union, intersection, diffrence, inverse, dilatation, rosion, etc. En utilisant ces oprations, on peut crer des domaines de lespace permettant de rsoudre de nombreuses questions faisant intervenir une restriction spatiale, comme par exemple : slectionner les objets dune relation se trouvant telle distance des objets dune autre relation, slectionner les objets dune relation se trouvant dans une zone de caractristiques donnes, etc.

De lobjet la collection dobjets 151 5.3.4. Objets spatiaux et oprations relationnelles classiques Les oprations de lalgbre relationnelle classique peuvent bien sr tre utilises sur les attributs descriptifs dans le cadre du modle relationnel tendu la localisation. Lincidence de ces oprations est nanmoins importante sur la conservation de la cl de localisation, les problmes tant poss essentiellement par les objets rsultant dune jointure classique. La restriction ou la projection sur un attribut descriptif na pas dincidence directe sur lattribut de localisation. En liminant des objets, la restriction peut nanmoins modifier des caractristiques gomtriques de la relation rsultante (connexit, genre, etc.). La jointure classique de lalgbre relationnelle permet de mettre en relation les objets de deux relations diffrentes de manire crer une nouvelle collection regroupant les objets rpondant au critre de jointure. Lorsque les objets sont localiss, ils sont regroups dans des relations o tous les objets sont de mme type gographique. La jointure classique va donc tre difficile mettre en uvre entre deux relations localises sans perdre la localisation du rsultat. Si les deux relations ne sont pas du mme type, la localisation des objets rpondant au critre de jointure ne peut tre conserve, car elle ne peut tre exprime par les mthodes que nous avons exposes plus haut et ne rentre pas dans le modle relationnel tendu. On pourrait dcider, pour les objets rsultant de la jointure, de ne conserver que la localisation provenant dune des deux relations, mais on risque alors malgr tout de perdre le principe dunicit de cl pour cet attribut. Lorsque les deux relations sont du mme type, on rencontre le mme problme, la localisation risque de perdre son caractre de cl, car les objets rsultant de la jointure pourraient partager le mme espace gographique, comme cest le cas pour la jointure spatiale lorsque la qualification de jointure nest pas d(O1,O2) = 0, et la relation rsultante ne peut donc tre considre comme une relation localise et devient donc une relation dobjets non localiss. Pour viter la perte de la cl de localisation, il est courant deffectuer une opration dagrgation dans une des relations dorigine aprs une jointure classique. Lagrgation doit se faire sur la cl de localisation, et correspond la suppression des doublons sur la localisation. Nous reviendrons en dtail sur ce type doprations dans le chapitre 8. 5.4. La structuration et lindexation de lattribut de localisation La structuration des donnes gographiques en vue damliorer les oprations de recherche en mmoire de stockage est un problme gnral qui concerne lensemble des donnes graphiques de la base, quels que soient les modes de reprsentation choisis. Il sagit ici des mthodes de partage ou dindexation des objets, mthodes

152

Chapitre 5

bases sur leur localisation absolue au niveau de lespace initial de reprsentation. La ncessit dune telle structuration est vidente car linterrogation dune base de donnes localises va faire intervenir en priorit la localisation ; une interrogation classique, dans un SIG, sera en effet souvent du type : retrouver dans telle zone tous les objets de tel type qui rpondent telles conditions. Cette interrogation se dcompose dune manire optimale en : Retrouver tous les objets dans une fentre contenant la zone dtude, Slectionner les objets qui rpondent aux critres de slection. La premire opration, la restriction spatiale, est de loin le critre le plus discriminant, car il repose sur un attribut multidimensionnel (n= 2 ou n=3), face aux oprations de slection sur les attributs descriptifs une dimension. Devant seffectuer en priorit pour optimiser le temps de recherche, elle ncessite laccs possible lensemble des donnes de la base sur les mmoires de stockage et reprsente lopration la plus coteuse en temps dexcution. Lorganisation des donnes doit donc tre conue en priorit par rapport lattribut de localisation. 5.4.1. Les mthodes classiques dindexation Les mthodes classiques de gestion de donnes ont pour objet de rduire le nombre des oprations daccs aux mmoires de stockage. Elles sont bases sur des techniques dindexation dattributs mono-dimensionnels ordonns (accs alatoire, squentiel index) [KNU 73] [LEE 80], et ne sont pas applicables directement lattribut de localisation, qui est par nature multidimensionnel sans relation dordre compatible avec la structure euclidienne. On peut organiser lindexation dun ensemble dobjets par leur nom, grce lordre lexicographique par exemple, les regrouper en paquets grce la relation dordre, et stocker les objets de chaque paquet sur un secteur contigu des disques magntiques, de manire pouvoir accder au paquet en une opration daccs mmoire. En revanche, il nest pas possible, pour le cas le plus simple de donnes ponctuelles, de structurer ces points de la mme manire, avec un ordre sur les abscisses ou sur les ordonnes, indpendamment lun de lautre, sans perdre toute relation de voisinage ou de distance entre deux points (il nexiste pas de relation dordre total dans les espaces euclidiens de dimension suprieure 1). Une telle structuration serait donc inefficace dans le cas qui nous intresse, savoir retrouver rapidement tous les objets dans un espace donn ou tous les objets proches dun objet donn. Cet objectif impose un rapprochement logique (et physique sur les mmoire de stockage) des objets bass sur leur localisation. Il est ncessaire de dvelopper pour cela des mthodes de gestion adaptes aux donnes localises, ou plus gnralement multidimensionnelles, mthodes bties sur une structuration base sur la notion de voisinage et de sous-ensemble born pour la mtrique choisie dans l'espace de reprsentation.

De lobjet la collection dobjets 153 5.4.2. Lindexation multidimentionnelle Lide la plus simple, calque sur les techniques du squentiel index [GAR 83] est de dcomposer lespace en sous-ensemble borns, que nous appellerons feuilles, et dindexer les objets par rapport ces feuilles et deffectuer les recherches squentiellement dans les feuilles slectionnes pour le domaine dtude ou de slection. On peut classer les diffrentes mthodes utilises selon la dfinition et la structure des feuilles [SCH 95] : - les structures en grille : les feuilles correspondent un quadrillage rgulier ; - les structures en arbres quaternaires ou region-quadtree ; - les structures en arbres k-d (k-dtree) ; - les structures en arbres R (R-tree). On trouvera dans [SCH 95] une prsentation dtaille des diffrentes structures permettant de grer les index spatiaux. Nous ne rappelons ici que les principes lmentaires et les structures les plus employes. Les structures de type grille utilisent une partition de lespace en feuilles lmentaires de forme rectangulaire. La structure est extrmement simple : chaque feuille est associe une page contenant lensemble des objets inclus dans la feuille. Pour optimiser les temps daccs la mmoire de stockage, la taille dune feuille sera choisie de manire tre lue en une seule opration dentre-sortie, ce qui impose un stockage de tous les objets dune feuille sur un secteur contigu de la mmoire de masse. Le nombre des objets pouvant tre trs variable dun endroit lautre de lespace gographique, cette taille ne peut tre fixe a priori sans dgrader les performances de lindexation (les feuilles se trouvant dans des zones de faible densit seraient alors presque vides). La taille dune feuille devrait donc tre variable en fonction de la densit dobjet : si le nombre des objets dune feuille dpasse le maximum, cette feuille sera divise en sous-feuille, et chaque objet raffect une des sous-feuilles. Cette division peut se faire en adaptant la taille de la grille au nombre dobjet (grille adaptative) ou de manire faciliter le choix de la sous-feuille, pour une localisation donne, et donc naturellement par dichotomie. La feuille est alors divise en 4m (pour n=2) ou 8m (pour n=3) sous-feuilles, o m nest pas trop lev pour ne pas crer un grand nombre de feuilles presque vides. Lclatement dune feuille en sous-feuille est une opration complexe, qui impose galement la rorganisation des index bass sur les numros de feuilles.

154

Chapitre 5

Lorganisation des feuilles et les diffrents niveaux dclatement peuvent tre reprsents par un m-quadtree (m-octree pour n=3). Chaque nud non terminal contient la description de la division et pointe vers ses fils, et chaque nud terminal contient ladresse de la feuille dans la mmoire de stockage. Un tel quadtree est appel rgion quadtree , par opposition aux quadtrees vus au chapitre 3 et servant reprsenter directement un espace dcoup en cellules. La recherche sur la localisation (slection gographique) se fait alors par descente dans larbre : chaque niveau sera choisi le fils qui contient la feuille cherche, jusquau nud terminal qui donne ladresse de la feuille. Si m est choisi de manire ce que la lecture dun nud ne ncessite quune entre-sortie (la recherche du fils se faisant en mmoire centrale), ladresse de la feuille est dtermine en quelques entre-sorties. La recherche des feuilles voisines fait appel des cheminements dans le quadtree, et ne demande donc elle aussi que quelques oprations [SAM 84].

fig. 5.4 : hirarchie en feuilles et region quadtree associ

Linconvnient majeur de la partition en region quadtree rside dans le cot arbitraire du dcoupage en quatre rgions gales, ce qui peut provoquer un dsquilibre important de larbre si les donnes ne sont pas rparties de manire relativement homogne dans lespace, et donc une baisse notable des performances de lindexation. Pour remdier ce problme, on peut utiliser un dcoupage rcursif qui tient compte de la position des objets de manire optimiser le nombre dobjets prsents dans chaque partie du dcoupage, limage des k-dtree [MAT 84]. Bien sr, le dcoupage doit alors tre mmoris car il nest plus implicite comme dans les region quadtree ; la recherche des feuilles du k-d tree contenues dans la fentre

De lobjet la collection dobjets 155 dtude se fait galement par descente dans un arbre binaire, mais en consultant pour chaque nud la manire dont larbre a t dcoup.

A E B

C G B D E F A C G

S D

fentre dtude

fig. 5.5 : dcoupage en k-d tree et arbre binaire associ

La recherche dun objet doit galement pouvoir se faire sur la valeur dune de ses cls, sans connatre la localisation : par exemple, un nom de ville doit permettre de retrouver rapidement ladresse de la feuille qui la contient. Ce type de recherche ncessite la mmorisation pour chaque objet de ladresse de la feuille laquelle il appartient : ceci revient crer pour la cl choisie un index dense, et dorganiser cet index de manire classique en arbre B+ ou en paquets. Quelques oprations dentre-sortie suffiront alors retrouver ladresse de la feuille qui contient lobjet. Les objets voisins se trouveront alors dans la feuille slectionne ou dans les feuilles adjacentes, faciles dterminer grce lindexation principale sur la localisation en cheminant dans les arbres associs. Ces index, ncessairement denses, peuvent occuper une place importante. Comme nous lavons dj mentionn, lclatement et lagrgation de feuilles imposent la raffectation des objets dans les feuilles et donc la rorganisation des index. Toutes ces oprations sont relativement complexes mettre en uvre. Laffectation dun objet dans une feuille est simple pour les objets dune relation de type point. Tout se complique lorsque ces objets sont des lignes ou des zones, car ils peuvent alors ne pas tre contenus strictement (au sens de linclusion) dans la feuille et lunicit du choix daffectation nest plus assure. Diverses solutions peuvent tre apportes ce problme. La plus simple consiste affecter un centrode chaque objet et stocker lobjet dans la feuille qui contient le centrode. Une autre alternative serait de diviser les objets en sous-objets en introduisant le

156

Chapitre 5

bord de la feuille, mais cette mthode complique beaucoup les manipulations ncessaires au stockage et lextraction des donnes. Matsuyama propose de conserver avec chaque feuille le numro des enregistrements de tous les objets totalement ou partiellement contenus dans la feuille : la slection dune feuille par descente dans le k-d tree ou dans le region quadtree permet de dterminer lensemble des feuilles consulter ainsi que le numro des objets dans chaque feuille [MAT 84]. Le problme peut galement tre rsolu de manire diffrente, en conservant une feuille chaque niveau de la structure arborescente o ne seront stocks que les objets qui ne peuvent tre contenus entirement dans aucune des feuilles des niveaux suivants. Evidemment, la gestion des objets en est fortement complique, car ces feuilles ne peuvent tre clates quand elles sont pleines et doivent alors tre chanes entre elles comme des paquets de dbordement. Pour n=2, le nombre des objets possibles un niveau est nanmoins fortement limit par la surface de la feuille ; les objets fortement convexes (surface/primtre2 << 1/4*) ainsi que ceux de petite surface qui sont coups par les premires divisions de lespace sont les plus problmatiques. Si lon arrive rsoudre le problme de laffectation de ces petits objets mal placs par rapport la division de lespace, cette structure multi-niveau introduit une hirarchie dans lencombrement des objets qui peut galement constituer un critre de slection intressant [FRA 81]. Notons pour conclure que peu de systmes mettent en uvre ces techniques de structuration. De nombreux systmes ne sont pas aptes fournir des performances valables lorsque la taille de la base de donnes gographique est importante, et noffrent pas alors les possibilits dinteractivit qui semblent nanmoins ncessaires un systme performant. 5.5. La mise en uvre du relationnel tendu dans le systme SAVANE Dans ce paragraphe, nous allons dtailler la mise en uvre concrte, dans le systme Savane, des principes de structuration noncs aux chapitres 3 et 5. Nous allons dcrire la mise en uvre concrte de la structuration relationnelle tendue la localisation dans le systme Savane. 5.5.1. Schma : relations et attributs Larchitecture de SAVANE est celle dun calculateur base de donnes : il possde un dictionnaire des donnes, indiquant les relations et attributs ainsi que leurs caractristiques (types, dfinition du schma interne associ), un dictionnaire des accs permettant de grer les niveaux externes (par lallocation de droits et la dfinition des accs aux donnes), un langage de commande permettant dinterroger

De lobjet la collection dobjets 157 et de manipuler les donnes. Chaque opration utilise ces trois structures pour accder au niveau interne et au systme de fichier. Les donnes sont structures en relations correspondant aux entits du monde rel. La structuration reprend le principe du modle relationnel tendu la localisation tel que nous lavons prsent plus haut. Les objets sont donc regroups en relations, dont le type peut tre : zone, ligne, point, mosaque, non localis. La localisation est conserve sous forme vectorielle (pour les types zone, ligne, point) et sous forme matricielle (pour le type mosaque). Les paramtres des relations dune base de donnes sont conservs dans le fichier base qui correspond au dictionnaire de la base de donnes. Pour chaque relation, la description comprend : - le nom de la relation - le type de la relation (zone, ligne, point, image, non localise) - le nombre dattributs descriptifs - le nom des fichiers associs (objets et valeurs descriptives, objets graphiques associs) La description dune relation est suivie de la description de ses attributs. Pour chaque attribut, la description comprend : - le nom de lattribut - le type de lattribut (nominal, ordinal, entier, numrique, date, RVB, etc) - le nombre de valeurs nominales (dans le cas dun attribut nominal) - ladresse de la premire valeur nominale dans le fichier des valeurs dattributs (dans le cas dun attribut nominal). La lecture du dictionnaire permet au systme de charger le schma des donnes et lensemble des paramtres permettant daccder aux objets (donnes graphiques et descriptives). La classe CDico permet dencapsuler lensemble des oprations de lecture et dcriture du dictionnaire de la base de donnes (A.1). On pourra consulter par exemple, le code des procdures EcrireRelation() et EcrireAttribut(). Toutes les oprations de dclaration ou de modification du schma dune base de donnes sont effectues avec le module SAVATECA (fig. 5.6, fig. 5.7). Il est possible tout moment de modifier le schma dune base de donnes, en ajoutant, modifiant, ou supprimant relations ou attributs. Toute modification du schma implique une modification du numro dtat de la base. Les programmes dexploitation du systme (comme les modules SAVANE, SAVEDIT, SAVAMER)

158

Chapitre 5

utilisent ce numro dtat pour remettre jour le schma sil a t modifi pendant lexploitation de la base de donnes.

fig. 5.6 : le dialogue pour la gestion des relations

Le dialogue gnral de gestion des relations de SAVATECA contient de nombreux boutons, permettant de crer, dimporter, de modifier, de supprimer, de rinitialiser ou de rorganiser une relation.

De lobjet la collection dobjets 159

fig. 5.7 : le dialogue de cration dune relation

Pour crer une relation, lutilisateur doit indiquer le nom et le type de la relation. Le schma de certaines relations est prdfini : la relation est alors automatiquement cre avec son type et ses attributs prdfinis. Lorsque la relation est du type mosaque, lutilisateur doit indiquer le rpertoire de stockage de la mosaque ainsi que la projection gographique utilise pour conserver les images. La cration de la relation se traduit concrtement par lcriture de la description de la relation dans le fichier base. La suppression dune relation supprime la description de la relation et de ses attributs dans le dictionnaire et supprime toutes les rfrences cette relation dans les vues externes.

fig. 5.8 : le dialogue de gestion du schma des attributs dune relation

Le dialogue de gestion des attributs de SAVATECA permet dajouter, modifier, supprimer, ou rinitialiser des attributs (fig. 5.8, fig. 5.9). Comme pour les relations, toute suppression dattribut est suivie dune suppression des rfrences de cet attribut dans les vues externes de la base, ainsi que dune modification du numro dtat de la base de donnes.

160

Chapitre 5

fig. 5.9 : le dialogue de cration dun attribut

La classe CSchema, prsente dans tous les modules du systme, permet de charger le schma en mmoire partir du dictionnaire. Elle est associe aux classes CRelation et CAttribut, qui permettent dencapsuler donnes et mthodes correspondant au schma des relations et de leurs attributs. Par exemple, la mthode Alloc() de la classe CSchema charge le schma dans un objet de type CSchema, partir du dictionnaire de la base et de la vue externe utilise (A.2.1.2.). Ces classes sont fondamentales dans le systme SAVANE. Elles sont au cur du systme et sont utilises par la majorit des autres classes. 5.5.2. Structuration des collections dobjets 5.5.2.1. Architecture gnrale et organisation des bases de donnes Tous les fichiers correspondant aux relations dune base de donnes sont conservs dans un rpertoire unique portant le nom de la base de donnes. Ce rpertoire peut tre physiquement situ nimporte o sur le rseau local. Laccs aux fichiers dune relation est gr par le systme dexploitation de lordinateur (ouverture, criture, accs concurrents) partir de ce rpertoire, dont lemplacement absolu est conserv dans le fichier fpconf. La seule exception concerne les relations de type pixel, pour que ces relations puissent tre partages entre plusieurs bases de donnes diffrentes. Les fichiers correspondants ce type de relation peuvent donc tre stocks dans un rpertoire

De lobjet la collection dobjets 161 particulier. Lemplacement de ce rpertoire est conserv dans le fichier base avec les caractristiques de la relation. Si les dclarations sont incompltes, ou si le systme narrive pas trouver les emplacements indiqus, lutilisateur devra indiquer le bon emplacement des fichiers chaque premire utilisation de la relation, lors dune session de travail. 5.5.2.2. Indexation gographique et structure des fichiers La structure des fichiers dune relation dpend du type de la relation. Nous allons dcrire cette structure pour chaque type. Dune manire gnrale, la description des objets (identifiant dobjet, entte gographique) et leurs valeurs dattributs sont conserves dans un fichier, la description de la localisation dans un autre (pour les types zone et ligne), et un troisime fichier conserve lindexation gographique (pour les relations localises). Toutes les localisations sont conserves en coordonnes gographiques (longitudelatitude) par rapport un point fixe, propre la base. Pour toutes les relations dune mme base, les coordonnes gographiques doivent donc tre exprimes dans un mme datum. Il est possible de modifier le datum dune base de donnes, toutes les coordonnes tant alors recalcules en utilisant la formule de Molodensky. Tous les types localiss sont indexs de faon primaire sur la localisation. Cette indexation utilise le principe des grilles adaptatives et une structure squentielle pour chaque entre de lindex (squentiel index). Pour dfinir les cellules, on utilise le dcoupage naturel en feuille cartographique de numrisation (voir chapitre 7). Lindexation conserve pour chaque feuille lespace gographique occup par les objets de la feuille (cest--dire le plus petit rectangle englobant lensemble des objets), le nombre dobjet de la feuille, ladresse du premier objet de la feuille dans le fichier de description. Pour les types zone et ligne, on conserve galement le nombre darcs utiliss pour dcrire la localisation des objets et ladresse du premier de ces arcs dans le fichier des arcs correspondant la relation. 5.5.2.2.1. Le type non localis Le type non localis est le plus simple : les objets sont stocks squentiellement, la description de chaque objet est constitue uniquement des valeurs des attributs. Il ny a pas dindexation, ni didentifiant dobjet. 5.5.2.2.2. Le type point Chaque objet point est dcrit par des valeurs dattributs descriptifs et par une localisation gomtrique ponctuelle. Le type point utilise deux fichiers : un fichier index et un fichier descriptif. Lindex comprenant pour chaque feuille : - le nom de la feuille,

162

Chapitre 5

- lespace gographique occup par les objets de la feuille (point bas gauche, point haut droit, en coordonnes gographiques), - le nombre dobjets de la feuille, - ladresse du premier objet de la feuille dans le fichier descriptif. Le fichier descriptif comprend pour chaque objet : - la localisation du point (en coordonnes gographiques), - les valeurs des attributs, dans lordre dcrit par le schma de la base. On peut donc lire lensemble des objets dune relation en balayant son index, et pour chaque entre de lindex, en balayant squentiellement les objets partir de ladresse donne pour le premier objet de la feuille.

Index
feuille i

Objets de type point

feuille j

x,y, v1,v2,... x,y,v1,v2,... ....

x,y, v1,v2,... x,y,v1,v2,... ....

5.5.2.2.3. Le type ligne Chaque ligne est dcrite par des attributs descriptif et par un arc gomtrique. Nous nutilisons pas de polyligne, ou de lignes constitues par plusieurs arcs. Le type ligne utilise trois fichiers : un fichier index, un fichier descriptif, un fichier darcs. Le fichier index permet daccder aux objets dune feuille, puis on obtient dans le fichier descriptif la description de chaque objet ainsi que ladresse de larc correspondant dans le fichier descriptif. Lespace gographique occup par chaque objet est conserv dans le fichier des arcs. Chaque arc est dcrit par la suite des points qui le constitue. Les coordonnes sont conserves en longitude, latitude par rapport au point bas de la base. Lindex comprend pour chaque feuille :

De lobjet la collection dobjets 163 - le nom de la feuille, - lespace gographique occup par les objets de la feuille (point bas gauche, point haut droit, en coordonnes gographiques), - le nombre dobjets de la feuille, - ladresse du premier objet de la feuille dans le fichier descriptif, - le nombre darcs utiliss pour dcrire la localisation des objets, - ladresse du premier arc dans le fichier des arcs. Le fichier descriptif comprend, pour chaque objet : - le numro de larc correspondant lobjet, - ladresse de larc dans le fichier des arcs, - la localisation du centrode de la ligne, - les valeurs des attributs dans lordre dcrit par le schma de la base. Le fichier des arcs comprend, pour chaque arc, un entte et un ensemble de points. Lentte comprend pour chaque arc : - le numro de larc, - le sens de larc, - le nombre de points de larc, - le pointeur vers larc suivant, - la fentre de larc, en coordonnes gographiques. Les coordonnes des points de larc suivent lentte. Ils sont exprims en longitude-latitude par rapport au point bas de la base. On peut lire lensemble des objets dune relation en balayant son index, et pour chaque entre de lindex, en balayant squentiellement les objets partir de ladresse donne pour le premier objet de la feuille. On retrouve larc gomtrique correspondant un objet par son pointeur dans le fichier des arcs. On peut galement accder lensemble des arcs dune feuille grce au pointeur du premier arc de la feuille, pointeur qui se trouve galement dans lindex.

164

Chapitre 5

Index
feuille i

Objets de type ligne

Arcs gomtriques
iarc,isens,nbpt,ptr,xb,yb,xh,yh x,y,.....,x,y iarc,isens,nbpt,ptr,xb,yb,xh,yh x,y,.....,x,y iarc,isens,nbpt,ptr,xb,yb,xh,yh x,y,.....,x,y iarc,isens,nbpt,ptr,xb,yb,xh,yh x,y,.....,x,y ..... .....

feuille j

x,y, ptrarc,v1,v2,... x,y, ptrarc,v1,v2,... .... x,y,ptrarc,v1,v2,... x,y,ptrarc,v1,v2,... ....

5.5.2.2.4. Le type zone Chaque zone est dcrite par un identifiant dobjet, par des attributs descriptifs et par des arcs gomtriques dcrivant la frontire de la zone. Dans une feuille, les arcs ne sont pas rpts : on conserve pour chaque arc le numro des deux zones adjacentes. Pour reconstituer le contour dune zone, il est donc ncessaire de balayer lensemble des arcs dune feuille pour retrouver les arcs qui appartiennent cette zone. Les seuls arcs rpts sont donc les arcs qui sont frontires de zones appartenant deux feuilles diffrentes. La topologie dune zone nest pas constitue lors du processus dintgration de la zone dans la base. La topologie est cre lors du processus de saisie ou dimportation, grce au module SAVEDIT, que nous tudierons en dtail au chapitre 7. Il est trs important que les objets dune feuille constituent un ensemble topologiquement sans erreur : de nombreux contrles dintgrit sont dvelopps dans SAVEDIT cet effet. Cette mthode de description de la gomtrie dun ensemble de zones est trs simple et facile grer, puisquelle ne ncessite pas la gestion du sens des arcs ou de leur chanage. Le problme des les ou des zones incluses et imbriques ne se pose pas . On privilgie ainsi la simplicit de la structure et de la reprsentation, au dtriment de la simplicit des traitements ncessaires certaines fonctions. Le type zone utilise trois fichiers : un fichier index, un fichier descriptif, un fichier darcs. Le fichier index comprend pour chaque feuille : - le nom de la feuille, - lespace gographique occup par les objets de la feuille (point bas gauche, point haut droit, en coordonnes gographiques),

De lobjet la collection dobjets 165 - le nombre dobjets zone de la feuille, - ladresse du premier objet de la feuille dans le fichier descriptif, - le nombre darcs utiliss pour dcrire la localisation des zones, - ladresse du premier arc dans le fichier des arcs. Le fichier descriptif comprend, pour chaque objet : - le numro de la zone dans la feuille, - la localisation du centrode de la ligne, - la fentre minimale contenant la zone, - les valeurs des attributs dans lordre dcrit par le schma de la base. Le fichier des arcs comprend, pour chaque arc, un entte et un ensemble de points. Lentte comprend pour chaque arc : - le numro de la premire zone adjacente, - le numro de la seconde zone adjacente. Si larc ne borde quune zone, ce numro est 2. Si la zone adjacente appartient une autre feuille, ce numro est 19 (si larc doit tre visible) ou 18 (si larc ne doit pas tre visible, comme dans le cas dun dcoupage arbitraire en feuille par une ligne droite), - le nombre de points de larc, - le pointeur vers larc suivant, - la fentre de larc, en coordonnes gographiques. Les coordonnes des points de larc suivent lentte. Elles sont exprimes en longitude, latitude par rapport au point bas de la base.

Index
feuille i ... feuille j ...

Objets de type zone

Arcs gomtriques
nz1,nz2,nbpt,ptr,xb,yb,xh,yh x,y,.....,x,y nz1,nz2,nbpt,ptr,xb,yb,xh,yh x,y,.....,x,y nz1,nz2,nbpt,ptr,xb,yb,xh,yh x,y,.....,x,y nz1,nz2,nbpt,ptr,xb,yb,xh,yh x,y,.....,x,y ..... .....

nz,x,y,xb,yb,xh,yh,v1,v2,... nz,x,y,xb,yb,xh,yh,v1,v2,... ....

nz,x,y,xb,yb,xh,yh,v1,v2,... nz,x,y,xb,yb,xh,yh,v1,v2,... ....

166

Chapitre 5

5.5.2.2.5. Le type mosaque Le type mosaque correspond aux images. A chaque relation correspond un fichier dcrivant les paramtres de la relation (taille du pixel, projection gographique, etc.), et chaque attribut de la relation correspondent deux fichiers : un fichier index, correspondant au dcoupage en feuille (on parlera plutt dimagettes dans le cas dune relation de type mosaque), et un fichier contenant la valeur de chaque pixel prsent dans la relation, pour cet attribut. La structure de ce type de relation sera tudie en dtail au chapitre suivant. 5.5.3. Intgration dobjets et de valeurs dattributs 5.5.3.1.La constitution dune relation La constitution dune relation de la base de donnes se fait par intgrations successives de groupes dobjets dans la relation. Pour les relations localises, lintgration se divise en deux phases distinctes : la premire phase consiste crer les objets en intgrant lattribut de localisation (saisi ou import dans le module SAVEDIT) et un identifiant descriptif pour chaque objet. La seconde phase permet dintgrer les valeurs descriptives des objets en utilisant lidentifiant comme attribut de jointure. Ces valeurs descriptives peuvent provenir dun fichier classique ou dune base de donnes relationnelle classique. Les valeurs des attributs des objets sont alors lues dans ces fichiers et recopies dans la base savane. Pour les relations localises, les objets intgrer sont regroups dans des documents intgrer, correspondant en gnral une coupure de carte, ou un espace gographique. Lide gnrale, cest davoir une relative homognit du nombre dobjets par document, puisque chaque opration de cration dobjets partir dun document cre une feuille, cest--dire une entre dans lindex gographique. Ladresse des objets et la position gographique en deux dimensions sont conserves pour chaque feuille et sont utilises lors de lexploitation de la base comme indexation primaire, dans une structure squentielle indexe en deux dimensions, comme nous lavons vu dans le paragraphe prcdent. Le dcoupage de lespace en grille adaptative doit donc se faire lors de la prparation de la saisie des donnes, bien avant lintgration des objets dans la base de donnes. 5.5.3.2. Codage des valeurs des attributs descriptifs Le codage des valeurs des attributs descriptifs dpend du type de lattribut. Rappelons les types d'attribut descriptif grs par le systme SAVANE : Nominal ou qualitatif : ceux qui prennent des valeurs nominales (une chane de caractres).

De lobjet la collection dobjets 167 Ordinal : ceux qui prennent des valeurs nominales que l'on veut pouvoir ordonner, Entier : ceux qui prennent des valeurs numriques entires, Rel : ceux qui prennent des valeurs numriques quelconques (comme un prix). Couleur 8 bits, 16 bits, RVB : la valeur de l'attribut correspond au codage d'une couleur. Avec 8 bits, on peut coder 256 couleurs, avec 16 bits 64000. Une couleur RVB comprend un niveau de rouge, un niveau de vert, un niveau de bleu, chaque niveau tant cod sur 8 bits (256 valeurs possibles pour chaque niveau, soit 16 millions de couleurs possibles). Date : ceux qui prennent la valeur dune date, Son : la valeur de l'attribut correspond la description d'un son, image : la valeur de l'attribut correspond une image ou une collection dimages (album de photographies, documents scanns,), vido : la valeur de lattribut correspond une squence vido, graphe : la valeur de l'attribut correspond la description d'un graphe en deux dimensions. Les valeurs des attributs nominaux sont codes en numrique : les valeurs nominales sont conserves sur 16 caractres dans un fichier global, propre la base de donnes (le fichier fpvaleurs). La valeur conserve dans le fichier de description des objets est lindice relatif de la valeur dans ce fichier, par rapport la premire valeur. Ladresse de la premire valeur dans le fichier fpvaleurs et le nombre de valeurs diffrentes sont conservs dans le descriptif de lattribut, dans le fichier base. Il est ainsi facile de connatre lensemble des modalits dun attribut nominal et de rechercher une modalit sans avoir balayer lensemble des objets. Un ensemble de modalits peut galement tre partag entre plusieurs attributs. Par contre, la gestion de ce codage est plus complexe, surtout en cas de modification ou dajout. Tous les attributs numriques sont conservs sous forme numrique en double prcision, directement dans le fichier descriptif de la relation. Les couleurs (8, 16, 24 bits) correspondent uniquement un attribut dune relation de type mosaque. Nous dtaillerons leur codage dans le chapitre suivant. Les valeurs des attributs de type son, album dimages, vido, graphe conservent des noms absolus de fichier, chaque valeur correspondant un fichier contenant lobjet en question. Ainsi, la valeur dun attribut de type video pour un objet (localis ou non) correspond au nom et lemplacement du fichier contenant la video. Ces noms de 256 caractres sont en fait conservs dans un fichier global (le

168

Chapitre 5

fichier fpfichier), et la valeur de lattribut correspond ladresse du nom dans le fichier global. Il arrive souvent que la valeur dun attribut dun objet soit inconnue ou indtermine. Nous avons donc dfini pour chaque type dattribut une valeur spciale correspondant la valeur inconnue . Pour les attributs nominaux ou de type son, album dimages, vido, graphe, on utilise la valeur 0. Pour les attributs numriques, on utilise la valeur 1.e+30. La seule drogation cette rgle concerne les attributs des mosaques cods sur 8 ou 16 bits : la valeur inconnue est 0, ce qui nous obligera modifier les pixels de valeur initiale 0 pour quils ne soient pas considrs comme des objets de valeur inconnue. 5.5.3.3. Lintgration graphique Lintgration graphique (fig. 5.10) cre physiquement des enregistrements dans le fichier des objets et dans le fichier des arcs (pour les types zone et ligne). Elle calcule la fentre gomtrique de chaque objet, crit lenregistrement avec les valeurs gographiques (centrode, fentre gomtrique) et tous les autres attributs avec une valeur rserve correspondant la valeur inconnue (code 1e30). Une fois les objets crs, lintgration graphique revient sur les objets pour intgrer la valeur dune cl descriptive (attribut nominal cl des attributs descriptifs de la relation). Pour les objets localiss, cette valeur a t saisie pour chaque objet lors de la saisie graphique. Lintgration graphique, lors de la cration des objets, ne fait que recopier dans les fichiers de la relation les objets digitaliss qui sont regroups dans des documents distincts. Ces documents sont constitus et dits grce au module SAVEDIT du systme. Lintgration graphique neffectue aucune cration ni contrle au niveau de la topologie des objets. Cette topologie est constitue et vrifie lors de la saisie graphique. Nous tudierons en dtail dans le chapitre 7 le module SAVEDIT et les diverses contraintes et contrles dintgrit lis lattribut de localisation. Lindexation en feuille conserve le regroupement des objets provenant des diffrents documents digitaliss : la topologie conserve donc galement cette structure. La seule difficult rside donc dans la gestion des relations graphiques entre objets appartenant des feuilles diffrentes : connexit darcs, frontires entre zones de feuilles diffrentes. Ces relations doivent tre gres lors de la saisie graphique des objets. Le module SAVEDIT contient donc des procdures permettant de joindre ou dunir des arcs appartenant des documents diffrents.

De lobjet la collection dobjets 169

fig. 5.10 : les dialogues de lintgration graphique

Une autre difficult apparat lorsque lon veut regrouper des objets appartenant des feuilles diffrentes, car la structure en feuille et lorganisation de SAVANE ne permet pas un objet davoir des arcs dans des feuilles distinctes.

170

Chapitre 5

Un identifiant descriptif, nominal, a t saisi pour chaque objet lors de la saisie graphique. Cet identifiant est intgr comme valeur dun attribut nominal qui servira ensuite de cl descriptive pour lintgration des valeurs des autres attributs. Les principes de cette intgration sont les suivants : - codage de la valeur nominale en numrique, - criture de la valeur de chaque objet dans lattribut correspondant, dans le fichier descriptif de la relation, - criture des nouvelles modalits dans le fichier des valeurs nominales (fpvaleurs) et actualisation des pointeurs et autres paramtres de lattribut dans le dictionnaire de la base (fichier base). Le codage de la valeur nominale se fait en plusieurs tapes : - indexation des valeurs nominales dj existantes pour cet attribut, - pour chaque objet, recherche de sa valeur dans lensemble des n valeurs dj existantes. Si la valeur est trouve, le code correspond lindice de cette valeur dans lensemble des valeurs de lattribut. Si la valeur nest pas trouve, on la rajoute aux valeurs existantes et le code correspond n+1. Ces procdures sont galement utilises lors de lintgration descriptive des autres attributs nominaux, dcrite dans le paragraphe suivant. Nous verrons en dtail un peu plus loin les classes regroupant ces procdures. 5.5.3.4. Lintgration descriptive Lintgration descriptive intgre, pour chaque objet, la valeurs des attributs descriptifs. Pour cela, on utilise la cl descriptive intgre lors de la cration des objets, et qui sert de lien entre lobjet et les valeurs intgrer, qui sont en gnral regroupes dans un fichier unique. Lutilisateur doit alors indiquer les correspondances entre champs de fichier et attributs, ainsi que la mthode de sparation de champs dans le fichier. Lintgration dun attribut descriptif se fait en plusieurs tapes : - si lattribut intgrer est nominal, codage de lattribut descriptif intgrer en fonction des valeurs dj existantes pour cet attribut. - codage du champ du fichier servant de cl de jointure, en fonction des valeurs de lattribut nominal choisi comme cl de jointure et dj intgr dans la base. Le systme signale ce niveau toute valeur nominale prsente dans le fichier mais non prsente dans la base pour lattribut choisi comme cl de jointure. - pour chaque objet de la relation, recherche dans le fichier dun enregistrement ayant mme valeur pour la cl de jointure. Si aucun enregistrement nest trouv, la valeur de lattribut intgrer reste inchange. Il est ainsi possible de modifier une

De lobjet la collection dobjets 171 partie seulement des objets intgrs : tout dpend des cls de jointure prsentes dans le fichier. - si lattribut intgrer est nominal, intgration des nouvelles modalits dans le fichier des valeurs nominales (fpvaleurs) et actualisation des paramtres de lattribut (nombre de modalits). Pour les relations localises, on a en gnral plus dobjets que de valeurs de cl descriptive, puisque par dfinition la localisation est une cl de chaque objet. Le fichier descriptif peut ainsi avoir beaucoup moins denregistrements que le nombre dobjet de la relation. Une carte des sols est un exemple classique : on peut avoir graphiquement beaucoup de zones (connexes), mais peu de cls descriptives distinctes. Voici les diffrents dialogues (fig. 5.11) permettant dintgrer des valeurs dattribut partir dun fichier ASCII :

172

Chapitre 5

fig. 5.11 : les diffrents dialogues de lintgration descriptive

De lobjet la collection dobjets 173 5.5.3.5. La classe CIndexAttribut La classe CIndexAttribut encapsule lensemble des structures et oprations ncessaires lindexation et la recherche dune valeur dans lensemble des valeurs dun attribut nominal. On indexe sur les trois premiers caractres des valeurs en utilisant un dcoupage en paquets lis lordre lexicographique. La recherche est squentielle partir de chaque entre de lindex. Cette classe est utilise dans les diffrents modules du systme (A.1.5.). 5.5.4. Savane : requtes et tats temporaires 5.5.4.1. Principe dune requte dans SAVANE Nous avons vu dans le chapitre 2 (prsentation du systme SAVANE) les principes de lexploitation dune base de donnes dans le systme SAVANE. Rappelons rapidement ces principes. Le document de base du logiciel SAVANE est une carte, cest--dire une feuille de papier destine contenir une reprsentation graphique de donnes gographiques. Cette feuille contient par dfaut un cadre gographique. Un cadre gographique correspond au rsultat dune requte sur la base de donnes : SAVANE utilise le principe de la requte pour linterrogation dune base de donnes. Il faut enchaner les oprations, le rsultat de lune pouvant servir dentre la suivante. Une interrogation, une requte, est donc compose dun ensemble doprations que lon dclenche grce au menu principal, et que lon peut conserver sous forme de macro-commande. Un cadre peut donc tre vu comme une fentre sur la base de donnes contenant un moment donn, un tat temporaire de la base correspondant une interrogation et aux oprations effectues (calculs, cration de nouvelles variables, croisement et jointure dobjets, etc.). Lorsquune relation est modifie, ses objets sont recopis dans des fichiers temporaires qui sont physiquement stocks dans le rpertoire de lutilisateur. La relation devient alors temporaire, et elle ne contient plus que les objets se trouvant dans la fentre dtude lie au cadre. La structure des fichiers temporaires lis aux relations temporaires est un peu diffrente de la structure des fichiers de base (voir plus loin la classe CLecture). A chaque relation temporaire peut correspondre quatre fichiers temporaires : un pour lindex (feuilles), un pour les objets (descriptif), un pour les arcs, et un pour conserver une image matricielle de la relation (voir paragraphe suivant). Des variables maintiennent le nom de ces fichiers, qui sont librs automatiquement lorsque la relation est de nouveau modifie, ou remise dans son tat initial. Des procdures globales (FChoixFeuille(), FChoixDescriptif(), FChoixArc()) permettent de connatre le premier fichier disponible pour chaque type (index, descriptif, arc).

174

Chapitre 5

La classe CSchema de SAVANE permet de dcrire ltat de la base de donnes correspondant la requte effectue dans un cadre (A.2.1.2.). Par exemple, la mthode Actualiser() permet de recharger le schma aprs une modification externe du schma de la base (avec SAVATECA), tout en conservant ltat des relations temporaires (modifies par la requte en cours). Les oprations de manipulation de donnes sont implmentes dans des fonctions globales qui prennent comme argument un objet de la classe CCadre (le cadre sur lequel doit seffectuer lopration) ou CSchema (le schma du cadre sur lequel doit seffectuer lopration) et lensemble des paramtres de lopration. Ces paramtres sont en gnral crits dans un fichier (fpmenu) aprs dialogue avec lutilisateur ou lecture dune macro-commande, et relus par la fonction dexcution de commande. Ces fonctions modifient le schma qui reflte ainsi ltat de la base aprs lexcution de la commande. Ainsi sont implmentes en particulier toutes les fonctions relationnelles classiques (restriction, projection, jointure). Par exemple, la fonction dexcution dune jointure entre deux relations dbute par le code suivant :
void XQuestJointure(CCadre* pCadre) { HCURSOR hcurSave = ::SetCursor(LoadCursor(NULL, IDC_WAIT)); //--- jointure entre deux relations CSchema* pSchema=pCadre->GetSchema(); CWind* pWind=pCadre->GetWind(); int i,j,k,iNothEmetteur1,iNothEmetteur2; int iNoattCleEmetteur1,iNoattCleEmetteur2; int iNbAttributsEmetteur1,itabNoattEmetteur1[NB_MAX_ATTRIBUTS]; int iNbAttributsEmetteur2,itabNoattEmetteur2[NB_MAX_ATTRIBUTS]; int iJointure; char chNomRelation[_MAX_PATH]; //--- lecture des paramtres FILE* FileMenu=fopen(base.m_chNomFtmp,"rb"); fscanf(FileMenu,"%d%*c",&iNothEmetteur1); fscanf(FileMenu,"%d%*c",&iNoattCleEmetteur1); fscanf(FileMenu,"%d%*c",&iNbAttributsEmetteur1); for(i=0;i < iNbAttributsEmetteur1;i++) { fscanf(FileMenu,"%d%*c",&itabNoattEmetteur1[i]); } fscanf(FileMenu,"%d%*c",&iNothEmetteur2); fscanf(FileMenu,"%d%*c",&iNoattCleEmetteur2); fscanf(FileMenu,"%d%*c",&iNbAttributsEmetteur2); for(i=0;i < iNbAttributsEmetteur2;i++) { fscanf(FileMenu,"%d%*c",&itabNoattEmetteur2[i]); } fscanf(FileMenu,"%d%*c",&iJointure); fgets(chNomRelation,_MAX_PATH,FileMenu); fclose(FileMenu); .

5.5.4.2. Dfinition et gestion des macro-commandes Une macro-commande permet de conserver tous les paramtres ncessaires lexcution dune ou de plusieurs commandes, indpendamment du schma sur

De lobjet la collection dobjets 175 lequel cette commande doit seffectuer. On peut ainsi conserver des parties dun traitement complexe pour les excuter de nouveau plus tard, ou les conserver dans la structure de la base de donnes comme des mthodes. Lors dune requte, toutes les oprations sont conserves dans une macrocommande spciale, attache au cadre et conserve dans la structure du cadre de la carte. Cette macro-commande nest rinitialise que si lutilisateur revient ltat initial de la base. Elle permet dexcuter de nouveau la squence doprations effectue dans le cadre depuis la dernire initialisation du cadre. Cette opration est particulirement importante dans le cas o la base est modifie de faon externe, car elle permet de ractualiser le rsultat de la requte. Les macro-commandes sont conserves dans un rpertoire de lutilisateur. La classe CMacro de SAVANE permet dencapsuler toutes les oprations ncessaires la gestion des macro-commandes (A.2.1.4.). 5.5.5. La classe Clecture La classe CLecture de SAVANE encapsule lensemble des procdures de lecture et dcriture des relations de la base de donnes, quelles soient permanentes ou temporaires (A.2.1.3.). La mthode Lire() de cette classe est utilise en permanence pour lire les valeurs des objets dune relation, en utilisant le code suivant :
CLecture lecture; if(lecture.Open(pCadre,iNoth)) { int i=lecture.Lire(v); while(i != -1) { if(i == 1) { //--- traitement de lobjet } i=lecture.Lire(v); } lecture.Close(); }

Pour accder un attribut dune relation non temporaire, il faut rechercher le numro interne de lattribut, partir de son numro externe iNoAttrExterne qui provient du dialogue avec lutilisateur. Le numro interne est conserv dans la variable membre m_iNumero de CAttribut (A.2.1.1.) :
iNoAttrInterne=pSchema->m_pRelations[iNoRel]->m_pAttributs[iNoAttrExterne]->m_iNumero ;

Cette indirection nest plus ncessaire lorsque la relation est temporaire, car les valeurs des attributs de la vue externe sont rcrites dans lordre de la vue, comme nous le verrons dans les paragraphes suivants. On a alors toujours iNoExterne=iNoInterne.

176

Chapitre 5

5.5.6. SAVANE : les structures internes 5.5.6.1. Vecteur et raster Comme nous lavons vu prcdemment, la localisation est conserve dans le systme SAVANE sous forme vectorielle pour les objets de type zone, ligne ou point, avec la prcision inhrente la dfinition smantique des objets. Par contre, le systme cre une matrice raster pour la rsolution rapide de certaines oprations impliquant des relations zonales ou des masques, lorsque la prcision de cette matrice est suffisante pour lopration en question, ainsi que pour amliorer les temps daffichage sur cran ou pour rechercher les valeurs dun objet en le dsignant sur lcran. Cette opration de rasterisation est transparente pour lutilisateur. De nombreuses oprations peuvent ainsi tre effectues sans avoir reconstituer le chanage des arcs en polygone, ou sans avoir se proccuper du problme des zones incluses. Cette opration de rasterisation cre une image, chaque pixel tant cod avec lindice de lobjet dans le fichier descriptif. On peut ainsi retrouver trs rapidement la valeur des attributs dun point appartenant une zone, sans avoir recrer le contour de la zone et tester lappartenance du point la zone partir de ses arcs frontire.

Objets de type zone

nz,x,y,xb,yb,xh,yh,v1,v2,... nz,x,y,xb,yb,xh,yh,v1,v2,... ....

nz,x,y,xb,yb,xh,yh,v1,v2,... nz,x,y,xb,yb,xh,yh,v1,v2,... ....

fig. 5.13 : structure de limage raster associe une relation zonale

La rasterisation est effectue dans la fentre dtude, et ractualise chaque changement de fentre dtude et chaque modification du fichier descriptif de la relation. La dfinition de limage matricielle cre est un paramtre du systme (habituellement fix entre 1600 et 3000). Dans la plupart des cas, cette rsolution

De lobjet la collection dobjets 177 offre une prcision suffisante. La prcision absolue dpend bien sr de la taille de la fentre dtude : plus la fentre est grande, plus la taille du pixel rsultant de la rasterisation sera petite. Le systme conserve cette image dans un fichier temporaire, li la relation, et qui est dtruit lors de la rinitialisation de la requte, la rinitialisation de la relation, le changement de la fentre dtude, ou le changement de projection gographique. Lavantage dune reprsentation matricielle rside dans la simplicit de la structure, et dans le fait que lensemble des relations peuvent ainsi tre compares pixel par pixel, puisque, dans une fentre donne, diffrentes rasterisations vont crer des pixels gomtriquement identiques. Si lutilisateur le souhaite, il peut galement conserver la reprsentation matricielle dun attribut dans une nouvelle relation, dont le type ne sera plus zone, ligne, point, mais raster. Ainsi, cette nouvelle relation nomme raster, toujours temporaire, pourra contenir, sous forme matricielle, des attributs provenant de toutes les relations de la base, et sur lesquelles on pourra appliquer trs facilement de nombreuses mthodes danalyse (comparaison, calculs, etc.). Cette relation temporaire raster sapparente ainsi aux systmes qui conservent la localisation sous forme matricielle, mais avec lavantage davoir une taille de pixel variable, choisie par lutilisateur, et une localisation provenant de donnes fiables conserves avec toute leur prcision sous forme vectorielle. Cette particularit fait de SAVANE un systme double structure interne raster-vecteur, vecteur pour le stockage des objets, raster pour la rsolution oprationnelle de certaines oprations danalyse spatiale. Cette proprit ne doit pas tre confondue avec la gestion et le traitement des relations de type mosaque, dont les objets sont galement des pixels mais dont la taille ne varie pas et est fixe par la dfinition smantique de la relation. Par contre, une relation de type mosaque peut galement apporter un attribut la relation raster (dans ce cas, lopration de conversion nest plus une rasterisation mais un rchantillonage, voir chapitre 6). Elle ne doit pas non plus tre confondue avec la possibilit de crer une relation vectorielle zonale dont les objets sont des mailles (carre, hexagonale) que nous verrons au chapitre 8. La reprsentation matricielle dune relation zonale permet galement dacclrer la visualisation des zones par plage sur un cran : il suffit deffectuer un rchantillonage de cette image en fonction de la taille du pixel de lcran, plutt quun chanage des arcs en contours de taches et un remplissage de chaque tache, avec le problme toujours dlicat des trous et des zones incluses. Pour une question de performance, cette reprsentation matricielle temporaire est donc presque indispensable lorsque la reprsentation de la localisation des zones utilise le mode topologique (frontires), comme cest le cas dans le systme SAVANE.

178

Chapitre 5

5.5.6.2. Un algorithme de rasterisation Lopration de rasterisation tant effectue de faon automatique en tche de fond et chaque modification de la relation, lalgorithme utilis pour passer dune description vectorielle une reprsentation matricielle doit tre trs efficace. Nous en prsentons ici les principes et la ralisation. Lalgorithme est bas sur le principe des algorithmes YX de rasterisation dune zone (un point de lintrieur dune zone est caractris par un nombre impair dintersections prcdents le point, le long dune droite horizontale coupant le contour de la zone). Cet algorithme est tendu la rasterisation simultane de plusieurs zones. Il comprend trois phases principales : - calculs des points dintersection des arcs avec des lignes horizontales spares dun pixel. La taille du pixel correspond la rsolution de la matrice obtenir. - tri des points dintersection en Y, puis en X sur chaque ligne, - pour chaque ligne du balayage, dtermination de lobjet zone compris entre deux points dintersection conscutifs. Le calcul des points dintersection des arcs doit grer avec prcision les segments horizontaux, ne pas prendre en compte, ainsi que les extrmits des segments qui ne doivent pas tre dupliqus. La mthode de tri des points doit tre efficace. Chaque arc des zones ayant une intersection avec la fentre dtude est dcoup en segments de droite, en reprenant directement les points reprsentant larc. Chaque segment est orient (du bas vers le haut, et de gauche droite), les segments horizontaux sont carts, puis les intersections avec les lignes du balayage sont calcules et stockes par insertion (sur Y, puis sur X) dans une structure qui conserve galement pour chaque point le numro des zones adjacentes de larc, ou la valeur dun attribut nominal de chaque zone adjacente. Le segment est cart si les deux valeurs adjacentes sont identiques. On obtient donc pour chaque ligne une liste des points dintersection se trouvant sur la ligne, trie par ordre croissant sur les abscisses. On dtermine ensuite pour chaque point le code entrant et le code sortant, en fonction du nombre de points dintersection confondus en chaque point dintersection. Cet algorithme, comme tous ceux de sa catgorie, exige une topologie sans faille : une zone ouverte cre une erreur dans la rasterisation et fait dborder la zone sur la zone adjacente. Nous avons construit plusieurs classes pour mettre en uvre cet algorithme : une classe CCellule, qui permet de stocker chaque point dintersection et le chaner avec le point suivant, et une classe CYX, qui permet de connatre ladresse de la premire cellule pour chaque ligne (membre m_Y) et qui regroupe les procdures de

De lobjet la collection dobjets 179 calcul des points dintersection (Points()), dinsertion des (InsererCellule()), et de calcul du balayage (YX()) (A.2.2.2.). cellules

Limage qui rsulte de la rasterisation est stocke dans un fichier sous forme compresse, en utilisant une compression simple par segments horizontaux permettant de regrouper les pixels contigus de mme valeur. Lopration duale, permettant de passer dune image une reprsentation vectorielle des zones, correspond une opration de vectorisation. Cette opration sera utilise par exemple pour retrouver une reprsentation vectorielle aprs traitement sur une reprsentation raster de la localisation. Nous prsenterons au chapitre 8 lalgorithme de vectorisation dvelopp dans le systme SAVANE. 5.5.7. Les masques 5.5.7.1. La structure dun masque Comme nous lavons vu plus haut, un masque correspond un domaine de lespace. Chaque masque est reprsent par une double structure, une image raster et un ensemble darcs qui correspondent aux contours du domaine. Limage raster est cre la dfinition interne du systme (la dfinition de rasterisation) suivant la projection gographique utilise, et est stocke sous forme dune image compresse forme de 0 (hors du domaine) et de 1 (dans le domaine). Les arcs sont conservs sous forme vectorielle, en coordonnes gographiques dans le datum de la base de donnes. La structure du fichier est identique celle des fichiers des arcs dune relation zonale. Chaque masque possde galement un fichier qui le dcrit (fentre minimale, nombre darcs, taille du pixel de limage raster associe, etc.). Toute modification de la fentre dtude ou de la projection gographique implique la cration dune nouvelle image raster partir des arcs, par rasterisation. On utilise lalgorithme de rasterisation que nous avons vu plus haut, simplifi, puisquil ny a ici quune seule zone traiter. Dans la majorit des cas, les traitements faisant intervenir un masque utiliseront la reprsentation matricielle du masque. 5.5.7.2. Cration dun masque : zone tampon ou dfinition sur cran Un masque peut tre cr principalement de deux faons : par saisie directe sur cran ou partir des objets dune relation. La saisie directe sur cran ne pose pas de problmes particulier : les contours du masque sont saisis sur lcran, polygone par polygone. Les coordonnes sont conserves en longitude-latitude, aprs avoir t transformes partir des

180

Chapitre 5

coordonnes cran (coordonnes cran carte cadre gographique). Limage matricielle est calcule directement partir des contours. La dfinition dun masque partir des objets dune relation est plus complexe, surtout lorsque lon fait intervenir une distance : le masque correspond alors au domaine de lespace se trouvant au maximum telle distance des objets de la relation (appel alors zone tampon, ou encore buffer) (fig. 5.14). Pour la cration de ce type de masque dans SAVANE, on va dabord crer limage matricielle correspondante, et lon obtiendra les arcs par vectorisation de limage. Lalgorithme de cration dpend du type de la relation utilise : pour une cration partir de points, on remplit limage autour de chaque point en utilisant un disque de la taille du tampon. Pour une cration partir de lignes, on applique ce disque autour de chaque point provenant du dessin des ligne dans limage raster. Pour une cration partir de zones, en utilisant limage de la relation ligne par ligne : on applique ce mme disque sur les extrmits de chaque segment horizontal de limage, en joignant les deux disques par un rectangle.

fig. 5.14 : la cration dun masque partir des points dune relation et dune distance ces points

De lobjet la collection dobjets 181 5.5.7.3. Lalgbre des masques De nombreuses oprations peuvent tre appliques aux masques dans SAVANE. Il sagit dopration unaires (inverser, roder, dilater) et doprations binaires (intersection, union, union exclusive, diffrence). Toutes ces oprations utilisent la reprsentation matricielle du masque, et sont simples mettre en uvre. Seule la dilatation demande quelque effort algorithmique, nous utilisons ici la mthode prsente pour crer un masque avec une distance. Lrosion correspond une dilatation de linverse du masque. Grce ces oprations, nous pouvons obtenir des domaines de lespace correspondant de nombreuses situations gographiques. Par exemple, dans la figure 5.15, le domaine en bleu dans le cadre correspond la zone se trouvant plus de trois cent mtres mais moins de cinq cent mtres dun htel. Il a t obtenu par diffrence entre deux masques :

Fig. 5.15 : un masque rsultat de la diffrence de deux masques

Les masques sont conservs dans le rpertoire de lutilisateur. Ils peuvent donc tre utiliss dans toutes les cartes construites par cet utilisateur.

182

Chapitre 5

5.5.8. La ralisation des oprations relationnelles classiques 5.5.8.1. La restriction La restriction dune relation correspond la slection dobjets de la relation sur un critre descriptif. La condition de slection peut porter sur plusieurs attributs : elle utilise une formule logique qui est ensuite vrifie pour chaque objet (fig. 5.16). Si un objet rpond la condition, il est conserv et recopi dans ltat temporaire de la relation. A la fin de lopration, la visualisation de la relation doit tre actualise pour reflter ce nouvel tat.

fig. 5.16 : dialogue de restriction par formule

Lopration de slection utilise un calculateur permettant de vrifier la syntaxe de lexpression et de calculer sa valeur pour un objet. Nous avons dvelopp une classe CCalculateur pour encapsuler lensemble de ces oprations (A.2.1.5.). La procdure de slection scrit alors de faon trs simple :
//--- initialisation de la lecture int iNoFichier=pSchema->FchoixDescriptif(); if(iNoFichier == -1)return; CLecture lecture; if(lecture.Open(pCadre,iNoth,iNoFichier,0)) { //--- lecture des objets float v[NB_MAX_ATTRIBUTS],fResultat; float vprim[NB_MAX_ATTRIBUTS]; i=lecture.Lire(v); while(i != -1)

De lobjet la collection dobjets 183

{ if(i == 1) { fResultat=(float) calculateur.Calcul(chFormule,v); if(fResultat != 0 && fResultat > FINCONNU) { iNbObjets++; if(pSchema->m_pRelations[iNoth]->m_iType < 10) { for(i=1;i <= iNba;i++)vprim[i]=v[tabp[i]]; lecture.Ecrire(vprim); } else lecture.Ecrire(v); } } i=lecture.Lire(v); } lecture.Close(); //--- mise a jour de la relation pSchema->m_pRelations[iNoth]->m_iNbObjets=-1; if(pSchema->m_pRelations[iNoth]->m_iType < 10) { pSchema->m_pRelations[iNoth]->m_iType+=10; pSchema->m_pRelations[iNoth]->m_iNoFichDescriptif=iNoFichier; pSchema->m_iFdisDescriptif[iNoFichier]=1; for(i=1;i <= pSchema->m_pRelations[iNoth]->m_iNba;i++)pSchema->m_pRelations[iNoth]>m_pAttributs[i]->m_iNumero=i; pCadre->GetDlgStatExplorateur()->MiseAJour(iNoth); } else { int iNo=pSchema->m_pRelations[iNoth]->m_iNoFichDescriptif; unlink(pSchema->m_chFprovDescriptif[iNo]); pSchema->m_pRelations[iNoth]->m_iNoFichDescriptif=iNoFichier; pSchema->m_iFdisDescriptif[iNoFichier]=1; pSchema->m_iFdisDescriptif[iNo]=0; //--- suppression de l'image si type 24 if(pSchema->m_pRelations[iNoth]->m_iType == 24) { pSchema->m_pRelations[iNoth]->m_iType=14; int iFim=pSchema->m_pRelations[iNoth]->m_iNoFichImage; pSchema->m_iFdisImage[iFim]=0; } //--- actualisation de l'explorateur cartographique if(pCadre->GetExplorateur()->IsRelationInside(iNoth)) { pCadre->Effacer(); carte.TracerUnCadre(pCadre); } }

La restriction sur un attribut nominal peut galement tre effectue en indiquant uniquement les modalits de lattribut conserver. Le dialogue est alors diffrent, et la restriction ne porte que sur un attribut (fig. 5.17). Aprs avoir retrouv et conserv le code interne des modalits slectionnes, la relation est restreinte en ne conservant que les objets correspondant ces valeurs. Le principe de limplmentation est identique la slection par formule.

184

Chapitre 5

fig. 5.17 : dialogue de restriction sur un attribut nominal

5.5.8.2. La jointure La jointure de deux relations correspond la restriction du produit cartsien des deux relations sur un critre descriptif. Le rsultat est une relation non localise, quel que soit le type des deux relations initiales. Une nouvelle relation non localise est cre, elle contient les objets rpondant au critre de jointure. Les attributs proviennent des deux relations initiales. Si lon veut conserver la localisation de lune des relations initiales, il faut tre sr de ne pas dupliquer les objets lors de la jointure. Cest pour cela que nous avons dvelopp une autre opration, appele union, qui sapparente une jointure avec les diffrences suivantes : - un objet de la premire relation est conserv dans la relation rsultante si il rpond au critre de jointure avec au moins un objet de la seconde relation ; - la valeur des attributs provenant de la seconde relation correspond la valeur des attributs du premier objet trouv dans la seconde relation satisfaisant au critre de jointure. Cette opration est notamment trs utile lorsque le critre de jointure est une galit (qui-jointure) et quil porte sur une cl de la seconde relation, car lon sait

De lobjet la collection dobjets 185 alors que le rsultat de la jointure ne cre pas de doublons : au maximum un seul objet de la seconde relation pourra tre mis en relation avec un objet de la premire relation. Le rsultat dune union est alors identique au rsultat dune jointure, mais permet de conserver la localisation de la premire relation. Limplmentation de cette opration dans le systme SAVANE est donne dans lannexe A.2.5.1. 5.5.9. La ralisation des oprations relationnelles tendues 5.5.9.1. La restriction spatiale La restriction spatiale correspond la slection dobjet sur un critre de localisation. Le systme SAVANE permet deffectuer des restrictions spatiales par rapport une fentre gographique rectangulaire (fentre de travail) et des domaines de lespace dfinis sous forme de masques. Lopration de slection recopie les objets slectionns dans un nouveau fichier descriptif temporaire. Si la relation est visualise dans le cadre, le dessin est automatiquement ractualis. Pour les types zone et ligne, le fichier des arcs nest pas modifi, sauf dans le cas dune restriction par domaine avec redfinition de la localisation, comme nous allons le voir un peu plus loin. 5.5.9.1.1. La restriction spatiale par fentre dtude Chaque cadre, correspondant une requte, possde une fentre de travail. Quel que soit lopration effectue dans le systme, une restriction spatiale sera automatiquement effectue dans cette fentre. Pratiquement, le systme utilise lindexation spatiale en feuille et naccde quaux feuilles qui ont une intersection non vide avec la fentre de travail. Ensuite, il naccde quaux objets dont la fentre a une intersection non vide avec la fentre de travail. Lindexation spatiale et la fentre dtude permettent damliorer considrablement les performances du systme, lors de linterrogation des donnes. Lors de la cration du cadre, cette fentre correspond lespace gographique donn lors de la dfinition de la base. On peut changer cette fentre par de nombreuses mthodes : coordonnes gographiques, coordonnes de projection, espace occup par les objets dune relation, choix sur cran, dplacement, etc. Chaque changement de fentre implique normalement une rinitialisation de la requte. Cette rinitialisation doit tre faite par lutilisateur lui-mme. 5.5.9.1.2. La restriction spatiale par domaine La restriction spatiale par domaine utilise un masque. Pour une relation, elle permet de slectionner les objets se trouvant dans ou hors du domaine reprsent par

186

Chapitre 5

le masque. Cette restriction ne pose pas dambigut pour les objets de type point. Par contre, pour les types ligne ou zone, il faut choisir entre une restriction ensembliste ou une restriction spatiale. On a donc le choix entre une slection par centrode (slection de lobjet si son centrode se trouve dans le masque), une slection ensembliste (slection de lobjet si lintersection avec le masque est non vide), et une slection avec redfinition de la localisation de lobjet (slection de lintersection). La slection par centrode ne pose aucune difficult de ralisation. On utilise la reprsentation matricielle du masque pour tester lappartenance du centrode au masque, en testant dans le masque la valeur du pixel correspondant la localisation du centrode de lobjet. La slection ensembliste est un peu plus complexe. Pour les zones, on utilise la reprsentation matricielle de la relation et du masque, ce qui permet de comparer les images pixel par pixel et tester lintersection dune zone avec le masque. On conserve la zone si lintersection est non vide. Pour les lignes, on teste directement lintersection de la ligne avec le masque en calculant dans le repre matriciel du masque les pixels correspondant la ligne. La slection de lintersection est un peu plus difficile mettre en uvre, puisquelle impose une redfinition de la gomtrie des objets rsultants de lopration. Pour les relations de type zone, deux mthodes sont disponibles pour cette opration : une mthode rapide en raster, une mthode plus longue mais plus prcise en vecteur. La mthode raster utilise la reprsentation matricielle de la relation et du masque : la comparaison pixel par pixel est rapide et permet dobtenir rapidement une image de la relation qui ne conserve que les pixels correspondant la valeur 1 du masque. Cette image est ensuite balaye pour obtenir la liste des objets existants et crer le nouveau fichier descriptif partir de lancien. Enfin, limage est vectorise pour crer un nouveau fichier darcs correspondant aux contours de ces nouvelles zones. La mthode vectorielle utilise directement les arcs en calculant les intersections des arcs des zones avec les arcs du masque. Les zones sont ensuite reconstitues partir des bouts ainsi forms. Lalgorithme classique dintersection darcs segment par segment est utilis (voir chapitre 3). Il est fortement acclr par la prise en compte de la fentre des arcs, qui permet dliminer de nombreuses comparaisons inutiles. 5.5.9.2. Les jointures spatiales Limplmentation des jointures spatiales dpend du type des deux relations et de la qualification de jointure. Les seules jointures qui ne font pas perdre la localisation sont les jointures avec une qualification d(O1,O2) = 0, le type du rsultat correspondant alors celui de lintersection des objets. Ainsi, le rsultat dune jointure zone-zone avec une qualification d(O1,O2) = 0 est une relation de type

De lobjet la collection dobjets 187 zone : les objets correspondent aux intersections des objets des deux relations. Le rsultat dune jointure zone-point est une relation de type point, et le rsultat dune jointure zone-ligne est de type ligne. Comme pour les restrictions de domaine, deux mthodes sont disponibles pour la ralisation des jointures spatiales lorsque lune des relations est de type zone. La mthode raster compare les images des relations, limage de la relation rsultante correspondant lintersection des deux images (fig. 5.18). Chaque zone du rsultat rcupre les attributs des deux zones initiales. Limage du rsultat est vectorise pour crer les contours des arcs correspondant aux zones de la jointure.

188

Chapitre 5

fig. 5.18 : une qui-jointure spatiale zone-zone

La ralisation de la jointure se droule ainsi en plusieurs phases : - cration dune nouvelle image par calcul pour chaque pixel dun code rsultant des valeurs du mme pixel dans les images des deux relations initiales, - cration des tuples descriptifs correspondant aux combinaisons rencontres dans la premire phase (ce qui revient liminer les tuples descriptifs en double), - tablissement de la relation image-tuples, - vectorisation de limage. On trouvera en annexe le code de la procdure dqui-jointure gomtrique entre deux relations de type zone, mthode raster (A.2.5.2.). La mthode vectorielle cre les intersections de zones partir des arcs de lensemble des zones initiales, puis cre les tuples descriptifs correspondant aux objets graphiques ainsi crs. Certaines jointures zone-zone crent de nombreuses petites zones qui nont pas de sens smantique car elles proviennent uniquement des diffrences de prcision de la reprsentation gomtrique et peuvent tre considres comme des artefacts. On

De lobjet la collection dobjets 189 peut supprimer ces zones parasites en liminant dans la nouvelle relation les zones de trop petite taille, ou celles dont le rapport primtre/surface est trop faible. 5.5.9.3. Les semi-jointures spatiales Pour viter la perte de la localisation de lune des deux relations, nous avons dvelopp dans le systme SAVANE plusieurs procdures qui sont des semijointures gomtriques suivies dune agrgation des valeurs descriptives sur la cl de localisation initiale. De mme, nous avons dvelopp des semi-jointures classiques qui vitent les doublons dobjets gographiques. Ces oprations, lies lanalyse spatiale, seront prsentes au chapitre 8. 5.5.10. La connexion dautres systmes de gestion de base de donnes Le systme SAVANE dispose de son propre moteur de base de donnes relationnel tendu, qui lui permet de grer de manire optimale les donnes localises. La plupart des SIG ne fonctionnent pas de cette manire : ils utilisent un systme relationnel classique pour grer les attributs descriptifs et ne grent que linformation de localisation des objets. Ces deux approches ont leurs avantages et leurs inconvnients. Les avantages sont vidents : on dispose de la puissance et de la fiabilit des SGBD relationnels commerciaux. Les inconvnients sont galement nombreux : toute opration ncessite lunion des objets gr par le SIG et ceux, non localiss, grs par le SGBD classique. Une requte un peu complexe demande donc plusieurs aller et retour entre les deux systmes, lorsque cela est possible. Nous avons dvelopp dans SAVANE une solution qui permet de bnficier des avantages des deux systmes : des attributs descriptifs peuvent tre imports des principaux SGBD relationnels (via ODBC, DAO, ou ADO) temporairement dans le SGBD directement gr par SAVANE. Si limportation est temporaire, les attributs ne sont utiliss que lors de la requte, mais une fois imports, ils sont considrs comme les autres attributs et grs directement par le systme. Il ny a donc quune seule connexion au SGBD externe. Cette particularit fait de SAVANE virtuellement un SGBD double moteur de gestion : un moteur interne bas sur une indexation primaire bidimensionnelle, et le moteur externe du systme externe associ. 5.6. Conclusion Lextension du modle relationnel au donnes localises constitue le premier objectif de notre travail : bnficier de la simplicit et de la puissance du modle

190

Chapitre 5

relationnel pour la gestion des donnes gographiques. Nous avons ainsi dfini de nouvelles oprations permettant dtendre lalgbre relationnelle sur lattribut de localisation. Ces oprations utilisent la structure mtrique et la distance euclidienne pour tendre les oprations classiques de lalgbre relationnelle (restriction, projection, jointure) . Dautres oprations pourraient ainsi tre dfinies, en utilisant la structure ensembliste (inclusion, intersection, appartenance) ou la structure topologique (relations dadjacence, par exemple). La jointure spatiale tend formellement lopration classique de jointure de lalgbre relationnelle, mais la validit de son emploi savre beaucoup dlicate que dans le cas classique, o lopration ne prsente aucune ambigut. En effet, comme nous lavons vu au chapitres 3 et 4, lattribut de localisation na pas toujours la mme prcision et la mme validit. Lopration de jointure telle que nous lavons dfinie ignore ces diffrences. Elle est donc peu adapte de nombreuses situations, surtout lorsque la jointure implique des relations dont limplantation spatiale na pas le mme degr de validit. Pour construire un systme performant, il nous faudra donc introduire de nouvelles oprations permettant de rsoudre ces problmes de transfert dchelle et de mise en relation dobjets de prcision gographique diffrentes. Ces oprations sont pratiquement toutes apparentes une jointure spatiale suivi dune opration de regroupement, mais nous les prsenterons dans le chapitre 8 consacr lanalyse spatiale : plus que des oprations de gestion, elles utilisent une mise en relation sur la localisation plus pour rsoudre des problmes danalyse que pour rpondre un besoin de bonne gestion de donnes.

De lobjet la collection dobjets 191

Bibliographie

[ABI 95] ABITEBOUL S., HULL R., VIANU V., Foundations of Databases, 1995, AddisonWesley [BER 93] BERTINO E., MARTINO L., Object-Oriented Database Systems, 1993, AddisonWesley [DAT 95] DATE C.J., Introduction to Database Systems, 1995, Addison-Wesley [DAV 91] DAVID B., Modlisation, reprsentation et gestion dinformation gographique, une approche en relationnel tendu, Thse de doctorat, 1991, Universit Paris VI [DEL 91] DELOBEL C., LECLUSE C., RICHARD P., Bases de donnes : des systmes relationnels aux systmes objets. 1991, InterEditions, Paris [EGE 91] ENGENHOFER M., Spatial Query langages. Thse de doctorat, 1991, University of Maine, USA [FLO 93] DE FLORIANI L., MARZANO P., PUPPO E., Spatial Queries and Data models, in Frank A. and Campari I.U., Spatial Information Theory, Lecture Notes in Computer Sciences 716, 1993, Springer-Verlag, p. 113-138 [GAR 83] GARDARIN G., Bases de donnes : les systmes et leurs langages, 1983, Eyrolles, paris [GRE 89] GREENE D., Implementation and Performance Analysis of Spatial Data Access Methods, IEEE, Intl. Conference on Data Engineering, 1989, p.606-615 [GUN 89] GNTHER O., Efficient Computation of Spatial Joins. IEEE, Intl. Conference on Data Engineering, 1989, p.50-59 [GUT 88] GTING R.H., Geo-Relational Algebra : A Model and Query Language for Geometric Database System, Proccedings of Intl. Conference on Extending Database Technology, 1988, p. 506-527

192

Chapitre 5

[HAS 82] HASKIN R.L. AND LORIE R.A., On extending the functions of a relational database system. Association for Computing Machinery, Proccedings of SIGMOD, NY : ACM Press, 1982, p. 207-212 [LAR 93] LARUE T., PASTRE D., VIMONT Y., Strong Integration of Spatial Domains and Operators in a Relational Database System, Intl. Symposium on Large Spatial Databases, LNCS n 692, 1993, p. 53-72, Springer-Verlag [LAU 93] LAURINI R., MILLERET-RAFFORT F., Les bases de donnes en gomatique, Herms, 1993, Paris [LOR 84] LORIE R.A., MEIER A., Using a Relational DBMS for Geographic Databases. GeoProcessing, 1984, p.243-257 [NEW 79] W. M. NEWMAN, R.F. SPROULL, Principles of Interactive Computer Graphics, 1979, Mc Graw Hill [OOI 89] OOI B.C., SACK-DAVIS R., MC DONELL K.J., 1989, Extending a DBMS for Geographic Applications, Intl. Conference on Data Engineering, p. 590-597 [PAV 82] PAVLIDIS T., Algorithms for Graphics and Image Processing, Computer Science Press, 1982 [SAM 80] SAMET H., Tree Structure for region representation, Aangeenbgug, Autocarto 4, vol. 1, 1980, pp 108-118 [SOU 86] SOURIS M., Systmes dinformation gographique et bases de donnes, Colloques et Sminaires, Traitement des donnes localises, 1986,Editions de lOrstom [SOU 87] SOURIS M., A Geographic Information System with relational architecture : principles and example of use. in Primera conferencia sobre informatica y geografia, San Jose, Costa Rica, 1987, pp 703-728 [ULL 88] ULMANN J.D., Principles of Database and Knowledge-Base Systems, 1988, Computer Science Press [WOR 90] WORBOYS M.F., HEARNSHAW H.M., MAGUIRE D.J., Object-Oriented data Modelling for Spatial Databases, International Journal of Geographic Information Systems, 1990, vol. 4, p. 369-383

De lobjet la collection dobjets 193

Chapitre 6

Go-rfrencement et intgration dimages

Lobjet de ce chapitre est de montrer comment les images numriques (tldtection spatiale, photographies ariennes, modles numriques, cartes scannes) peuvent tre intgres en tant quinstances de classes dobjets gographiques dans une base de donnes relationnelle et bnficier ainsi de la gestion du systme dinformation gographique au mme titre que les autres classes dobjets localiss (zones, lignes, points). Nous introduirons le type dobjet dfini pour grer les images, puis les diffrentes mthodes utilises pour crer les objets pixels dans un SIG, par redressement et mosaquage des images brutes ou par cration directe partir dobjets dun autre type. Nous passerons rapidement en revue les diffrentes oprations pouvant tre utilises dans le cadre de la gestion relationnelle des objets de type pixel, ainsi que les oprations permettant de passer du type pixel aux autres types dobjets localiss. Enfin, nous montrerons comment la dfinition de classes dobjet pour les principaux types de capteurs de donnes gographiques par balayage permet dencapsuler dfinition des objets et mthodes dutilisation de ces objets, facilitant ainsi lexploitation des ces donnes dans le cadre du SIG. Le systme peut ainsi proposer des schmas de donnes incluant de nombreuses mthodes associes aux attributs, et se charge de lensemble de la gestion de donnes souvent trs volumineuses. Enfin, nous exposerons la mise en uvre de ces principes et mthodes dans le systme dinformation gographique SAVANE.

196

Chapitre 6

6.1. Introduction Les donnes de type image sont souvent considres comme des donnes un peu part dans les SIG, ce qui donne lieu de nombreuses ambiguts sur la validit des traitements effectus par rapport aux autres objets de la base de donnes. Cette approche ne peut nous satisfaire : il est ncessaire de recourir un formalisme plus prcis, et il convient dappliquer aux donnes provenant dun capteur de type raster les mmes critres quaux autres donnes gographiques [EST 92]. On devra ainsi dfinir exactement quel est lobjet trait par le SIG. Le pixel dune image brute est en effet rarement un objet localis de faon absolue avec prcision : la position dun pixel nintervient souvent dans une image que de manire relative, par rapport ses voisins. La plupart des oprations en tldtection et traitement dimage ne considrent que lagencement des pixels entre eux, et ne ncessitent pas de gorfrenciation absolue de chaque pixel. Mais lorsque lon veut joindre ces pixels avec les objets dune base de donnes localises, le premier problme est de localiser les lments dune image avec une prcision connue. Pour cela, on se rend vite compte que le pixel de limage brute ne peut tre lobjet final. Il est ncessaire de dfinir un nouvel objet, connu et parfaitement localis (avec une prcision gographique donne), et de calculer pour cet objet la valeur dun attribut en utilisant les donnes de limage, par une opration de r-chantillonnage. Mais il est galement important de conserver linformation de voisinage prsente dans limage de dpart, car lon connat la prcision de voisinage grce au capteur (par exemple, le satellite SPOT permet une prcision relative de 10 mtres entre les pixels; une photographie arienne peut tre scanne avec une prcision relative de un mtre, etc.). La prcision nest bien sr quun ordre de grandeur, puisque la projection gographique des images est en gnral inconnue (les images sont par dfinition projetes, puisque elles sont donnes dans un plan, mais les caractristiques de cette projection sont inconnues - elle ne pourrait tre trouve quau moyen de la rsolution dquations un grand nombre dinconnues). On ne peut donc parler de lunit des coordonnes de cette projection inconnue. On a deux critres pour dfinir les objets : un critre de taille pour conserver linformation de voisinage, et un critre de calcul pour conserver linformation descriptive (la valeur physique correspondant au signal). On peut choisir des objets qui existent dj (des zones par exemples), et calculer une valeur descriptive pour ces objets (mais on perd en gnral linformation de voisinage). On peut choisir de crer des objets simples (de nouveaux des pixels, mais cette fois-i considrs comme des mailles), dont on dfinira exactement les caractristiques et dont on connatra alors la position exacte dans un plan de projection donn. Toute la difficult vient alors de dfinir la mthode permettant dassocier ces objets une valeur descriptive venant de limage dorigine, par redressement et rchantillonnage. Pour cela, il faut essayer de savoir quels sont les pixels de limage

Gorfrencement et intgration dimages

197

dorigine qui sont candidats intervenir dans la valeur dun objet darrive, et il faut dfinir la mthode employer pour associer une valeur descriptive lobjet partir de ces pixels dimage. Nous allons donc dfinir dans le schma relationnel un type dobjet pour grer les images, puis introduire les diffrentes mthodes utilises pour crer les objets dans un SIG, par redressement et mosaquage des images brutes, ou par cration directe partir dobjets dun autre type. Nous prsenterons les principes de la gestion des relations de type mosaque dans SAVANE, ainsi que les diffrentes oprations pouvant tre utilises dans le cadre de la gestion relationnelle. Enfin, nous prsenterons en dtail le module SAVAMER qui permet deffectuer le redressement des images et la constitution de mosaques dans le systme SAVANE. 6.2. Dfinition dune classe dobjet pour les donnes venant dimages : le pixel 6.2.1. Dfinition de lobjet Nous allons dfinir une nouvelle classe dobjet localis pour grer les images gorfrences. Dabord, nous pouvons remarquer que chaque objet est un ensemble de points de lespace, correspondant un lment de limage : ce sont des zones. La gomtrie des objets est la plus simple possible, et est identique pour tous les objets de la classe; la plupart du temps, elle ne sera mme pas prise en compte dans les traitements, et la zone sera assimile son centrode. Cest justement cette ambigut qui ne doit pas faire oublier la dfinition des objets, en terme de prcision de leur localisation. Par dfinition, lobjet est une zone carre, qui est appele pixel par similitude avec les lments dimage, et sa localisation est donne par la position de son centre et la taille exacte du cot du carr dans un plan de projection. Comme tous les objets ont la mme taille, il suffit de connatre la position absolue dun seul objet pour dterminer la position de tous les objets, si leur position peut tre donne relativement cet objet. Lagencement des objets en grille permet donc de connatre la localisation de chaque objet, pour peu que lon connaisse la position dun seul objet, la taille commune des objets, et le nombre de colonnes de la grille. Cette description est donc trs efficace en terme de mmoire et de slection des objets sur un critre de localisation, puisquil suffit de stocker les valeurs des pixels et que lagencement de ces valeurs dans la structure de stockage est suffisant pour connatre la localisation des objets. On vite ainsi de conserver les coordonnes du centre de chaque objet. Les attributs correspondent aux valeurs affectes chaque pixel. Les donnes provenant des images brutes peuvent tre de diffrents types, correspondant des

198

Chapitre 6

attributs nominaux, des attributs entiers (cods sur 1, 8, 16 ou 32 bits), rels, reprsentant une couleur RGB (24 bits) ou RGBK (32 bits). Par exemple, une image SPOT fournit trois ou quatre attributs, de type entier cod sur 8 bits (256 valeurs maximum), une image TM en fournit sept, une image scanne en vraie couleur en fournit un de type RGB, etc. Une relation de type pixel sera donc dfinie par les critres suivants : - la taille des objets (en fait la taille du cot du pixel, en mtre) ; - le plan de projection utilis (en fait les paramtres de la projection gographique) ; - les attributs descriptifs. 6.2.2. Gestion des collections de pixels La localisation dun objet de type pixel est donc donne par la position de la valeur de ses attributs dans une grille. Mais le stockage des pixels en grille pose un problme quant lexistence des objets, car il suppose lexistence de tous les pixels de la grille. Il faut donc ajouter un attribut boolen indiquant lexistence relle de tel objet dans la relation. Une grille est toujours rectangulaire : pour viter une importante perte de volume de stockage lorsque le domaine dexistence des objets est de forme quelconque, il convient de trouver une structure qui minimise la place perdue dans la grille pour les pixels non existants, tout en conservant la simplicit du stockage en grille. Nous avons donc choisi naturellement de diviser lespace en petites rgions (imagettes) et dindexer ces imagettes. Lensemble des imagettes constitue donc une mosaque, et lensemble des pixels des imagettes dont lattribut dexistence est vrai correspond lensemble des objets de la relation. La position dun pixel quelconque de la mosaque est donne par sa position dans limagette auquel il appartient, et par la position absolue dun pixel de limagette. Chaque imagette sera donc caractrise par ces trois paramtres : position absolue dun pixel dans le plan de projection (on prendra le pixel bas-gauche), nombre de colonnes et nombre de lignes de limagette. Lexistence des objets est donne par la valeur de lattribut dexistence. Les valeurs des attributs des objets sont donnes par les valeurs de limagette correspondant la position de lobjet dans limagette (on a donc une mosaque dimagettes par attribut). Les oprations relationnelles (restriction, jointure) utilisent en priorit lattribut dexistence. La restriction correspond par exemple une modification de la valeur cet attribut.

Gorfrencement et intgration dimages

199

Les relations de type pixel seront donc composes de : - une liste des imagettes existantes, dcrivant pour chaque imagette la localisation du coin bas gauche du pixel bas gauche, le nombre de colonnes et de lignes, et ladresse du dbut de limagette dans lensemble des grilles de valeurs dattributs ; - pour chaque attribut, un ensemble de grilles de valeurs. 6.3. Gorfrencement des images et cration des objets Une fois dfini le schma dune relation de type pixel, les objets peuvent tre crs partir dautres objets de la base de donnes (par changement de type, par exemple par interpolation ou par rasterisation), mais le plus souvent, ces objets seront crs partir dimages numriques provenant dun capteur (photographie numrique, scanner, satellite, etc.). Pour chaque pixel potentiel de lespace, il est alors ncessaire de rpondre plusieurs questions : - un objet doit-il tre cr ? - quelles valeurs pour les attributs, partir des valeurs des pixels de limage dorigine ? Lopration de gorfrencement dune image permet de rpondre ces questions. Cette opration vise crer une nouvelle image possdant les caractristiques de taille et de projection gographique de la relation, et permettant de connatre la localisation exacte de chacun de ses pixels. Lors de lintgration de cette image dans la relation, seuls les pixels prsents dans les imagettes ayant une intersection avec limage gorfrence seront physiquement crs dans la relation. Lattribut dexistence des pixels crs mais non prsents dans limage gorfrence sera initialis FAUX. La cration dobjets de type pixel dans la base de donnes partir dune image correspond donc deux oprations : - la gorfrenciation de limage dorigine, par redressement gomtrique et rchantillonnage ; - lintgration des pixels de limage gorfrence dans la relation, par mosaquage.

200

Chapitre 6

6.3.1. Redressement dimage Les images obtenues par un capteur ne sont pas directement go-rfrences : elles comportent des dformations globales ou locales et doivent tre redresses pour tre mises au mieux en conformit avec la ralit gographique, dans un plan de projection. Nombreuses sont les causes de dformation [NOV 92]. Pour les photographies ariennes ou les images satellites, on peut citer par exemple les dformations dues loptique de prise de vue, aux conditions atmosphriques, la position de linstrument de prise de vue, au relief de la surface, la projection gographique [HOT 99]. Une fois dfinis les paramtres de limage darrive (taille du pixel et plan de projection), le problme du redressement consiste trouver le ou les pixels de limage dorigine qui correspondent un pixel de limage darrive. Le choix des fonctions utiliser pour assurer au mieux cette correspondance dpend du type de dformation prsume, des possibilits de prise de points de correspondance entre image dorigine et image darrive (points dappui ou amers), et de la disponibilit dun modle numrique de terrain. Corriger gomtriquement une image revient toujours dterminer un modle de dformation entre les coordonnes dans limage brute et les coordonnes dans le systme de rfrence utilis pour la relation crer. Trois cas peuvent se prsenter : - on connat les modles de dformation avec une grande prcision. Dans ce cas, il suffit de modliser le redressement en prenant en compte les dformations connues ; - on ne connat pas les modles de dformation. On modlise alors arbitrairement ces dformations avec une fonction donne, en gnral polynomiale. On calcule les coefficients du modle laide de points dappui, points dont on connat les coordonnes dans les deux repres (image et systme de rfrence de la relation crer) ; - on connat les modles de dformation, mais avec une prcision insuffisante. On ajuste alors le modle laide de points dappui. Le nombre de points dappui ncessaires dpend alors du modle. Les deux derniers cas sont les plus courants en pratique. Les possibilits de dtermination de points dappui sont donc fondamentales. Cette opration revient localiser (dans le plan de projection) des points de limage dorigine. Les modles de dformation et les mthodes de redressement qui en dcoulent sont nombreux : ils dpendent essentiellement du type de dformations auxquelles limage redresser est soumise, des possibilits de prise de points dappui, de la disponibilit dun modle numrique de terrain [HOT 99]. Ils dpendent galement

Gorfrencement et intgration dimages

201

de la prcision souhaite par rapport aux donnes dorigine. Dans la pratique, on utilise les fonctions suivantes : - une translation : dans ce cas, limage dorigine est dj conforme la projection gographique, la taille du pixel est connue, la translation nest utilise que pour localiser limage mais neffectue aucune transformation sur les pixels. Un seul point dappui est ncessaire pour effectuer une translation. - une translation et une rotation : cest la transformation la plus simple, utiliser dans le cas o limage dorigine est gographiquement correcte mais doit subir une translation et une rotation pour tre en conformit avec le repre de la projection. Les distances dans limage ne sont pas modifies. Deux points dappui sont ncessaires pour effectuer cette transformation. - une similitude : cest une translation et une rotation suivie dune homothtie (mise lchelle). La similitude est utiliser lorsque, pour tre mise en conformit avec une projection gographique, limage doit subir une translation, une rotation, puis une mise lchelle. La mise lchelle est identique sur lensemble de limage, la dformation est identique quelque soit la direction. Deux amers sont ncessaires pour cette transformation. - une dformation polynomiale de degr 1 : cette dformation est identique la similitude, sauf pour la mise lchelle qui nest pas identique quelque soit la direction. Trois points dappui sont ncessaires pour effectuer cette transformation. - une dformation projective : cest une perspective centrale, dformation naturelle idale obtenue sur une photographie, lorsque le terrain photographi correspond un plan. Au minimum six points dappui sont ncessaires pour fixer les coefficients de cette transformation, ce qui revient positionner le faisceau projectif dans lespace. Lorsque la distance aux objets est grande par rapport la taille des objets, la perspective centrale peut tre approche par une dformation polynomiale de degr 1. Lorsque lon redresse une image de la Terre, cette transformation doit tre combine une dformation prenant en compte laltitude et la courbure de la Terre, sinon lchelle obtenue nest pas correcte. En effet, la dformation prcdente ne tient pas compte de laltitude des points dans limage : les points sont projets dans le plan comme sils taient tous laltitude zro, alors que la projection dans le plan doit suivre une verticale, et non pas un rayon lumineux, partir de laltitude suppose du point. Pour prendre en compte cette dformation, il faut connatre le relief en tout point et donc disposer dun modle numrique de terrain. - une dformation par grille ou par triangulation : cette dformation combine une premire transformation globale (rotation, similitude, polynomiale, perspective centrale), avec une dformation locale (en gnral polynomiale) dans chaque triangle rsultant dune triangulation partir des points damers saisis. Cette transformation est trs efficace lorsque lon ne dispose pas dun modle numrique de terrain permettant de connatre laltitude en chaque point. En effet, elle tablit un modle de dformation dans chaque triangle. La dformation correspond un

202

Chapitre 6

dcoupage de lespace en facettes (planes dans le cas dun polynme de degr 1), et si le rseau de point damers est dense et homogne (et dautant plus dense que les diffrences daltitude sont grandes), le redressement permet dobtenir directement une image en conformit avec la projection gographique choisie. Ce type de dformation permet galement dassurer une jointure parfaite entre diffrentes images : une fois une image redresse, il suffit de saisir des points damers entre limage redresse et limage recaler pour faire concider les deux images. La transformation initiale permet de caler grossirement limage redresser : elle doit correspondre au mieux au type de dformation globale laquelle est soumise cette image. Le redressement polynomial de degr 1 ou projectif (si lon connat laltitude des points damers) est souvent le plus adquat. 6.3.2. Le choix des points dappui Disposer du modle de la dformation est peu courant en pratique. Pour une photographie arienne par exemple, cela revient connatre les paramtres de loptique du capteur, la position exacte du point focal, et laltitude de lensemble des points de lespace photographi. La prise de points dappui est donc fondamentale. Quelque soit la mthode de redressement employe, il est important de multiplier les points dappui de manire mieux ajuster le modle et rduire lincertitude. Des points de contrle permettront destimer la validit du modle employ. Le choix des points dappui peut tre manuel ou automatique. Lorsque la prise des points est manuelle, le choix devra se focaliser sur des points remarquables et prcis, comme des intersections de routes, des arbres (pris au niveau du sol), des angles de champs, etc. Dans la majorit des cas, cette prise de point seffectue sur une carte (cest lune des fonctionnalits du module SAVAMER dcrit dans ce chapitre). Lorsque lon ne dispose pas de cartes, ou que la prcision est insuffisante, on aura recours la prise de points sur le terrain, par des mthodes godsiques classiques ou par GPS. La prise de points manuelle est une opration longue et fastidieuse ; elle peut mme tre dangereuse car une grande attention est requise pour ne pas introduire des erreurs. Des techniques de saisie automatique peuvent alors tre employes pour dterminer des points remarquables quivalents entre limage redresser et le document go-rfrenc, en mesurant des indices de corrlation locale. Ces techniques sont particulirement efficaces lorsquil sagir de redresser une image en utilisant comme rfrence une autre image go-rfrence. Elle est plus dlicate entre une carte et une image pour des raisons de prcision. Le principe est le suivant :

Gorfrencement et intgration dimages

203

- on effectue un premier redressement global de degr 1 ou 2 laide de quelques points dappui saisi manuellement ; - on effectue une recherche systmatique de points singuliers dans la premire image. Pour chaque point singulier, on dtermine la forme dune fonction partir des valeurs des pixels de limage proche du point singulier. On recherche ensuite dans la seconde image le point qui offre la mme forme pour cette fonction. La recherche est faite autour du point correspondant au redressement global initial. Le choix de la fonction est important : on peut prendre une fonction sur les valeurs des pixels, ou une fonction sur lagencement local de ces valeurs (comme une texture, par exemple). Le rayon de la recherche est galement un paramtre important : il dpend de lampleur des dformations locales estimes, ainsi que du relief suppos. Enfin, le seuil de ressemblance ou de variance locale sont galement des paramtres importants : ils permettront dtre plus ou moins exigeant sur la qualit du rsultat. 6.3.3. Le r-chantillonnage Le redressement saccompagne galement dun r-chantillonnage : les pixels dans limage darrive nont pas forcment la mme taille que les pixels dans limage de dpart. En fait, les pixels ne sont jamais les mmes, puisquils sont dforms par les nombreuses oprations de redressement. La dmarche est donc inverse : la taille et la position des pixels de limage darrive tant fixes par dfinition de la relation, on calcule la valeur en cherchant quel est ou quels sont les pixels dans limage de dpart qui lui correspondent, aprs toutes les dformations inverses. Le r-chantillonnage consiste donc choisir une fonction de calcul ou dinterpolation pour la valeur du pixel partir des pixels qui lui correspondent dans limage de dpart. Les mthodes les plus rpandues sont : plus proche voisin, interpolation partir dune fonction bilinaire ou dune fonction bicubique sur les voisins [GDT 93]: - la rgle du plus proche voisin consiste affecter au point la valeur du point le plus proche dans limage de dpart. - la fonction bilinaire correspond une interpolation partir dun domaine de 2x2 pixels autour du point trouv, en traitant linairement les abscisses et les ordonnes. - la fonction bicubique utilise un polynme de degr 3 sur un domaine 4x4, en traitant indpendamment les abscisses et les ordonnes. 6.3.4. Le mosaquage et lintgration dans une relation Une fois redresse, les pixels de limage peuvent tre intgrs dans une relation qui possde les mme caractristiques de taille de pixel et de projection

204

Chapitre 6

gographique. Cette opration est appele mosaquage. Le mosaquage permet de choisir de faon interactive les pixels de limage redresse intgrer dans la relation. Si un objet nexiste pas dans la relation, il est cr et la valeur de limage est affect lattribut choisi, qui doit tre du mme type que limage (nominal, entier, rel, RGB, etc.). Si lobjet existe dj, la valeur de limage remplace la valeur de lattribut choisi. Dans la suite, nous appellerons mosaques les relations dont les objets sont de type pixel. Une mosaque provient de diverses images redresses et intgres dans un mme ensemble. La correction gomtrique permet dassurer le bon assemblage gomtrique des images. Mais il est courant davoir des images qui prsentent des diffrences de valeurs : on constate alors un mauvais raccord des valeurs des pixels. Pour palier ce problme, il convient deffectuer un redressement descriptif des images aprs le redressement gomtrique. Ce redressement revient normaliser les valeurs des diffrentes images avant de les mosaquer. La ralisation dune mosaque peut donc tre dcompose en trois tapes : - corrections gomtriques des images assembler ; - corrections des valeurs pour normaliser lensemble des images ; - assemblage des images 6.3.4.1. Les mthodes de correction gomtrique pour les mosaques Les mthodes de correction gomtrique sont celles que nous avons vues au paragraphe prcdent. Mais lorsque lon redresse une image dans le but de lintgrer une mosaque, il est trs utile de se servir des zones de recouvrement entre images pour la prise de points dappui, et assurer ainsi une superposition exacte des zones communes. Le problme du mosaquage est bien connu en photogrammtrie analytique. Plusieurs mthodes ont t dveloppes pour viter la propagation derreurs lors de la prise de points dappui dans des zones de superposition [HOT 99]. 6.3.4.2. Les mthodes de correction descriptive pour les mosaques Les images dune mosaque sont gnralement obtenues des dates diffrentes, ou avec des conditions de prise de vue diffrentes (ensoleillement, angle, etc.). Comme les objets de mme nature doivent apparatre avec des tonalits identiques, il faut minimiser leurs diffrences de couleurs ou de niveaux de gris de part et dautre de la ligne de raccord. On opre gnralement lgalisation des valeurs dune image par talement, en prenant des valeurs de rfrence calcules sur la base dun ajustement des histogrammes sur une zone de recouvrement. Nanmoins, cette mthode nest pas toujours satisfaisante, car elle suppose lajustement linaire, la fois dans la zone de recouvrement (pour la constitution du modle) et dans

Gorfrencement et intgration dimages

205

lensemble de limage redresser. Ce nest que rarement le cas en pratique, car, dans le cas de photographies ariennes ou spatiales par exemple, les diffrences proviennent de multiples facteurs non linaires. 6.3.4.3. Lassemblage des images Pour crer une mosaque, il est courant davoir des images dont une partie est commune. Trois mthodes de mosaquage peuvent tre employes : - remplacement de la zone de recouvrement par la zone correspondante dune seule des deux images ; - calcul de nouvelles valeurs pour les pixels de la zone de recouvrement, par combinaison des valeurs des deux images (par exemple, la moyenne) ; - dtermination dune ligne de jointure adapte, dans la zone de recouvrement, aux diffrences de valeurs des deux images. Le module SAVAMER, que nous allons dcrire dans ce chapitre, met en uvre lensemble de ces techniques. 6.3.5. Un cas particulier : les satellites dobservation de la Terre Les satellites dobservation de la Terre sont une source trs importante dinformation gographique. Ils fournissent des images prises par des instruments qui balayent la surface terrestre. Les donnes fournies par les satellites dobservation de la Terre sont caractrises par : - la partie du spectre lectromagntique utilise (visible, infra-rouge, ondes radar) ; - la rsolution au sol, ou plutt la taille du plus petit lment chantillonn sur le terrain ; - la rptitivit de lobservation ; - la qualit des images. La plupart des images provenant des satellites dobservation de la Terre de haute rsolution (comme SPOT, LANDSAT, IKONOS, ASTER) subissent un prtraitement de base pour effectuer des corrections gomtriques ou radiomtriques [GDT 93]. Ainsi, les niveaux de pr-traitement dune scne SPOT sont : - Niveau 1A : galisation des dtecteurs dans chaque bande spectrale ; - Niveau 1B : correction radiomtrique et gomtrique des dformations systmatiques introduites par le systme : rotation de la Terre, effet de fil, angle de vise. La prcision absolue de la localisation est denviron 800 m.

206

Chapitre 6

- Niveau 2A : corrections gomtriques pour restituer la scne dans une projection gographique donne. Cette correction ne fait pas intervenir de points dappui, la prcision absolue de la localisation est celle du niveau 1B. - Niveau 2B : corrections gomtriques faisant intervenir quelques points dappui. Limage est donc restitue dans une projection gographique, et la prcision absolue de la localisation des pixels ne dpend en principe plus que du relief et des conditions atmosphriques. Elle est dautant plus prcise que la vise est plus verticale et le relief moins important. - Niveau 3 : cest une correction de niveau 2B qui tient compte des dformations dues au relief. Il faut alors disposer dun modle numrique de terrain pour connatre laltitude approche en chaque point. Le problme de la gorfrenciation est actuellement bien rsolu par les fournisseurs dimages satellitales, condition de disposer de modles numriques de terrain suffisamment prcis dans la zone concerne. 6.4. SAVANE et mosaques Le systme SAVANE permet de grer des relations de type mosaque dans le cadre du modle relationnel tendu. Nous allons dcrire dans ce paragraphe la structure de ce type de relation ainsi que les particularits de gestion quelle implique. 6.4.1. Structure des relations de type mosaque Les relations de type mosaque permettent de conserver des objets pixel dont les valeurs sont donnes sous forme dimage. Dans ce type de relation, les objets sont trs nombreux (il nest pas rare davoir plusieurs dizaines de millions de pixels), et reprsentent, comme nous lavons vu, la fois une surface ou un point. A cause de ces caractristiques et pour grer ce type de donnes de faon efficace, la structure de reprsentation interne est profondment diffrente de la structure des relations vectorielles : - les donnes sont conserves selon une projection gographique particulire, ce qui permet dutiliser la mosaque dans cette projection sans avoir recalculer la position de chaque pixel ; - la position dun objet est donn par son agencement dans une grille, appele encore imagette, et non par ses coordonnes ; - lindexation nutilise pas une grille adaptative, mais une grille rgulire ;

Gorfrencement et intgration dimages

207

- une mosaque peut tre partage par plusieurs bases de donnes, pour ne pas avoir dupliquer une information volumineuse si deux bases de donnes souhaitent lutiliser. A cause de ces caractristiques, la cration et la gestion dune relation de type mosaque utilise des procdures particulires dans SAVATECA. Par exemple, le dialogue de cration dune relation de ce type est diffrent, car il faut indiquer des paramtres supplmentaires : la taille des pixels, le rpertoire de stockage et la projection dans laquelle est conserve la mosaque. La taille de la grille dindexation peut galement tre paramtre (fig. 6.1).

fig. 6.1. : le dialogue de cration dune relation mosaque

Pour les attributs, nous avons tendu les types de base (nominal, entier, rel) de manire minimiser lespace de stockage de chaque valeur. Rappelons quun attribut correspond ici la notion dimage ou de canal (pour les images satellitaires). Ainsi, le type entier peut se dcliner en entier 8 bits (valeurs de 1 255, valeur inconnue 0), entier 16 bits (valeurs de 1 65655, valeur inconnue 0), entier 32 bits (fig. 6.2). Le type RGB correspond un codage de chaque valeur en 24 bits, pouvant ainsi dcrire une couleur par ces trois composantes, chacune sur un octet (rouge, vert, bleu). Le type rel correspond un codage sur 32 bits (en float) en non sur 64 bits.

208

Chapitre 6

fig. 6.2. : le dialogue de cration dun attribut dune relation mosaque

Tous les fichiers dune relation sont stocks dans un rpertoire qui porte le nom de la relation. Ce rpertoire peut tre nimporte o sur le rseau local, et son adresse (indique lors de la cration ou de la modification de la relation) est conserve dans le fichier base. La structure dune relation de type mosaque comprend un fichier dcrivant la relation (taille du pixel, projection, taille des imagettes), et, pour chaque attribut, un fichier index contenant la description des imagettes prsentes pour cet attribut et un fichier descriptif contenant les valeurs des pixels (fig. 6.3).

Valeurs des pixels, imagette i Index

imagette i ... imagette j ...

Valeurs des pixels, imagette j

fig. 6.3 : structure interne des relations mosaques

Gorfrencement et intgration dimages

209

La description de chaque imagette comprend la fentre gographique occupe par limagette (dans la projection de la mosaque), et ladresse de premier pixel de limagette dans le fichier descriptif. Les pixels de chaque imagette sont ensuite agencs comme dans une image, en ligne du bas vers le haut, chaque ligne tant organise de la gauche vers la droite. Chaque relation comprend galement deux fichiers spciaux indiquant lexistence des pixels, pour lensemble des attributs. Le premier correspond lindex des feuilles existantes, le second indique, pour chaque feuille, lexistence de chaque pixel dans la feuille. Des attributs temporaires peuvent tre crs dans une relation de type mosaque, comme dans tout type de relation (nous dcrirons ces oprations au chapitre 8). Dans ce cas, le fichier correspondant au nouvel attribut temporaire nest pas cr dans le rpertoire de la mosaque, mais dans le rpertoire de lutilisateur. 6.4.2. Oprations relationnelles Les pixels dune mosaque sont grs dans la base de donnes comme les objets dune relation, et bnficient ainsi de lensemble des oprations disponibles, sans quil soit ncessaire de recourir un formalisme spcial pour ce type dobjet. Ainsi, slections, slections gographiques, calculs de nouveaux attributs, classifications, calculs statistiques, utilisent dans le systme SAVANE un formalisme identique quelque soit le type de la relation (zone, ligne, point, pixel, non localis). Par exemple, le calcul dun indice de vgtation sur un domaine de lespace partir dune mosaque provenant dune image satellite cre un nouvel attribut pour la relation : lutilisateur nindique que la formule de calcul, et le nom du nouvel attribut crer. Le systme de gestion se charge de lensemble des oprations. Les oprations de restriction sur les mosaques noffrent aucune particularit dpendant du type : les objets pixel peuvent tre slectionns sur un critre descriptif comme sur un critre de localisation (slection sur un masque). Seul lattribut dexistence est temporairement modifi. Il est par exemple trs simple dtudier les valeurs dun attribut dune mosaque sur un domaine de lespace dfini partir des objets dune autre relation localise. Les oprations de jointure classique (sur un critre descriptif) nont que peu dintrt pour les relations de type mosaque, car le rsultat nest pas localis et le nombre dobjets crs peut tre trs grand. Par contre, les oprations de jointures gomtriques, suivies ou non dune agrgation sur un critre descriptif, sont intressantes et deviennent galement trs faciles mettre en uvre. Par exemple :

210

Chapitre 6

- lqui-jointure gomtrique zone-pixel permet de crer de nouveaux attributs dans la relation mosaque, par intersection des zones et des pixels. - lagrgation de pixels dans des zones permet de crer un attribut pour des objets dune relation zonale en effectuant, par zone, une opration sur la valeur des pixels se trouvant dans la zone. Lopration peut tre une somme, une moyenne, un cart-type, la frquence dune valeur nominale, la surface occupe par les pixels, etc. Par exemple, il est ainsi trs simple de calculer la moyenne de radiomtrie dans une zone de vgtation, ou dajuster un modle de calcul entre canaux grce la mise en relation avec les valeurs dun chantillon de zones. - lagrgation de pixels dans dautres pixels effectue une opration de rchantillonnage, et permet ainsi trs facilement de comparer des images de rsolutions diffrentes. Bases sur ces oprations relationnelles, les oprations de gostatistique, univaries ou multivaries, deviennent galement trs faciles mettre en uvre. 6.4.3. Cration de relations de type mosaque et oprations de changement de type La cration dune relation de type pixel peut galement tre interactive et intervenir tout moment lors dune requte : - par dfinition directe des paramtres de la relation : taille du pixel, projection gographique ; - par rasterisation dune relation zonale, en calculant pour chaque zone les objets pixel correspondants, et en affectant chaque pixel la valeur dun attribut de la zone laquelle il appartient ; - par interpolation partir de points ou darcs, en calculant pour chaque pixel du domaine dtude une valeur par interpolation entre les points dorigine. Les mosaques cres partir dautres objets de la base ont la mme structure que les mosaques permanentes. Elles peuvent ensuite tre intgres de manire permanente la base de donnes. Ces oprations de cration dune relation de type pixel partir de relations localises dautres types (zone, ligne, point, pixel) correspondent un changement de type dobjet. Inversement, on peut crer des relations de type zone, ligne, point ou pixel partir dune relation de type pixel : - cration de zones, par vectorisation et lablisation sur un attribut nominal de la relation mosaque (par exemple, pour crer les zones correspondant la classification dun attribut) ;

Gorfrencement et intgration dimages

211

- cration de lignes, par vectorisation sur un attribut nominal (par exemple, pour crer des courbes disovaleur partir dune interpolation) ; - cration de points, par calcul direct des coordonnes de chaque pixel de la mosaque ; - cration de pixels, par r-chantillonnage permettant modifier la taille du pixel dorigine. Nous dtaillerons lensemble de ces oprations dans le chapitre consacr aux changement de type dobjet (chapitre 9). 6.4.4. Utilisation des mosaques dans le cadre objet 6.4.4.1. La classe de base CMosaique Les relations de type mosaque peuvent tre dcrites en tant quinstances dune classe drive dune classe de base que nous appellerons CMosaique. Les attributs de la relation sont des membres de la classe drive, et dpendent bien sr de la dfinition de la relation correspondante. Du fait de la forme et de lagencement des objets, le type mosaque possde de nombreuses oprations spcifiques, provenant du traitement et de lanalyse dimages, comme par exemple : - morphologie mathmatique (rosion, dilatation, connexit), - calculs gomorphologiques et hydrologiques : pente, orientation, courbures, volume, drainage, etc. - analyse dimage, filtrage, texture et segmentation, - squelettisation et transformations de voisinage, - anisotropie, reconnaissance de forme. Ces oprations sont implantes en tant que mthodes de la classe de base CMosaique. De mme, certaines procdures de visualisation sont propre au type et sont implantes en tant que mthodes de la classe de base : clairements, perspectives, compositions colores. Les mthodes ont en gnral comme paramtres un ou deux attributs de la relation correspondante linstance de la classe drive. Pour la mise en uvre des mthodes, la structure des mosaques en imagettes ne pose aucun problme algorithmique majeur. Il faut seulement grer efficacement les relations de voisinage entre imagettes, pour pouvoir retrouver facilement les

212

Chapitre 6

relations de voisinage entre pixels quelque soit limagette laquelle ils appartiennent. 6.4.4.2. Quelques classes drives On peut dfinir une classe drive partir de la classe de base lorsque lon connat les attributs et des mthodes spcifiques associes ces attributs. Par exemple, les capteurs satellites SPOT ou TM permettent de dfinir des classes drives, car les attributs et leurs caractristiques sont connus (les canaux radiomtriques). Tous les indices particuliers au capteur (comme par exemple les indices de vgtation, dont le NDVI, peuvent tre implants en tant que mthodes propre la classe.

fig. 6.4 : un modle numrique de terrain

Les modles numriques de terrain offrent dautres classes drives. Si lunique attribut correspond une valeur daltitude de chaque pixel, la dfinition de la classe est fonction de la taille de lobjet (la taille du pixel). La classe hrite de nombreuses mthodes de la classe de base, notamment pour toutes les oprations gomorphologiques et hydrologiques. En proposant ces classes drives, le systme peut faciliter considrablement lutilisation des donnes de type pixel dans le SIG : il propose des schmas de donnes incluant de nombreuses mthodes associes aux attributs, et se charge de lensemble de la gestion de donnes souvent trs volumineuses. Lintgration de ce

Gorfrencement et intgration dimages

213

type de donnes dans le systme de gestion est complte et lexploitation de ces donnes peut tre facilement accessible de non-spcialistes. 6.5. Le module SAVAMER 6.5.1. Prsentation gnrale Le systme SAVANE comporte deux modules de saisie graphique, lun pour les images, lautre pour les donnes vectorielles. Le module SAVAMER permet de gorfrencer des images raster et de les intgrer dans une relation de type mosaque. A partir dune image non gorfrence, appele image de dpart dans la suite, le module SAVAMER permet de crer une nouvelle image, appele image darrive, par redressement et r-chantillonage. Les paramtres de cette nouvelle image (projection gographique, taille de pixel, espace gographique) sont indiqus par lutilisateur. Une fois cette opration effectue, le module SAVAMER permet dintgrer les valeurs de limage darrive un attribut dune relation mosaque dune base de donnes. Les paramtres gographiques et gomtriques (projection gographique, taille et forme de pixel) de limage darrive sont donc connus : ce nest pas le cas pour limage de dpart. Le module SAVAMER permet la saisie de points dappui et le redressement avec r-chantillonage, en donnant le choix de la fonction de redressement : similitude, projection centrale, fonction polynomiale de degr 1 ou 3, tessellation, etc. Plusieurs fonctions de redressement peuvent tre combines : il est courant deffectuer une transformation globale (de type projective ou de degr1) suivie de transformations locales (par exemple, redressement de degr 1 dans les triangles issues dune tessellation partir de points dappui). La fonction de r-chantillonage peut galement tre choisie : plus proche voisin, fonction bilinaire sur les voisins, fonction bicubique sur les voisins. 6.5.2. La prise de points dappui 6.5.2.1. Principes gnraux et interface graphique La premire tape du redressement, cest la prise de points dappui, cest--dire de couples de points, lun dans limage redresser, lautre dans lespace gographique. Le nombre de points dappui saisir dpend de la mthode de redressement qui sera employe par la suite : un point suffit pour une translation, deux points pour une rotation, une similitude, ou une fonction polynomiale plus gnrale de degr 1, six points pour une perspective centrale, neuf points pour une

214

Chapitre 6

fonction polynomiale de degr 3, et le plus de points possibles dans le cas dun redressement local par triangulation. Linterface de SAVAMER comprend plusieurs fentres : une fentre gnrale correspondant un espace gographique, dessin dans une projection gographique donne par lutilisateur, et des fentres permettant dafficher une partie ou la totalit de limage redresser. La fentre gographique permet de dessiner tous les objets dj prsents dans les relations de la base de donnes, ainsi que des images dj gorfrences, ou des documents provenant dune saisie vectorielle effectue avec le module SAVEDIT. La prise de points dappui seffectue visuellement en associant un point de la fentre image un point de la fentre gographique . Il est galement possible dindiquer directement les coordonnes gographiques dun point de limage. Cest la mthode utilise lorsque lon redresse une carte scanne, en choisissant des points dintersection des amorces de projection dans limage de la carte scanne. On peut galement dessiner les amorces de projection dans lespace gographique pour vrifier le bon placement des points dappui (fig. 6.5).

fig. 6.5 : linterface graphique du module SAVAMER

Cest galement la mthode utilise lorsque les points dappui proviennent dune campagne de mesures directes sur le terrain : aprs avoir point un point sur limage, on indique les coordonnes gographiques qui ont t releves sur le terrain.

Gorfrencement et intgration dimages

215

Les points dappui sont conservs dans linstance dune classe CAmers (A.3.1.). Cette structure conserve les points dappui dans divers systmes de coordonnes. La procdure de sauvegarde cre un fichier qui conserve les points dappui en coordonnes sphriques (pour le point gographique) et en coordonnes image (pour le point de limage). Ce fichier est associ limage redresser. Sil existe dj (des points dappui ont dj t saisis), il est automatiquement ouvert lors de louverture de limage, et les points dj saisis sont dessins sur lcran. 6.5.2.2. La saisie manuelle des points dappui La saisie manuelle consiste associer manuellement deux points, lun saisi dans lespace gographique, lautre dans limage. Loprateur peut bien sr modifier la position de chaque point avant ou aprs validation du point dappui (fig. 6.6).

fig. 6.6 : exemple de prise de points damers dans une zone commune deux images

Ds que deux points dappui ont t saisis, il est possible de calculer une fonction polynomiale de degr 1 (en fait une similitude) pour passer dun repre un autre. Une option trs utile permet dutiliser cette fonction pour proposer automatiquement un point lors de la saisie ultrieure de points dappui : ds que loprateur choisit un point dans lun des espaces (gographique ou image), le systme propose automatiquement le point correspondant dans lautre espace. En gnral, ce point nest pas trs loign du point rel (la diffrence correspond la diffrence entre la similitude et la dformation relle modliser). Loprateur na plus qu dplacer ce point laide des touches de dplacement du clavier, pixel par

216

Chapitre 6

pixel (la taille du pixel dpend de lespace visualis, qui peut bien sr tre choisi tout moment par loprateur). 6.5.2.3. La saisie semi-automatique et automatique La saisie semi-automatique permet dans certains cas damliorer la prcision de la prise des points dappui. On utilise alors un indice de corrlation bas sur lagencement des pixels dans limage redresser et dans une image dj gorfrence ou dans une relation de la base de type mosaque. La recherche dune meilleure ressemblance est effectue au voisinage du point propos par loprateur : il permet souvent daffiner la prise du point de quelques pixels. La saisie automatique permet de saisir automatiquement des points dappui ds quun redressement polynomial initial peut tre effectu. Le principe de la corrlation est identique celui de la saisie semi-automatique, mais ici les points sont choisis par le systme en fonction de leur singularit dans limage redresser. Le systme balaye limage la recherche des pixels qui sont trs diffrents de leurs voisins, ou qui sont le centre dune structure remarquable. Il recherche ensuite pour chaque point celui de limage dj redress qui lui ressemble le plus, au voisinage du point calcul par la fonction polynomiale initiale de degr 1. Nous avons construit des classes pour encapsuler lensemble des oprations de calculs de la transformation polynomiale initiale (CSimilitude, CSystme1). Ces classes sont galement tre utilises pour redresser lensemble dune image. Nous les prsenterons dans le paragraphe suivant. 6.5.3. Le redressement et le r-chantillonnage Les pixels de limage darrive sont dfinis sans ambigut, taille et position. Pour savoir quelle valeur affecter un pixel de limage darrive partir des pixels dune image de dpart, il faut calculer, par gorfrencement, quels pixels de limage de dpart participent par leur position la dfinition de la valeur du pixel de limage darrive, puis, par une opration de r-chantillonnage, il faut calculer une nouvelle valeur partir de ces pixels. Nous effectuons donc cette opration en deux tapes : calcul des coordonnes dans le repre de limage de dpart dun pixel de limage darrive, puis calcul dune valeur partir des pixels voisins de cette coordonne. 6.5.3.1. Le redressement Le redressement consiste donc savoir quelles sont les coordonnes dans le repre de limage de dpart dun pixel de limage darrive. On utilise pour cela une fonction qui est cense approcher la dformation. Cette fonction peut tre

Gorfrencement et intgration dimages

217

parfaitement connue, mais cest rarement le cas. Par exemple, si une carte na pas subit de dformation du papier, si le scanner utilis ne provoque aucune dformation locale, la transformation est une similitude (si, bien sr, on conserve la mme projection gographique. Sinon, il faut composer avec un calcul de changement de projection). Si loptique dun appareil photographique de prise de vue ne provoque aucune dformation, si les rayons lumineux sont rectilignes, si le terrain est totalement plat, et si la prise de vue est orthogonale, la transformation est une projection centrale suivie dun changement de projection gographique (tenant alors compte de la courbure de la Terre). Evidemment, ces conditions ne sont jamais remplies dans la pratique (une optique nest jamais parfaite, etc.). On peut essayer de modliser la dformation de chaque lment (loptique, le relief, les angles de prise de vue, les conditions atmosphriques) pour composer ces dformations et aboutir une fonction globale modlisant la dformation. La modlisation de certains lments ncessitent des donnes de positionnement (par exemple, les phmrides des satellites) ou des points dappui (pour calculer par exemple les angles de prise de vue, la position du point focal dun appareil de prise de vue arienne), dautres ncessitent uniquement des paramtres intrinsques aux appareils employs. Ces paramtres sont en gnral obtenus par chantillonage initial (pour la dformation optique, par exemple). Nous avons dvelopp dans SAVAMER des mthodes de modlisation exclusivement bases sur les points dappui et non sur les paramtres intrinsques des appareils de prise de vues ou de rasterisation. Ces mthodes sont les suivantes : - modlisation par une transformation polynomiale de degr 1 (translation, rotation, similitude, ou polynme gnral de degr 1) ; - modlisation par une transformation polynomiale de degr 3 ; - modlisation par une transformation perspective conique ; - modlisation par une transformation perspective cylindro-conique ; - modlisation par une transformation locale polynomiale de degr 1. Les paramtres des fonctions correspondantes ces mthodes sont dtermins uniquement par les points dappui. Les modlisation polynomiales de degr 1 ncessitent de 1 3 points dappui. Les modlisations perspectives demandent de 4 6 points. La modlisation locale polynomiale utilise au minimum quatre points dappui : elle utilise une triangulation calcule partir de lensemble des points dappui, et une fonction polynomiale de degr 1 dans chacun des triangles (fig. 6.7). Le systme permet de combiner une dformation globale, polynomiale de degr 1 ou perspective, et une dformation locale par triangulation, en effectuant successivement les deux transformations. La dformation par triangulation revient modliser la dformation due au relief et aux autres paramtres de prise de vue par

218

Chapitre 6

un ensemble de facettes planes, aprs une premire transformation qui est cense modliser la dformation idale (optique sans dformation, prise de vue orthogonale, etc.) de manire globale. La surface modliser est reprsente par un rseau de facettes triangulaires dont les sommets sont les points dappui redresss par la premire transformation globale. On se trouve devant le classique problme mathmatique visant approcher une fonction de deux variables connues uniquement en un nombre fini de points distribus de faon quelconque dans son domaine de dfinition. La discrtisation du domaine de dfinition est la premire tape de rsolution de ce problme. Si les points sont distribus de manire alatoire, une grille triangulaire dont les sommets sont les points initiaux rpond la question, lorsque cette triangulation permet dassurer la continuit de la fonction interpoler. La triangulation de Delaunay, duale de la tessellation de Vorono, satisfait cette condition. Elle est par ailleurs utilise, tout comme la tessellation de Vorono, dans la rsolution de nombreux problmes en gomtrie discrte ou algorithmique [SHA 78] [ORO 93]. Nous prsenterons au paragraphe 6.6.3.3. lalgorithme utilis dans SAVAMER pour calculer la triangulation de Delaunay utilise lors du redressement par triangulation.

Gorfrencement et intgration dimages

219

fig. 6.7 : le dialogue de redressement de SAVAMER

La triangulation de Delaunay cre, partir des points dappui redresss par le calcul global, un graphe planaire reprsent par ensemble de segments (fig. 6.8). Ces segments sont ensuite rasteriss pour obtenir une image code, chaque code reprsentant un triangle de la triangulation. Paralllement, on calcule et on conserve pour chaque triangle les coefficients de la transformation bilinaire appliquer aux points du triangle, grce aux coordonnes redresses des trois points dappui et de leurs coordonnes correspondantes dans le repre de projection gographique. Le redressement de limage se fait donc en plusieurs tapes : - pour un point de limage darrive, recherche du triangle dans lequel se trouve ce point, et calcul des coordonnes par transformation locale inverse ; - calcul de ses coordonnes dans limage de dpart par transformation globale inverse.

220

Chapitre 6

fig. 6.8 : triangulation obtenue partir des points dappui

Pour toutes les mthodes de redressement, il faut commencer par calculer la fentre de redressement, cest--dire lespace gographique de limage darrive concern par limage de dpart. Cette fentre permet de dterminer les paramtres de limage darrive, dont on ne connat a priori que la rsolution. Le calcul de la fentre utilise uniquement le redressement global, qui est effectu sur les quatre coins de limage de dpart. Plusieurs classes permettent dans SAVAMER dencapsuler lensemble des calculs ncessaires aux oprations de redressement : CSimilitude, CSysteme1, CSysteme3 (A.3.2.). La mthode Equations() de chacune de ces classes calcule, partir des trois premiers points damers, les coefficients des formules de calculs. Les mthodes ProjectionToImage() et ImageToProjection() effectuent les calculs de changement de repre. Le calcul de la fentre de redressement est effectu par la fonction FenetreDestination(). La mthode Recalage() effectue la fois le redressement et le r-chantillonage. 6.5.3.2. Le r-chantillonnage Comme nous lavons vu, le redressement saccompagne dune opration de rchantillonnage. Plusieurs mthodes peuvent tre employes pour effectuer cette opration [GDT 93]. La plus simple consiste prendre la valeur du pixel de limage dorigine le plus proche (plus proche voisin), mais il est galement courant de faire

Gorfrencement et intgration dimages

221

une moyenne sur les pixels voisins, par un calcul bilinaire ou bicubique. Ces trois oprations de r-chantillonage sont implantes dans le module de redressement de SAVAMER. Le calcul bilinaire calcule la valeur en fonction de la position du point par rapport aux quatre voisins, le calcul bicubique calcule la valeur en fonction de la position du point sur une fentre de 4*4 voisins (A.3.2.). Toutes les oprations de redressement crent une nouvelle image gorfrence, munie dun fichier dcrivant ses paramtres de localisation (coordonnes du point bas-gauche, taille du pixel, projection gographique, nombre de lignes, nombre de colonnes). Le type de limage cre (codage sur 8, 16, 24 ou 32 bits) est toujours identique celui de limage de dpart. 6.5.3.3. Un algorithme de triangulation Plusieurs algorithmes ont t dvelopps pour crer une tessellation de Vorono ou un graphe de Delaunay partir dun semis de points alatoirement distribus dans le plan. On peut les classer en deux catgories : les algorithmes par incrmentation, qui construisent la triangulation partir dun point intrieur quelconque et en ajoutant les points un par un, en recalculant la triangulation pour chaque point ajout, et les algorithmes de type diviser pour rgner , qui emploient une mthode rcursive en divisant rcursivement la rgion en sousrgions jusqu ce que la triangulation finale soit atteinte. Les techniques incrmentales ne sont pas trs optimises car en gnral de complexit en O(n2), mais elles sont plus faciles mettre en uvre et demandent moins de ressources mmoire. Lalgorithme implment dans SAVAMER est du type incrmental. Il est dcrit dans [FLO 85]. Il se divise en plusieurs oprations : - triangulation de Delaunay pour un simple polygone ; - insertion incrmentale de points dans la triangulation. La classe CTessel regroupe lensemble des structures et des oprations ncessaires la mise en uvre de lalgorithme de triangulation de [FLO 85] (A.3.3.). 6.5.3.4. Le redressement descriptif des dynamiques La dernire tape avant lintgration dune image dans la base par mosaquage concerne le redressement des valeurs de limage gomtriquement redresse. En effet, une image peut tre gomtriquement correcte mais comporter dimportantes diffrences de valeur avec des images voisines correspondant au mme attribut.

222

Chapitre 6

Dans SAVAMER, on peut oprer lgalisation des valeurs dune image gorfrence par rapport une mosaque par talement, en prenant des valeurs de rfrences calcules sur la base dun ajustement linaire des histogrammes. Ltalement est calcul par rgression linaire partir des points dappui ou sur lensemble des pixels de la zone de recouvrement. Si limage est de type RVB, la rgression linaire est calcule sparment pour chaque composante de couleur. 6.5.4. Le mosaquage et lintgration dans une relation Lopration de mosaquage permet dintgrer une image gorfrence un attribut dune relation de type pixel. Le systme Savane gre ces attribut de manire permettre des ensembles de pixels plus complexes que des images rectangulaires. Lopration dintgration consiste donc, partir dune image gorfrence, crer des objets pixels dans une relation (si ces objets nexistent pas dj), et affecter les valeurs des pixels de limage un attribut dans cette relation. On constitue ainsi une mosaque dont la gestion est entirement la charge du systme, et dont la structure externe est identique celle des autres types de relation. Le module SAVAMER permet de choisir le domaine intgrer, ainsi que la mthode dintgration. Le domaine peut tre choisi de plusieurs manires (fig. 6.10) : - par imagette, en slectionnant directement sur lcran les imagettes crer ; - par rectangle, en choisissant le rectangle sur lcran ou en donnant ses coordonnes gographiques ; - par polygone, en dessinant sur lcran le polygone intgrer. Si la valeur dun pixel existe dj, la mthode dintgration peut tre : remplacer la valeur, ne pas remplacer la valeur, faire la moyenne (fig. 6.9).

fig. 6.9 : le dialogue dintgration dune image dans une mosaque

Gorfrencement et intgration dimages

223

fig. 6.10 : le choix des pixels intgrer : mthode par polygone

Lintgration dune image cre des imagettes pour lattribut slectionn dans la relation. Une imagette est cre ds quun pixel doit tre cr dans lespace correspondant. Lintgration peut ainsi tre effectue en plusieurs tapes, et la mosaque crot au fur et mesure de la cration de nouvelles imagettes (fig. 6.11). Il est bien sr galement possible de supprimer des pixels. Si tous les pixels dune imagette doivent tre supprims, limagette elle-mme est supprime dans le fichier servant dindex.

224

Chapitre 6

fig. 6.11 : exemple de constitution de mosaque dimages gorfrences

6.6. Conclusion Lintgration des donnes de type image dans le processus relationnel permet de bnficier de la simplicit du modle avec des donnes dont la structure est trs diffrente des objets gographiques dont la localisation est dcrite par la gomtrie. Elle permet surtout de ne pas avoir diffrencier la logique des oprations relationnelles classiques (restriction, jointure) ou des oprations sur les attributs (calculs, classifications, etc.) entre les diffrents types de localisation. Mais cette intgration exige davoir une dfinition formelle de ce type dobjets, et dassurer la validit de lattribut de localisation pour chacun des objets. Nous avons donc introduit un nouveau type dobjet, le pixel, et un nouveau type pour les relations reprsentant des collections de pixels, les mosaques, qui sont structures et gres de faon trs diffrente des autres types de relations. La validit de la localisation est assure par des oprations de redressement dimages. La mise en uvre de ces oprations souvent complexes a donn lieu au dveloppement dun module spcialis dans le systme SAVANE. Ce module regroupe le redressement des images, la gorfrenciation des pixels, et leur intgration dans une relation de la base de donnes. Le redressement peut tre effectu par plusieurs mthodes. La plus complte utilise un redressement local de degr 1 dans les triangles issues de la triangulation de Delaunay obtenue partir de lensemble des points damers, et a lavantage de ne pas utiliser les paramtres intrinsques de la prise de vue.

Gorfrencement et intgration dimages

225

Bibliographie

[EST 92] ESTES J., Remote sensing and GIS integration : research needs, status and trends. ITC Journal, 1992, n 1, p. 2-9 [FLO 85] DE FLORIANI L., FALCIDIENO B., PIENOVI C., Delaunay-based Representation of Surfaces Defined over Arbitrary Shaped Domains, Computer Vision, Graphics, and Image Processing, 1985, n 32, p. 127-140 [GDT 93] GDTA, Les Spatiocartes, Cahiers Pdagogiques du GDTA, 1993 [HOT 99] HOTTIER, Photogrammtrie analytique, Cours ENSG, 1999 [NOV 92] NOVAK K., Rectification of digital Imagery. Photogrammetry Eng. And Remote Sensing, 1992, vol. 58, p.339-344 [ORO 93] OROURKE J., Computational Geometry in C, 1993, Cambridge University Press [REN 91] RENOUARD L., Restitution automatique du relief partir de couples stroscopiques dimages du satellite SPOT, 1991, Thse de Doctorat prsente lEcole Polytechnique [SHA 78] SHAMOS M.I., Computational Geometry, PHD Thesis, 1978, Yale University

Chapitre 7

Contraintes d'intgrit spatiale et saisie graphique

Les contraintes d'intgrit permettent d'assurer la cohrence des bases de donnes et de renseigner sur leur niveau de qualit. Dans les systmes d'information gographique, la qualit des donnes provient galement de la qualit de la localisation des objets et de leur niveau de cohrence spatiale. Ce chapitre a pour objectif de passer en revue l'ensemble des contraintes d'intgrit spatiale applicables une base de donnes localises, contraintes qui permettent, si elles sont remplies, de renseigner sur le niveau de qualit de la base de donnes, d'assurer la fiabilit des processus utilisant ces donnes, et d'assurer ainsi la capacit du systme remplir les fonctions attendues par les utilisateurs. De plus, avec les possibilits d'change ou de partage de donnes, il est important de pouvoir renseigner l'utilisateur sur le niveau de qualit et de cohrence des donnes qu'il reoit ou qu'il souhaite exporter vers un autre systme. Comme nous lavons vu, les systmes d'information gographique peuvent utiliser de nombreux modles gomtriques internes pour reprsenter les objets localiss, mais les contraintes d'intgrit lies la localisation doivent, lorsque cela est possible, tre exprimes indpendamment de ces modles internes. Par contre, la cohrence s'exprime par rapport une modlisation de la ralit en entits gographiques, correspondant des collections d'objets gographiques (classiquement des zones, des lignes, des points, des pixels), et les contraintes d'intgrit spatiale sont exprimes en fonction de cette modlisation, sur les objets et entre les objets. Les contraintes les plus classiques concernent par exemple la fermeture des zones, la non-intersection dobjets, la connexit, les relations spatiales entre les objets de diffrentes entits gographiques. Nous tudierons les contraintes

228

Chapitre 7

d'intgrit spatiale en nous basant sur le modle relationnel pour la modlisation de la ralit et la gestion des collections d'objets gographiques. Nous tudierons ensuite les possibilits de mise en uvre de ces contraintes en fonction des diffrents modes de reprsentation gomtrique de la localisation, lors du processus de saisie graphique. Nous prsenterons enfin en dtail le module SAVEDIT de saisie graphique sur cran, qui met en uvre au sein du systme SAVANE un certain nombre de contraintes dintgrit. Nous prsenterons larchitecture de ce module et les algorithmes utiliss pour rsoudre les nombreux problmes graphiques soulevs par la mise en uvre interactive des contraintes dintgrit. 7.1. La qualit dans les bases de donnes gographiques 7.1.1. Le problme gnral de la qualit dans les bases de donnes gographiques La connaissance de la qualit de la localisation dans les bases de donnes gographiques devient de plus en plus importante pour assurer une bonne utilisation de ces bases de donnes, avec notamment la multiplication des changes de donnes entre les SIG. Il n'est plus rare en effet d'avoir travailler sur des donnes trs htrognes, et il devient de plus en plus important de dfinir des critres de contrle et de qualit pour la localisation des donnes gographiques et leurs relations dans lespace. Ces critres ne peuvent pas se rsumer de simples problmes de prcision, comme cela a t longtemps le cas pour la cartographie. Les bases de donnes grent des collections dobjets, et l'attribut de localisation prend ses valeurs dans un espace de dimension deux ou trois, ce qui introduit des critres qui ne sont plus seulement lis une relation d'ordre, mais la structure de cet espace : topologie, mtrique, relations ensemblistes, etc. [LAU 93]. Par exemple, le respect des critres topologiques (fermeture, connexit, relations spatiales entre objets) pourra contribuer faire la diffrence entre des donnes ne pouvant tre utilises qu' des fins de dessin automatique et des donnes pouvant tre intgres dans une base de donnes et utilises dans un systme d'information gographique. Il n'existe pas de description simple de l'incertitude lie la modlisation de la ralit par des objets et des collections dobjets gographiques. Cette modlisation est nanmoins toujours lie une chelle gographique de description, qui associe choix des attributs descriptifs et description de la localisation. Mais, lors de lutilisation des objets, la description de la localisation peut ne plus correspondre la description smantique de l'objet car les SIG donnent la possibilit de choisir une chelle diffrente de l'chelle de validit pour l'utilisation et la mise en relation d'objets. Ceci provoque bien sr des problmes de cohrence entre les objets rsultant des traitements ainsi effectus. De nombreuses rponses ont t proposes

Contraintes d'intgrit spatiale

229

pour tenter de rsoudre les problmes d'intgrit et de cohrence lors de l'utilisation des objets et de leur mise en relation [GOO 89] [ML 95]. Mais lorsque cela est possible, il est plus efficace d'assurer la cohrence de la base de donnes gographiques lors de la constitution des objets, en respectant des contraintes d'intgrit spatiale qui ne dpendent que de la dfinition formelle des objets. L'approche que nous proposons ici vise donc assurer la cohrence intrinsque des objets dans une base de donnes gographiques. Cette cohrence ne dpend pas des traitements effectus, elle dpend uniquement de la dfinition des objets par rapport l'objectif de modlisation de la ralit. La dmarche s'inscrit donc dans l'approche base de donnes [DAT 90]. D'une manire gnrale, l'information sur la qualit des donnes gographiques peut tre dcompose en diffrents domaines : la gnalogie (information sur les sources des donnes), l'actualit (validit temporelle), la cohrence logique (contrle de l'intgrit des donnes), la prcision gomtrique, la prcision smantique, l'exhaustivit [FAI 96]. Nous ne traiterons ici que de cohrence logique lie la localisation : nous chercherons dcrire l'ensemble des contraintes d'intgrit permettant de renseigner sur le degr de cohrence spatiale d'une base de donnes gographiques. L'intgrit ne couvre pas le plus vaste domaine de l'erreur dans les SIG, mais le respect des contraintes permet de minimiser la gnration d'erreurs lors des traitements, permettant ainsi de grer ces erreurs de manire plus fiable [GOO 89], [GUP 95]. 7.1.2. La cohrence spatiale La cohrence spatiale s'exprime par rapport une modlisation de la ralit en entits gographiques, correspondant la dfinition de collections d'objets gographiques. Comme nous lavons dj vu au chapitre 3, une entit, ou collection d'objets gographiques, sera dfinie par : un type de localisation (classiquement : zone, ligne, point, pixel), des attributs descriptifs (la description smantique des objets), des relations et des contraintes spatiales entre les objets. Ds lors, on peut donc exprimer la cohrence spatiale selon ces trois composantes : une cohrence gomtrique (adquation entre la description gomtrique des objets et le modle gomtrique dfini pour la collection), et une cohrence smantique (adquation entre modlisation de la ralit d'une part et relations entre les objets d'autre part). Les rgles d'intgrit spatiale visent assurer ces deux niveaux de cohrence. Par exemple, assurer qu'un objet d'une collection de type zone soit bien une zone (un domaine ferm de l'espace, cest une condition

230

Chapitre 7

gomtrique), que deux parcelles d'un cadastre ne se chevauchent pas (la condition de non-intersection est smantique, et provient de la dfinition mme dun cadastre), qu'un btiment appartienne une et une seule parcelle (cest galement une condition smantique, mais qui porte sur les relations spatiales entre les objets de deux collections distinctes). 7.1.3. Les contraintes d'intgrit spatiale L'un des objectifs des SIG, en tant que systmes de gestion de collections d'objets gographiques, est d'assurer la cohrence spatiale, au mme titre qu'un systme de gestion de bases de donnes classique (SGBD) doit assurer la cohrence et l'intgrit des donnes. Le modle relationnel conventionnel (les attributs ne peuvent tre que quantitatifs ou qualitatifs) est trs efficace dans le domaine de l'intgrit des donnes et de la cohrence, et il a d'ailleurs t en partie conu dans cette optique. Il propose des rgles d'intgrit permettant d'assurer la cohrence des donnes d'une base. Ces rgles concernent l'unicit de la cl (existence et unicit d'un identifiant pour chaque objet), les contraintes par rfrence entre relations (un ensemble d'attributs d'une relation est dfini comme cl dans une autre relation), et les contraintes de domaine (les valeurs d'un attribut doivent vrifier une assertion logique). On peut galement tendre les contraintes par rfrence aux contraintes par jointures, en imposant des contraintes de domaine au rsultat d'une jointure entre deux relations [GAR 84]. On a donc tout intrt tendre les contraintes dintgrit du modle relationnel conventionnel de nouveaux types d'objets - avec l'introduction de la localisation comme attribut. Le modle relationnel nous guide alors naturellement dans la modlisation de la ralit et dans la dfinition des contraintes d'intgrits lies ces nouveaux types. En effet, si l'attribut de localisation est dfini comme une cl primaire des collections d'objets localiss, il doit vrifier le principe d'unicit (qui correspond alors au principe d'unicit d'un phnomne dans l'espace-temps : au mme moment, on ne peut avoir deux objets de la mme collection au mme endroit). Les contraintes de domaine peuvent tre tendues la dimension 2, la fois sur la gomtrie (position) et sur la topologie (fermeture, simplicit, connexit, relations entre objets voisins). Les contraintes par rfrence peuvent galement tre tendues la dimension 2, notamment au niveau de la gomtrie (contours communs, hirarchie entre objets). Enfin, des contraintes par jointure peuvent galement tre proposes, en utilisant la localisation comme attribut de jointure entre les objets (une bouche d'gout ne peut se trouver que dans une rue : le rsultat d'une jointure gomtrique entre bouches d'gout et immeubles doit tre vide). D'une manire gnrale, les contraintes d'intgrit spatiale sont exprimes sur les attributs des objets, que ces attributs concernent la description ou la localisation. Le

Contraintes d'intgrit spatiale

231

modle relationnel tendu nous fournit donc tous les principes permettant d'exprimer la cohrence spatiale d'une base de donnes gographiques indpendamment du modle gomtrique interne au SIG. Le modle objet supprime la notion de domaine pour les attributs, puisqu'un attribut peut lui-mme tre un identifiant d'objet d'une autre classe. De ce fait, les contraintes d'intgrit sont plus difficiles dfinir et mettre en uvre pour les bases de donnes orientes objet que pour le modle relationnel. Nanmoins, il convient de respecter des contraintes d'intgrit dans le cadre du modle orient objet, sous peine de dgrader considrablement les objectifs assigns aux SGBD et de perdre les bnfices acquis du relationnel [BEN 93]. On peut tablir pour le modle objet des rgles de cohrence encapsules comme les mthodes : la dfinition d'une classe peut inclure la dfinition de mthodes de cohrence sur et entre les membres de la classe. Ainsi, lorsqu'une classe drive d'une autre, et que ces deux classes possdent un attribut de localisation (hirarchie de dcoupage par exemple), on devrait pouvoir exiger que ces attributs suivent la hirarchie des objets (par exemple, les arcs des objets d'une classe sont forcment des arcs des objets d'une classe qui en drive). 7.2. Les contraintes d'intgrit pour les bases de donnes Les contraintes d'intgrit permettant d'assurer la cohrence spatiale d'une base de donnes vont donc s'exprimer dans le cadre du modle relationnel tendu aux donnes localises. Nous allons dcrire comment ces contraintes s'expriment pour les objets et les collections d'objets dans les bases de donnes gographiques. 7.2.1. Le cadre relationnel Nous avons vu que la localisation des objets gographiques s'exprime soit par des lments de l'espace (pour les objets dont la localisation peut tre ramene un point), soit par des sous-ensembles de l'espace (lignes ou zones). La schmatisation gomtrique de la localisation des objets gographiques en zone, ligne, point, pixel tablit une classification naturelle sur laquelle repose la fois l'extension du modle relationnel et la dfinition de classes d'objets gographiques pour le modle objet. Toutes les considrations ultrieures seront bases sur la classification en zone, ligne, point, pixel, classification qui permet de schmatiser la gomtrie des objets gographiques et de dfinir des collections dobjet du mme type.

232

Chapitre 7

Un arc n'est pas un objet gographique, mais seulement un objet gomtrique. Les contraintes d'intgrit gomtrique sont exprimes sur les points et les arcs, c'est--dire sur les objets gomtriques qui permettent de dfinir la localisation des objets gographiques. 7.2.2. Les contraintes d'intgrit L'un des objectifs des SGBD, c'est d'assurer le maintien et la cohrence des donnes par rapport aux schmas (contrle des types), ainsi que la cohrence des donnes entre elles (par exemple, un enfant de moins de cinq ans ne peut avoir un niveau d'tude lev). On appelle contrainte d'intgrit toute rgle que doivent suivre les donnes, pour spcifier les valeurs permises pour certaines donnes, ventuellement en fonction d'autres donnes. L'une des contraintes d'intgrit souvent utilise est la contrainte d'unicit de cl: on impose l'existence d'une cl (identifiant unique) pour tout objet d'une entit. Tout objet d'une entit vrifiant cette contrainte devra donc avoir une valeur bien dtermine (et unique) pour cette cl. On dfinit galement les contraintes dites de rfrence : on impose une association de n'associer que des objets existants dans la base (par exemple, un acte de vente ne peut tre enregistr que si l'acheteur et le bien existent dj dans la base). Les contraintes les plus courantes sont les contraintes de domaine : on prcise le domaine de variation de l'attribut (par exemple, lge d'une personne est compris entre 0 et 140). La contrainte peut tre plus complexe, et faire appel aux valeurs de plusieurs attributs. Elle se prsente alors comme une assertion logique qui doit tre vrifie pour l'ensemble des objets de la relation. On peut tendre les contraintes de domaine aux contraintes par jointure : c'est alors le rsultat d'une jointure entre deux relations qui devra rpondre une contrainte de domaine (par exemple, un fils ne peut pas tre plus g que son pre). 7.2.3. Les contraintes d'intgrit pour les donnes localises Lorsque les attributs sont de type simple, comme c'est le cas dans les SGBD classiques, les contraintes d'intgrit s'expriment par des assertions logiques fondes sur l'galit ou la relation d'ordre en dimension 1, comme toute opration algbrique sur les attributs. Lorsque l'on tend le modle aux donnes gographiques, l'attribut de localisation doit lui aussi tre soumis des contraintes d'intgrit. Ces contraintes

Contraintes d'intgrit spatiale

233

s'expriment alors dans l'espace, soit par des assertions ensemblistes (appartenance, intersection, etc.), soit par des assertions topologiques (voisinage, fermeture, connexit, etc.), soit par des assertions mtriques (contraintes sur les distances entre objets). Par exemple, la contrainte d'unicit de cl est fondamentale pour une bonne modlisation de la ralit en entits gographiques, car cette contrainte pour la localisation permet d'assurer l'unicit d'un phnomne en un lieu, et d'tre sr que la localisation de tout objet gographique est bien dfinie. Les contraintes d'intgrit peuvent porter sur l'attribut de localisation lui-mme, mais la localisation peut galement tre utilise comme attribut de jointure pour exprimer une contrainte de domaine entre attributs descriptifs simples (par exemple, un immeuble de huit tages ne peut se trouver dans une zone limite deux tages). Les contraintes d'intgrit interviennent lors de la constitution de la base de donnes. La saisie des donnes graphiques correspondant la localisation doit ainsi prendre en compte ces contraintes pour assurer la cohrence de la base, sachant que toute modification ultrieure est particulirement dlicate. Dans le paragraphe suivant, nous allons dcrire, pour l'attribut de localisation, l'ensemble des contraintes d'intgrit qui peuvent tre ncessaires la bonne cohrence d'une collection d'objets localiss. Certaines contraintes sont ncessaires et doivent toujours tre vrifies. Les autres sont optionnelles, mais les SIG devraient proposer un formalisme (langage et mthodes) pour permettre leur mise en uvre lors de la constitution ou la modification d'une base de donnes [LAU 91], [UBE 96]. 7.3. Les contraintes dintgrit spatiale 7.3.1. Une typologie des contraintes dintgrit spatiale Nous allons tudier les contraintes d'intgrit portant sur l'attribut de localisation selon la classification suivante : les contraintes gomtriques, portant sur les composants gomtriques servant schmatiser les objets gographiques (arc, point, segment) : simplicit, extrasimplicit, ultra-simplicit ; les contraintes topologiques de type, permettant d'assurer l'intgrit gomtrique d'un objet, en fonction de son type : forme de l'objet, relations entre les lments gomtriques constituant un objet, (fermeture, connexit, centrode). Ces conditions dpendent du type de localisation (zone, ligne, point, pixel) ; les contraintes relationnelles, permettant d'assurer l'intgrit d'une collection d'objets par rapport sa dfinition smantique : unicit de cl (existence et unicit d'un objet en un point), appartenance un domaine (assertion logique sur l'attribut de localisation), contraintes de voisinage (assertion logique sur les couples d'objets

234

Chapitre 7

d'une mme collection, rpondant un critre topologique ou mtrique), relations gomtriques entre les objets d'une collection ; les contraintes topologiques de jointure : contraintes topologiques entre les objets de deux collections (assertion topologique sur les couples d'objets rsultant d'une jointure gomtrique entre deux collections : intersection, inclusion, position, hritage, etc.) ; les contraintes descriptives de jointure : contraintes descriptives (assertion logique sur les attributs descriptifs des couples d'objets rsultant d'une jointure gomtrique entre deux collections), contraintes d'hritage (par exemple, un canton ne peut avoir plus d'habitants que le dpartement auquel il appartient). Les contraintes gomtriques et topologiques de type correspondent la cohrence gomtrique. Les contraintes relationnelles et topologiques de jointure correspondent la cohrence smantique. Certaines contraintes gomtriques ou topologiques de type devront toujours tre vrifies (par exemple, une zone doit toujours tre ferme), d'autres dpendent de la dfinition smantique de la collection (un rseau routier doit toujours tre connexe, mais un rseau tlphonique peut ne pas l'tre). Du fait des rpercussions immdiates de leur non-respect, les contraintes gomtriques et topologiques de type sont celles qui ont t mieux tudies [EGE 91], [HAD 92], [LAU 91 93 94], [UBE 96], [TAN 95]. Cette typologie des contraintes d'intgrit est fonctionnelle : elle est indpendante du mode de stockage et de reprsentation interne des objets, et ne prend pas en compte les particularits d'un systme par rapport un autre. Par contre, leur mise en uvre sera fonction du mode de reprsentation interne utilis par le systme de gestion de ces objets [LAU 93]. 7.3.2. Les contraintes gomtriques Les contraintes gomtriques s'expriment sur les points ou les arcs servant schmatiser les objets gographiques. Rappelons que les arcs sont constitus de segments, les extrmits des segments sont appels points de larc, et les deux points extrmits de larc sont appels des nuds. Nous pouvons dfinir les conditions gomtriques ou topologiques sur les arcs et les points, conditions qui nous serviront exprimer les contraintes d'intgrit sur les objets gographiques euxmmes : la simplicit d'un arc : l'arc ne doit pas avoir d'intersection avec lui-mme (aucun des segments qui le constituent ne doit recouper un autre segment qui le constitue). Cette contrainte sexprime sur larc lui-mme, et ne fait pas intervenir dautres objets (fig. 7.1).

Contraintes d'intgrit spatiale

235

arc simple

arc non simple

fig. 7.1 : Simplicit des arcs

On imposera pratiquement toujours aux arcs d'tre simples, mme si cette condition n'est pas ncessaire du point de vue de la cohrence des objets. Mais elle simplifie les oprations sur les arcs, notamment dans les cas o le sens de l'arc est pris en compte. l'extra-simplicit d'un arc : l'arc ne doit avoir d'intersection avec aucun autre arc constituant un objet de la mme collection (seuls les nuds peuvent tre des points communs entre les arcs de la relation) (fig. 7.2).

les arcs sont extra-simples

les arcs ne sont pas extra-simples

fig. 7.2 : Extra-simplicit des arcs

l'ultra-simplicit d'un arc par rapport une autre collection : l'arc ne doit avoir d'intersection avec aucun arc constituant un objet de cette autre collection.

236

Chapitre 7

inclusion d'un arc : un arc est inclus dans un autre si tous les points de l'arc appartiennent l'autre arc et si deux points conscutifs dans l'arc inclus sont deux points conscutifs dans l'autre l'arc. fermeture : un ensemble d'arcs est dit ferm s'il existe un chemin ferm constitu par ces arcs (fig. 7.3).

ensemble d'arcs ferms

ensemble d'arcs non ferms

fig. 7.3 : Fermeture dun ensemble darcs

connexit : un ensemble d'arcs est dit connexe s'il existe un chemin connexe constitu par ces arcs (fig. 7.4).

ensemble d'arcs connexe

ensemble d'arcs non connexe

fig. 7.4 : connexit dun ensemble darcs

La plupart des systmes imposent ds la saisie graphique des conditions de connexit sur les arcs, qu'ils soient composants d'une zone ou d'une ligne, le critre de connexit tant uniquement fonction de la distance sparant leurs nuds. Si les nuds de deux arcs sont proches (leur distance est infrieure un seuil donn), alors ces deux nuds doivent tre identiques (les arcs doivent appartenir une mme composante connexe). Les systmes assurent alors automatiquement cette contrainte en modifiant la position des nuds.

Contraintes d'intgrit spatiale

237

Dans une base de donnes gographiques, on doit imposer aux objets gomtriques, arcs et points, dappartenir des objets gographiques : les nuds ou arcs isols (dit baladeurs ou libres ) sont interdits. 7.3.3. Les contraintes topologiques de type Les contraintes topologiques de type sont les mieux respectes, sous peine de dgradation considrable de la validit des oprations spatiales les plus simples. Elles concernent les objets de type zone et de type ligne. Il n'y a aucune contrainte topologique de type sur les objets point ou sur les objets pixel. 7.3.3.1. Fermeture et centrode On impose aux zones d'tre par dfinition des ferms de l'espace : les arcs dcrivant une zone doivent donc toujours constituer un chemin ferm, dfinissant la zone de manire unique. Cette condition doit imprativement tre vrifie pour assurer la bonne cohrence des objets zone, et permettre les calculs gomtriques ou topologiques (primtre, surface, remplissage, etc.). Les arcs dcrivant une zone doivent galement tre simples. On impose galement toujours la condition d'appartenance du centrode la zone, par dfinition mme du centrode (un point appartenant un objet de type zone et reprsentant le centre de la zone). On peut galement demander aux objets ligne dtre ferms : les arcs dcrivant la ligne doivent alors constituer un chemin ferm. 7.3.3.2. Connexit On peut demander aux zones d'tre connexes (une zone est alors reprsente par un seul polygone). Cette condition n'est pas toujours requise, certains systmes acceptant que l'objet zone ne soit pas forcment connexe. La connexit est alors une exigence qui dpend de la dfinition smantique de la collection d'objet, et non pas du type. On peut imposer aux rseaux d'tre connexes. Les objets sont alors des lignes qui doivent tre relies entre elles pour former un graphe connexe. D'une manire plus gnrale, un objet constitu de plusieurs lignes forme un graphe. On peut imposer cet objet d'avoir des proprits topologiques correspondant cette structure de graphe : fortement connexe (cas gnral des rseaux routiers), symtrique, complet, planaire. Toujours dans le cas des lignes, on peut assortir la condition gomtrique de connexit de deux arcs d'une condition sur la valeur des lignes auxquelles

238

Chapitre 7

appartiennent les arcs. Par exemple, deux courbes de niveaux doivent tre relies si elles ont un nud proche et si et seulement si elles ont mme valeur. 7.3.3.3 Surface et primtre On peut imposer une contrainte descriptive sur la surface, sur le primtre (pour les zones), ou sur la longueur (pour les lignes) d'un objet. C'est en fait une contrainte descriptive classique, puisque la surface, le primtre, la longueur sont des attributs numriques classiques, leur seule particularit tant de pouvoir tre calculs directement partir de la gomtrie des objets. 7.3.4. Les contraintes relationnelles Les contraintes relationnelles concernent la cohrence smantique dune collection dobjets. Elles font donc appel aux relations gomtriques ou topologiques entre les objets dune mme collection. 7.3.4.1. Contrainte d'unicit de cl Du fait mme de la dfinition dune entit gographique, la localisation (espace et temps) doit tre considre comme une cl primaire d'une relation localise. En effet, si tel n'est pas le cas, on pourrait avoir dans une mme relation deux objets diffrents mais situs au mme endroit. Dans une base de donnes gographiques, cette ventualit relve d'une mauvaise schmatisation de la ralit et d'une mauvaise dfinition des objets. On doit donc imposer la localisation d'tre une cl, et la relation de satisfaire la contrainte d'unicit de cl pour cet attribut. Cela signifie simplement que tout objet doit tre localis et que cette localisation doit tre connue pour que l'objet soit prsent dans la base, et que deux objets d'une mme relation ne peuvent partager le mme lieu. Cet identifiant d'objet n'est pas forcment directement visible par l'utilisateur de la base de donne, mais il doit exister : un objet doit tre diffrenci d'un autre par sa localisation. On peut mme caractriser une relation localise par cette contrainte, en disant quune carte doit tre une tessellation du plan [PL 97]. La contrainte d'unicit de cl pour la localisation est forte. Elle assure dans les bases de donnes relationnelles localises la mme fonction que le principe de l'existence d'un identifiant d'objet dans les bases de donnes orient objet. Ce principe doit galement tre respect dans les bases spatio-temporelles, et il porte alors sur la localisation dans l'espace-temps (dans une relation, on ne peut avoir deux objets au mme lieu et au mme instant). A un instant t fix, on retrouve les contraintes sur la localisation du cas non temporel. On peut galement imposer des contraintes d'intgrit sur la localisation dans l'espace-temps (par exemple, en

Contraintes d'intgrit spatiale

239

donnant une contrainte de domaine sur la vitesse de dplacement d'un objet). Dans la suite, nous ne considrerons plus que les bases non temporelles (ou l'tat d'une base temporelle un instant t fix). La contrainte d'unicit de cl pour les points ne pose aucun problme : on ne peut pas avoir dans une relation de type point deux objets distincts au mme endroit. Cette condition est facilement vrifiable. La contrainte d'unicit pour les lignes impose deux lignes d'une mme relation de n'avoir aucune intersection. Deux lignes ne peuvent donc se rencontrer qu'aux extrmits de leurs arcs (sur les nuds), et ne doivent donc pas se croiser : tous les arcs doivent vrifier la condition d'extra-simplicit. Par contre, il n'est pas forcment requis un arc d'tre simple (une ligne peut se croiser sur elle-mme). Il est parfois normal que des lignes se croisent (par exemple, c'est souvent le cas dans un rseau de rues avec les passages souterrains ou ariens), mais elles ne se croisent alors que dans leur projection en deux dimensions : une bonne schmatisation de la ralit doit, dans ce cas, prendre en compte trois dimensions dans l'espace, et le principe d'unicit est alors vrifi. La contrainte d'unicit pour les zones impose deux zones quelconques d'une mme relation d'avoir une intersection vide. On considre que les points des arcs servant dfinir les zones n'appartiennent pas la zone : deux zones peuvent donc partager les arcs qui les constituent (ils acquirent alors le statut topologique de frontire), mais les domaines ouverts (le domaine ferm moins les frontires) constitus par ces arcs doivent avoir une intersection vide. Deux arcs constituant des zones d'une mme relation ne peuvent donc pas se croiser : tous les arcs doivent vrifier le principe d'extra-simplicit ou d'inclusion. On aura donc divers problmes rsoudre, dpendant du mode de saisie graphique. Les erreurs d'extra-simplicit proviennent souvent d'arcs saisis par erreur deux fois ou d'une mauvaise prcision dans le raccord des nuds. On a galement des problmes d'extra-simplicit, d'inclusion et de fermeture lorsque des arcs sont frontires de zones appartenant des documents diffrents. 7.3.4.2. Contrainte d'appartenance un domaine On peut imposer aux objets d'une relation d'appartenir un domaine de l'espace. Cette condition correspond la condition classique de vrification d'une assertion logique pour les donnes de dimension 1, l'assertion portant ici sur l'attribut de localisation et pouvant tre exprime soit sous forme ensembliste, soit sous forme mtrique, suivant la dfinition du domaine. Cette contrainte permet galement de sassurer de la validit des coordonnes des points : tous les objets situs sur le globe terrestre doivent vrifier une contrainte minimum (longitude de 0 360, colatitude de 0 90).

240

Chapitre 7

7.3.4.3. Contraintes descriptives de voisinage On peut imposer une contrainte sur les valeurs d'un attribut en fonction d'une condition de voisinage entre objets d'une mme collection. En gnral, on fixera des conditions sur l'cart entre les valeurs pour deux objets voisins. Ce type de contrainte intervient par exemple pour les courbes de niveaux : la diffrence des valeurs de deux courbes voisines ne doit pas dpasser une valeur d'quidistance donne. Dune manire plus gnrale, on peut imposer un attribut descriptif de satisfaire une proprit fonctionnelle par rapport la position dans lespace (par exemple, continuit uniforme). Il faut dfinir la condition de voisinage pour chaque type d'objet, par exemple : deux lignes sont voisines s'il existe un segment de droite reliant un point dans chaque ligne et ne coupant aucune autre ligne (ou encore si tout segment de droite reliant la ligne une autre ligne coupe l'autre ligne), deux points sont voisins au sens de Vorono (ils sont contigus dans le graphe dual de Delaunay), deux zones sont voisines s'il existe un arc frontire appartenant aux deux zones, deux pixels sont voisins sils ne sont spars que dune maille. Par exemple, imposer un modle numrique de terrain de ne pas contenir de cuvette (un point plus bas que tous ses voisins) est une contrainte descriptive de voisinage qui permet dassurer la validit de nombreux calculs en hydrologie (cest un des rares exemples de contraintes dintgrit sur les objets de type pixel). 7.3.4.4. Contraintes topologiques Les contraintes topologiques concernent les relations topologiques entre deux objets dune mme collection. Comme les objets dune mme collection sont de mme type (zone, ligne, point, pixel), et que, pour une bonne modlisation de la ralit, ils doivent de plus satisfaire au principe dunicit de cl (pas dintersection entre les objets dune mme collection), les contraintes topologiques au sein dune mme collection ne concernent donc que ladjacence et la connexit. On peut ainsi contraindre une collection zonale tre une tessellation de lespace (contrainte dadjacence) : les arcs schmatisant les zones doivent alors constituer un graphe planaire. Pour les collections de type ligne, les contraintes de connexit ne concernent pas seulement les arcs dun objet isol, mais portent sur tous les objets entre eux. Lensemble des objets doit alors rpondre une condition topologique : former un graphe connexe, fortement connexe, symtrique, complet, planaire.

Contraintes d'intgrit spatiale

241

Il ny a pas de contraintes topologiques sur les collections de type point ou pixel. 7.3.4.5. Contraintes mtriques Les contraintes mtriques suivent le mme principe que les contraintes de voisinage, mais les conditions topologiques sont remplaces par des conditions sur la distance entre les objets. La distance entre deux zones ou deux lignes est dfinie comme le minimum des distances entre tous les points des deux objets (d(O1,O2)=min(d(x,y),x O1,y O2). 7.3.5. Les contraintes de jointure Les contraintes spatiale de jointure sont des conditions que l'on impose entre les objets de deux collections distinctes, soit directement sur les relations spatiales entre objets, soit sur les valeurs des couples d'objets rpondant un critre spatial. Si les contraintes portent uniquement sur les relations spatiales entre objets (intersection, inclusion, position respective, distance, etc.), on parle de contrainte topologique (par exemple, une route ne doit pas avoir d'intersection avec un immeuble, une bouche d'gout doit se trouver dans une rue, etc.). Si les contraintes portent sur les valeurs des couples d'objets rpondant un critre de localisation, on parle de contrainte descriptive (par exemple, le nombre d'tage d'un immeuble ne doit pas dpasser le nombre d'tage permis par la zone de rglementation auquel l'immeuble appartient). On nomme ces contraintes d'intgrit spatiale contraintes de jointure, car elles correspondent des conditions topologiques, mtriques, ou descriptives sur le rsultat d'une jointure gomtrique entre deux collections d'objets localises. Les objets mettre en relation appartiennent des collections diffrentes, et ces collections peuvent tre de type gographique diffrent. Nous allons donc d'abord tudier l'expression des relations spatiales entre entits gographiques quelconques, avant d'tudier la mise en uvre formelle des contraintes d'intgrit par jointure spatiale. 7.3.5.1. Les relations spatiales entre objets gographiques Pour modliser la ralit, il n'est pas suffisant de dfinir des entits gographiques. Il faut galement dfinir des relations spatiales entre ces entits. Ces relations spatiales sont importantes, notamment pour la reprsentation des connaissances [FRA 93] [EGE 90], le raisonnement spatial [FRA 96] [EGE 94], et, bien sr, les contraintes d'intgrit spatiale [UBE 96]. Elles peuvent tre classes de la manire suivante [PUL 88][EGE 89] : les relations bases sur un ordre spatial li la dfinition dune origine ou dun axe (par exemple, une direction),

242

Chapitre 7

les relations topologiques qui dcrivent voisinages et proprits ensemblistes (par exemple, disjoint, adjacent, intersecte), les relations mtriques lies une distance. Les relations topologiques ont donn lieu de nombreux travaux, car ce sont les plus importantes vis vis du raisonnement et de la cohrence spatiale [EGE 90] [FRA 92b] [CLE 93] [CUI 93] [BOU 94] [MOL 94] [FRA 96]. Ainsi, plusieurs modles thoriques de reprsentation des relations topologiques ont t proposs : le modle des 9-Intersections, qui sappuie sur les notions topologiques dintrieur et de frontire : une relation topologique entre deux objets est dcrite par les 9 intersections de lintrieur, la frontire, et lextrieur du premier objet avec lintrieur, la frontire, et lextrieur du second objet. le modle RCC (Region Connection Calculus) utilise une approche axiomatique fonde sur le calcul de prdicats du premier ordre. La base du formalisme est la relation de connexion x est connect y , qui signifie que les ensembles x et y partagent un point. Un ensemble dautres relations est dfini partir de cette relation de connexion [CUI 93] [COH 93]. le modle CBM (Calculus Based Method), qui, partir de cinq relations ensemblistes (touch, in, overlap, disjoin, cross) et doprateurs de frontires, permet de coder toutes les situations topologiques entre deux objets [CLE 95]. Afin de faciliter lutilisation des modles de reprsentation, on peut grouper les relations topologiques en fonction du type de lobjet et du type de relation [UBE 97]. La dfinition mathmatique comprend les notations suivantes : pour un ensemble Y, Y reprsente lintrieur, Y reprsente la frontire, Y- reprsente lextrieur. Le type polygone correspond au type zone limit aux domaines connexes de genre 1 (zones sans trou). Le nombre de relations indique le nombre de cas possibles de relations topologiques diffrentes pour chaque regroupement (daprs [UBE 97]).

Nom de la relation EGALITE DISJOINT EXTREMITE SUR DISJOINT

Le groupe Point / Point Dfinition mathmatique (P1 P2 = 0) (P1 P2 = ) Le groupe Point / Ligne (P L = 0) (P L = 0) (P L = )(P L = ) Le groupe Point / Polygone

Nombre de relations 1 1 1 1 1

Contraintes d'intgrit spatiale

DANS SUR DISJOINT CROISE JOINT RENCONTRE COUVRE DISJOINT (P R = 0) (P R = 0) (P R = )(P R = ) Le groupe Ligne / Ligne (L1 L2 = 0) (L1 L2 = 0) (L1 L2 = 0) (L1 L2 = 1) (L1 L2 = )(L1 L2 = ) (L1 L2 = )(L1 L2 = ) DANS DEHORS CROISE RENCONTRE BORDE DISJOINT Le groupe Ligne / Polygone (L R = 1)(L R = ) (L R = ) (L R = 1)(L R = 1) (L R = 0)(L R 1) (L R = 1) (L R = )(L R = ) (L R = ) Le groupe Polygone / Polygone (R1 R2 = 2)(R1 R2 = ) (R1 R2 = ) (R1 R2 = 2)(R1 R2 = 1) (R1 R2 = 1) (R1 R2 = )(R1 R2 = 0) (R1 R2 = )(R1 R2 = 1) (R1 R2 = )(R1 R2 = ) 9 10 12 11 13 1 1 1 1 11 14 23 13 1

243

CONTIENT-DANS DEHORS RECOUVRE RENCONTRE BORDE DISJOINT

4 3 2 1 1 1

7.3.5.2. Les contraintes topologiques Les contraintes topologiques permettent de spcifier quelles relations topologiques sont interdites ou imposes entre les entits gographiques de la base de donnes. Elles nimposent de contraintes que sur la localisation des objets. La difficult de mise en uvre vient de la description des situations par des relations topologiques lmentaires ou des regroupements de relations. Des langages de contraintes ont ainsi t proposs par plusieurs auteurs [HAD 92] [UBE 97]. Les contraintes topologiques les plus courantes sont nanmoins assez simples, comme par exemple les contraintes dinclusion des objets dune entit dans les objets dune autre entit (pour un cadastre, les btiments doivent tre inclus dans les

244

Chapitre 7

parcelles), ou les contraintes de non-intersection (les rues ne doivent pas croiser les parcelles). 7.3.5.3. Les contraintes descriptives Ces contraintes s'expriment sur un attribut descriptif obtenu par jointure gomtrique entre deux collections (mise en relation d'objets par leur localisation). Elles n'imposent pas de conditions sur la localisation, mais sur les valeurs des attributs des couples d'objets qui satisfont une condition topologique ou mtrique de jointure. Ce sont des contraintes sur le rsultat descriptif de vritables requtes spatiales : zone dans zone, point dans zone, agrgation, zones adjacentes, dispersion Par exemple, on peut imposer un immeuble de n'avoir pas plus d'tages que ne le permet la zone d'occupation du sol dans laquelle il se trouve (pour mettre en uvre cette contrainte, il faut, pour chaque immeuble, calculer par go-jointure le nombre d'tages maximum de la zone d'occupation du sol dans laquelle il se trouve, et comparer avec le nombre d'tages de l'immeuble). On peut imposer un modle numrique de terrain de ne pas prsenter de diffrences de valeurs avec des valeurs ponctuelles daltitude (cette contrainte correspond la condition dgalit -ou de faible diffrence- sur le rsultat dune qui-jointure gomtrique entre les deux collections dobjets : des points cots, des pixels dun modle numrique). Pour toutes les contraintes d'intgrit faisant intervenir une distance, par jointure ou par appartenance, on peut introduire une incertitude de manire grer l'incertitude de la mesure de la localisation (la prcision gomtrique). La propagation de cette incertitude rend les contraintes moins fortes et permet ainsi d'viter les rejets injustifis dans les contrles de cohrence. 7.4. Modles gomtriques et mise en uvre des contraintes dintgrit spatiale Jusqu' prsent, nous avons tudi les contraintes spatiales indpendamment de la structure interne et des mthodes de stockage des lments graphiques dans tel ou tel systme. En fait, les mthodes de stockage sont essentiellement construites de manire faciliter les contrles de cohrence. Par exemple, la mthode de stockage la plus simple (de type dessin o tous les lments sont mlangs) ne permet aucun contrle de cohrence : c'est un problme constant dans les SIG que de rcuprer des cartes digitalises sans aucune relation avec la structure de la base de donnes.

Contraintes d'intgrit spatiale 7.4.1. Les diffrentes mthodes de stockage

245

Les modles de stockage peuvent tre classs en deux grandes familles : les modles spaghetti, qui offrent uniquement des primitives gomtriques pour la reprsentation des objets gographiques, et les modles topologiques, qui conservent la fois des primitives gomtriques et des relations topologiques entre les primitives ou les objets gographiques. Plus le modle est simple, plus le cot de la digitalisation est faible, et plus le stockage est direct. A l'inverse, si le modle est peu structur, il n'offre que peu de contrle au niveau des objets, et rend difficiles sinon impossibles les recherches suivant un critre spatial. 7.4.1.1. Les modles spaghetti Le modle le plus simple consiste stocker les lments graphiques sans aucune structure : les points, les arcs, les libells, sont digitaliss comme du dessin. Seul l'indication d'un niveau, ou d'un attribut graphique (comme une couleur ou un type de symbole), permet de diffrencier l'appartenance une collection. Si la notion de polygone n'est pas prsente, il est impossible de reconstituer les objets de type zone, ou plus gnralement d'tablir une correspondance entre les objets gographiques et les lments gomtriques qui dfinissent sa position dans l'espace. C'est le modle spaghetti anarchique, qui ne permet pratiquement aucun contrle de cohrence. Seuls des contrles de type gomtrique sur les arcs sont possibles (de type simplicit ou extra-simplicit). Les documents de ce type sont malheureusement trs nombreux, car souvent issus de logiciels de dessin, et donc digitaliss sans structuration au pralable. Pour intgrer ces documents dans un SIG, il est souvent ncessaire de recourir une dition : labelisation des objets, organisation des arcs en polygones, sparation des niveaux et regroupement suivant les entits gographiques. On arrive alors la notion de modle spaghetti simple, polygonal, polygonal unifi, o l'lment gomtrique reste l'arc, mais structur par rapport son appartenance un polygone. Ces modles ne conservent pas de topologie, mais permettent en gnral de la reconstituer en utilisant les rfrences entre les objets si des contraintes gomtriques sont respectes, telle que fermeture des chemins, simplicit, etc. La sparation des objets par entit gographique reste fondamentale pour la vrification de la cohrence de l'ensemble. On est donc dans un cas o la cohrence spatiale ne peut tre assure que par le respect de contraintes d'intgrit gomtrique, souvent difficiles tablir et respecter du fait de la faible structuration des lments graphiques digitaliss. 7.4.1.2. Les modles topologiques On parle de modle topologique lorsque l'on introduit des relations topologiques d'adjacence, de frontire ou de connexit dans la description gomtrique des objets. On peut ainsi conserver les relations de connexion entre arcs, les relations entre arcs et nuds, l'appartenance d'un arc un polygone, etc. Le modle le plus rpandu

246

Chapitre 7

s'appuie sur les notions de points, de nuds et d'arcs, avec des relations entre les points initiaux, les points finals, les faces gauche et droite, et les arcs sortants, gauche et droit (modle surfacique planaire). Les modles topologiques offrent alors de nombreuses possibilits de contrle de cohrence, grce la conservation explicite des relations d'adjacences et de connexions entre arcs. Mais, comme pour les modles spaghetti, la cl d'un bon contrle de cohrence est la bonne gestion des entits gographiques : on peut alors vrifier la cohrence pour les objets d'une mme collection avant de vrifier la cohrence entre collections, en suivant les principes que nous avons noncs dans les paragraphes prcdents. Il est pour cela essentiel de structurer les documents en fonction de la dfinition des entits gographiques avant de les digitaliser. 7.4.2. La vrification de la cohrence spatiale Pour les contraintes gomtriques, les contraintes topologiques de type, et les contraintes relationnelles, la vrification de la cohrence spatiale utilise des oprations gomtriques simples. La difficult de mise en uvre vient donc plus de la dfinition des contraintes et de la structuration de l'information que de la ralisation informatique des oprations. Mises part les contraintes gomtriques, toutes les oprations de vrification de la cohrence spatiale exigent de pouvoir reconstituer les relations entre les objets et les lments graphiques utiliss pour la description de leur localisation. Cette reconstitution est d'autant plus simple que le modle gomtrique utilis est plus complexe. Une fois cette reconstitution effectue, les contrles de cohrence utilisent des oprations gomtriques lmentaires, telles que : les contrles de simplicit et d'extra-simplicit bass sur la recherche d'intersections entre segments d'arcs, pour les objets de type point, les contrles d'unicit de cl faisant appel uniquement des calculs de distance, les contrles de fermeture bass sur des parcours d'arcs et donc sur des calculs de distances et de parcours entre les nuds des arcs constituant un polygone, pour l'unicit de cl concernant les objets de type zone, il faut assurer la simplicit et l'extra-simplicit des arcs, et l'ajustement des frontires entre zones adjacentes (union d'arcs), les trous dans les zones sont des problmes relevant de l'unicit de cl (un trou ne doit pas tre considr comme une autre zone, car deux zones d'une mme collection partageraient alors un mme lieu). Certains systmes grent ce problme par le sens des arcs des polygones, d'autres par la prise en compte directe de l'adjacence. Le contrle gnral de l'unicit de cl pour les zones exigent de tester la non-intersection de deux zones d'une mme collection. On peut utiliser pour cela, en

Contraintes d'intgrit spatiale

247

plus de la vrification d'extra-simplicit des arcs, une vrification de non-inclusion par un algorithme de type y-x. les contrles de connexion impliquant des calculs de distances entre nuds. Les contraintes topologiques de jointure font appel en gnral des conditions de non-intersection ou de non-inclusion entre objets dont les types peuvent tre diffrents. Elles utilisent les mmes algorithmes graphiques que prcdemment : vrification de l'extra-simplicit des arcs, non-inclusion, calculs de distance, etc. 7.5. SAVANE, saisie graphique et contraintes d'intgrit spatiale Le systme SAVANE comprend un certain nombre de contrles d'intgrit spatiale. Ces contrles se situent essentiellement au niveau de la saisie des donnes, dans le module SAVEDIT. Ils concernent l'unicit de cl, la fermeture de zones, le placement du centrode, la connexit, la simplicit des arcs, l'extra-simplicit des arcs, les contrles de valeur, les contrles de jointure. Nous allons en dcrire l'implmentation aprs avoir prsent rapidement le module de saisie. 7.5.1. Prsentation du module SAVEDIT 7.5.1.1. Les principes de la saisie graphique avec SAVEDIT Le module SAVEDIT permet la saisie graphique sur cran, partir de documents scanns puis gorfrencs (notamment grce au module SAVAMER, comme nous lavons vu dans le chapitre prcdent). La saisie graphique doit suivre la modlisation de la ralit et la structure de la base de donnes qui en dcoule : chaque collection dobjet doit tre saisie sparment lune de lautre, et donnera lieu la cration dun document spar. La saisie cre directement des documents dont la structure est proche du modle de stockage topologique de SAVANE pour la localisation : il ne sagit pas de saisie de type spaghetti, mais bien dune saisie avec topologie permettant de nombreux contrles dintgrit, dont certains sont effectus de manire interactive ou en arrire-plan. chaque objet saisi sera affecte une valeur, correspondant un attribut de lobjet servant de cl pour les autres attributs descriptifs. Cet attribut, nomm cl dans le logiciel, servira dattribut de jointure lors de lintgration dans la base de donnes des valeurs des autres attributs descriptifs de lobjet. SAVEDIT permet galement de saisir directement une valeur numrique pour chaque objet (par exemple, lors de la saisie de courbes de niveaux, on peut saisir directement la valeur de la courbe dans un attribut numrique sans avoir passer par un identifiant nominal, ce qui serait trs lourd. Aucune cl descriptive nominale nest saisie, et

248

Chapitre 7

aucune autre valeur, part celle directement saisie dans SAVEDIT, ne pourra tre affecte aux objets dans la base de donnes). Linterface utilisateur de SAVEDIT est identique celle du module SAVAMER. Lors de lentre dans le logiciel, on indique une base de donnes, un utilisateur et une vue externe. Une fois la base ouverte, lcran de SAVEDIT correspond un espace gographique, dans lequel on peut dessiner des objets existants dans la base de donnes, des documents dj saisis, des images gorfrences, et des fonds graphiques gorfrencs, au format DXF. Cet espace gographique peut tre modifi grce aux boutons de zoom de la barre doutils ou grce aux commandes du menu WIND. Lutilisateur peut galement choisir la projection gographique parmi les nombreuses possibilits qui lui sont offertes, et les objets de la base de donnes seront dessins dans cette projection gographique. La saisie seffectue ensuite, aprs avoir cr un document ou ouvert un document existant. Cest lors de la cration dun document que lon doit indiquer le type du document (zone, ligne, point) et le type de lidentifiant saisir pour chaque objet (nominal, numrique). On peut galement indiquer un certain nombre dautres paramtres facultatifs (nom de loprateur, datum, chelle de prcision). Le processus de saisie est diffrent suivant le type du document. La saisie de points ou de lignes est trs simple, la saisie de zone est un peu plus complexe. Des options de visualisation sont disponibles pour tous les types de document (affichage de la cl ou de la valeur des objets par exemple). Le principe de la saisie est donc trs diffrent dun logiciel de saisie graphique de type CAD. Avec SAVEDIT, les diffrents niveaux sont spars dans des documents diffrents, chaque document correspondant aux objets dune relation de la base. On nindique lors de la saisie aucun attribut graphique (de type couleur, paisseur de trait, ), mais on doit donner pour chaque objet un identifiant descriptif. 7.5.1.2. Saisie et indexation gographique Comme nous lavons vu au chapitre 5, lindexation graphique dans la base de donne utilise directement le dcoupage gographique en feuille ou coupure de carte. Il convient donc de dfinir ou de conserver ce dcoupage lors de la saisie graphique. La saisie des objets dune mme relation donne donc lieu en gnral la cration de plusieurs documents de saisie, chaque document couvrant un espace gographique donn, correspondant ce dcoupage en feuilles. Pour lefficacit la fois du systme de saisie (SAVEDIT) et du systme dindexation dans SAVANE, il est prfrable de ne pas dpasser un certain nombre dobjets par document (environ 2000 pour les zones, 5000 pour les lignes ou les points), mme si le systme de saisie supporte un nombre dobjet par document bien suprieur (150000).

Contraintes d'intgrit spatiale

249

Si le contrle du dcoupage est assez simple lorsque lon saisit des objets partir de cartes existantes, il est plus complexe lorsque les objets sont imports partir de documents numriques saisis sur un autre systme nutilisant pas ces principes dindexation. Dans ce cas, il faut utiliser les options de dcoupage automatique lors de limportation. 7.5.1.3. La saisie de points Le processus de saisie de points est trs simple : il suffit, une fois dans le mode de saisie de points, de cliquer avec la souris sur lcran pour saisir un point. Le point est valid, avec sa cl, lorsque lutilisateur appuie sur le bouton accepter du dialogue de saisie (ou sur la touche Entre). Un point peut tre ensuite dplac, supprim, ou sa cl modifie, lorsquil est slectionn par lutilisateur. 7.5.1.4. La saisie de lignes La saisie de lignes est galement trs simple, chaque arc saisi correspondant un objet. Pour saisir un arc, il suffit de saisir les points de larc (plusieurs modes de saisie sont disposition de lutilisateur : point par point, en continu sur la distance ou sur la surface entre trois points contigus), indiquer la valeur de la cl, puis valider. Un arc peut tre modifi par la suite : ajouter, dplacer ou supprimer des points, filtrer, lisser, modifier la cl descriptive. On peut galement le couper en deux, le dplacer, le fermer sur lui-mme, etc. Un menu contextuel contenant ces options peut tre visualis lorsquun arc est slectionn dans lcran. Certaines procdures permettent de rgler directement lors de la saisie de larc des contraintes de connexit : une option permet de joindre automatiquement les extrmits des arcs lorsque la distance est infrieure une valeur qui peut tre paramtre, en pixels cran (la valeur absolue dpend donc de la fentre de visualisation : plus le territoire de la fentre est troit, plus le pixel cran est grand, en valeur absolue). De mme, dplacer lextrmit dun arc proche de lextrmit dun autre arc va joindre automatiquement les deux arcs si loption est active. 7.5.1.5. La saisie de zones La saisie de zones se fait en deux temps : dans un premier temps saisie des arcs frontires de la zone, et dans un second temps saisie de lobjet zone lui-mme avec indication de la valeur de la cl descriptive. La saisie dun arc seffectue indpendamment de la zone, avec les mmes possibilits que pour la saisie darc dans le cas des objets de type ligne. Par contre, lors de la dfinition de lobjet zone, il faut indiquer la valeur de la cl descriptive ainsi que tous les arcs formant la frontire de la zone. Un arc ne peut bien sr ntre frontire que de deux zones.

250

Chapitre 7

Comme pour les lignes, certaines options permettent dassurer directement des contraintes de connexit lors de la saisie. Par exemple : - jointure automatique des extrmits proches, - cration automatique dun nouveau nud par division dun arc dj saisi, lorsque lon saisit un nouveau nud proche de cet arc. - cration automatique dun nud avec division des arcs chaque intersection darcs. De plus, certaines options de saisie darcs sont spcifiques aux arcs de zones pour assurer la cohrence topologique : - inclusion dun arc dans les arcs frontires dune zone, - exclusion dun arc des arcs frontires dune zone, - indication de visibilit (certains arcs, crs uniquement pour assurer la fermeture des zones, ne devront pas tre visualis dans une reprsentation cartographique). - option permettant dassurer la persistance de la connexit des arcs, dans le cas de modification dun nud (les extrmits des autres arcs sont alors galement dplaces). A chaque zone est affect un identifiant interne (un numro, partir de 20 ; les 20 premiers numros sont rservs). Chaque arc conserve les numros des deux zones adjacentes dont il est frontire. Un arc est dit libre sil nest affect aucune zone (ses deux numros de zones adjacentes ont pour valeur 0). Un arc est dit pendant si lune de ses extrmits nest rattache aucun autre arc. Un document en fin de saisie ne doit contenir ni arcs libres ni arcs pendants. Nous employons indistinctement le terme bout ou nud pour dsigner lextrmit dun arc. 7.5.1.6. Saisie, datum et projection gographique Chaque point saisi sur lcran est transform immdiatement en coordonnes gographiques (longitude, colatitude) selon la projection gographique utilise. Tous les points sont donc conservs en coordonnes sphriques. Le datum dun document peut tre dclar pour information, et peut tre modifi par la suite : dans ce cas, lutilisateur a le choix de transformer ou non les coordonnes des points saisis. Ceci peut tre ncessaire car tous les objets dune base de donnes SAVANE doivent tre exprims dans le mme datum. Si le document dorigine nest pas dans le datum de la base de donnes dans laquelle il est destin tre intgr, il faut dabord le saisir dans son datum dorigine, puis transformer toutes les coordonnes saisies grce loption de changement de datum. Le changement de datum utilise les formules de Molodensky telles quexposes dans le chapitre 4.

Contraintes d'intgrit spatiale 7.5.2. Les contraintes sur les objets gomtriques 7.5.2.1. Les classes CArc et CSaveditDocument

251

La classe CArc de SAVEDIT permet dencapsuler lensemble des membres et des procdures ncessaires la manipulation dun arc et la vrification des contraintes gomtriques (A.4.1). Lallocation mmoire pour les points (tableau m_ArrayPoint) est dynamique. Elle utilise les fonctionnalits de la classe CArray de la MFC (Microsoft Fundation Class). Toutes les variables et procdures lies au document de saisie sont regroupes dans une classe nomme CSaveditDocument (A.4.2). 7.5.2.2. Nettoyage des arcs De nombreux tests peuvent tre effectus pour viter davoir des arcs inconsistants. On peut ainsi : - liminer les arcs de moins de deux points (cas impossible en thorie, mais pouvant provenir dun dfaut du logiciel), - contraindre les coordonnes des points saisis rester dans des limites gographiques donnes, - liminer les arcs trop petits. Certains arcs trs petits peuvent tre crs accidentellement par les options de division ou de jointure automatique, et sont ensuite difficiles slectionner sur lcran pour les liminer manuellement. Ces procdures ne posent aucun problme algorithmique. Elles sont implmentes dans la mthode NettoyerTousLesArcs() de la classe CSaveditDocument (A.4.2). 7.5.2.3. Simplicit La simplicit des arcs est une contrainte qui doit toujours tre respecte, sous peine dincohrence future, surtout lorsquil sagit darcs formant le contour de zones. En effet, certains logiciels ne supportent pas les arcs qui ne sont pas simples et crent automatiquement un polygone correspondant la boucle pour liminer le problme. Mais cette solution nest pas agrable, car elle peut entraner des incohrences avec des fichiers de valeurs descriptives. Le contrle de simplicit teste pour chaque arc lintersection de tous les segments deux deux (fig. 7.5). Il utilise la procdure SegmentIntersection() que nous avons vue au chapitre 3 (A.4.1).

252

Chapitre 7

fig. 7.5 : test de simplicit sur un arc dans SAVEDIT

7.5.2.4. Extra-simplicit Lextra-simplicit teste lintersection de chaque arc avec tous les autres. On teste pour cela lintersection de chaque segment dun arc avec les segments de tous les autres arcs. Bien sr, les arcs qui ne peuvent avoir dintersection sont carts tout de suite (on utilise le rectangle incluant larc), sinon le test serait trs long. 7.5.2.5. Fusion darcs La fusion darc permet de rsoudre le problme de lincohrence entre deux documents, ou dviter la saisie directe de portions darc en double. Cette procdure peut tre active lors de la saisie (on parle alors de snapping), en correction sur un arc, ou pour lensemble des arcs du document. En saisie, chaque point digitalis est compar lensemble des arcs dj saisi ; sil existe un arc proche, cest--dire une distance infrieure au minimum donn pour la fusion (cest un paramtre qui peut tre choisi par lutilisateur), il est remplac par le point de larc en question. Ce point est calcul en utilisant la procdure PointLePlusProche(). En correction, la procdure est effectue sur lensemble des points de larc, arc qui est ensuite filtr pour liminer les ventuels points en double. Effectu sur lensemble du document, la fusion compare lensemble des arcs entre eux (A.4.1). Dans le cas des zones, il faudra aprs la fusion liminer les arcs en double, puisque la fusion cre des portions identiques au sein darcs diffrents.

Contraintes d'intgrit spatiale 7.5.2.6. Suppression darcs en double

253

Avec le modle topologique (arcs frontires), lune des erreurs les plus courantes provient des arcs saisis en double. Un arc en double provoque une erreur dextrasimplicit, quelquefois difficile identifier car, si les deux arcs se recouvrent exactement, lerreur nest pas visible lcran. Il convient dliminer les portions darcs en double sans dtruire la cohrence de lensemble. Lalgorithme utilis dans SAVEDIT teste, sur lensemble du document, les portions darcs identiques, et dcoupe les arcs pour liminer lune des portions en question. La portion qui reste sert alors de frontire aux deux zones concernes. La procdure seffectue en plusieurs tapes, grce de SupprimerLesArcsEnDouble() CSaveditDocument (A.4.2) : - pour chaque arc, chercher les autres arcs qui peuvent avoir une intersection, - si un arc est candidat, rechercher partir de lun des nuds un point commun, - si lon a trouv un point commun, on recherche si les points suivants sont galement communs, dans chacun des arcs. Pour le second arc, on doit tester dans le sens de larc, puis dans le sens inverse, car les deux arcs nont pas forcment t saisis dans le mme sens. - si lon a trouv une squence commune, on dcoupe le premier arc en trois arcs ( moins que le premier point de la squence commune soit un bout de larc), le second de mme, et lon limine lun des deux arcs correspondant la partie commune. 7.5.2.7. Union darcs Lunion darcs permet de regrouper plusieurs arcs pour en faire un seul. Elle permet dallger le document en diminuant le nombre des arcs et donc des nuds. Elle intervient en gnral aprs une jointure automatique des arcs sur les nuds. Pour unir plusieurs arcs, il faut chaner les arcs qui peuvent ltre en testant lensemble des nuds du document, et en changeant lordre des points dun arc si ncessaire. Pour un document de type zone, le chanage sarrte ds quun nud apparat dans plus de deux arcs du document. 7.5.3. Les contraintes sur les objets gographiques 7.5.3.1. Le nettoyage des zones Comme pour les arcs, quelques procdures permettent dassurer une bonne cohrence de lensemble du document, comme par exemple la suppression des zones sans arc, la suppression des arcs sans zones (arcs libres), ou la dtection des arcs pendants. Ces procdures interviennent en gnral lors de la rvision finale du document.

254

Chapitre 7

7.5.3.2. La fermeture de zones On teste la fermeture des zones en vrifiant le nombre doccurrences dapparition dun bout pour tous les arcs constituant la zone. Ce nombre doit toujours tre un multiple de 2 (mthode de IsZoneFermee() CSaveditDocument, A.4.2).

fig. 7.6 : test de fermeture dune zone

La fermeture des zones est lun des tests les plus importants, car la cohrence des zones intervient dans de nombreux problmes graphiques. De plus, les erreurs de fermeture sont trs pnalisantes pour la saisie, si elles ne sont pas corriges au fur et mesure. Il est en effet difficile de corriger la cohrence dun document comportant de nombreuses erreurs de fermeture de zone. Dans SAVEDIT, une option permet de visualiser automatiquement toute erreur de fermeture de zone : les nuds ouverts sont indiqus par un cercle rouge (fig. 7.6). Avec cette option, le test de fermeture est effectu pour lensemble des zones chaque fois que lon dessine les zones sur lcran. On peut galement tester la fermeture des zones grce loption de remplissage des zones fermes par une couleur (fig. 7.7). Cette option permet de visualiser le document en cours de saisie en utilisant une image raster de lensemble des zones fermes. Limage raster est cre par rasterisation en utilisant les arcs des zones, aprs test de fermeture. Elle est actualise de faon dynamique chaque modification de zone. On utilise pour cela lalgorithme de rasterisation prsent au chapitre 5, avec une dfinition de rasterisation gale la rsolution de lcran.

Contraintes d'intgrit spatiale

255

fig. 7.7 : visualisation de la fermeture par remplissage en couleur

7.5.3.3. Connexit et fermeture des arcs pour le type ligne Pour les objets de type ligne, la connexit ou la fermeture des arcs nest pas une contrainte gomtrique, mais elle sexprime nanmoins sur les arcs saisis. Il est donc utile davoir des outils permettant de joindre deux arcs sur leurs extrmits ou de fermer un arc sur lui-mme. Lutilisateur doit effectuer ces oprations manuellement, en slectionnant larc (pour le fermer sur lui-mme) ou les deux arcs (pour les joindre), lorsque cela est ncessaire la cohrence de lensemble. 7.5.3.4. Unicit de cl (zones scantes, zones incluses) La contrainte dunicit de cl est fondamentale pour assurer la cohrence du modle relationnel. Il faut donc viter que deux zones dun mme document ne se recouvrent. Le cas de zones scantes est le plus simple : il peut tre contrl grce aux procdures de contrle sur les arcs (extra-simplicit). Par contre, il faut faire particulirement attention au problme des zones incluses, car une zone incluse peut facilement tre saisie sans que la topologie soit prise en compte, si lon oublie dinclure larc dans la zone qui la contient. Il faut donc tester lintersection des zones lorsquil y a possibilit dinclusion. On teste pour cela les possibilits dinclusion pour lensemble des couples de zone dun document. Ce test utilise le rectangle minimum des zones. Lorsque deux zones sont candidates, on rasterise ces deux zones dans un espace dfini partir de

256

Chapitre 7

la plus petite. Les deux images ainsi obtenues doivent tre disjointes. La rasterisation utilise lalgorithme prsent au chapitre 5 pour la rasterisation dun masque. 7.5.3.5. Centrode de zones Comme un centrode peut tre dplac par loprateur de saisie, il est important de tester lappartenance des centrodes leur zone pour assurer la cohrence globale. Rappelons que le centrode est utilis lors de lexploitation des donnes pour des oprations dagrgation ou dappartenance, ainsi que pour placer des lments cartographiques (symboles, labels, etc.). On teste lappartenance dun centrode une zone ferme en utilisant un algorithme YX : une ligne traversant la zone doit couper son contour avec un nombre impair dintersection avant un point intrieur (thorme de Jordan). Dans la pratique, on calcule le nombre dintersection dune ligne horizontale passant par le centrode avec lensemble des arcs formant le contour de la zone, en ne retenant que les points dintersection qui se trouve avant le centrode (de la gauche vers la droite). Si la ligne passe par un nud (extrmit commune plusieurs arcs) cette intersection ne doit tre compte quune seule fois. 7.5.3.6. Valeurs adjacentes (courbes de niveaux) Cette contrainte descriptive de jointure est trs utile pour trouver les erreurs lors de la saisie de courbes de niveaux. Elle permet de trouver les courbes adjacentes dont la diffrence des valeurs ne se situe pas dans un intervalle donn. Elle est complmentaire dune recherche dextra-simplicit des arcs, qui doit normalement tre effectue auparavant. Nous considrerons que deux lignes sont voisines s'il existe un segment de droite reliant un point dans chaque ligne et ne coupant aucune autre ligne. Pour vrifier cette contrainte, lalgorithme dvelopp dans SAVEDIT discrtise lespace de manire trouver rapidement les conditions dadjacence. Le principe est le suivant : - on calcule la fentre du document ; - on fait passer n lignes horizontales (y=constante, dans le plan de projection) travers ce document, en calculant pour chaque ligne horizontale les points dintersection de cette ligne avec les objets du document. Les intersections sont conserves avec le numro de lobjet auquel elles appartiennent ; - pour chaque ligne horizontale, les points sont tris en x. Ensuite, on teste la diffrence des valeurs des objets de deux points contigus, par rapport lintervalle des valeurs admissibles, donnes par lutilisateur.

Contraintes d'intgrit spatiale

257

On peut rpter lopration en inversant x et y. Bien sr, la prcision du test dpend du pas de calcul. Plus n est grand, plus on se rapproche de la dfinition exacte de la relation dadjacence, et moins on aura de possibilit de voir une courbe chapper au contrle. Le temps dexcution est proportionnel n. Outre les erreurs sur les valeurs, ce test permet de mettre en vidence des problmes de connexit entre deux lignes : un espace entre deux lignes de mme valeur permet une ligne horizontale ou verticale de traverser cet espace, et donc de provoquer une erreur sur les valeurs. Voici la procdure TestValeur() de la classe CSaveditDocument correspondant ce test (A.4.2). Les points dintersection sont stocks dans des cellules et tris sur x par insertion. La structure est identique celle utilise pour la rasterisation. 7.5.3.7. Valeurs adjacentes (points cots) Cette contrainte descriptive permet de trouver les erreurs lors de la saisie de points cots . Elle permet de trouver les points voisins dont la diffrence des valeurs ne se situe pas dans un intervalle donn. Ici, deux points sont voisins sils sont contigus dans la triangulation de Delaunay. La vrification calcule donc la triangulation de Delaunay pour lensemble des points saisis (avec lalgorithme prsent au chapitre 6), puis calcule la valeur de la diffrence de deux points contigus dans la graphe correspondant la triangulation. 7.5.4. Quelques procdures automatiques : algorithmes Nous allons prsenter ici rapidement quelques procdures et algorithmes un peu plus complexes qui permettent damliorer considrablement les performances du logiciel de saisie graphique. Ces procdures sont en cours de dveloppement dans le module SAVEDIT. 7.5.4.1. La dtection automatique des contours de zone La constitution automatique de zones partir des arcs saisis peut amliorer considrablement les temps de saisie, car loprateur na plus indiquer la main les arcs constituant le contour de chaque zone. Mais pour que cette procdure puisse fonctionner, il faut que le document soit dj en bon tat (pas darcs libres, pas darcs pendants). Cette opration correspond la cration automatique de la topologie pour les zones. Deux mthodes peuvent tre utilises :

258

Chapitre 7

- une mthode semi-automatique, avec lindication pour chaque zone dun point intrieur. Lalgorithme recherche alors lensemble des arcs ncessaires pour fermer le polygone contenant le point. - une mthode automatique : le programme cre des polygones partir de lensemble des arcs et calcule un centrode pour chaque polygone. Les objets zone correspondent aux polygones. Cette mthode ne peut rsoudre le problme des zones incluses : elles seront toujours considres comme des objets, et le document cr ne comportera donc aucun trou . 7.5.4.2. La saisie semi-automatique darc par suivi de contour La saisie automatique permet de saffranchir de la saisie manuelle des arcs : elle correspond une opration de vectorisation partir dune image du document scann. Mais la vectorisation brute est peu efficace, car elle peut crer de nombreux arcs parasites, et ne cre pas les objets ou la topologie de lensemble. Nous dveloppons donc une mthode semi-automatique qui permet loprateur de crer des arcs en indiquant la ligne suivre et en donnant la direction du suivi de contour lorsque lalgorithme rencontre un ambigut. Pour crer les arcs partir dun document scann, nous utilisons une mthode par suivi de contour partir du document transform en une image noir et blanc [BAR 88]. Les contours correspondent au squelette obtenu partir des zones noires. Loprateur indique le dbut de larc saisir, puis la direction du suivi en pointant sur un autre point de larc. Lalgorithme suit la ligne et sarrte ds quil rencontre une branche dans la ligne. Loprateur indique alors si larc est termin ou la direction dans laquelle le suivi doit continuer. 7.5.5. Le format des documents SAVEDIT Quelque soit le type du document, SAVEDIT cre un fichier dextension .car indiquant les caractristiques du document. Ce fichier texte a laspect suivant :
.Version 7 .Nom seismes .Date Wed Feb 23 18:14:59 2000 .Operateur Importation de points .Datum WGS84 .Echelle 0 .Type 1 .Attribut 2 .TailleCle 40 .Datum non prcis .Projection 2.0000000000e+000 6.3781370000e+006 6.6943799901e-003 9.9960000000e-001 1.6740000000e+004 0.0000000000e+000 0.0000000000e+000 0.0000000000e+000 0.0000000000e+000

Contraintes d'intgrit spatiale

0.0000000000e+000 0.0000000000e+000 0.0000000000e+000 0.0000000000e+000 0.0000000000e+000 0.0000000000e+000 0.0000000000e+000 0.0000000000e+000 0.0000000000e+000 0.0000000000e+000 0.0000000000e+000

259

Chaque ligne qui commence par un . correspond un paramtre du document. Par exemple, .Type indique le type du document (1 : point, 2 : ligne, 3 : zone), .Attribut indique le type de lidentifiant (1 : numrique, 2 : nominal, 3 : les deux). .Projection indique la projection gographique privilgie pour laffichage du document lors de la saisie (20 paramtres), mais les coordonnes sont conserves en longitude-latitude dans un datum, qui est normalement prcis par une ligne .Datum. Un document de type point comporte un seul fichier, dextension .pt. Tous les objets sont crits les uns la suite des autres (A.4.2). Un document de type ligne comporte deux fichiers, lun dextension .lg, lautre dextension .arc. Le fichier dextension .lg comporte la description des objets, et le fichier dextension .arc comporte la description des arcs constituant les objets lignes. Un document de type zone comporte galement deux fichiers, dextension .zon et .arc. Le fichier dextension .zon comporte la description des objets, et celui dextension .arc la description des arcs constituant les frontires entre zones. Les fichiers dextension .arc ont la mme structure, quelque soit le type des objets auxquels se rfrent les arcs (A.4.2). 7.6. Conclusion La mise en uvre de contraintes d'intgrit dans les bases de donnes gographiques est essentielle, car plus que d'autres ces bases sont difficiles maintenir et mettre jour, et de nombreux traitements gographiques ne sont valables qu' la stricte condition d'une bonne cohrence des donnes. Ce n'est qu'au prix d'un bon respect des contraintes d'intgrit gographique que l'on pourra assurer une bonne utilisation de la base de donnes. Les contraintes d'intgrit sont dtermines par la modlisation de la ralit en collections d'objets du mme type (qui correspond la dfinition de la structure de la base de donnes). Les contraintes gomtriques et topologiques de type peuvent intervenir trs tt dans le processus de constitution de la base. On a mme tout intrt les traiter de faon interactive lors de la saisie des donnes elles-mmes, car

260

Chapitre 7

toute modification graphique dans un grand ensemble d'objets gomtriques est par la suite dlicate, si l'on veut maintenir la cohrence de l'ensemble, du fait de la propagation possible d'erreurs. Une base de donnes gographique doit finalement tre considre comme un ensemble complexe, comprenant la dfinition d'un ensemble de collections, la dfinition de contraintes d'intgrit pour chaque collection, de contraintes d'intgrit entre les collections, et des mthodes dutilisation pour les collections d'objets. Un SIG devrait tre capable de proposer et de grer cette structure complte, avec un langage de description et de manipulation des collections et des relations entre collections, que ce soit pour les contraintes d'intgrit comme pour les mthodes dexploitation des donnes.

Contraintes d'intgrit spatiale

261

Bibliographie

[BAR 88] BARUCH O., Line Thinning by Line Following, Pattern Recognition Letters, 1988, Vol. 8, p. 271-276 [BEN 93] BENKAZEN V., DOUCET A., Bases de donnes orientes objet, 1993, Armand Colin [BOU 94] BOURSIER P., TAO-YUAN J., A model for Handling topological relationships in a 2D environment, Proceedings of the 6th International Symposium on Spatial Data Handling, 1994, Vol 1, pp 73-88, Endinburgh [CLE 93] CLEMENTINI E., DI FELICE P., VAN OOSTREROM P., A Small Set of Formal Topological Relationships Suitable for End-User Interaction, Proceedings of the 3th Symposium on Large Spatial Databases, 1993, Lecture Notes in Computer Sciences 692, pp 277-295, Singapore [CLE 95] CLEMENTINI E. DI FELICE, CALIFANO G., Composite Regions iin Topological Queries, Information Systems, 1995, Vol. 20, n7, pp 579-594 [COH 93] COHN A.G., RANDELL D.A., CUI Z., BENNETT B., Qualitaiv Spatial Reasoning and Representation, Preceedings of QUARDET 93, PP 513-522, Barcelona, Spain, 1993 [CUI 93] CUI Z., COHN A.G., RANDELL D.A. , Qualitativ and Topological Relationships in Spatial Databases, Proceedings of the 3th Symposium on Large Spatial Databases, 1993, Lecture Notes in Computer Science 692, pp 296-315, Singapore [DAT 90] DATE C., A Contribution to the study of database integrity, in Relational Database Writing, 1990, Addison-Wesley [DAV 94] DAVID B., FASQUEL P., Qualit dune base de donnes gographique : concepts et terminologie, Bulletin dinformation de lIGN, 1994, n 67, Paris [EGE 89] EGENHOFER M.J., A Formal Definition of Binary Topological Relationships, Proceedings of the 3th International Conference on Foundations of data Organization and Algorithms, 1989, Lecture Notes in Computer Science 367, Paris, France, pp 457-472

262

Chapitre 7

[EGE 91] EGENHOFER M.J., FRANZOZA R.D., Point-Set Topological Relations, International Journal of Geographic Information Systems, 1991, 5-2, pp 161-174 [EGE 94] EGENHOFER M.J., CLEMENTINI E., SHARMA J., Modelling topological spatial relations : strategies for query processing, Computer and graphics, 1994, vol. 18, n6, pp 515-522 [FAI 96] FAIZ S.O., Modlisation, exploitation et visualisation de l'information qualit dans les bases de donnes gographiques, Thse de Doctorat, 1996, Univ. Paris XI Orsay [FRA 92] FRANK A.U., Qualitative Spatial Reasoning about Distances and Directions in space, Journal of Visual Langages and Computing, 1992, vol. 3, n 4, pp 343-371 [FRA 96] FRANK A.U, Qualitative spatial reasoning : cardinal directions as an example. International Journal of Geographical Information Systems, 1996, Vol. 10, n3, pp 269-290 [GOO 89] GOODCHILD M., GOPAL S., Accurancy of Spatial Databases, 1989, Taylor & Francis [GUP 95] GUPTILL S.C., MORRISON J.L., Pergamon/Elsevier Science, 1995 Elements of Spatial Data Quality,

[HAA 96] HAADZILACOS T., TRYFONA N., A model for expressing topological integrity constraints in geographical databases, in Proceedings : Theories and Models of SpacioTemporal Reasoning in Geographic Space, 1996, International Conference GIS, Pisa, Italy. A. Frank, I. Campari, U. Fomentini (Ed.), pp 252-268 [LAU 94] LAURINI R., Dtection et corrections d'erreurs topologiques dans les bases de donnes gographiques, Actes des premires journes de la recherche CASSINI, 1994, Lyon, France, pp 105-114 [LAU 93], LAURINI R., MILLERET-RAFFORT F., Les bases de donnes en gomatique, 1993, Herms, Paris [LAU 91] LAURINI R., MILLERET-RAFFORT F., Cohrence dans les bases de donnes spatiales, VIIe journes Bases de donnes Avances, INRIA, 1991, pp 471-488, Lyon [MOL 94] MOLENAAR O, KUFONIYI O., BOULOCOS T., Modelling topological relationships in vector maps, Proceedings of the 6th International Symposium on Spatial Data Handing, 1994, pp 112-126, Endinburgh [ML 95] MLLER J.C., LAGRANGE J.P., WEIBEL R., (ed.), GIS and Generalization, GIS DATA I, 1995, Taylor & Francis [ORO 93] OROURKE J., Computational Geometry in C, 1993, Cambridge University Press [PUL 88] PULLAR D.V., EGENHOFFER M.J., Toward formal definitions of topological relations among spatial objects, Procedings of the third International Symposium on Spatial Data Handling, 1988, Sydney, Australia, pp 225-241 [PL 97] PLMER, GRGER, Archiving Integrity in Geographic Information Systems Maps and Nested Maps, Geoinformatica, 1997, vol.1, n 4, pp 345-367, Kluwer Academic, Boston

Contraintes d'intgrit spatiale

263

[SOU 86] SOURIS M., Systmes dinformation gographique et bases de donnes, Colloques et Sminaires sur le Traitement des donnes localises, 1986, pp 29-87, Editions de lOrstom, Paris [TAN 95] TANZI T., UBEDA T., Contrle topologique de la cohrence dans les bases de donnes gographiques : application aux rseaux , Revue Internationale de Gomatique, 1995, Vol. 5, n2, pp 133-155 [UBE 96] UBEDA T., SERVIGNE S., Geometric and Topological Consistency of Spatial Data, 1996, in Proceedings: First International Conference on Geocomputation, Leeds, UK [UBE 97] UBEDA T., Contrle de la qualit spatiale dans les bases de donnes gographiques : Cohrence topologique et corrections d'erreurs, Thse soutenue l'INSA de Lyon, 1997

Troisime partie : Analyse spatiale et cartographie

266

Chapitre 8

Analyser 267

Chapitre 8

Analyser : calculs et analyse spatiale

8.1. Introduction Lobjectif des SIG nest pas seulement de reprsenter des objets lmentaires pour les grer et les restituer graphiquement avec des cartes. A partir dune modlisation de la ralit qui se veut la plus complte mais aussi la plus simple grer, le systme doit nous permettre danalyser les objets ainsi modliss pour en construire dautres, plus complexes, plus synthtiques, soit pour construire une modlisation dun problme spcifique, soit pour dcouvrir par une dmarche empirique des situations nouvelles. Cette dmarche nest pas spcifique aux donnes localises, mais la localisation, qui tait souvent vue comme un fait et non une causalit, doit galement intervenir dans ce processus danalyse. Lanalyse spatiale recouvre un ensemble de mthodes et doutils qui permettent dinterprter et de rendre compte des relations qui existent entre des objets localiss, afin de dcouvrir ou de mettre en vidence des rgles gnrales dorganisation de lespace [PUM 97]. Son objectif est essentiellement de dcrire une disposition particulire de certains objets, de leur organisation spatiale, de reprer des structures, dexpliquer une localisation par dautres. Pour cela, il faut dceler en quoi la localisation apporte un lment utile la connaissance des objets tudis et peut en expliquer les caractristiques, en partie ou en totalit. Lanalyse spatiale permet dintroduire la localisation comme une cause explicative dun phnomne, ou lintroduire dans une analyse statistique qui habituellement lignore.

268

Chapitre 8

Les dmarches de lanalyse spatiale sont multiples. Elle peut tendre un simple rsum de linformation contenue sur une carte thmatique, par exemple en localisant le centre de gravit dun semis de points ou en dessinant des zones homognes. Elle peut chercher faire apparatre des structures spatiales connues, comme certains types de rseaux ou une organisation de type centre-priphrie. Elle peut aussi viser tester la pertinence dun modle spatial, ou aider simuler un processus spatial. Quelle que soit la mthode employe, lanalyse portera toujours sur un ensemble dobjets, et non sur un individu isol. Lanalyse spatiale a besoin pour cela de beaucoup de donnes localises. Et cest l quinterviennent les SIG, pour aller au-del de leurs simples possibilits de gestion de donnes localises bien efficaces en tant que telles mais insuffisantes pour tudier un phnomne et rpondre des problmes dorganisation du territoire tudi. Au del de cette fonction de gestion de donnes, les SIG doivent contenir les outils et instruments permettant de remplir tout ou partie des fonctions de lanalyse spatiale. Et cest bien ce qui fait alors la puissance de ces systmes, car il sont les seuls permettre la fois la gestion de la localisation et son introduction dans un processus danalyse. Mais ces outils sajoutent aux outils statistiques ou mathmatiques existants quils utilisent dailleurs largement et ne les remplacent pas. Un SIG se doit donc galement dincorporer ou de donner accs aux mthodes classiques de lanalyse de donnes. Lun des intrts majeurs de lutilisation de la statistique dans un SIG rside dans la possibilit dtudier facilement la localisation des variations dun attribut descriptif, et de rechercher les relations entre variation dun attribut et localisation des objets [SAN 89]. Aprs un bref rappel des principaux concepts de lanalyse spatiale, nous prsentons dans ce chapitre les oprations qui permettent de mettre en uvre des procdures danalyse spatiale dans le module dexploitation des donnes du systme SAVANE. Ces oprations ne sont plus des oprations de lalgbre relationnelle tendue, et sapparentent plus des programmes dapplication ou des mthodes. Le SIG, initialement systme de gestion de type relationnel, soriente maintenant vers une approche objet, avec lintroduction de mthodes sur les collections dobjets. Les mthodes lies la localisation dpendent pour la plupart du type des objets. 8.2. Rappels sur lanalyse spatiale 8.2.1. Structures spatiales et objets gographiques : gnralisation et agrgation Comme nous lavons vu loccasion des exemples donns au chapitre 3, la description dun phnomne gographique complexe, statique ou dynamique, fait appel de nombreuses chelles de description et la dfinition de nombreux objets suivant une modlisation qui nest pas toujours vidente construire. Cest partir

Analyser 269 de cette schmatisation que lutilisateur gographe va pouvoir construire des objets plus complexes, extraire des modles, des organisations, des structures, pour aboutir une vision plus synthtique [HAG 73]. En fait, cest bien souvent le travail danalyse spatiale qui va permettre de dfinir ces chelles de description et les attributs qui lui correspondent, partir dune information de base donne par rapport dautres objets gographiques. Cest ce qui fait lambigut et la difficult de cette dmarche souvent rcursive, et qui amne souvent un SIG contenir des collections dobjets correspondant diffrents niveaux danalyse. Cest la fin dune analyse gographique quapparat lidentification de nouveaux objets spatiaux : on utilise linformation connue pour des objets gographiques pour en dfinir dautres, plus cohrents par rapport un problme donn, ou relevant dune autre chelle dobservation, plus synthtique. Les gographes font rfrence ces diffrents niveaux dobservation en parlant de changement dchelle gographique de lanalyse. Lanalyse spatiale permet donc de passer dun modle de la ralit un autre. Diffrents modles concernent bien souvent diffrentes chelles de description. Lanalyse spatiale consiste alors utiliser des oprations permettant de passer dune chelle une autre sans provoquer derreur dans la conception de ces nouveaux objets. Par exemple, le passage dune chelle une autre peut seffectuer en runissant des units spatiales de niveau infrieur. On parlera alors dun processus dagrgation. Mais les agrgations possibles sont trs nombreuses. Une grande partie du travail danalyse spatiale consiste explorer quels sont les regroupements dunits de base qui sont les plus pertinents, selon diffrents types de critres, pour produire des dcoupages intressants une autre chelle, gnralement pour mettre en vidence des structures spatiales impossible voir partir des donnes non agrges. Cette tape ne modifie pas seulement la nature spatiale des objets gographiques, elle en modifie galement la description et les attributs. Lanalyse spatiale va donc bien plus loin quune simple mise en relation dobjets sur un critre de localisation. Elle permet de dfinir des oprations permettant dtendre la jointure spatiale en fonction de la validit smantique des objets. Dans un processus de changement dchelle, la dfinition de nouveaux objets est le rsultat dune abstraction qui repose sur un processus dlimination de dtails , appel gnralisation [RIM 90] [PUM 97]. Ainsi, un ensemble dobjets htrognes un niveau dagrgation gographique peut apparatre homogne un niveau suprieur, parce que lon oublie volontairement lhtrognit interne pour ne retenir que les traits qui permettent la comparaison avec dautres units spatiales situes au mme niveau dobservation. La mme remarque sapplique lorsquon agrge des units spatiales de base en fonction non plus de leur ressemblance pour un attribut ou un ensemble dattributs, mais daprs les relations quelles entretiennent les unes avec les autres.

270

Chapitre 8

Lopration dagrgation est toujours dlicate et il est ncessaire dobserver des rgles prcises pour contrler la perte dinformation lors de la gnralisation, surtout lorsquil ny a pas hirarchie spatiale des dcoupages. La distribution spatiale dun phnomne est un critre important dans de nombreux cas [PUM 97]. Ces rgles nous ont amen dvelopper plusieurs mthodes dagrgation spatiales dans le systme SAVANE. La dsagrgation le passage un dcoupage plus fin - pose encore plus de problmes de validit, et sapparente dans de nombreux cas un problme dinterpolation. En effet, elle est souvent employe pour remdier une carence dinformation : on va alors chercher de linformation un autre niveau de validit (plus faible), en faisant implicitement une hypothse duniformit de la rpartition spatiale de cette information. Cette hypothse trs forte ne doit pas tre oublie lors de lutilisation du rsultat obtenu. La plupart des procdures dagrgation ou de dsagrgation sont dangereuses lorsquelles sapparentent des interpolations : pour un point de lespace, la donne nest plus quapproche et sa validit dpend de lopration qui a t effectue et des hypothses sous-jacentes. Nous sommes bien face la dfinition de nouveaux objets, avec leur validit spatiale propre, et le rsultat dune opration de ce type doit bien tre considr comme une nouvelle modlisation de la ralit : lopration employe fait partie du processus de dfinition du modle. Loubli de cette rgle peut amener de graves erreurs dans lutilisation ultrieure des objets ainsi construits. 8.2.2. Distribution spatiale dun phnomne O ? Comment ? Pourquoi l et pas ailleurs ? Ces questions, comme nous lavons dj soulign au chapitre 3, sont au cur de nombreuses questions gographiques [LAU 93]. La rpartition dun phnomne est une question essentielle dans lanalyse ds que lon dcide de prendre en compte la localisation de ce phnomne. On sintresse la rpartition de lensemble form par tous les objets : la structure spatiale propre de chaque objet nimporte plus et peut tre ramene un point, car on cherche tudier lagencement des objets les uns par rapport aux autres. On cherche caractriser larrangement gographique des lieux en explicitant les principes de leur distribution, indpendamment dun attribut descriptif particulier : les mthodes prsentes ici ne prennent en compte que la localisation des objets tudis (qui peuvent bien sr avoir t slectionns auparavant sur un caractre descriptif). La simple cartographie de la distribution dobjets par leur centrode donne dj une vision synthtique dun phnomne. Pour aller plus loin, on peut dfinir le centre dun ensemble de point, point remarquable le plus reprsentatif possible de

Analyser 271 lensemble (point mdian, centre de gravit). Bien sr, cette reprsentation, image de la mdiane ou de la moyenne en deux dimensions, ne rend pas compte de lhtrognit de la situation. On peut utiliser pour cela une mesure de la dispersion. Cette dispersion peut tre value par rapport un point remarquable ou calcule comme une mesure gnralise des carts entre lensemble des points. On peut galement classer le territoire, et compter le nombre dobjets par classe, par analogie un histogramme sur une variable de dimension 1. Les classes seront habituellement des objets de surface gale et de gomtrie simple, telle des mailles carres. Et lon calculera plutt des densits que des effectifs, pour avoir des valeurs qui ne dpendent pas directement de la taille des mailles. Bien sr, on peut galement utiliser une classification de lespace en utilisant un dcoupage dj existant, mais ce dcoupage peut introduire un biais dans ltude de la dispersion, car il ne faudrait pas que le dcoupage utilis soit corrl la distribution que lon cherche tudier. Enfin, la distribution spatiale peut tre galement caractrise par la forme du semis de points, correspondant larrangement et lespacement entre les points. Cette distribution peut tre compare quelques forme de rfrences : distribution spatiale rgulire, concentre, alatoire. On peut pour cela utiliser de nouveau des mailles et des calculs de dispersion comme les courbes de concentration ou lindice de Theil, ou encore comparer la distribution avec une distribution spatiale de rfrence dont la loi de formation est connue. 8.2.3. Homognit spatiale, relations de voisinage, regroupement Dans le paragraphe prcdent, nous avons vu quelques mthodes danalyse concernant uniquement la position des objets, indpendamment de la valeur dun attribut de ces objets. Mais bien souvent la valeur dun attribut est corrle la position relative des objets entre eux ou la forme du semis de point. Il est donc naturel de chercher dfinir des indices de ressemblance provenant la fois de la position relative des objets dans lespace et de la valeur dun caractre de ces objets. Lide de voisinage, de continuit, de connexit est sous-jacente ces indices refltant lhomognit spatiale dun ensemble dobjets. Lanalyse spatiale sintresse donc directement la dfinition ou la dtermination densembles homognes partir dune collection dobjets lmentaires. La notion dhomognit est toujours relative une srie dattributs et une certaine chelle dobservation. Les mesures dhomognit, le plus souvent exprimes sous forme dindice, sont nombreuses. La statistique classique fournit dj un certain nombre doutils permettant de mesurer le degr dhomognit dune collection dobjets, mais sans toutefois prendre en compte les relations de voisinage entre les objets.

272

Chapitre 8

Mais on sait que bien souvent il y a interaction spatiale entre les objets dune collection : cest le cas lorsque la rpartition spatiale des objets par rapport un attribut descriptif nest pas alatoire. On se doit alors dintgrer la localisation dans ltude statistique du phnomne, sous peine, par exemple, de biaiser la dfinition dun chantillon dans lequel on utiliserait ultrieurement la localisation dans le processus danalyse. La gostatistique fournit des outils permettant de vrifier lexistence dune corrlation entre voisinage et variation dun attribut descriptif. Si lon veut introduire le voisinage dans le calcul de la ressemblance, il faut utiliser ces outils, et notamment lautocorrlation spatiale qui permet de mesurer lintensit de la relation entre la proximit des objets et leur degr de ressemblance. Enfin, le regroupement dobjets suivant ces critres nobit plus seulement une classification descriptive, mais introduit le voisinage et la continuit pour aboutir la dfinition de nouvelles partitions de lespace minimisant certains critres. En particulier, lanalyse de la variance permet dobtenir une agrgation dobjets gographiques qui cre le plus ou le moins de diffrence entre les classes ainsi dfinies. 8.3. SAVANE : exploration des donnes et statistique Lutilisateur qui souhaite analyser un ensemble dobjets gographiques commencera sans aucun doute par reprsenter graphiquement lensemble des objets pour visualiser leur rpartition spatiale, et il poursuivra son exploration par lanalyse statistique des attributs lis ces objets, et la poursuivra en essayant de dterminer les relations entre rpartition spatiale et variation descriptive. La dmarche exploratoire peut ainsi se dcliner : - analyse de la rpartition spatiale dun ensemble dobjets ; - analyse de la rpartition statistique dun ou plusieurs attributs descriptifs dun ensemble dobjet ; - mise en vidence et analyse des relations entre les variations de la localisation et variations dun ou plusieurs attributs descriptifs. Un systme dinformation gographique tourn vers lanalyse devra donc comporter la fois des fonctions de reprsentation graphique et de cartographie et des fonctions statistiques permettant dexplorer les attributs des objets [BEG 94]. Cest le cas du systme SAVANE, et nous exposerons en dtail au chapitre suivant les principes de la reprsentation cartographique du module dexploitation. Lexploration graphique de la rpartition des objets est trs simple, car on utilise en gnral des paramtres cartographiques proposs par dfaut par le systme. Lexploration des attributs peut quant elle porter sur des objets individuels ou sur

Analyser 273 des collections dobjets. Lexploration individuelle utilise des procdures lmentaires dinterrogation sur une valeur dattribut descriptif ou sur un point de lespace. Lexploration dune collection dobjet fait appel aux procdures statistiques classiques et celles, moins rpandues, de la gostatistique. 8.3.1. Lexploration individuelle Lexploration individuelle consiste rechercher les valeurs des attributs dun objet, que lon peut choisir graphiquement sur lcran (fig. 8.1) ou en indiquant la valeur de lun de ses attributs. Dans le premier cas, un seul objet est slectionn dans la relation. Il est retrouv grce sa localisation. On utilise pour cela les procdures de distance un point, une ligne, ou le test dinclusion dun point dans une zone.

fig. 8.1 : interrogation sur cran des objets prsents dans le cadre gographique

Dans le second cas, plusieurs objets peuvent correspondre une valeur dun attribut. Le rsultat est donn dans une liste, pour les attribut descriptifs, et dessin sur une carte, pour lattribut graphique lorsque la relation est localise.

274

Chapitre 8

8.3.2. Lexploration statistique Lexploration statistique des attributs des objets dune base de donnes est une opration fondamentale dans un processus danalyse et dinterprtation. Cette exploration fait appel la statistique univarie (moments dun attribut numrique) ou multivarie (corrlations, rgressions, analyse factorielle, etc.). Si lon peut facilement avoir accs des logiciels statistiques extrieurs au SIG, il nous a sembl nanmoins ncessaire de dvelopper quelques fonctions lmentaires qui permettent rapidement de visualiser la rpartition statistique dun phnomne. Nous avons donc dvelopp un module dexploration statistique permettant de calculer les moments statistiques dun attribut, de calculer et visualiser un histogramme, de calculer un indice de corrlation, de visualiser une droite de rgression linaire ou un nuage de points suivant deux attributs (fig. 8.2). Toutes ces oprations sont appliques aux objets dune mme relation.

fig. 8.2 : statistiques univaries sur un attribut dune collection dobjets

Enfin, le calcul du rsidu par rapport une distribution standard (linaire, exponentielle, normale, de Poisson, etc.) peut tre ajout au schma comme un nouvel attribut sur les objets, selon le principe de cration de nouveaux attributs que nous allons exposer au paragraphe suivant. La cartographie du rsultat permet de mettre en avant la rpartition gographique des carts une distribution donne (fig. 8.3).

Analyser 275

fig. 8.3 : exemple de reprsentation des carts par rapport une distribution donne

8.4. SAVANE et mthodes sur les attributs descriptifs Nous allons prsenter dans ce paragraphe de nouvelles oprations concernant les attributs descriptifs dune relation. Ces oprations sont la base des oprations dexploration et danalyse des donnes. Elles permettent pour la plupart de modifier temporairement le schma des relations en ajoutant de nouveaux attributs. Combines aux oprations de lalgbre relationnelle tendue, elles sont une tape importante dans la mise en uvre de nombreuses oprations danalyse spatiale. Lanalyse spatiale ne seffectue pas en utilisant des procdures toutes faites : lutilisateur devra construire lui-mme sa dmarche en utilisant les nombreuses oprations lmentaires qui sont sa disposition et qui sinspirent pour la plupart des principes que nous avons rappels lors de lintroduction : gnralisation, agrgation, changement dchelle, classification. 8.4.1. Le principe de la cration de nouveaux attributs descriptifs La cration de nouveaux attributs partir des attributs descriptifs dune relation est une opration fondamentale dans un processus de requte exploratoire. Cest lopration de modlisation la plus lmentaire : on peut ainsi modifier temporairement le schma dune relation en introduisant de nouveaux attributs calculs partir des attributs initiaux. Le module SAVANE permet la cration de nouveaux attributs par calcul numrique, par calcul logique, par classification, par

276

Chapitre 8

agrgation, par combinaison, par comparaison, par tri. Toutes les oprations que nous prsenterons dans ce paragraphe concernent les attributs dune seule collection dobjet : les calculs ne font jamais intervenir de mise en relation dobjets de plusieurs relations. Elles peuvent sappliquer tous les types de relation, puisque la localisation nintervient pas dans ces calculs. Nous verrons dans le paragraphe suivant des oprations qui crent de nouveaux attributs en faisant intervenir la localisation des objets, et qui dpendent donc du type des relations mises en jeu. Mais le principe de la cration de nouveaux attributs reste le mme. Tous les attributs crs lors dune requte sont temporaires : la base de donnes nest jamais modifie dans SAVANE. La relation temporaire est une copie de la relation permanente et se trouve physiquement dans le rpertoire du cadre correspondant la requte, qui lui-mme se trouve dans le rpertoire de la carte. La gestion des tats temporaires permet plusieurs utilisateurs diffrents de travailler sur la mme base, sans risque dinterfrence, et la base garde son intgrit. Si lon veut intgrer de faon dfinitive le rsultat dun calcul entre attributs, il faut exporter cet attribut pour lintgrer avec SAVATECA dans une opration dadministration. Il est bien sr prfrable de conserver le calcul sous forme de macro-commande ou de mthode, car on peut alors tre sr que lexcution de la macro-commande sera base sur des valeurs actualises des attributs. Pour grer la vue externe du schma, il faut connatre la place dans le schma interne de chaque attribut du schma externe. Cette place est conserve dans la variable m_iNumero membre de la classe CAttribut. Lorsquun nouvel attribut est cr dans une relation, celle-ci devient temporaire si elle ne ltait pas dj : la relation rsultante ne contient plus que les objets de la fentre dtude et, pour chaque objet, elle ne contient plus que les attributs permanents prsents dans la vue externe, plus les attributs temporaires. La classe CRelation contient une variable permettant de connatre le nombre dattribut de la relation dans son tat initial (m_iNb0) et dans son tat temporaire (m_iNba). Lors de lcriture dune relation temporaire, les attributs permanents sont rcrits dans lordre de la vue externe, les attributs temporaires la suite. La variable m_iNumero devient alors toujours gale la place de la variable dans le schma externe. Lors de laccs un attribut dune relation non modifie, il faut dabord rechercher le numro interne de lattribut, partir de son numro externe iNoatt qui provient du dialogue avec lutilisateur :
iNovar=pSchema->m_pRelations[iNoRel]->m_pAttributs[iNoAttr]->m_iNumero ; val=v[iNovar] ;

La procdure NouvelAttribut() de la classe CSchema regroupe lensemble des oprations ncessaires la cration de lattribut temporaire dans le schma de la base de donnes (A.2.1.2.).

Analyser 277

8.4.2. Calculs numriques et logiques On peut crer un attribut par calcul numrique ou logique entre les attributs dune mme relation. Il suffit dindiquer la formule de calcul, comme dans le cas dune restriction par condition de slection (fig. 8.4). Lattribut cr contient pour chaque objet de la relation la valeur rsultant du calcul. La vrification de la formule et le calcul pour chaque objet utilise la classe CCalculateur dont nous avons vu le schma au chapitre 5 (A.2.1.5.). Le calcul est bas sur le parcours dun arbre (fils gauche-frre droit) dexpressions (binaires) et de termes (unaires), reprsentant la formule de calcul. Lexpression peut contenir des oprateurs numriques ou des oprateurs logiques.

fig. 8.4 : le dialogue de cration dattribut par calcul numrique ou logique

Pour une relation non mosaque, le code de la procdure permettant de crer un nouvel attribut par calcul est donn dans lannexe A.2.5.3. Pour une relation de type mosaque, le principe est le mme mais le code est plus complexe, car les valeurs dattributs doivent tre lues dans des fichiers diffrents, et le rsultat du calcul peut ne pas correspondre au type de lattribut crer, qui est choisi par lutilisateur. Par exemple, une somme de deux attributs cods sur un octet

278

Chapitre 8

(correspond des valeurs entires de 0 255) peut dpasser 255. Si lattribut crer doit tre cod sur 8 ou 16 bits, il faut donc galement choisir une mthode de rtalement des valeurs (fig. 8.5 et 8.6).

fig. 8.5 : le dialogue de cration dun attribut dune mosaque

fig. 8.6 : le calcul dun indice de vgtation (NDVI) partir des canaux 3 et 4 dune image Thematic Mapper

Analyser 279 8.4.3. Classifications et mthodes de discrtisation Lopration de classification permet de transformer un attribut quantitatif en un attribut qualitatif, cest--dire prenant ses valeurs dans un ensemble fini. Cette opration est trs importante car la vision de la distribution de lattribut est synthtique, et il est facile de reprsenter un nombre fini de valeurs sur une carte. La classification est un processus trs classique en analyse de donnes. La mise en uvre de la classification dun attribut ne pose pas de problmes particuliers. Lattribut cr est nominal : ses modalits, qui ont t entres par lutilisateur du systme, sont conserves dans un fichier temporaire, nomm ftvaleurs, qui a la mme structure que le fichier fpvaleurs, qui lui contient lensemble des valeurs des attributs nominaux permanents. Le fichier ftvaleurs est propre une requte, et donc un cadre dune carte : il se trouve physiquement dans le rpertoire du cadre de la carte. Le type dun attribut est conserv dans la variable membre m_iType de la classe CAttribut. Il est cod 1 pour les attributs nominaux permanents, 5 pour les attributs nominaux temporaires. En consultant cette variable, le systme sait dans quel fichier (fpvaleurs ou ftvaleurs) il doit aller chercher les modalits de lattribut. Nombreuses sont les mthodes de dfinition des classes. La classification peut tre arbitraire (des intervalles donns, par exemple), mais bien souvent lutilisateur choisira la mthode de dfinition des classes en fonction de la rpartition des valeurs de lattribut. Dans SAVANE, nous avons implment les procdures les plus courantes utilises pour discrtiser une variable numrique (fig. 8.7) :

fig. 8.7 : le menu de classification de SAVANE

Par exemple, pour la classification par quantile (classification par intervalles avec des classes deffectifs gaux), la dtermination des bornes des classes impose le tri des valeurs de lattribut. On doit donc lire la valeur de tous les objets de la relation, pour lattribut classer, puis trier ces valeurs pour dterminer les bornes des classes. Pour les relations de type mosaque, le nombre dobjet peut tre trs

280

Chapitre 8

grand, et le tri serait alors trop long pour une procdure interactive. On regroupe donc les valeurs en effectuant une premire discrtisation arbitraire, puis en calculant le nombre dobjets pour chaque classe de cette premire discrtisation. Dans tous les cas, le calcul des classes est automatique et seffectue lors du dialogue avec lutilisateur du systme (fig. 8.8) :

fig. 8.8 : dialogue de dfinition des classes par quantiles

Le code de la procdure permettant de lire et de trier les valeurs dun attribut dune relation non mosaque peut tre consult dans A.2.5.4. 8.4.4. Agrgations descriptives Lagrgation descriptive concernent le regroupement des valeurs dun attribut par rapport un autre attribut, toujours qualitatif nominal, et servant de cl dagrgation. Elle permet de modifier le niveau de perception en changeant, en quelque sorte, de cl descriptive. Par exemple, les donnes dun recensement, disponibles au niveau de la commune, peuvent tre agrgs au niveau du dpartement. Bien sr, lagrgation nest possible que si lon dispose dun attribut indiquant pour chaque commune le nom du dpartement auquel elle appartient : il sagit dune agrgation descriptive, o les deux attributs utiliss sont descriptifs. Cette opration ne fait pas intervenir la localisation des objets, mais seulement la valeur des attributs descriptifs choisis. Nous verrons plus loin les go-agrgations, qui, elles, utilisent la localisation comme cl dagrgation, et qui ne sont valables quentre relations localises.

Analyser 281 Notons quil y a dpendance fonctionnelle entre lattribut choisi comme cl dagrgation et lattribut cr : la relation rsultante nest plus en deuxime forme normale. Si cette situation ne doit pas exister dans une base de donnes bien constitue, ici nous sommes dans un tat temporaire au milieu dune requte, et cette dpendance est tout fait admise. Le nouvel attribut contenant le rsultat de lopration peut tre cr dans la mme relation, ou dans tout autre relation comportant un attribut nominal ayant le mme ensemble de modalits que la cl dagrgation. Dans lexemple prcdent, si lon dispose dans la base dune relation dpartement , il est possible de crer le nouvel attribut dans cette relation. Si celle-ci est localise, il sera alors possible dutiliser sa localisation soit pour dessiner le rsultat, soit pour poursuivre lanalyse en faisant, si ncessaire, intervenir la localisation des dpartements. Plusieurs oprations sont disponibles pour effectuer lagrgation et crer le nouvel attribut (fig. 8.9). Si lattribut agrger est numrique, on peut effectuer une somme, une moyenne, un cart-type, une variance, un minimum, un maximum. Si lattribut est nominal, on peut calculer la frquence, relative ou absolue, dune modalit particulire. Le choix de lopration dpend bien sr de la nature smantique de lattribut (par exemple, on ne peut faire de somme que sil sagit deffectifs, et non de taux mais le choix de lopration est laiss lutilisateur, car il ny a pas de renseignement smantique de ce type dans la base de donnes).

fig. 8.9 : le choix de lopration dagrgation descriptive

Notons enfin que si la cl dagrgation est une cl de la relation, lopration dagrgation na pas dintrt. Et dans ce cas, si le rsultat doit tre cr dans une

282

Chapitre 8

autre relation, lopration dagrgation est identique lopration dunion que nous avons vue au chapitre 5. 8.4.5. Comparaison dattributs Il est souvent utile de pouvoir crer un nouvel attribut par comparaison dattributs numriques dune mme relation. Cette opration cre deux nouveaux attributs : lun est nominal, et correspond au nom de lattribut qui correspond au rang choisi pour la comparaison, lautre est numrique et contient la valeur de cet attribut. Cette opration permet de rpondre aux questions du type : dans chaque commune, quel est le parti politique arriv en seconde position, et combien dlecteurs sont-ils concerns ? Quelle est lessence la moins reprsente dans ces zones forestires, et combien darbres sont-ils concerns ? 8.4.6. Combinaison dattributs La combinaison dattributs concerne les attributs nominaux. Elle permet de combiner deux attributs nominaux en crant un troisime attribut, nominal lui aussi, qui combine les valeurs des deux autres. 8.4.7. Ordre La cration par ordre perme de crer un nouvel attribut numrique partir dun attribut numrique de la relation. Le nouvel attribut donne le rang (croissant ou dcroissant) de lobjet dans lensemble des objets de la relation par rapport aux valeurs de lattribut choisi. Il permet par exemple de classer les entreprises par rapport limpt sur les bnfices. On pourrait par la suite facilement calculer le pourcentage que reprsente les vingt premires entreprises dans limpt national. 8.5. Lutilisation de la localisation pour la cration de nouveaux attributs descriptifs Les oprations relationnelles tendues la localisation permettent dj de rpondre un certain nombre de requtes en utilisant la localisation de certains objets. Ainsi, la restriction spatiale dune relation sur un masque cr partir des objets dune autre relation permet de rpondre toutes les interrogations du type o ? . La jointure spatiale permet de mettre en relation des objets de deux relations en utilisant leur localisation, sur un critre de distance. Mais ces oprations sont avant tout des oprations de gestion, visant utiliser le principe de la dcomposition relationnelle pour grer au mieux des collections dobjet. Elles ne

Analyser 283 crent jamais de nouveau attributs. La go-jointure a en particulier le dfaut majeur de faire perdre la localisation du rsultat lorsque lon nutilise pas un critre d(O1,O2)=0. Ces oprations ne permettent pas non plus de mettre en uvre le transfert dchelle. Nous avons donc dvelopp un certain nombre doprations pour rpondre ces questions. Ces mthodes, pour la plupart, sont spcifiques au type des relations et peuvent tre considres comme des mthodes sur les types gnraux que sont les zones, les lignes, les points, les pixels. Les oprations que nous prsentons dans ce paragraphe permettent de crer de nouveaux attributs descriptifs, mais elles ne modifient pas la gomtrie des objets ni ne crent de nouveaux objets ou de nouvelles relations. Nous verrons au paragraphe 6 de ce chapitre les oprations permettant la modification dobjets ou la cration de nouveaux objets partir des relations existantes. 8.5.1. Surface, primtre, coordonnes La surface et le primtre sont typiquement des mthodes pouvant tre appliques uniquement au type zone. Le calcul du primtre dune zone utilise les arcs frontire de la zone et la distance euclidienne dans le plan de projection gographique. Il ne pose aucune difficult. Le rsultat est toujours exprim en mtres. Le calcul de la surface dune zone utilise galement les arcs frontire de la zone. La surface est calcule dans le plan de projection, sans tenir compte de laltitude des points (cest une surface projete). Elle peut tre exprime en mtres carrs, en hectares, en kilomtres carrs. Nous avons mis en oeuvre deux mthodes de calcul, une mthode par rasterisation et une mthode par calcul direct : (1) La mthode par rasterisation calcule pour chaque zone une image raster binaire de la zone dans la plus petite fentre contenant la zone. La rasterisation utilise une rsolution fixe de 1600*1600 pixels. On compte ensuite le nombre de pixels appartenant la zone, et lon approche ainsi sa surface puisque lon connat la taille du pixel de la rasterisation. Cette mthode est rapide mais elle introduit une incertitude sur le calcul due la dfinition de la rasterisation. (2) La seconde mthode calcule la surface directement partir des arcs. Cette mthode rend ncessaire le chanage des arcs en polygones ferms et la dtection des polygones inclus. Le contour des polygones doit tre orient. La surface dun polygone dont le contour est reprsent par les points de coordonnes (x0,y0,x1,y1,..,xn,yn), dans le sens trigonomtrique, est donn par la formule : S=1/2

i =1

(xiyi+1 yixi+1)

(le point xn+1,yn+1 correspond au point x0,y0)

284

Chapitre 8

La surface dun polygone inclus doit tre soustraite ou ajoute suivant le degr dinclusion. La mthode utilise pour chaner les arcs dune zone en polygones et calculer le degr dinclusion dun polygone est identique celle utilise pour exporter des zones au format ShapeFile (chapitre 3, A.2.2.6.). Dans SAVANE, les coordonnes des objets napparaissent pas directement dans le schma des attributs : la localisation est implicite au type et ne peut tre utilise a priori quau travers des oprations de gestion et danalyse spatiale. Mais il peut tre utile de faire apparatre explicitement les coordonnes du centrode dans le schma des attributs, notamment lorsque lon dsire introduire la localisation dans une opration statistique multivarie ou pour exporter cette localisation vers un autre systme. Une opration permet donc de crer deux attributs, lun pour labscisse, lautre pour lordonne du centrode. Les coordonnes sont alors exprimes dans le plan de projection gographique utilis dans le cadre. 8.5.2. Orientation et pente Le calcul dorientation peut tre appliqu des objets de type ligne (fig. 8.10). Ce nest une valeur exacte que dans le cas de lignes reprsentes par un segment de deux points. Sinon, lorientation correspond la moyenne de lorientation des segments pondre par la longueur de chaque segment.

fig. 8.10 : dessin et histogramme de la rpartition de lorientation de failles gologiques, calcule partir de la gomtrie des objets

Analyser 285 Le calcul de la pente utilise une relation de type mosaque, contenant un attribut correspondant laltitude (souvent un modle numrique de terrain cr partir de courbes de niveaux). Le systme cherche par go-jointure laltitude des deux extrmits de chaque ligne pour calculer la pente de la ligne. Comme pour lorientation, la valeur calcule ne reprsente la pente relle que dans le cas de lignes reprsentes par un segment de deux points 8.5.3. Distance un point, une relation, un masque Cette opration calcule la distance de chaque objet dune relation un point, un masque, ou lobjet le plus proche dune autre relation localise. Par distance, on entend la plus courte distance euclidienne de lobjet au point donn (choisi sur lcran ou par ses coordonnes), au masque, ou lobjet le plus proche dans lautre relation. On utilise pour calculer la distance dun point un arc la procdure que nous avons prsente au chapitre 7. 8.5.4. Go-agrgations Les go-agrgations permettent de mettre en uvre des oprations de transfert dchelle. Elles correspondent une go-jointure entre deux relations suivie dune opration dagrgation descriptive sur la cl gographique de la relation rceptrice. Elles utilisent donc la localisation des objets pour les mettre en relation. On utilisera la terminologie metteur et rcepteur pour diffrencier la relation qui met les objets et la valeur dun de ses attributs, et la relation qui reoit le nouvel attribut cr par agrgation. La relation rceptrice est donc celle qui gnralise le phnomne, chaque objet de la relation rceptrice tant cens recevoir plusieurs objets de la relation mettrice. On calcule la valeur du nouvel attribut de lobjet rcepteur partir des valeurs de ces objets, par agrgation descriptive. Grce cette agrgation descriptive, le rsultat dune go-agrgation conserve la localisation des objets rcepteurs. Lopration dagrgation descriptive est classique : somme, moyenne, cart-type, variance, minimum, maximum, dans le cas dun attribut numrique, et frquence relative ou absolue dans le cas qualitatif. 8.5.4.1. La go-agrgation gomtrique par distance Lopration de go-agrgation par distance cherche, pour tous les objets de la relation rceptrice, quels sont les objets de la relation mettrice qui doivent lui tre agrgs. Les relations mettrice et rceptrice doivent tre localises, mais peuvent tre de nimporte quel type (zone, ligne, point, pixel). On peut galement utiliser une distance autour des objets rcepteurs, pour ne pas limiter la jointure une opration dinclusion des objets metteurs aux objets rcepteurs. Lopration reste nanmoins ambigu dans certains cas.

286

Chapitre 8

(1) Lorsque la relation mettrice est de type point, il ny a pas dambigut : pour chaque objet rcepteur, les objets metteurs joindre sont ceux dont la distance du point lobjet rcepteur est infrieure la distance dagrgation. Lopration utilise le calcul de la distance dun point un point (objet rcepteur de type point ou pixel), un arc (objet rcepteur de type ligne), ou un ensemble darcs sil ny a pas inclusion (objet rcepteur de type zone) (fig. 8.11).

fig. 8.11 : exemple de go-agrgation de points dans des zones : calcul de laltitude moyenne par lot partir de points cots (moyenne, d < 100 m)

(2) Lorsque la relation mettrice est de type ligne, il peut y avoir ambigut : pour chaque objet rcepteur, les objets metteurs joindre sont ceux dont la distance de larc lobjet rcepteur est infrieure la distance dagrgation. Lopration utilise le calcul de la distance dun arc un point (objet rcepteur de type point ou pixel), un arc (objet rcepteur de type ligne), ou un ensemble darcs sil ny a pas intersection (objet rcepteur de type zone). Le critre de jointure utilise donc dans tous les cas la distance dun arc un objet, cest--dire la distance minimale de tous les points de larc cet objet : il suffit quun point de larc soit proche de lobjet rcepteur pour quil soit pris en compte dans lagrgation. (3) Lorsque la relation mettrice est de type zone, il peut galement y avoir ambigut : pour chaque objet rcepteur, les objets metteurs joindre sont ceux dont la distance de la zone lobjet rcepteur est infrieure la distance dagrgation. Cest le cas lorsque lobjet rcepteur est inclus ou intersecte la zone,

Analyser 287 ou que la distance entre lobjet rcepteur et les arcs formant le contour de la zone mettrice est infrieure la distance dagrgation. Dans tous les cas, si un objet metteur est proche de plusieurs objets rcepteurs, il est mis en relation avec tous ces objets. Si lagrgation est une somme et porte sur un attribut numrique reprsentant un effectif, agrger plusieurs fois lobjet metteur dans des objets rcepteurs diffrents revient dupliquer la valeur. Pour viter cette erreur, il est possible de choisir une option permettant de nagrger lobjet metteur que dans lobjet rcepteur le plus proche (fig. 8.12).

fig. 8.12 : la page finale du dialogue de go-agrgation par distance

Lopration de go-agrgation par distance doit tre utilise avec prudence, comme nous lavions dj signal au dbut de ce chapitre. Sa validit dpend de la prcision smantique et graphique de chaque relation, et dpend du type des objets et des ambiguts qui sont cres lorsque les dcoupages ne sont pas hirarchiques.

288

Chapitre 8

fig. 8.13 : exemple de go-agrgation de zone zone sans ambiguit : agrgation de la population dlots aux quartiers (somme, d=0)

Elle ne doit tre employe en principe que pour rsoudre des oprations de transfert dchelle, et donc lorsque la prcision de la relation mettrice et suprieure la prcision de la relation rceptrice, ou lorsquil y a hirarchie gographique des objets (fig. 8.13). Notons enfin que lopration dagrgation par distance utilise la distance entre objets metteurs et rcepteurs pour savoir sils doivent tre mis en relation, mais nutilise pas cette distance dans le calcul dagrgation descriptive qui suit. Par exemple, lopration de go-agrgation entre deux relations de type pixel correspond en quelque sorte un r-chantillonage, dans lequel seules les options de plus proche voisin ou de moyenne seraient disponibles. Lutilisation de la distance dans le calcul est employe dans dautres oprations que nous verrons plus loin : pour un vritable r-chantillonage entre relations de type pixel, ou pour la cration de nouveaux objets par interpolation. 8.5.4.2. Go-agrgation par surface dun masque Ce type dagrgation cherche rsoudre lambigut de la go-agrgation zonezone lorsquil ny pas hirarchie des dcoupages, et lorsque lon cherche rendre compte de la distribution dun caractre (nominal) dans un autre dcoupage. Cest bien souvent le cas lorsque les deux thmes ne sont pas lis mais dune prcision quivalente. On a alors deux collections dobjets de type zone avec de multiples intersections entre les objets des deux relations.

Analyser 289 Lopration permet de calculer pour chaque zone rceptrice le pourcentage de la surface de la zone occupe par un masque. Si ce masque a t cr partir des objets dune autre relation, aprs restriction sur un caractre nominal, le rsultat correspond pour chaque zone rceptrice au pourcentage de la surface occupe par le caractre (fig. 8.14).

fig. 8.14 : un masque (cultures et paturages) et le pourcentage de la surface dans un dcoupage (cantons)

8.5.4.3. Go-agrgation par valeur pondre par la surface Toujours dans le cas dune go-agrgation zone-zone lorsque les dcoupages ne sont pas hirarchiques, mais lorsque lon veut rendre compte dun attribut numrique de lun des dcoupages dans lautre, il peut tre intressant de pondrer par la surface occupe par chaque valeur dans la zone rceptrice. On fait ainsi une hypothse sur la rpartition linaire des valeurs en fonction de la surface occupe. On nutilise pas de masque dans cette opration qui effectue directement le calcul du nouvel attribut en faisant par zone la moyenne des valeurs pondre par la surface occupe (fig. 8.15).

290

Chapitre 8

fig. 8.15 : calcul de la moyenne dun indice radiomtrique (TM, canal 1) dans des zones prdfinies (quartiers) par go-agrgation pondre par la surface

8.5.5. Appartenance Lappartenance est lopration inverse de lagrgation. Elle consiste aller chercher dans une relation mettrice lobjet qui contient le centrode de lobjet rcepteur. La valeur de lattribut mettre est alors affecte lobjet rcepteur. La ralisation informatique dans SAVANE est soit vectorielle (test de linclusion ou de la distance du centrode lobjet metteur en utilisant les arcs), soit matricielle (on utilise alors la reprsentation matricielle de la localisation : lexcution est plus rapide mais la prcision dpend de la taille du pixel de rasterisation et donc de la taille de la fentre dtude). Lopration utilise le centrode de lmetteur et peut donc tre ambigu, sauf sil y a inclusion des objets rcepteurs dans les objets metteurs. Elle ne devrait tre utilise que dans ce cas. 8.5.6. Goagrgation sur les pixels : le r-chantillonage Lagencement des objets dune relation de type mosaque permet de dfinir un certain nombre doprations propre ce type de relation. Par exemple, lopration de goagrgation par distance peut tre affine en utilisant les mthodes de rchantillonage que nous avons vues au chapitre 6. La relation rceptrice est de type zone ou mosaque, et la valeur dune zone est calcule partir des pixels metteurs par voisinage plutt que par distance ou appartenance. On peut ainsi utiliser une fonction bilinaire ou bicubique pour calculer la valeur dobjet rcepteur.

Analyser 291 8.5.7. Oprations sur les modles numriques : orientation, pente, coulements Un modle numrique de terrain est un attribut dune relation de type mosaque reprsentant une altitude. Cet attribut est souvent obtenu par interpolation, comme nous le verrons dans le paragraphe suivant. De nombreuses oprations sont spcifiques ce type driv du type mosaque : pente, orientation, coulements, calculs hydrologiques, calculs de volume ou de visibilit. Nous sommes encore dans le domaine de lanalyse spatiale, mais spcialise ici un domaine particulier. Nous pouvons ici appliquer des mthodes correspondant au contenu smantique de lattribut, alors que nous navions vu jusqu prsent que des oprations valables quel que soit le contenu smantique de lattribut. 8.5.7.1. Pente et orientation Pour chaque pixel, la pente ou lorientation est calcule sur les voisins : cest langle form par le vecteur unitaire normal la surface et le plan z=0 (pente) ou x=0 (orientation). En chaque point, on approche la surface en utilisant le plan de rgression le plus proche des quatre voisins du point pi,j (pi-1,j-1,pi+1,j-1,pi+1,j-1,pi+1,j+1). Lopration cre un nouvel attribut de type entier 16 bits : les pentes et orientation sont conserves en minutes darc. 8.5.7.2. Dautres indices en gomorphologie et hydrologie De nombreux indices peuvent ainsi tre calculs partir de lattribut altitude pour crer de nouveaux attributs : convexit verticale, convexit horizontale, convexit transversale, encaissement, modle de drainage, bassins-versants, longueurs de drainage, surfaces draines, distances lexutoire, etc. Tous ces nouveaux attributs temporaires peuvent bien sr tre utiliss dans la suite de la requte (fig. 8.16).

292

Chapitre 8

fig. 8.16 : pente et orientation calcules partir dun modle numrique de terrain

8.6. La cration de relations temporaires Jusqu prsent, nous avons vu des oprations dexploration ou de cration de nouveaux attributs partir de relations existantes. Aucune de ces oprations ne crent de nouveaux objets. Mais bien souvent, limplantation spatiale des objets dune collection ne permet pas davancer dans lanalyse, et il faut modifier limplantation spatiale en crant de nouveaux objets, soit de toute pice, soit partir des objets dune collection existante. Nous allons voir dans ce paragraphe les nombreuses oprations permettant la cration de nouvelles collections dobjets. Ces oprations sinscrivent toujours dans le cadre de lanalyse spatiale, mais elles vont plus loin que la simple rponse une question pose. Elles sont fondamentales pour

Analyser 293 assurer un usage efficace de lextension du modle relationnel, car elles permettent de saffranchir de la barrire impose par le type de limplantation spatiale. En effet, les oprations que nous avons vues plus haut sont dans de nombreux cas limites un type de localisation. Le passage dun type un autre permet alors de les utiliser et met laccent sur la difficult dutilisation dobjets dont la dfinition et la prcision diffrent, au sein dune mme base de donnes. Aprs avoir rappel le principe de cration de nouvelles relations temporaires dans le schma de la base de donnes, nous avons organis ce paragraphe en regroupant les oprations par le type dimplantation spatiale des objets crs. 8.6.1. Le principe de la cration de nouvelles relations Lors dune requte, il est possible de crer de nouvelles collections dobjets. Ces relations sont temporaires, le schma de la base de donnes est modifi temporairement comme lors de la cration dattributs. Mais la cration dune nouvelle relation localise implique la cration de toute la structure des fichiers correspondants : fichier index, fichier descriptif, fichier graphique. La procdure NouvelleRelation() de la classe CSchema encapsule les diffrentes oprations ncessaires la modification du schma (A.2.1.2.). Il existe plusieurs manires de crer une nouvelle collection dobjets : - par duplication (valable quel que soit le type de la relation) ; - par dfinition des objets (mailles) ou par digitalisation des objets sur cran (valable pour les types zone, ligne, point) ; - partir dune relation existante, par modification gomtrique des objets (rosion, dilatation, ou par masque) ou par changement de type dimplantation spatiale. Nous allons voir rapidement les deux premires oprations, avant de consacrer un paragraphe plus dtaill la cration de relation par modification des objets dune relation existante. 8.6.2. La duplication La duplication dune relation permet de recopier tous les objets dune relation dans une nouvelle relation identique. Pour le type zone, les arcs ne sont pas recopis : les deux relations partagent le fichier des arcs. Cette opration permet de conserver une copie dune relation avant de la modifier par restriction ou projection.

294

Chapitre 8

8.6.3. La dfinition directe sur cran ou par masque La dfinition directe sur cran permet lutilisateur de crer une nouvelle relation temporaire en numrisant directement les objets dans le cadre gographique. La dfinition par masque cre une relation de type zone, possdant un seul objet correspondant au masque utilis. 8.6.4. La cration de mailles Bien souvent, on ne dispose pas dun dcoupage de lespace reprsentatif dune chelle de description donne, ou suffisamment rgulier pour tre employ dans une opration de changement dchelle et de go-agrgation. En effet, il ne faut pas que le dcoupage utilis pour agrger soit corrl la rpartition spatiale des objets que lon agrge. La solution la plus simple consiste donc crer de nouveaux objets dont la gomtrie ne puisse pas a priori interfrer dans le processus dagrgation : les mailles carres ou hexagonales sont les plus employes, car elles correspondent une rpartition uniforme des objets dans lespace (fig. 8.17).

fig. 8.17 : Donnes ponctuelles, mailles, et go-agrgation dans les mailles

Si la forme des objets est prdfinie, on peut par contre choisir la taille des mailles. La variation de la dimension de la maille na pas le mme effet selon que le semis de point des objets agrger est plus concentr ou plus dispers. Dans le premier cas, la diminution de la taille de la maille a tendance augmenter la

Analyser 295 dispersion relative et les disparits de densit entre les mailles. Dans le second cas, les effets sont plus faibles. Le choix de la taille des mailles doit tenir compte du nombre de points agrger et de la forme du semis de points. Souvent, la meilleure taille est celle qui minimise la variance intra-maille et maximise la variance intermaille pour lattribut agrger. La cration de maille correspond la cration de nouveaux objets : on cre ici une nouvelle relation, temporaire, de type zone. 8.7. Les oprations de changement de type dobjet Il est trs courant dutiliser les objets dune ou plusieurs relations existantes pour crer de nouveaux objets. Bien souvent, cette cration dobjet saccompagne dun changement de type dimplantation spatiale des objets des relations dorigine. De nombreux algorithmes sont employs dans ces oprations : interpolation, extrapolation, vectorisation, triangulation et tessellation, morphologie mathmatique, etc. Nous allons dtailler ces diverses mthodes en les classant en fonction du type de la nouvelle relation cre. 8.7.1. Vers le pixel : interpolation ou rasterisation 8.7.1.1. Mosaque et type Raster Lobjectif est ici de crer une nouvelle relation dont les objets sont des pixels, cest--dire des objets de gomtrie identique et de taille connue, comme nous lavons dfini au chapitre 6. Il y a analogie avec la cration de mailles, mais ici le nombre dobjets crs sera en gnral beaucoup plus grand et la valeur de lattribut sera calcule directement lors de la cration des objets et non par go-agrgation comme dans le cas des mailles. La relation cre est de type mosaque et non de type zone : la gestion dun nombre de mailles dpassant le million nest pas trs efficace, alors que la gestion dune relation de type mosaque est conue pour recevoir sans problme plusieurs dizaines de millions de pixels. Alors que les mailles sont construites pour recevoir des valeurs par goagrgation, la valeur des pixels est construite directement par interpolation en utilisant la localisation du centrode des objets initiaux dans le calcul de linterpolation : le changement dchelle sous-jacent sapparente donc plus une opration dappartenance qu une opration dagrgation. La taille du pixel sera en gnral infrieure ou gale la prcision des objets initiaux, alors que la taille des mailles est le plus souvent choisie pour effectuer une gnralisation. La surface du pixel nest jamais utilise dans le calcul dinterpolation.

296

Chapitre 8

La relation cre peut tre de type mosaque ou de type raster . Cette relation particulire fixe la taille des pixels en fonction de la fentre dtude. Elle est gre comme une relation de type mosaque, mais ne contient quune seule feuille, est toujours temporaire, et nexiste qu un seul exemplaire dans la requte. Elle est automatiquement dtruite lors dun changement de fentre dtude ou de projection gographique. 8.7.1.2. Mthodes dinterpolation La cration dune relation de type mosaque cre des pixels sur lensemble de la surface de la fentre dtude ; on peut limiter cette cration au domaine reprsent par un masque. La cration de la relation et des objets saccompagne de la cration dun attribut pour tous les pixels : la valeur est obtenue partir des objets des relations initiales choisies par lutilisateur, qui peuvent tre de type zone, ligne, ou point. On utilise pour cela des mthodes dinterpolation qui prennent en compte la position des objets initiaux par rapport au pixel. Les mthodes dinterpolation sont trs nombreuses : leur choix dpend du contenu smantique de lattribut crer. Par exemple, la cration dun modle numrique de terrain relve de cet type dopration : on cherche crer des pixels avec un attribut altitude partir dobjets initiaux qui peuvent tre des courbes de niveaux ou des points cots. Linterpolation utilise doit correspondre ce type de problme : de nombreuses mthodes ont t proposes et font lobjet dune abondante littrature. On peut citer notamment les mthodes barycentrique, statistique, par triangulation, par fonction polynomiale, spline, etc.

fig. 8.18 : le dialogue du choix de lopration dinterpolation

Analyser 297 Nous avons dvelopp dans SAVANE quelques mthodes dinterpolation : plus proche voisin, barycentrique sur les voisins, barycentrique sur tous les points, bilinaire dans triangulation, spline aprs barycentrique. Ces mthodes permettent de rpondre la plupart des besoins dinterpolation (fig. 8.18). 8.7.1.2.1. La mthode barycentrique La mthode dinterpolation barycentrique est la plus utilise en pratique. Elle permet notamment dobtenir de trs bons rsultats pour la cration des modles numriques de terrain lorsque les donnes initiales sont suffisamment denses. Nous appellerons points de rfrence les points du plan qui servent de support au modle et permettent linterpolation. Ils proviennent de la localisation des objets de relations existantes dans la base de donnes. La mthode de calcul consiste en une interpolation de type barycentrique sur les huit points de rfrence les plus proches du point interpoler, rpartis dans les huit portions du plan. Limportance dun point de rfrence est dautant plus grande dans le rsultat du calcul que sa distance au point interpoler est faible (par rapport aux distances des autres points au point interpoler). Cette mthode ne donne pas une surface diffrentiable, et nutilise pas de modle local ou de modle de variance : elle ncessite donc une densit de points de rfrence dautant plus grande que les variations de lattribut sont fortes. Cest en fonction de cette variation que les points de rfrence doivent tre choisis si cela est possible. La mthode dinterpolation barycentrique est stable : elle ne modifie pas la valeur des points de rfrence dans le rsultat de linterpolation. Cette proprit est essentielle dans de nombreuses applications.

p2(v2) p3(v3)

p1(v1)

p8(v8)

v(Pij) =
p4(v4) p5(v5) p6(v6) p7(v7)

8 k=1 8 8

v(Pk) d(Pij,Pm)
m=1 m=k

d(Pij,Pm)

m=1 k=1 m=k

298

Chapitre 8

Aprs cration des pixels, le calcul de la valeur de lattribut par interpolation seffectue en deux temps : dans un premier temps, on affecte chaque pixel la moyenne des valeurs des points de rfrences dont la distance au pixel est infrieure la taille du pixel. Ces pixels deviennent alors les points de rfrences utiliss pour calculer la valeur des autres pixels (une option permet dviter de faire la moyenne entre les points provenant de diffrentes relations). Dans un second temps, on cherche pour chaque pixel les pixels les plus proches dans chacun des huit cadrans, et on affecte au pixel la valeur interpole partir de ces pixels. Enfin, le rsultat peut tre liss (par une fonction polynomiale de Bziers de degr 6) sur chaque ligne et chaque colonne pour supprimer les erreurs ventuelles dans les points de rfrence. La recherche des points valus voisins est ltape la plus longue de lopration : elle peut tre trs longue si la densit de points de rfrence est trop faible (fig. 8.19). Lopration est effectue imagette par imagette. Le nombre dimagettes cres dans la relation dpend de la taille de pixel choisie pour la nouvelle relation. La matrice de pixel utilise pour conserver les points de rfrence doit tre plus grande que limagette pour ne pas exclure arbitrairement les points extrieurs qui pourraient participer au calcul de la valeur dun point de limagette, notamment pour les points prs du bord, et assurer ainsi la continuit des valeurs dune imagette lautre. La classe Cbabel encapsule lensemble des variables et des mthodes utilises pour le calcul dinterpolation barycentrique (A.2.1.6.).

fig. 8.19 : rsultat de linterpolation barycentrique partir de courbes de niveau

Analyser 299 Les relations donnant les points de rfrence peuvent tre de type zone, ligne, ou point. Dans la cas de zone, on utilise le centrode de la zone comme point de rfrence. Dans le cas de ligne, on utilise lensemble de larc reprsentant la ligne, ce qui donne de nombreux points de rfrence. La mthode Draw() de la classe CArc calcule les points de rfrence partir des points de larc. Loption deux passages propos pour le calcul barycentrique dinterpolation permet de palier au problme pos par une mauvaise densit des points de rfrence et dviter des temps de calcul trop longs. Le calcul seffectue alors en deux passages : un premier passage permet de calculer par interpolation des points suivant un pas donn (un pixel sur dix, par exemple). Ces points calculs sont ensuite ajouts aux points de rfrence et utiliss dans le calcul gnral dinterpolation. La recherche de voisins est alors limite au maximum au pas de la premire interpolation. 8.7.1.2.2. Barycentre sur tous les points Linterpolation barycentrique sur tous les objets sapparente un calcul de potentiel ou dinfluence. La valeur calcule pour chaque pixel est la moyenne des valeurs des points de rfrence pondres par la distance. La mthode ne doit tre employe que lorsque le nombre de points de rfrence est faible (fig. 8.20). On peut nanmoins limiter la calculer aux points dont la distance au point interpoler est infrieure une valeur donne.

fig. 8.20 : exemple dinterpolation barycentrique sur tous les points de rfrence (classe par quantiles)

300

Chapitre 8

8.7.1.2.3. Interpolation barycentrique sous contrainte Le caractre interpoler est parfois directement li un autre caractre, connu sur lensemble de lespace dtude. Par exemple, on ne peut interpoler la temprature au sol sans tenir compte de laltitude. On a donc le choix dinterpoler des valeurs normalises (par exemple des tempratures ramenes au niveau de la mer), puis de calculer les variations dues la dpendance des variables (par exemple, la dpendance linaire de la temprature en fonction de laltitude), ou de calculer directement le nouvel attribut par une interpolation sous contrainte. Cette option est disponible dans SAVANE pour les contraintes linaires. 8.7.1.3. Zone vers pixel : rasterisation Les oprations que nous avons dcrites au paragraphe prcdent ne prennent en compte que le centrode des zones dans le processus dinterpolation. Lopration de rasterisation dune relation zonale permet daffecter des valeurs aux pixels de la relation raster en fonction de leur appartenance aux zones. Elle correspond lopration dinterpolation par plus proche voisin ou dappartenance dun pixel une zone. On peut ainsi crer des attributs dans la relation raster partir de nombreuses relations diffrentes. Ces attributs peuvent ensuite tre combins, pixel par pixel, en utilisant les oprations que nous avons vues au paragraphe 4 de ce chapitre. Comme nous lavons dj soulign, la valeur du pixel provient dune opration dappartenance et non dagrgation, comme dans le cas de mailles. Les deux approches sont donc complmentaires. La rasterisation dune relation zonale utilise lalgorithme de rasterisation que nous avons dj vu plusieurs reprises. 8.7.2. Vers la zone : vectorisation ou tessellation Nous avons dj vu la cration directe dune nouvelle relation de type zone, par cration de mailles ou directement par digitalisation. Mais il est galement trs intressant de crer des zones partir des objets dune autre relation. Les mthodes de cration de zones dpendent du type des objets de la relation initiale : - partir dune relation de type pixel, on utilisera un algorithme de vectorisation et lablisation pour crer les arcs et les objets ; - partir dune relation de type ligne, on utilisera un algorithme de construction de zone pour crer des polygones partir dun ensemble darcs, si cela est possible ; - partir dune relation de type point, on utilisera un algorithme de tessellation pour diviser lespace en zones partir du semis de point ; cette mthode peut

Analyser 301 galement tre utilise pour tous les types dobjets vectoriels, partir du centrode des objets ; - partir dune relation de type zone, on peut rdfinir de nouvelles zones par morphologie mathmatique (rosion ou dilatation) ou par regroupement. Lalgorithme de vectorisation est le plus complexe. Il est utilis galement pour calculer le contour des masques aprs des oprations sur leur reprsentation matricielle. 8.7.2.1. Un algorithme de vectorisation Lopration de vectorisation est linverse de la rasterisation : elle vise crer des arcs partir dun ensemble de pixels, en faisant passer un arc entre les pixels qui nont pas la mme valeur. Nous avons dvelopp un algorithme de vectorisation dune image code dont nous allons rapidement dcrire le principe. Lalgorithme de vectorisation que nous avons dvelopp cherche faire passer les arcs entre les pixels, et non sur les pixels. On ne cherche donc pas le cheminement dun pixel un autre, mais on cherche les configurations de valeurs quatre pixels adjacents qui permettent le passage dun arc : un arc doit passer entre deux pixels si leurs valeurs sont diffrentes. Dans une premire phase, lalgorithme teste les configurations de quatre pixels adjacents pour dterminer si une ligne doit passer entre ces pixels. Dans une seconde phase, les segments darcs ainsi dtermins sont chans entre eux pour crer des arcs. Dans une troisime phase, les objets sont crs en fonction des valeurs de limage initiale. La classe CVectoriser encapsule lensemble des oprations de la vectorisation dune image (A.2.2.3.). Les configurations possibles de quatre pixels adjacents sont au nombre de 13. Elles sont codes suivant le schma suivant, o deux pixels de mme valeur sont reprsents par la mme couleur, et o le trait reprsente le trajet du segment darc crer :

302

Chapitre 8

11

12

13

10

13

Limage initiale est donc remplace par limage des configurations codes (procdure SegmentType() de Cvectoriser()). La seconde phase de lalgorithme, la plus dlicate et la plus longue, vise chaner lensemble de ces segments darcs pour constituer des arcs. Les arcs conservent le code des pixels adjacents quils sparent. Le principe est assez simple : partir du premier segment qui na pas encore t chan, on cherche le segment qui peut le continuer, et ainsi de suite, dans un sens, puis dans lautre. Le type du segment donne la direction dans laquelle il faut chercher le suivant. La recherche doit sarrter lorsque lon tombe sur une configuration trois segments, qui correspond un nud (type 5, 6, 8 , 10, 13). Des types temporaires doivent tre crs pour grer les configurations plusieurs segments (5, 6, 7, 8, 9, 10, 13 ; par exemple, le type 6 devient type 2 ou 3 aprs chanage dun premier segment, mais sans oublier que la configuration correspond un nud). Les bords de limage sont chans part.

Analyser 303

fig. 8.21 : vectorisation aprs classification dune mosaque (image TM)

Enfin, les arcs ainsi crs sont lisss pour liminer les points superflus (de nombreux points crs sont aligns) (fig. 8.21). Lalgorithme de vectorisation est employ pour crer une relation de type zone partir dune relation de type mosaque. La vectorisation est effectue pour chaque imagette et cre dans la relation vectorielle une feuille par imagette. Les objets zone sont crs partir des codes rencontrs dans la mosaque initiale, par imagette. Chaque zone reprsente en gnral un ensemble de polygones non connexes, car il ny a pas lablisation de chaque polygone. La cration dune zone saccompagne de la cration de son centrode. La localisation dun centrode partir dun ensemble de polygones quelconques nest pas triviale : il faut sassurer que le centrode se trouve bien dans le polygone et est bien plac par rapport la forme du polygone. Plusieurs mthodes peuvent tre employes, avec la mme ide : dterminer un point central, puis bouger ce point sil ne se trouve pas dans la zone. Comme point central, on peut prendre le centre du plus petit rectangle contenant les polygones, le centre de lun des polygones, ou le centre du cercle inscrit lun des polygones. Le test de linclusion du point dans les polygones peut tre effectu par lalgorithme YX que nous avons dj vu au chapitre 7. Si le point est en dehors de la surface de la zone, il peut tre dplac en X pour se situer au milieu du polygone qui le prcde ou qui le suit. Lalgorithme de vectorisation est galement employ pour vectoriser les masques, ou pour vectoriser des objets aprs des oprations effectues sur des reprsentations matricielles.

304

Chapitre 8

8.7.2.2. Un algorithme de tessellation On utilise pour la cration de zones partir de points un algorithme de tessellation, cest--dire de partition de lespace en zones disjointes. Nous avons mis en uvre dans SAVANE la tessellation de Vorono, duale de la triangulation de Delaunay que nous avons dj vue au chapitre 6. La tessellation est calcule partir de la triangulation : celle-ci donne la liste oriente des artes des triangles partant de chaque point, il suffit donc de calculer les intersections deux deux de ces artes pour dterminer les arcs. Il y a ici bijection entre les points initiaux et les zones cres, et chaque zone conserve lidentifiant de lunique point initial quelle contient. Les points servent galement de centrodes aux zones (fig. 8.22). Le bord de la fentre gographique de travail est utilise pour fermer les zones extrieures.

fig. 8.22 : cration de zones partir de points : tessellation de Vorono

8.7.2.3. De la ligne la zone : crer la topologie Il est possible de crer des zones partir de lignes destines former le contour des zones. Celles-ci doivent alors former un graphe planaire ferm. Lopration seffectue en deux temps : - vrification de la planarit et de la fermeture du graphe ; - cration des polygones. Pour vrifier la planarit du graphe, on teste les arcs deux deux la recherche dune intersection non situe sur une extrmit, aprs avoir limin les arcs ou portions darc en double. On teste la fermeture en comptant le nombre dapparition

Analyser 305 de chaque nud dans lensemble des arcs. Chaque nud doit apparatre en nombre pair. La cration des polygones utilise lalgorithme vu au chapitre 7 pour la reconstitution de polygones partir darcs. 8.7.2.4. De la zone la zone : regrouper, roder, dilater On peut galement crer une nouvelle relation zonale partir des zones dune autre relation, par regroupement de zones ou par modification de la gomtrie des zones initiales en utilisation des algorithmes de morphologie mathmatique (rosion, dilatation). Le regroupement de zones se fait sur un attribut nominal de la relation initiale. Cet attribut devient une cl descriptive des objets de la relation rsultante. La topologie doit donc tre modifie pour supprimer les arcs frontire de deux zones initiales de mme valeur et recrer de nouvelles zones partir de ces arcs. On prendra comme centrode des nouvelles zones le centrode de lune des zones initiales de mme valeur. Le dcoupage en feuille pose ici un problme difficile rsoudre, car deux zones de feuilles diffrentes mais de mme valeur pour lattribut qualitatif choisi doivent tre regroupes dans un mme objet de la nouvelle relation. Cette opration fait donc perdre lindexation gomtrique, et la relation rsultante ne contient plus quune seule feuille. Les arcs en double, prsents dans deux feuilles distinctes mais sparant deux zones adjacentes de mme valeur descriptive doivent tre limins. Lrosion et la dilatation sont des oprations dun autre type. Elles modifient les contours des zones sans modifier les valeurs descriptives des objets. Le nombre dobjets reste le mme (fig. 8.23). Dans SAVANE, la ralisation de ces oprations utilise la reprsentation matricielle des objets. Aprs rosion ou dilatation des objets dans limage, cette image est vectorise pour crer les contours des nouvelles zones. Voici par exemple la mthode de dilatation dune image matricielle. On cherche, pour chaque pixel susceptible dtre rempli (les pixels qui ne correspondent aucune zone initiale) la zone initiale la plus proche, en limitant la recherche la distance de dilatation. On peut limiter la dilatation un masque. Pour amliorer les performances de lalgorithme, on construit toujours un masque autour des objets dilater, avec la distance de dilatation : seuls les pixels de ce masque sont susceptibles dtre remplis. La procdure de dilatation est implmente dans la procdure globale DilaterImage() dont le code est dcrit dans lannexe A.2.2.4. (pour roder, on inverse le processus : les pixels susceptibles dtre remplis sont ceux qui appartiennent une zone initiale, et on dilate lespace vide).

306

Chapitre 8

fig. 8.23 : deux dilatations partir des objets initiaux (5 m, 20 m). Lobjectif est ici de diminuer ou de remplir lespace interstitiel en ville

On peut galement utiliser cet algorithme pour crer des zones partir de lignes ou de points. Chaque objet donne le jour une zone de la nouvelle relation (fig. 8.24).

fig. 8.24 : cration de zones par dilatation partir de lignes ou de points

Analyser 307 8.7.3. Vers la ligne On peut crer de nouveaux objets de type ligne partir de zones, par squelettisation, ou partir de pixels, par vectorisation. On peut galement considrer les frontires des zones comme des objets de type ligne, en affectant chaque frontire une valeur dduite des valeurs des deux zones. 8.7.3.1. Squelettisation de zones La squelettisation dune zone est lopration qui permet de rduire la surface de la zone la ligne la plus reprsentative de la forme de cette surface. Le squelette dune zone peut tre obtenu partir de son contour : le squelette est lensemble des points de la zone qui ont au moins un point du contour la mme distance que le point du contour le plus proche. Il peut galement tre obtenu partir dun attribut qualitatif dune relation mosaque : on emploie alors des mthodes itratives de morphologie mathmatique (rosions successives jusqu stabilit, par exemple). 8.7.3.2. Vectorisation et courbes disovaleurs La vectorisation permet dobtenir des lignes partir dun attribut dune relation de type zone ou mosaque, par suivi des diffrences de lattribut. Si lattribut est numrique, il est automatiquement class en intervalles gaux : les objets correspondent alors des courbes disovaleurs pour cet attribut. Lalgorithme de vectorisation est toujours le mme, mais les objets crs ne sont plus considrs comme des contours de zones mais comme des lignes. Si la relation initiale est de type zone, on utilise limage raster de lattribut de la relation. La cration de courbes disovaleurs partir dun attribut cr par interpolation permet de tester lidempotence de la composition des deux oprations (fig. 8.25) :

308

Chapitre 8

fig. 8.25 : Courbes de niveau initiales, interpolation, puis cration de courbes de niveau par vectorisation (en rouge, superposes aux courbes initiales en bleu)

8.7.4. Vers le point Le type point est le plus simple de tous les types de relations localises. De plus, les types zone et ligne conservent pour chaque objet un centrode qui permet de considrer ces objets comme des points dans de nombreuses oprations de dessin ou de go-agrgation. Il ny a donc pas lieu de crer une nouvelle relation de type point lorsque lon souhaite utiliser des objets de type zone ou ligne dans ces oprations. Nous avons dj vu comment trouver un centrode partir dune zone dfinie par ses arcs frontires, ou partir de larc dune ligne, lors de la cration dobjets de ce type.

Analyser 309 Par contre, il peut tre intressant de dfinir des objets de type point partir de la localisation dobjets dune relation suivant la valeur de lun des attributs des objets, de manire avoir une vision synthtique dun phnomne ou reprsenter un semis de points par un seul point. La gestion des rseaux impose souvent de diffrencier ligne et nud, et de traiter les deux collections sparment, sans oublier nanmoins les relations topologiques entre les deux entits. 8.7.4.1. Centre dun semis de points Cette procdure de cration de relation ponctuelle permet de mettre en uvre les oprations de reprsentation dun semis de points par un point remarquable, oprations que nous avons voqu au dbut de ce chapitre. On peut ainsi crer un point comme point mdian ou comme point moyen dun ensemble de points ou de centrodes (fig. 8.26). On peut galement pondrer le calcul du point moyen par la valeur dun attribut numrique.

fig. 8.26 : Cration de points centraux (en bleu) partir dun semis de points (provenant des lots, en rouge) et de lappartenance au quartier (attribut cr par go-appartenance)

8.7.4.2. De la ligne aux points : lutilisation des nuds La cration dune relation ponctuelle partir des extrmits de lignes permet de sparer les nuds des arcs. Cette sparation est importante car, sil est possible de grer un rseau avec une relation de type ligne, certaines proprits du rseau doivent tre exprimes sur les nuds et non sur les arcs. Ces proprits seront donc

310

Chapitre 8

calcules partir de la localisation des nuds regroups dans une relation ponctuelle. Par exemple, la cration dune relation ponctuelle partir des extrmits des objets dune relation de type ligne saccompagne de la cration dun attribut indiquant pour chaque nud le nombre doccurrence de lextrmit dans chaque objet ligne de la relation initiale (fig. 8.27).

fig. 8.27 : occurrence des nuds dans un rseau de lignes de bus

8.8. Conclusion Avec lanalyse spatiale, le SIG quitte le strict domaine du systme de gestion de donnes et devient galement programme dapplication, puisque, comme nous lavions vu au chapitre 5, les seules oprations de gestion relationnelle ne sauraient permettre de rpondre aux problmes lis la schmatisation de lespace. Ds lors, nous ne pouvons que dvelopper et prsenter ici quelques mthodes dapplication des donnes localises, tant les champs dapplication sont vastes et varis. Lanalyse spatiale sadresse plus particulirement aux gographes, mais la dmarche pourrait tre la mme quelque soit le domaine dapplication envisag, comme lhydrologie, la gologie, la gomorphologie, lurbanisme, la gestion du territoire, etc. Le SIG senrichit non seulement de structures de donnes propres certaines applications, il senrichit galement de mthodes spcifiques pour devenir un vritable systme objet. Le dveloppement dun systme comme SAVANE peut donc se poursuivre selon trois voies : limplmentation de nouvelles oprations danalyse ou de simulation directement dans le module dexploitation, lappel de fonctions externes partir dun schma de mthodes dveloppes par les concepteurs dobjets ou de

Analyser 311 collections dobjets et spcialises un domaine dapplication particulier (lappel de fonction externe est gre directement en tant quopration lmentaire de la requte), et le dveloppement dune librairie permettant aux dveloppeurs dapplications dintgrer lensemble des mthodes de gestion de donnes dans le programme dapplication.

312

Chapitre 8

Analyser 313

Bibliographie

[BEG 94] BEGUIN M., PUMAIN D., La reprsentation des donnes gographiques, 1994 Armand Colin, Cursus , Paris [HAG 73] HAGGETT P., Lanalyse spatiale en gographie humaine, 1973, Armand Colin, Paris [LAU 93] LAURINI R., MILLERET-RAFFORT F., Les bases de donnes en gomatique, 1993, Hermes, Paris [MON 82] MONMONIER M., Computer-Assisted Cartography, Principles and Prospects, 1982, Prentice-Hall [ORO 93] OROURKE J., Computational Geometry in C, 1993, Cambridge University Press [PAR 97] PARKER J.R., Algorithms for Image Processing and Computer Vision, 1997, Wiley Computer Publishing [PUM 97] PUMAIN D., SAINT-JULIEN T., Lanalyse spatiale, 1997, Armand Colin, Cursus , Paris [RIM 90] RIMBERT S., Carto-graphies, 1990, Herms, Paris [SAN 89] SANDERS L., Lanalyse des donnes applique la gographie, 1989, RECLUS, Montpellier [VOI 95] VOIRON C., Analyse spatiale et analyse dimages, 1995, RECLUS, Montpellier

Chapitre 9

Reprsenter

Ce dernier chapitre traite de la reprsentation des donnes gographiques dans le systme SAVANE. Aprs la modlisation, la saisie, le traitement, lanalyse, cest la dernire tape dun long processus et lun des objectifs du systme construire : pour tre complet, un systme dinformation gographique doit intgrer des fonctionnalits classiques ddition graphique ainsi que des capacits spcialises dans la reprsentation cartographique, de manire prsenter les rsultats dune requte. Cette dernire tape est fondamentale et passionnante, car la reprsentation cartographique est le moyen privilgi pour prsenter des donnes ds lors quelles sont localises, et cette reprsentation correspond de nouveau une schmatisation des objets et des phnomnes contrairement aux bases de donnes classiques qui prsentent les rsultats sous forme de listes ou de formulaires. Nous nallons ici que rappeler brivement les principes de la cartographie ou de la smiologie graphique pour dcrire plus en dtail le principe et limplmentation des procdures de cartographie partir des donnes gres par le systme SAVANE. 9.1. Les principes de la reprsentation cartographique La reprsentation graphique est la transcription laide de signes graphiques dune information connue laide dun autre systme de signes. La reprsentation graphique est une partie de la smiologie, science qui traite de tous les systmes de signe [BER 67]. Le systme de signes qui nous intresse ici ne concerne que ce qui est reprsentable sur un cran dordinateur ou sur une feuille plane de papier blanc, par tous les moyens graphiques disponibles. On traitera un peu part lintervention du mouvement et lanimation, car les lois graphiques du cinma sont trs diffrentes des lois graphiques de la cartographie. On traitera galement part lintervention de

316

Chapitre 9

la troisime dimension et la reprsentation en perspective, car bien que J. Bertin ne la prconise pas pour visualiser des donnes quantitatives, elle savre tre une aide consquente linterprtation des photographies ariennes ou des images satellites. 9.1.1. Le langage cartographique Le langage cartographique regroupe les moyens graphiques permettant lutilisation de ces signes pour transmettre une information. Cest une forme dexpression dont les signes graphiques lmentaires (le point, le trait, la tache) seraient lalphabet, dont le vocabulaire est fait de variables visuelles et dont la syntaxe est dfinie par les rgles de la perception visuelle. Les lments du dessin constituent le signifiant, le contenu du message, dont le signifi, le contenu informatif, rside dans la correspondance tablie entre les signes et linformation transmettre. [BEG 94]. Ce langage doit satisfaire plusieurs objectifs : obir aux rgles gnrales de la perception visuelle, tre universel, cest--dire comprhensible par tous ceux qui ont les mmes rgles de perception visuelle, tre cohrent en vitant la redondance, la surcharge ou lambigut. En combinant les diverses variables dont il dispose, le langage cartographique offre une trs large gamme de possibilits pour reprsenter un phnomne, mais le cartographe, dans son choix dune reprsentation, doit sefforcer de garantir la clart et cohrence du message. De nombreuses rgles ont t tablies en vue du respect de ces principes [BER 67]. Dans les limites que nous avons fixes plus haut, on considre que le systme graphique dispose de sept variables : - une variable dimplantation en deux dimensions : une tache visible peut reprsenter un point, une ligne, ou une zone ; - six variables de reprsentation : taille, valeur, grain (ou trame), couleur, orientation, forme. A partir dobjets gographiques, le cartographe ralise une carte en utilisant des signes lmentaires quil distribue selon une certaine implantation graphique. Une carte est constitu de figurs, ensemble de dessins visant reprsenter ou schmatiser le phnomne cartographier. Le langage cartographique nutilise que trois signes graphiques lmentaires pour dessiner un figur : un point, un trait, un aplat de noir ou de couleur. Limplantation graphique est la manire de reprsenter un figur partir de ces signes lmentaires. Par exemple, limplantation graphique est ponctuelle lorsque le figur est un symbole. Il ny a pas forcment de correspondance entre implantation gographique et implantation graphique : par exemple, il est courant de reprsenter une zone par un symbole (implantation ponctuelle), ou par un contour (implantation linaire). Ce passage correspond au

Reprsenter 317 pouvoir de modlisation et de schmatisation de la cartographie dont nous avons dj parl au chapitre 3. 9.1.2. Les variables visuelles Les variables visuelles de reprsentation (forme, taille, couleur, valeur, grain ou trame, orientation) permettent de faire varier les signes graphiques en fonction des valeurs des objets gographiques schmatiser. Elles sont utilises pour reprsenter graphiquement, partir dobjets localiss, des informations qualitatives, des variations quantitatives, des rpartitions ordonnes, permettant ainsi de schmatiser le phnomne que lon cherche exprimer. Lutilisation dun ordinateur permet de simplifier considrablement les oprations visant dessiner un figur correspondant aux valeurs dun objet gographique. Cest lobjet de la cartographie automatique. 9.1.2.1. La forme La forme dun lment graphique permet de transcrire une information qualitative. Il existe une infinit de formes disponibles, allant des symboles les plus simples carrs, cercles, etc. - aux pictogrammes symboliques vocateurs de tel ou tel phnomne. Une carte, pour rester lisible, ne devra pas en contenir plus dune dizaine. La forme est utilise dans tous les types dimplantation graphique : elle est la base des figurs ponctuels, et sert galement diffrencier des lignes de natures diffrentes (frontires, courbes topographiques, failles, etc.). La forme dun aplat est en fait une texture obtenue partir de la rptition dune forme lmentaire. Quelle que soit limplantation graphique, la forme ne doit jamais tre employe pour reprsenter une variation quantitative. 9.1.2.2. La taille La taille dun figur est dfinie par sa longueur, sa hauteur, sa surface ou son volume. Contrairement la forme, la taille est utilise pour reprsenter des variations quantitatives. De ce fait, elle permet non seulement de reprsenter des quantits mais galement lordre des diffrents objets, car lil ordonne naturellement, du plus petit au plus grand, une forme en fonction des diffrences de longueur ou de surface, et dautant plus facilement que ltalement des tailles est galement rparti entre la plus petite et la plus grande taille : on sefforcera donc souvent de rendre la correspondance phnomne-taille proportionnelle, en agissant sur la variable gographique reprsenter. La taille peut tre utilise pour les implantations graphiques ponctuelles et linaires ; on peut faire varier lpaisseur dun segment de droite en fonction dun attribut numrique ; on peut faire varier la surface dun symbole proportionnellement une variable.

318

Chapitre 9

9.1.2.3. La couleur Lil humain peroit facilement de nombreuses teintes, et la couleur est abondamment utilise en cartographie. Une couleur peut sexprimer par la proportion de chacune des couleurs primaires (cyan, magenta, jaune), ou, sur un cran, par la proportion des couleurs fondamentales (rouge, vert, bleu). Lhomme peroit plus facilement les diffrences de couleur grce aux variations de ton, dintensit, et de saturation. La couleur permet de diffrencier aisment des variations aussi bien quantitatives que qualitatives, mais cest la variable visuelle la plus utilise pour reprsenter des diffrences qualitatives. On a dailleurs tabli dans de nombreuses thmatiques des palettes de couleurs standards pour reprsenter des modalits de la thmatique (et gologie, en pdologie notamment). Par contre, la couleur seule ne suffit pas pour reprsenter un ordre, car il est impossible dagir sur lune des composantes de la couleur sans altrer visuellement lordre les deux autres. Dans un dgrad de couleur, lordre des couleurs ne correspond pas de faon intuitive un ordre numrique. Nanmoins, on utilise parfois des dgrads de couleurs pour reprsenter des variations numriques, et lon sefforce alors de nutiliser que quelques tons diffrents. Si la carte est destine limpression, il faut tre trs attentif aux couleurs employes. Le rendu dune couleur est toujours diffrent sur un cran et en impression. On choisira les couleurs en fonction de la technique employe pour limpression, et le plus souvent partir dune charte imprime fournie par limprimeur et donnant le rendu des couleurs en fonction de leurs niveaux dans les trois couleurs primaires (benday). 9.1.2.4. La valeur La valeur correspond au rapport entre les quantits de noir et de blanc perues dans une surface donne. La variation de valeur est la progression continue que lil peroit dans la suite des gris qui schelonnent du noir au blanc. La valeur dune surface colore est dsigne par le gris qui sgalise en valeur avec cette surface. Cette variable visuelle est toujours ordonne. Si lil peut distinguer un grand nombre de niveaux de gris, en pratique il faut limiter le nombre de niveaux 6 ou 7. On utilise essentiellement cette variable pour reprsenter des valeurs qualitatives ordonnes sur des implantations zonales, et la surface ne doit pas tre trop petite pour que lil puisse apprcier le rapport entre le blanc et le noir. 9.1.2.5. Grain, trame, texture Le grain est la quantit de taches sparables dans une surface donne. La tache est un motif, gnralement simple : carr, disque, ligne. La variation de grain est la sensation qui rsulte de la succession des rductions photographiques du semis de taches. Les rductions augmentent le nombre de taches mais ne font pas varier la

Reprsenter 319 valeur de la surface. Toute valeur peut donner lieu une variation de grain, mais cest dans les valeurs moyennes que les paliers de grain sont les plus sensibles. Cest en implantation zonale que le grain est le plus utilis. Mais cette variable visuelle est dun usage dlicat, car il est difficile den matriser la perception : valeur gale une trame gros grain parait plus noire quune trame petit grain qui sera perue comme plus couvrante et plus grise. 9.1.2.6. Orientation Lorientation est dfinie par langle que fait un figur avec la verticale. Pour que la variation devienne significative, il faut pouvoir dceler des catgories dorientation, ce qui en limite considrablement le nombre disponible. En gnral, on se limite quatre directions : verticale, horizontale, et deux obliques 45. 9.1.3. La reprsentation cartographique A partir dobjets gographiques, le cartographe dispose dune grande libert pour reprsenter ou schmatiser ces objets sur une carte en utilisant figurs et variables visuelles. Il peut diffrencier implantation gographique et implantation graphique ; il peut choisir des variables visuelles en fonction des implantations et de la nature des informations reprsenter. Lutilisation de la cartographie automatique supprime tout travail de dessin manuel, mais augmente la libert de choix graphiques. Ainsi, lessor des SIG doit saccompagner dun effort de formation la cartographique, puisque ces systmes mettent disposition de lutilisateur la fois des outils de traitement et de reprsentation de linformation gographique, avec de nombreuses possibilits de schmatisation et de modlisation. Les SIG rapprochent gographie et cartographie, comme nous lavons dj soulign au chapitre 3, mais ce rapprochement ne peut tre fructueux qu la condition du respect mutuel des rgles imposes par les deux disciplines. Gnralement, le gographe-cartographe cherchera conserver pour la reprsentation cartographique limplantation gographique des objets, et ce dautant plus quil cherchera rendre compte directement de la modlisation initiale de la ralit. Par contre, cette correspondance sera souvent modifie lorsque la carte rend compte dun travail de synthse ou de modlisation. Par exemple, lchelle de la carte est un lment important de cette schmatisation ; elle va de pair avec une simplification de linformation et une modlisation qui induit souvent une reprsentation des objets de type zone par des symboles ponctuels. Limplantation gographique zonale est la plus difficile reprsenter telle quelle, sans en changer

320

Chapitre 9

limplantation ; on ne dispose pas pour limplantation graphique zonale de variables visuelles permettant facilement de transcrire la valeur absolue ; les diffrences de surface entre les objets induisent frquemment des erreurs dinterprtation de la reprsentation. Elle sera donc souvent remplace par une implantation graphique linaire ou ponctuelle. Le choix des variables visuelles est fonction du type dimplantation et de la nature des variables reprsenter, suivant les principes numrs au paragraphe prcdent. Pour rsumer : - les attributs qualitatifs sont reprsents au moyen de variations de forme et de couleur (implantation ponctuelle et linaire), de couleur et de texture (implantation zonale) ; - lordre dun attribut quantitatif est reprsent par une variation de valeur, un dgrad de couleur, un variation de taille en implantation ponctuelle, une variation de taille ou un dgrad de couleur en implantation linaire, une variation de valeur, un dgrad de couleur, une variation de grain en implantation zonale ; - la valeur absolue dun attribut quantitatif est reprsente par une variation de taille en implantation ponctuelle ou linaire. 9.1.4. Lgendes et habillage La transmission de linformation laide du langage cartographique saccompagne galement de rgles de mise en forme, dune part pour reprsenter la correspondance entre variables visuelles et information descriptive (la lgende), dautre part pour dcrire la position spatiale de lespace reprsent (amorces gographiques, rose des vents, indication de la projection, etc.). Enfin, il est courant dajouter des lments graphiques pour faciliter la lecture de la carte ou de modifier la position de signes pour rpondre des rgles gnrales de prsentation. 9.2. La cartographie avec SAVANE : carte et cadres Lergonomie du module SAVANE du SIG est construite pour faciliter lexpression graphique du rsultat dune requte. Le document de base du logiciel est donc une carte, cest--dire une feuille de papier avec un cadre gorfrenc destin contenir une reprsentation graphique dune requte sur des donnes gographiques. 9.2.1. La carte A lentre dans le module dexploitation de SAVANE apparat une feuille de papier sur lcran, reprsentation graphique de lunique instance de la classe CCarte. Cette feuille de papier est destine contenir la reprsentation graphique

Reprsenter 321 des diffrents cadres gographiques, instances de la classe CCadre, chaque cadre correspondant une requte sur la base de donnes comme nous lavons vu depuis le chapitre 5. Une carte doit contenir au minimum un cadre, et peut en contenir jusqu dix. Elle est galement destine contenir les objets graphiques dessins par lutilisateur (textes, logotypes, images, lgende, dessins, etc.) (fig. 9.1).

fig. 9.1 : une carte ralise avec SAVANE

Lobjet carte, instance de la classe CCarte, contient de nombreux paramtres graphiques permettant de la dessiner sur lcran ou de limprimer : taille, orientation, couleur du fond, paramtres de visualisation sur lcran (position et agrandissement) (A.2.4.1). Elle contient galement un tableau donnant les pointeurs des objets graphiques quelle contient (de types drivs du type CODD, A.2.4.2). Lutilisateur agit directement sur ces paramtres grce lditeur graphique, conu comme un logiciel de dessin graphique : la fentre principale du module SAVANE correspond un diteur graphique traditionnel permettant de dessiner sur une feuille de papier avec des outils de dessin.. Il a donc sa disposition des fonctions de

322

Chapitre 9

dessin tout fait classiques, qui lui permettent de se dplacer dans la page et dy dessiner des figurs. Chaque objet de dessin correspond une classe particulire drive de CODD, et contenant les paramtres et les mthodes permettant de le dessiner ou de limprimer (A.2.4.2.). Les objets peuvent tre groups, et un groupe peut tre slectionn par lutilisateur pour modifier les paramtres des objets graphiques. Nous avons construit deux classes permettant de manipuler groupes et slection sur cran (CGroupe, CSelection, A.2.4.3.). Les cadres sont des objets graphiques plus complexes que nous allons dcrire dans la paragraphe suivant, mais ils sont manipuls grce lditeur graphique comme les autres objets graphiques (slection, dplacement, duplication, modification).

fig. 9.2 : la fentre principale de SAVANE est un diteur graphique

Les lgendes et les chelles graphiques proviennent des cadres dinterrogation. Mais une fois poss dans la carte, ces lments sont des objets graphiques de type CODD comme les autres, et peuvent tre manipuls grce lditeur graphique, contrairement aux figurs qui proviennent des objets gographiques, comme nous allons le dcrire dans le paragraphe suivant. 9.2.2. Les cadres Un cadre peut tre vu comme une fentre sur la base de donnes contenant un moment donn, un tat temporaire de la base correspondant une interrogation et aux oprations effectues (calculs, cration de nouvelles variables, croisement et jointure dobjets, etc.). Ltat temporaire de la base li au cadre est conserv avec la carte qui contient le cadre, ainsi que la macro-commande correspondant toutes les

Reprsenter 323 oprations effectues dans ce cadre. En plus de la requte et de ltat temporaire de la base, au cadre sont attachs des paramtres qui lui sont propres et qui permettent de le dessiner dans la carte (espace gographique visualis, projection gographique, chelle de trac, visualisation des amorces gographiques ou de projection, type de dessin pour le bord, position dans la carte) (A.2.4.4.). Un dialogue permet de choisir lensemble de ces paramtres (fig. 9.3). Lchelle de trac correspond la dfinition exacte de lchelle en cartographie, savoir le facteur de rduction entre coordonnes de projection et coordonnes de dessin. La taille du cadre dans la carte est donc fonction de lespace gographique visualis et de lchelle. Lespace gographique visualis peut tre diffrent de la fentre gographique de travail correspondant la requte (de type CWind). Lutilisateur peut modifier directement lespace gographique sur lcran en modifiant la position des bords du cadre.

fig. 9.3 : dialogue de proprits dun cadre gographique

Lchelle graphique dpend du cadre auquel elle est attache, puisquelle dpend de lchelle de reprsentation du cadre. Le dialogue de cration dune chelle graphique donne le choix de plusieurs types de dessin. Comme les signes graphiques constituant une chelle graphique nont pas vocation tre modifis, nous avons cr une classe CODD_ECHELLE drive de CODD pour reprsenter ce type dobjet graphique (A.2.4.2.). La reprsentation cartographique des objets des relations contenues dans un cadre utilise les principes de la smiologie graphique que nous avons noncs au dbut de ce chapitre. Pour chaque cadre, les paramtres permettant dassocier implantation graphique et variables visuelles, partir des relations et des attributs

324

Chapitre 9

reprsenter, sont conservs dans un objet de type CCartExplorateur, que nous appelons explorateur cartographique, et auquel nous consacrerons le paragraphe 9.3., aprs avoir indiqu comment est trait la couleur dans le systme SAVANE. 9.2.3. Couleurs et palettes Une couleur peut tre dcrite grce aux proportions de couleurs fondamentales quelle contient. En informatique, on utilise habituellement des niveaux de rouge, vert, bleu, chaque niveau tant cod de 0 255 (de manire occuper un octet en mmoire). On a ainsi la possibilit de coder environ 16 millions de couleurs, mme si certaines couleurs peuvent difficilement tre code de cette manire (notamment les teintes dor ou dargent, ou les couleurs fluorescentes). Dans le codage RVB, le niveau de chaque couleur primaire correspond directement la quantit dlectrons mise par le tube cathodique dans chacune des composantes de couleur. Pour du papier, on rsonne linverse, puisque intervient une quantit dencre dans chacune des composantes. On exprime alors une couleur par les proportions de cyan, magenta, jaune quelle contient. Parfois, on spare galement le noir, de manire sparer teinte et saturation, et amliorer limpression en quadrichromie (une couleur sexprime alors en proportions de cyan, magenta, jaune, noir quelle contient).

fig. 9.4 : dialogues de dfinition dune couleur et de choix dans une palette

Dans le systme SAVANE, une couleur est dfinie par ses niveaux de rouge, vert, bleu, ou ses proportions de cyan, magenta, jaune. La dfinition dune couleur seffectue directement sur lcran grce un dialogue (fig. 9.4). Pour viter davoir redfinir une couleur chaque fois que lon a besoin de dfinir la couleur dun lment, le systme SAVANE utilise des palettes, cest--dire des ensembles de

Reprsenter 325 couleurs prdfinies et conserves par le systme (classe CPaletteSavane, A.2.4.8.). Lutilisateur choisit donc une couleur dans une palette quil a constitu auparavant ou que le systme lui propose (palettes prdfinies). On peut ainsi crer une fois pour toute des ensembles de couleurs (des palettes) correspondant une thmatique particulire (topographie, gologie, pdologie, etc.). Lutilisation dune palette est dailleurs ncessaire dans les oprations de reprsentation par dgrad, puisque cest le systme qui va automatiquement affecter la couleur du dgrad en fonction de la valeur de la variable descriptive reprsenter. Il suffit alors de modifier la palette de couleurs pour modifier la correspondance valeur numriquecouleur. Mme chose pour une image code : il serait trs fastidieux davoir dfinir la couleur correspondant chaque valeur dune image (par exemple, une image satellite code de 0 255). On utilise alors une palette et une fonction de correspondance linaire entre code de limage et indice de la couleur dans la palette. Le systme SAVANE utilise deux palettes distinctes pour dessiner des dgrads dans une carte : une palette dite thmatique, et une palette dite imagerie. Les palettes thmatiques contiennent 100 couleurs, les palettes imageries 128 couleurs. Il est donc possible de dessiner simultanment deux dgrads. Par exemple, pour dessiner une photographie arienne code sur 256 niveaux, on peut utiliser une palette de gris et une fonction de correspondance entre chaque niveau de limage et la palette imagerie (par dfaut, f(x)=x/2). Pour augmenter le contraste de limage, on peut soit modifier la palette de gris (en restreignant la variation de gris), soit modifier la fonction de correspondance (f(x)=(b-a)x/255 + a, pour une variation entre la couleur dindice a et la couleur dindice b de la palette initiale). La carte conserve ses palettes et les charge automatiquement lors de son ouverture. Certains ordinateurs sont limits dans lutilisation de la couleur sur cran : il est encore courant, dans certaines rsolutions dcran, de ne pouvoir afficher que 256 couleurs simultanment. Dans ce cas, SAVANE utilise les couleurs des deux palettes de la carte, plus les couleurs rserves par le systme dexploitation (20 couleurs). Si la couleur dun lment graphique ne fait pas partie des couleurs des palettes courantes ou des couleurs systme, llment est dessine sur lcran avec la couleur la plus proche (on utilise pour cela une fonction de distance euclidienne sur les couleurs en utilisant les trois composantes comme des coordonnes). 9.3. Lexplorateur cartographique 9.3.1. Principes de lexplorateur cartographique Lexplorateur cartographique regroupe lensemble des informations permettant de dessiner dans un cadre partir des objets gographiques des relations quil contient. A chaque cadre est donc associ un explorateur cartographique. Il conserve

326

Chapitre 9

le choix des relations dessiner, leur ordre de dessin, et pour chaque relation choisie, le choix de limplantation graphique, des attributs et des variables visuelles associes. De nombreux choix sont possibles, et les combinaisons possibles sont quasiment illimites. Une mme relation peut tre choisie plusieurs fois, et tre dessine dans le cadre avec des paramtres diffrents. Elle peut galement ne pas tre trace mais nanmoins conserver lensemble de ses paramtres de dessin. A chaque implantation graphique correspond une classe regroupant les paramtres de dessin propre cette implantation graphique (CDessinZone, CDessinLigne, CDessinSymbole, CDessinPixel, A.4.2.6.). Le type de la relation dtermine les choix possibles pour limplantation graphique. Ensuite, pour chaque type dimplantation graphique choisi, lutilisateur indique lattribut reprsenter et la ou les variables visuelles associes cet attribut. Nous allons dcrire les possibilits et les paramtres correspondant chaque type dimplantation graphique. Pour chaque relation choisie, lutilisateur accde aux paramtres de dessin grce un bouton proprits du dialogue de lexplorateur (fig. 9.5).

fig. 9.5 : le dialogue principal de lexplorateur cartographique

Lexplorateur cartographique donne galement la possibilit de tracer des masques, des fonds graphiques, ou des documents de saisie au format SAVEDIT. Ces lments ne contiennent aucune information descriptive : les paramtres de dessin choisis seront appliqus tous les lments (CDessinFond, A.4.2.6.). Les figurs dessins partir des objets ne sont pas des objets de dessin au mme titre que les objets dessins directement sur lcran grce lditeur graphique. Lutilisateur ne peut les slectionner ou les modifier indpendamment les uns des autres. Ils sont attachs au cadre et se dplacent automatiquement avec lui. Faire une carte avec SAVANE utilise donc deux outils : dune part les cadres et leur

Reprsenter 327 explorateur cartographique, dautre part lditeur graphique qui est actif en permanence dans la fentre principale du programme. 9.3.2. Limplantation graphique ponctuelle Limplantation graphique ponctuelle peut tre utilise par tout type de relation, sauf pour le type mosaque. En implantation ponctuelle, plusieurs types de figurs peuvent tre dessins : un symbole, un diagramme sectoriel, un texte. Pour chaque objet de la relation, llment dessin utilise la localisation du centrode de lobjet (rappelons que pour une ligne, le centrode est situ automatiquement au milieu de la ligne ; pour une zone, il est choisi lors de la saisie graphique ; pour un point, il correspond la position de lobjet lui-mme).

fig. 9.6 : les trois possibilits de figurs en implantation ponctuelle : symboles, valeurs, diagrammes sectoriels

La reprsentation par symbole permet dassocier un symbole chaque objet. La forme du symbole peut tre la mme pour tous les objets, ou varier en fonction dune variable qualitative. Lutilisateur dispose pour cela dune palette de formes de symboles prdfinies. Lorsquil souhaite faire varier la forme en fonction dun attribut nominal, il tablit une correspondance entre chaque valeur reprsenter et une forme de symbole. La couleur de lintrieur du symbole peut galement varier selon une variable qualitative. La taille du symbole peut tre la mme pour tous les objets ou varier selon une variable numrique. La couleur et lpaisseur du trait sont choisies par le cartographe et sont les mmes pour tous les objets de la relation. La reprsentation par symbole permet donc dutiliser simultanment trois variables visuelles : forme, taille, couleur, suivant au maximum deux variables descriptives

328

Chapitre 9

distinctes. Le centre du symbole est toujours situ sur le centrode de lobjet. La surface totale des symboles reprsents ne doit pas dpasser 20 30 % de la surface totale du cadre [BER 77].

fig. 9.7 : la reprsentation par symbole selon deux caractres

La reprsentation par diagramme permet dassocier un diagramme sectoriel (camembert ou histogramme) chaque objet, en fonction des valeurs de plusieurs attributs numriques. On peut ainsi reprsenter pour chaque objet les proportions relatives de chacun des attributs numriques (fig. 9.8). La reprsentation de texte permet de dessiner la valeur dun attribut pour chaque objet. Lattribut peut tre numrique ou nominal. Il est possible de choisir la

Reprsenter 329 position de la chane de caractre par rapport au centrode, mais de faon identique pour tous les objets. Comme nous lavons dj mentionn, les figurs dpendent de lexplorateur cartographique et ne peuvent tre modifis la main directement par lutilisateur. Mais il est courant davoir dplacer un texte lorsque le placement automatique calcul par lexplorateur cartographique nest pas satisfaisant. Pour cela, il est possible de dtacher les textes de lexplorateur et de les transformer en lments de dessin de type CODD. Lutilisateur pourra alors slectionner un texte pour le dplacer si ncessaire, mais ce texte ne sera plus automatiquement attach au cadre.

fig. 9.8 : la reprsentation par diagramme sectoriel suivant trois attributs descriptifs

La classe CDessinSymbole permet de conserver lensemble des paramtres de dessin en implantation ponctuelle (A.2.4.6). Elle contient notamment une procdure de trac par type de reprsentation (TracerSymbole(), TracerDiagramme(), TraceValeurs()). 9.3.3. Limplantation graphique zonale Limplantation graphique zonale ne peut tre choisie que pour les relations de type zone. Elle apparat dans le dialogue des proprits de trac dune relation de type zone sous longlet Zone . Il est alors possible de choisir un attribut pour tracer lintrieur des zones (fig. 9.9). Le trac des contours relve de limplantation graphique linaire que nous verrons au paragraphe suivant.

330

Chapitre 9

Si lattribut choisi est nominal, il faut tablir la correspondance entre chaque valeur reprsenter et la couleur, la valeur, le grain associ. On peut donc agir simultanment sur ces trois variables visuelles, grce au dialogue de constitution de ce que nous appelons une palette de valeur (association entre des valeurs nominales, et des couleurs et des trames). Lutilisateur dispose pour cela de la palette de couleur courante et dune palette de trames correspondant des variations de forme, de valeur ou de grain dun aplat.

fig. 9.9 : les dialogues pour le trac en implantation zonale

Reprsenter 331 Si lattribut choisi est numrique, on peut faire varier la couleur ou la valeur en fonction de lattribut. Pour faire varier la couleur, lutilisateur tablit une correspondance entre les valeurs minimum et maximum reprsenter et deux couleurs de la palette, ainsi quune fonction dtalement (linaire, logarithmique, exponentielle). Le systme affecte alors chaque objet, en fonction de la valeur de lattribut, la couleur de la palette correspondant au rang calcul en utilisant la fonction dtalement. La valeur, correspondant la trame choisie, est alors la mme pour tous les objets. Pour faire varier la valeur, il tablit une correspondance entre les valeurs minimum et maximum reprsenter et deux valeurs de trames. Le systme calcule de la mme manire pour chaque objet la trame correspondante. Une option particulire permet destomper la couleur en fonction de la valeur dune relation de type mosaque. On fait alors varier lintensit de la couleur (sans changer le ton), en fonction de la valeur de chaque pixel de la mosaque. Ce type de trac correspond en fait au trac dune mosaque, puisque lon trace finalement les pixels et non les zones. La mosaque est le plus souvent un modle numrique de terrain, et lestompage est calcul en fonction de la quantit de lumire rflchie par chaque pixel, partir dune source lumineuse. La classe CDessinZone permet de stocker lensemble des paramtres de dessin en implantation zonale (A.2.4.6). 9.3.4. Limplantation graphique linaire Limplantation graphique linaire ne peut tre choisie que pour les relations de type zone ou ligne. Pour les zones, elle correspond au trac des contours des objets. Pour les lignes, elle correspond au trac des objets eux-mmes. Lorsque la relation est de type zone, on peut tracer tous les arcs avec les mmes paramtres (couleur, paisseur, forme), ou diffrencier les paramtres en fonction de lgalit dun attribut pour les deux zones adjacentes. Lattribut choisi peut tre nominal ou numrique. Lorsque la relation est de type ligne, on peut agir directement sur la couleur, lpaisseur, et la forme de chaque arc. On peut donc faire varier simultanment trois variables visuelles : couleur, valeur, forme. Le principe est le mme que pour le trac de symboles : la couleur et la forme peuvent varier en fonction dun attribut nominal (on tablit alors une palette de valeurs nominales), et lpaisseur du trait peut varier en fonction dun attribut numrique. Lutilisateur dispose dune palette de formes pour les types de ligne.

332

Chapitre 9

Lorsque la relation est de type ligne, une option supplmentaire permet de tracer les lignes comme des courbes de niveaux, en diffrenciant les paramtres de trac (couleur, paisseur) en fonction dun attribut numrique.

fig. 9.10 : proprits de dessin pour les relations de type ligne

La classe CDessinLigne permet de stocker lensemble des paramtres de dessin en implantation linaire (A.2.4.6). 9.3.5. La reprsentation des images La reprsentation des images correspond une implantation zonale, chaque pixel pouvant tre considr comme une zone. Mais il est trs rare de vouloir tracer les contours des pixels, ou de vouloir reprsenter chaque pixel dune mosaque par un symbole. De plus, certaines mthodes de visualisation utilisent lagencement des pixels, et sont donc propre au type mosaque. Enfin, seul le type mosaque utilise le type dattribut RVB, qui conserve une couleur absolue pour chaque objet. Nous avons donc spar les procdures de trac des relations de type mosaque des procdures de trac des relations de type zone. Le trac dune relation de type mosaque ne comporte donc que le choix de limplantation zonale. Le dialogue ne comporte pas de page correspondant au trac par symbole ou par contour.

Reprsenter 333 Le principe du trac dun attribut nominal est le mme que pour les zones : il faut tablir une palette de valeurs donnant la correspondance entre les valeurs nominales reprsenter et la couleur et la trame. Si lattribut choisi est de type numrique, il peut tre reprsent par valeur, comme pour les zones. On tablit alors une correspondance entre les valeurs reprsenter et les couleurs dessiner, comme pour les zones. Un attribut numrique peut galement tre reprsent par illumination : lindice de la couleur dans la palette de couleur est alors calcul en fonction de la quantit de lumire mise par le pixel. Cette quantit de lumire dpend de la position de la source lumineuse et de la normale au pixel, calcule en fonction des pixels voisins (sur une matrice 3x3). Cest ainsi que lon reprsente en gnral les modles numriques de terrain, cest--dire lattribut altitude dune mosaque calcule partir de courbes de niveaux.

334

Chapitre 9

fig. 9.11 : reprsentation dun mnt par valeur, par illumination, par estompage (combinaison de valeur et illumination)

La classe CDessinPixel permet de stocker lensemble des paramtres de dessin en implantation de type pixel (A.2.4.6). 9.3.6. Masques, fonds graphiques, documents digitaliss Lexplorateur cartographique donne galement la possibilit de tracer dans un cadre des masques, des fonds graphiques, ou des documents digitaliss. Un masque nest reli aucun attribut : cest seulement la dfinition dun domaine de lespace. Pour le reprsenter, on peut donc jouer sur le figur du contour, de lintrieur ou de lextrieur. On peut donc choisir la couleur, la forme et lpaisseur du contour ; la couleur et la trame de lintrieur ou de lextrieur. Lexplorateur cartographique donne galement la possibilit de tracer un document graphique go-rfrenc, au format DXF. Les paramtres graphiques ne peuvent tre modifis dans SAVANE : le document est trac tel quil a t constitu lextrieur du systme. Il sadapte la projection gographique du cadre sil contient un fichier dcrivant sa propre projection gographique. 9.3.7. Les procdures de trac Les procdures de trac des lments vectoriels (points, lignes, contours) utilisent tous les paramtres de position du cadre pour dessiner les figurs. Toutes les coordonnes vectorielles des objets et des arcs sont conserves en coordonnes gographiques dans SAVANE. Le dessin dun point dans la carte ncessite plusieurs changements de coordonnes : - une transformation correspondant la projection gographique associe au cadre gographique ; - une transformation correspondant lespace gographique dlimit par le cadre et lchelle cartographique du cadre (translation-homothtie) ; - une transformation correspondant la position du cadre dans la carte (translation). Lorsque le trac correspond lcran, il faut ajouter une transformation correspondant la position de la carte dans lcran et au facteur dagrandissement (translation-homothtie).

Reprsenter 335 Les procdures de trac dune mosaques sont diffrentes : le dessin est effectu en traant les lignes des imagettes de la mosaque, par balayage. Chaque imagette est gorfrence en coordonnes de projection, et la taille du pixel permet de connatre lemplacement exact de la ligne dans le cadre, et donc dans la carte. Limpression sur papier utilise quant elle des procdures de dessin de bitmap, contenue dans la MFC (Microsoft Fundation Class). Le dessin daplat pour les zones rend ncessaire la constitution du contour de chaque zone, si lon veut utiliser une procdure vectorielle de remplissage. Le systme SAVANE, comme nous lavons vu, ne conserve pas cette structure pour chaque zone. Reconstituer les contours par chanage des arcs chaque rafrachissement du trac sur cran serait trop long : les aplats sont tracs sur lcran partir de limage raster associe chaque relation de type zone. Cette image raster est donc calcule lors du premier trac, si elle nexiste pas encore. Par contre, limpression daplat utilise une procdure vectorielle, avec reconstitution des contours, en utilisant la classe CZone (A.2.2.6.). 9.3.8. Les lgendes La lgende correspond lexplication de la correspondance entre valeurs des objets et implantation graphique et variables visuelles utilises pour la reprsentation cartographique. Lexplorateur cartographique dun cadre contient lensemble des paramtres de cette correspondance, et il est donc galement utilis pour tablir une lgende.

336

Chapitre 9

fig. 9.12 : diffrents types de lgendes gnrs partir de lexplorateur cartographique et des dialogues de proprits de lgende

Une lgende dpend bien sr du type dimplantation graphique choisi pour reprsenter les objets. Par exemple, pour une implantation zonale et un attribut nominal, la lgende sera constitue de caissons donnant la correspondance entre valeur de lattribut et couleur et forme utilise. Pour une implantation ponctuelle et un attribut numrique, la lgende indique la variation de taille du symbole utilis. Pour constituer une lgende, on choisit donc une entre dans lexplorateur cartographique : le dialogue de constitution de la lgende dpend ensuite du type dimplantation graphique, du type de lattribut reprsent, et de la variable visuelle utilise. Une fois la lgende pose dans la carte, elle est considre comme du dessin graphique, et peut tre modifie grce lditeur graphique. Par contre, le lien entre la lgende et lexplorateur cartographique est perdu : la lgende nest pas mise jour automatiquement en cas de modification des paramtres de reprsentation cartographique. Comme une lgende est un ensemble de figurs qui dpendent de nombreux paramtres (par exemple, taille des caissons, largeur de linterligne, couleur et paisseur du bord des caissons, etc.), nous avons dvelopp des classes propres chaque type de lgende (CLegendeCaisson, CLegendeSymboleParTaille,
CLegendeSymboleParValeur, CLegendeDegrade, CLegendeDiagrammeCaisson, CLegendeDiagrammeParTaille, ClegendeLigneParTaille, CLegendeLigneParValeur).

La lgende ne replace pas la notice de la carte, explication et analyse du phnomne reprsent. 9.4. La reprsentation en perspective La smiologie graphique se limite la reprsentation sur une feuille plane dobjets en utilisant des implantations graphiques limites deux dimensions. La

Reprsenter 337 reprsentation en perspective ou lanimation sortent de ces limites. La cartographie classique nutilise donc pas, ou trs peu, la reprsentation en perspective (nomme 2.5D) ou en volume. Dans un SIG, la localisation de lensemble des objets gographiques nest que trs rarement dcrite en trois dimensions (longitude, latitude, altitude). Mais il est assez courant de disposer dune relation dcrivant laltitude dans la zone tudie, avec une certaine prcision : soit on dispose dun modle numrique, soit de courbes de niveaux permettant de le calculer. Par jointure entre le modle numrique de terrain et les autres collections dobjets localiss, le SIG permet donc davoir une ide de laltitude de lensemble des objets gographiques de la zone tudie. Il est donc dommage de ne pas utiliser cette altitude pour la reprsentation des objets et de toujours se limiter une reprsentation projete dans les deux dimensions du plan de projection gographique. La reprsentation en perspective est la solution la plus lgante pour rendre compte du relief sur une feuille de papier plane. Elle est facile mettre en uvre avec un ordinateur (classe CPerspective, A.2.4.9.). Elle consiste reprsenter le modle numrique de terrain illumin en projetant chaque pixel du modle sur un plan, selon une perspective centrale ou cavalire, en liminant les parties caches. Une carte est reprsente en perspective en superposant les figurs aux pixels du modle numrique. Reprsenter des figurs en perspective nest techniquement pas difficile si lon peut connatre laltitude des points qui en dfinissent le trac. Par contre, linterprtation de la carte peut alors tre plus complexe, car la perspective change limpression visuelle de nombreux signes graphiques et altre la signification ou la lisibilit de la carte. Ainsi, la surface dun symbole projet en perspective peut varier considrablement en fonction de la pente ou de lorientation du terrain ; une partie de texte peut tre cach par une montagne ; les trames sont sujettes aux effets de moirs. Dune manire gnrale, les variables visuelles taille et valeur sont difficiles reprsenter, quelle que soit limplantation graphique des figurs, et lon doit viter de les utiliser dans une reprsentation en perspective. Par contre couleur et forme sont les variables visuelles qui sont le moins altres par la reprsentation en perspective. Le systme SAVANE permet la reprsentation en perspective partir dun modle numrique de terrain. Le systme cre une image (de type bitmap), indpendante de la carte, mais que lutilisateur peut ajouter la feuille de papier reprsentant la carte sur lcran. Lutilisateur choisit les paramtres de la perspective (cavalire ou centrale ; point de vue ; position de la source lumineuse), puis, parmi les entres de lexplorateur cartographique, celles quil souhaite superposer au

338

Chapitre 9

modle numrique de terrain. Les paramtres cartographiques sont inchangs : seule la reprsentation graphique est modifie par la perspective.

fig. 9.13 : dialogues pour crer une vue en perspective

fig. 9.14 : reprsentation en perspective cavalire des valeurs daltitude dun mnt

9.5. Louverture ou la sauvegarde dune carte dans SAVANE La carte, document de base dans le module dinterrogation SAVANE, regroupe lensemble des paramtres dinterrogation et de reprsentation cartographique dune requte. Tous les fichiers correspondant une carte sont conservs dans un rpertoire qui se trouve dans le rpertoire d_carte de lutilisateur. Sauver une carte permet de conserver lensemble des paramtres ainsi que ltat de la base de donnes correspondant chaque cadre de la carte. La procdure dune carte comprend plusieurs phases :

Reprsenter 339 - sauvegarde des objets graphiques dessins par lutilisateur (conservs dans un fichier dextension .obj) ; - sauvegarde des paramtres de la carte et des cadres (conserv dans un fichier dextension .sav). La sauvegarde dun cadre comprend la sauvegarde des paramtres graphiques du cadre, des palettes de couleurs, la sauvegarde de ltat de la base de donnes correspondant au cadre conserve dans un objet de la classe CSchema. La sauvegarde dun schma comprend la sauvegarde du schma temporaire de la base de donnes. Les fichiers temporaires des relations modifies sont crs dans le rpertoire du cadre, qui lui-mme se trouve dans le rpertoire de la carte. Louverture dune carte relit lensemble de ces paramtres. Lutilisateur retrouve donc ltat complet de la carte, la fois pour le dessin et pour les requtes lies la base de donnes. Mais la base de donnes a pu subir des modifications de schma ou de valeurs dobjets entre la sauvegarde de la carte et son ouverture. De mme, la vue externe peut avoir t modifie. La procdure de lecture teste ces diffrences de manire mettre jour le schma des cadres. Par contre, si la valeur de certains objets a t modifie, les relations temporaires ne sont pas mises jour automatiquement, puisquelles conservent les anciennes valeurs des objets. Pour actualiser la carte, il faut excuter de nouveau lensemble des oprations effectues dans chaque cadre. Pour cela, il suffit de dclencher la macro-commande associe chaque cadre : cette macro-commande conserve automatiquement lensemble des oprations qui ont t effectues dans le cadre. Tous les objets intervenant dans une carte (cadres, objets graphiques, schma) possdent des mthodes permettant de sauver ou de lire ces objets partir des deux fichiers de sauvegarde.

340

Chapitre 9

Reprsenter 341

Bibliographie

[BEG 94] BEGUIN M., PUMAIN D., La reprsentation des donnes gographiques, 2000, CURSUS, Armand Colin [BER 67] BERTIN J., Smiologie graphique, 1967, Gauthiers-Villars, Paris [BER 77] BERTIN J., Le graphique et le traitement graphique de linformation, 1977, Flammarion, Paris

Conclusion

Tout au long de cet ouvrage, nous avons dcrit la construction dun systme dinformation visant rpondre aux impratifs que nous lui avions fixs au dpart. Nous avons abord au cours de cette construction de nombreux domaines et appliqu de nombreuses mthodes pour aboutir la description de ce systme complet. Dans cette conclusion, nous souhaitons la fois revenir sur les points forts de cette construction et dcrire les enseignements de son utilisation dans un cadre oprationnel, par rapport aux objectifs fixs, et prsenter en quoi ce systme pourrait tre amlior pour mieux rpondre aux difficults rencontres lors de son utilisation. Ces difficults se situent essentiellement dans le domaine de lintelligibilit des donnes, de la documentation des bases de donnes et de lexplication des traitements effectus dans une carte. 1.1. La construction dun SIG : synthse Tout dabord, il faut souligner que le systme que nous avons construit cherche privilgier la rigueur et la logique sur la facilit dutilisation. Il nesquive donc pas la complexit lorsque celle-ci est ncessaire pour maintenir la cohrence et la rigueur des principes thoriques, principes que nous avons largement dtaills pour cela tout au long de cet ouvrage. Dautre part, il faut galement prciser que ce systme a vocation tre utilis aussi bien dans un cadre industriel que dans un cadre scientifique. Il sagit donc de manipuler des donnes trs diverses, aussi bien du point de vue smantique que du point de vue qualitatif, dans leur gense comme dans leur prcision. Cette remarque qui peut paratre anodine recouvre en fait une ralit complexe, comme nous avons essay de le dvelopper au chapitre 3. Enfin, si

344

Conclusion logique de sa construction, cette chapitres ne reflte pas toujours techniques sinscrivent dans cette approfondie, rflexion qui a elle-

la prsentation de ce systme met en avant la logique a t longue construire : lordre des lordre de sa gense ; larchitecture et les choix logique mais ils ont donn lieu une rflexion mme permis de construire cette logique globale.

Nous avions fix plusieurs objectifs dans notre introduction : le premier tait la gestion centralise et la prennisation de linformation avec des objectifs de partage et defficacit. Pour assurer lintgrit des donnes, le modle relationnel simpose, condition de ltendre aux donnes localises. Pour une gestion efficace, il est ncessaire dutiliser une indexation primaire sur la localisation, puisque la localisation est un premier critre de slection pour la plupart des requtes dans un SIG. Enfin, la gestion multi-utilisateur et le partage des bases de donnes imposent la sparation entre administration et exploitation avec gestion des tats temporaires. Toutes ces conditions imposent la construction dun moteur de gestion de donnes propritaire au systme. Ce moteur, comme nous lavons dcrit, est bas sur le principe de la modlisation et de la gestion relationnelle avec des fonctionnalits orient-objet sur lesquelles nous reviendrons. La gestion relationnelle est tendue aux attributs reprsentant une localisation bi- ou tridimensionnelle dans un espace euclidien. Lindexation primaire est base sur cet attribut lorsquil est prsent. La gestion multi-utilisateur est dlicate : elle impose de sparer ladministration de lexploitation et interdit un utilisateur de modifier une base de donnes si cela peut entraner un disfonctionnement de lutilisation par dautres. Le systme que nous avons construit est ainsi diffrent des systmes commerciaux les plus rpandus : il ne se base pas sur un SGBD relationnel commercial classique et conserve le rsultat des requtes non pas dans la base initiale mais dans des tats temporaires, propre chaque utilisateur. Cette gestion rend la conception du systme plus complexe, mais elle permet le partage des bases de donnes sans provoquer dinterfrence entre utilisateurs. Elle peut paratre trop complexe un utilisateur isol qui serait le seul utilisateur de sa base de donnes, car elle lui impose des contraintes dont il ne voit pas forcment lutilit. Par contre, elle sera perue comme transparente et naturelle dans un environnement o les donnes doivent tre prennises et gres pour tre partages. Elle permet la sparation claire du serveur de base de donnes et du client, tout en autorisant une approche exploratoire lors de linterrogation des donnes qui nous parat essentielle en analyse spatiale - et la gestion dtats temporaires de la base de donnes lors dune requte. Linterrogation via Internet se base sur ce mme principe, sans avoir changer la structure du systme : le client est simplement hors du rseau local. Seules les techniques daccs aux fichiers de la base de donnes et la gestion des reprises sur erreurs diffrent. Par contre, les temps de transfert de linformation entre le client et le serveur sont encore un frein important ce dveloppement, que nous navons pas souhait aborder dans cadre de cet ouvrage.

Conclusion 345 La gestion intgre de la localisation impose de pouvoir manipuler lensemble des types dobjets gographiques disponibles ; elle impose galement la matrise de la mesure et de la prcision de la localisation. Nous sommes donc revenu en dtail sur la modlisation du monde rel et sur la schmatisation de la ralit en objets gographiques. La gestion interne de lattribut de localisation dpend du type des objets. Mais le systme se charge de cette gestion : lutilisateur nintervient jamais ce niveau. Cest le moteur interne qui se charge de lensemble des oprations de gestion de cet attribut qui est toujours vu comme formel par lutilisateur. Par exemple, il na jamais intervenir sur le codage interne de la localisation, quil peut dailleurs ignorer. Ainsi, il manipule des pixels dimages de la mme manire que des lignes dun rseau ou que des zones dune couverture vgtale. Cette gestion intgre nest possible qu condition que la localisation soit exprime dans un rfrentiel unique. Nous sommes revenu longuement sur ce sujet important au chapitre 4. La saisie de la localisation est fondamentalement diffrente de la saisie dattributs classiques, nominaux ou numriques. Elle est directement lie au type des objets localiss et doit prendre en compte lensemble des contraintes dintgrit lies ces types. Elle doit sappuyer sur la modlisation de la ralit et grer la prcision lie au modle. Les mthodes de saisie emploient diverses techniques, du redressement dimage la saisie de contours de zones. Nous lui avons consacr deux chapitres de cet ouvrage. Lopration de saisie est une opration indpendante de la gestion de base de donnes. Pour faciliter lutilisation du systme, ces fonctions donnent donc lieu des modules distincts, indpendants du module dadministration ou dexploitation des bases de donnes. Ils assurent lintgrit de lattribut de localisation. Ces modules nont pas t conus comme des diteurs graphiques sur lesquels nous aurions ajouts des fonctions des contrles : la vrification des contraintes dintgrit en est le noyau, et ils ont t techniquement construits autour de ces fonctionnalits. Enfin, le systme doit aller au-del de simples fonctionnalits de gestion et doit intgrer des fonctionnalits trs diverses qui en font autant un programme dapplication quun systme de gestion de base de donnes. La premire de ces fonctionnalits, cest de permettre la reprsentation cartographique des donnes. Le module dexploitation permet donc ldition graphique et la reprsentation cartographique partir des objets de la base de donnes utilise. Cette fonctionnalit incontournable dtermine largement lergonomie de ce module. La plupart des autres fonctionnalits sont lies lexploration statistique ou aux types gnriques des objets localiss (zone, ligne, point, pixel). Elles sont intgrs dans le module dexploitation et sont indpendantes du contenu smantique des relations de la base. Des fonctionnalits plus spcialises peuvent tre intgres au module dexploitation. Cest la cas par exemple de lexploitation des modles numriques

346

Conclusion

de terrain pour lhydrologie. Mais la dmarche habituelle sera plutt celle du couplage avec des programmes dapplication, le systme se chargeant alors de linterface entre les deux systmes. Lautre approche consiste intgrer dans un programme dapplication spcialis des ordres daccs aux objets gographiques dune base de donnes, partir dun langage de programmation et dune bibliothque de primitives (nous avons pour cela construit une librairie de primitives SAVANE en C++). Mais on perd alors les capacits dexploration, danalyse spatiale ou ddition cartographique du SIG, en se limitant la gestion des objets. Lambivalence entre gestion dune base de donnes et programme dapplication est en fait au cur des difficults dutilisation dun SIG, qui on demanderait volontiers de rpondre lensemble des besoins. Plus gnralement, de nombreux objets gographiques ont des caractristiques dutilisation propres leur dfinition smantique, au-del des types dobjets gographiques qui proviennent de la modlisation cartographique de la ralit. En gnral, ces caractristiques ne sont pas intgres dans la base de donnes, qui se limite aux attributs et nintgrent pas les mthodes dutilisation de ces attributs. On perd ainsi une grande partie de linformation, celle qui serait peut-tre la plus utile dans le cadre de lexploitation de la base de donnes. Lutilisation dun SIG est en effet trs diffrente dune base de donnes classique : la requte fait souvent appel une dmarche exploratoire ; lexploration des donnes influence largement lutilisateur dans les traitements quil envisage dappliquer aux donnes. De plus, il ny a pas capitalisation du savoir acquis par lexploitation de la base de donnes, le SIG tant exploit peu prs comme pourrait ltre une base de donnes classique. Cette dficience est majeure, car dans un SIG, les requtes sont souvent difficiles exprimer, beaucoup plus en tout cas que dans le cadre des base de donnes relationnelles classiques o la seule vrai difficult, pour rpondre une question, est celle de lutilisation dun formalisme dpendant de la mthode de gestion. 1.2. Vers plus dintelligibilit pour les bases de donnes gographiques En rsum, le principal enseignement de lutilisation dun systme comme celui que nous avons construit, cest dune part sa difficult dutilisation face un corpus de donnes habituellement htrogne et dautre part la faible capitalisation de la connaissance induite par son utilisation. La difficult dutilisation ne vient pas de lergonomie ou de la structuration et de la gestion de linformation, car nous lavons justement construit avec lobjectif de librer lutilisateur de toute tche de gestion de donnes. Le systme remplit avec satisfaction ces tches et assure avec succs la prennit des bases de donnes. La difficult dutilisation vient essentiellement de la diversit des domaines que nous avons abord : la connaissance de ces domaines est ncessaire une bonne

Conclusion 347 utilisation dun SIG quel quil soit. En particulier, le systme doit remplir, au del des fonctions de gestion, des fonctions danalyse et de modlisation pour aboutir des rsultats synthtiques. La difficult est inhrente laspect programme dapplication, car le systme ne propose pas assez de mthodes sur linformation quil gre. Or, les utilisateurs attendent plus quune simple aide ou quune liste doprations susceptibles dtre effectues sur un jeu de donnes. Ils souhaiteraient souvent que le SIG se charge tout seul de lanalyse ou leur indique quel chemin suivre parmi les nombreuses possibilits qui leur sont offertes. Paradoxalement, la multiplication des possibilits fonctionnelles nuit lutilisation et la simplicit recherche par la plupart des utilisateurs. Enfin, la difficult dutilisation provient galement de la structure mme de linformation gographique : elle induit une dpendance fonctionnelle entre localisation et description, et elle rsulte le plus souvent dune modlisation initiale qui nest pas toujours connue ou bien documente. La question qui pourrait nous tre pos est donc maintenant : comment construire un logiciel SIG dont lutilisation ne ncessite pas lensemble de cette connaissance gographique ? . Cette question na srement pas de rponse globale. Il est peu probable que lon pourra arriver concevoir un systme qui conserverait la rigueur scientifique ncessaire la gestion et au traitement de linformation gographique mais qui nexigerait de lutilisateur quune faible connaissance des contraintes lies cette rigueur. On peut malgr tout essayer damliorer le systme pour aller dans ce sens. Ces amliorations concernent lintelligibilit des bases de donnes, et vont dans trois directions : - amliorer la connaissance de linformation par lintgration systmatique de mta-donnes pour renseigner sur la gense des donnes et le rapport entre localisation et description (la prcision gographique) ; - amliorer la connaissance en intgrant dans la base de donnes des mthodes dutilisation ; - permettre la capitalisation de la connaissance en permettant la documentation ou lintgration de mthodes dutilisation des donnes, autant au niveau de la base de donnes elle-mme que sur les rsultats cartographiques des requtes. Une carte devrait en toute logique comporter toujours une notice permettant de comprendre quelle a t la dmarche qui a abouti son laboration. Larchitecture du systme SAVANE permet davancer dans ces trois directions. Les mta-donnes peuvent tre gres avec un systme de gestion classique partir du dictionnaire de la base de donnes gre par SAVANE. Elles doivent comporter des champs fixes (dfinis pour lensemble des relations), des champs dpendant du type gomtrique de relation, et des champs variables laisss au choix de

348

Conclusion

ladministrateur ou du fournisseur de linformation. Il est trs difficile dtablir de faon rigide la structure des champs fixes de cette base de donnes, car lon arrive rapidement concevoir un schma qui ne sera en fait pas respect en pratique : il est courant davoir moins de 20 % de rponses sur un schma de mta-donnes Il semble donc plus efficace davoir une approche plus souple, cest--dire de limiter les variables requises et de mettre laccent sur la gestion de donnes htroclites, non structures en attributs, dcrivant linformation de chaque relation. La vision du schma peut galement tre amliorer en introduisant un regroupement thmatique de relations ou dattributs au niveau des vues externes. Une vue externe est alors une hirarchie de thmes dont seules les feuilles correspondent des relations ou des attributs rels de la base de donnes. Le second point est sans doute le plus riche pour lutilisateur : il consiste introduire dans la base de donnes des mthodes dutilisation construites partir des oprations relationnelles ou danalyse disponible dans le module de base, ou partir de modules dapplications externes appels par le systme. Ces mthodes sont conservs techniquement sous la forme de macro-commandes ; lutilisateur accde au schma des mthodes comme il accde au schma des donnes. La base de donnes passe donc du schma relationnel au schma objet, tout en conservant la gestion interne relationnelle qui lui permet dassurer la cohrence de linformation. Cette approche permet dintroduire de la connaissance dans des bases de donnes souvent difficiles exploiter ; elle permet de proposer lutilisateur des mthodes qui peuvent aller du simple calcul dune densit ou dun indice de vgtation une application complte. Une base de donnes contenant des mthodes devient en soi un objet de connaissance, et disposer ce cette connaissance change lapproche dans llaboration mme dune base de donnes : dans de nombreux cas, le schma de la base de donnes sera dtermin par les mthodes que lon souhaite pouvoir utiliser par la suite. On peut ainsi proposer des schmas de base de donnes gographiques permettant de rpondre un certain nombre de questions, grce des mthodes fournies avec le schma. Lapproche classique dans llaboration est donc inverse : les mthodes dapplication ne sont plus dtermines par la structure de linformation, cest la structure de la base qui est dtermine par les mthodes que lon souhaite pouvoir utiliser. Cette approche est bien sr fortement contextuelle : elle doit dboucher sur la dfinition dobjets gographiques, valables dans un contexte donn, et contenant mthodes et donnes permettant de les utiliser dans ce contexte. Cette approche permet de capitaliser de la connaissance au niveau de la base de donnes, mais elle nest pas suffisante pour conserver lensemble de la connaissance labore dans lutilisation du SIG. En effet, elle conserve des mthodes dutilisation sous forme de macro-commandes, mais ne renseigne pas sur le cheminement gnral dune application ou sur llaboration cartographique du rsultat. Il est

Conclusion 349 galement ncessaire de conserver cette information. Dans SAVANE, nous dveloppons donc galement des mthodes de documentation au niveau dun cadre, dans une carte, comme au niveau de la carte elle-mme. Cette documentation est difficile structurer par un schma analytique : nous avons choisi de la conserver sous forme de texte, limage dune notice ; le texte est labor par lauteur de la carte. A chaque cadre dans une carte et chaque carte est donc attach un document de type texte qui est la disposition de lutilisateur et auteur de la carte, contrairement aux mthodes qui sont gres au niveau de ladministrateur de la base de donnes. Ces trois approches sont en cours de dveloppement au sein du systme SAVANE. Elles sappuient sur la gestion relationnelle tendue aux donnes localises : les mta-donnes partir du dictionnaire de la base, les mthodes partir doprations de gestion ou dapplications externes, les notices partir du rsultat dune requte. Elles permettent dtendre la gestion relationnelle en intgrant une approche orient objet et hypermdia, tout en conservant la rigueur de ce modle de gestion pour les donnes localises.

Bibliographie gnrale

[ABE 84] ABEL D.J., A B+-Tree Structure for Quadtrees, Computer Vision, Graphics, and Image Processing, 1984, vol. 27, n 1, p. 19-31 [ABI 95] ABITEBOUL S., HULL R., VIANU V., Foundations of Databases, 1995, AddisonWesley [AOK 79] AOKI M., Rectangular region coding for image data compression, Pattern Recognition, 1979, vol. 11, p. 297-312 [AMI 71] AMIDON E.L. AND ATKIN G.S., Algorithmic selection of the best method for compressing map data string : Communications, ACM, 1971, vol. 14, n 12, p. 769-774 [BAL 98] BALMINO G., Champ de pesanteur terrestre et gode. Principes, progrs et connaissance actuelle, 1998, Bureau Gravimtrique International, Toulouse, France [BAR 88] BARUCH O., Line Thinning by Line Following, Pattern Recognition Letters, 1988, Vol. 8, p. 271-276 [BEG 94] BEGUIN M., PUMAIN D., La reprsentation des donnes gographiques, 2000, CURSUS-Armand Colin, Paris [BEK 92] BEKKER J.H., Semantic Data Modeling, Prentice-Hall, 1992, New-York [BEN 93] BENKAZEN V., DOUCET A., Bases de donnes orientes objet, 1993, Armand Colin [BER 67] BERTIN J., Smiologie graphique, 1967, Gauthiers-Villars, Paris [BER 77] BERTIN J., Le graphique et le traitement graphique de linformation, 1977, Flammarion, Paris [BER 93] BERTINO E., MARTINO L., Object-Oriented Database Systems, 1993, AddisonWesley [BOT 98] BOTTON S ., DUQUENNE F., EGELS Y., EVEN M., WILLIS P., GPS, localisation et navigation, 1998, Herms, Paris [BOU 81], BOURSIER P., Reprsentation compacte des cartes dans les systmes dinformation gographique, Thse de 3-ime cycle, Universit Paris VI, 1981, [BOU 82] BOURSIER P. ET SCHOLL M., Performance Analysis of compaction techniques for map representation in geographic data cases, Computer and Graphics, 1982, vol. 6, p. 73-81

352

Bibliographie

[BOU 94] BOURSIER P., TAO-YUAN J., A model for Handling topological relationships in a 2D environment, Proceedings of the 6th International Symposium on Spatial Data Handling, 1994, Vol 1, pp 73-88, Endinburgh [BRE 65] BRESENHAM J.E., Algorithm for computer control of a digital plotter, IBM System Journal, 1965, vol. 14, n 1, p.44-50 [CAP 84] CAPSON D.W., An improved algorithm for the sequential extraction of boundaries from a raster scan, Computer Vision, Graphics, and Image Processing, 1984, vol. 28, n1, p. 109-125 [CAZ 94] CAZENAVE A., FEIGL K., Formes et mouvements de la Terre, 1994, Ed.Belin-CNRS [COO 67] COOK B.G., A Computer Representation of plane Region Boundaries, Autralian Computer Journal, 1967, vol. 1, n1, p.44-50 [CLE 93] CLEMENTINI E., DI FELICE P., VAN OOSTREROM P., A Small Set of Formal Topological Relationships Suitable for End-User Interaction, Proceedings of the 3th Symposium on Large Spatial Databases, 1993, Lecture Notes in Computer Sciences 692, pp 277-295, Singapore [CLE 95] CLEMENTINI E. DI FELICE, CALIFANO G., Composite Regions iin Topological Queries, Information Systems, 1995, Vol. 20, n7, pp 579-594 [COH 93] COHN A.G., RANDELL D.A., CUI Z., BENNETT B., Qualitaiv Spatial Reasoning and Representation, Preceedings of QUARDET 93, PP 513-522, Barcelona, Spain, 1993 [CUI 93] CUI Z., COHN A.G., RANDELL D.A. , Qualitativ and Topological Relationships in Spatial Databases, Proceedings of the 3th Symposium on Large Spatial Databases, 1993, Lecture Notes in Computer Science 692, pp 296-315, Singapore [DAN 81] DANGERMOND J., Some trends in the evolution of GIS technology, Marble Ed., 1981, Kensington Workshop, p. 25-57 [DAN 83] DANGERMOND J., Classification des lments logiciels utiliss habituellement dans les systme dinformation gographique, fascicule n 96 du comit franais de cartographie, 1983, p. 7-20 [DAT 90] DATE C., A Contribution to the study of database integrity, in Relational Database Writing, 1990, Addison-Wesley [DAT 95] DATE C.J., Introduction to Database Systems, 1995, Addison-Wesley [DAV 91] DAVID B., Modlisation, reprsentation et gestion dinformation gographique, un approche en relationnel tendu. Thse de doctorat, Universit Paris VI, 1991 [DAV 94] DAVID B., FASQUEL P., Qualit dune base de donnes gographique : concepts et terminologie, Bulletin dinformation de lIGN, 1994, n 67, Paris [DEL 91] DELOBEL C., LECLUSE C., RICHARD P., Bases de donnes : des systmes relationnels aux systmes objets. 1991, InterEditions, Paris [DIM 70] DIME, Technical description of the DIME System, U.S. Bureau of Census : Census and study, the DIME Geocoding System, Report n 4, Washington D.C., 1970, p. 25-30

Bibliographie 353
[DUF 98] DUFOUR J.P., Cours dintroduction la godsie, Ecole nationale des sciences gographiques,1998, IGN-ENSG [EGE 89] EGENHOFER M.J., A formal definition of binary topological relationships, Proceedings of the third International Conference FODO, Paris, Lecture Notes in Computer Science 367, 1989, Sprinter Verlag, Berlin, p.457-472 [EGE 90] EGENHOFER M.J. AND HERRING J.R., A mathematical framework for the definition of topological relationships, Proceedings of the 4th International symposium on Spatial Data Handling, 1990, Zurich p. 803-813 [EGE 91A] ENGENHOFER M., Spatial Query langages. Thse de doctorat, 1991, University of Maine, USA [EGE 91B] EGENHOFER M.J., FRANZOZA R.D., Point-Set Topological Relations, International Journal of Geographic Information Systems, 1991, 5-2, pp 161-174 [EGE 94] EGENHOFER M.J., CLEMENTINI E., SHARMA J., Modelling topological spatial relations : strategies for query processing, Computer and graphics, 1994, vol. 18, n6, pp 515-522 [EST 92] ESTES J., Remote sensing and GIS integration : research needs, status and trends. ITC Journal, 1992, n 1, p. 2-9 [FAI 96] FAIZ S.O., Modlisation, exploitation et visualisation de l'information qualit dans les bases de donnes gographiques, Thse de Doctorat, 1996, Univ. Paris XI Orsay [FLO 85] DE FLORIANI L., FALCIDIENO B., PIENOVI C., Delaunay-based Representation of Surfaces Defined over Arbitrary Shaped Domains, Computer Vision, Graphics, and Image Processing, 1985, n 32, p. 127-140 [FLO 93] DE FLORIANI L., MARZANO P., PUPPO E., Spatial Queries and Data models, in Frank A. and Campari I.U., Spatial Information Theory, Lecture Notes in Computer Sciences 716, 1993, Springer-Verlag, p. 113-138 [FRA 81] FRANCK A., Application of DBMS to Land information systems, CH 1701-2, IEEE 81, 1981, p. 448-453 [FRA 92] FRANK A.U., Qualitative Spatial Reasoning about Distances and Directions in space, Journal of Visual Langages and Computing, 1992, vol. 3, n 4, pp 343-371 [FRA 96] FRANK A.U, Qualitative spatial reasoning : cardinal directions as an example. International Journal of Geographical Information Systems, 1996, Vol. 10, n3, pp 269-290 [FRE 61] FREEMAN H., On the Encoding of arbitrary geometric Configuration, Inst. Radio Engineers Trans. Elec. Computers, 1961, vol. EG 10, p. 260-268 [FRE 75] FREEMAN J., The modelling of spatial relations, Computer Graphics and Image Processing, 1975, vol. 4, p. 156-171 [GAR 83] GARDARIN G., Bases de donnes : les systmes et leurs langages, 1983, Eyrolles, paris [GDT 93] GDTA, Les Spatiocartes, Cahiers Pdagogiques du GDTA, 1993 [GEO ] Gophysique, Encyclopdie de la Pliade, Gallimard, Paris

354

Bibliographie

[GOO 89] GOODCHILD M., GOPAL S., Accurancy of Spatial Databases, 1989, Taylor & Francis [GRE 89] GREENE D., Implementation and Performance Analysis of Spatial Data Access Methods, IEEE, Intl. Conference on Data Engineering, 1989, p.606-615 [GUN 89] GNTHER O., Efficient Computation of Spatial Joins. IEEE, Intl. Conference on Data Engineering, 1989, p.50-59 [GUP 95] GUPTILL S.C., MORRISON J.L., Pergamon/Elsevier Science, 1995 Elements of Spatial Data Quality,

[GUT 88] GTING R.H., Geo-Relational Algebra : A Model and Query Language for Geometric Database System, Proccedings of Intl. Conference on Extending Database Technology, 1988, p. 506-527 [HAA 96] HAADZILACOS T., TRYFONA N., A model for expressing topological integrity constraints in geographical databases, in Proceedings : Theories and Models of SpacioTemporal Reasoning in Geographic Space, 1996, International Conference GIS, Pisa, Italy. A. Frank, I. Campari, U. Fomentini (Ed.), pp 252-268 [HAG 73] HAGGETT P., Lanalyse spatiale en gographie humaine, 1973, Armand Colin, Paris [HAS 82] HASKIN R.L. AND LORIE R.A., On extending the functions of a relational database system. Association for Computing Machinery, Proccedings of SIGMOD, NY : ACM Press, 1982, p. 207-212 [HOT 99] HOTTIER, Photogrammtrie analytique, Cours ENSG, 1999 [LAR 93] LARUE T., PASTRE D., VIMONT Y., Strong Integration of Spatial Domains and Operators in a Relational Database System, Intl. Symposium on Large Spatial Databases, LNCS n 692, 1993, p. 53-72, Springer-Verlag [LAU 91] LAURINI R., MILLERET-RAFFORT F., Cohrence dans les bases de donnes spatiales, VIIe journes Bases de donnes Avances, INRIA, 1991, pp 471-488, Lyon [LAU 93] LAURINI R., MILLERET-RAFFORT F., Les bases de donnes en gomatique, Paris, Ed. Herms, 1993 [LAU 94] LAURINI R., Dtection et corrections d'erreurs topologiques dans les bases de donnes gographiques, Actes des premires journes de la recherche CASSINI, 1994, Lyon, France, pp 105-114 [LEV 88] LEVALLOIS J.J., BOUCHER C., BOURGOIN J., COMOLET-TIRMAN A., ROBERTOU A., Mesurer la Terre : 300 ans de godsie franaise, De la toise du Chtelet au satellite, 1988, Association franaise de topographie, Presse de lEcole Nationale des Ponts et Chausses, AFT, Paris [LOR 84] LORIE R.A., MEIER A., Using a Relational DBMS for Geographic Databases. GeoProcessing, 1984, p.243-257 [MAG 97] MAGELLAN SYSTEMS CORPORATION, User guide for the Magellan GPS ProMARK X-CM, 1997

Bibliographie 355
[MAT 84] MATSUYAMA T., LE VIET H., NAGAO M., A File Organisation for Geographic Information System based on Spatial Proximity, Computer Vision, Graphics, and Image Processing, 1984, vol. 26, n3, p.303-318 [MER 73] MERRILL R.D., Representation of contours and region for efficient computer search, Communication ACM, 1973, vol. 16, n2, p. 69-82 [MOL 94] MOLENAAR O, KUFONIYI O., BOULOCOS T., Modelling topological relationships in vector maps, Proceedings of the 6th International Symposium on Spatial Data Handing, 1994, pp 112-126, Endinburgh [MON 82] MONMONIER M., Computer-Assisted Cartography, Principles and Prospects, 1982, Prentice-Hall [ML 95] MLLER J.C., LAGRANGE J.P., WEIBEL R., (ed.), GIS and Generalization, GIS DATA I, 1995, Taylor & Francis [NEW 79] W. M. NEWMAN, R.F. SPROULL, Principles of Interactive Computer Graphics, 1979, Mc Graw Hill [NOV 92] NOVAK K., Rectification of digital Imagery. Photogrammetry Eng. And Remote Sensing, 1992, vol. 58, p.339-344 [OOI 89] OOI B.C., SACK-DAVIS R., MC DONELL K.J., 1989, Extending a DBMS for Geographic Applications, Intl. Conference on Data Engineering, p. 590-597 [ORO 93] OROURKE J., Computational Geometry in C, 1993, Cambridge University Press [PAL 75] PALMER J.A.S., Computer Science aspects of the mapping problem, from Davis and Mc Cullagh, Display and analysis of spatial Data, New York, John Wiley and Sons, 1975 [PAR 97] PARKER J.R., Algorithms for Image Processing and Computer Vision, 1997, Wiley Computer Publishing [PAV 82] PAVLIDIS T., Algorithms for Graphics and Image Processing, Computer Science Press, 1982 [PL 97] PLMER, GRGER, Archiving Integrity in Geographic Information Systems Maps and Nested Maps, Geoinformatica, 1997, vol.1, n 4, pp 345-367, Kluwer Academic, Boston [PUL 88] PULLAR D.V., EGENHOFFER M.J., Toward formal definitions of topological relations among spatial objects, Procedings of the third International Symposium on Spatial Data Handling, 1988, Sydney, Australia, pp 225-241 [PUM 97] PUMAIN D., SAINT-JULIEN T., Lanalyse spatiale, 1997, Armand Colin, Cursus , Paris [REN 91] RENOUARD L., Restitution automatique du relief partir de couples stroscopiques dimages du satellite SPOT, 1991, Thse de Doctorat prsente lEcole Polytechnique [RIM 90] RIMBERT S., Carto-graphies, 1990, Herms, Paris [ROS 80] ROSENFELD A. AND SAMET H., Tree structure for region representation, Aangeenburg, Autocarto 4, 1980, vol. 1, p. 108-118

356

Bibliographie

[ROU 91] ROUET P., Les donnes dans les systmes dinformation Gographique. Trait des nouvelles technologies, srie Gomatique, 1991, Herms, Paris [SAM 80A] SAMET H., Region Representation : quadtrees from boundaries codes, Communication ACM, 1980, vol. 23, n3,p. 163-170 [SAM 80B] SAMET H., Tree Structure for region representation, Aangeenbgug, Autocarto 4, vol. 1, 1980, pp 108-118 [SAM 90] SAMET H., Applications of Spatial Data Structures, Addison-Wesley, 1990 [SAN 89] SANDERS L., Lanalyse des donnes applique la gographie, 1989, RECLUS, Montpellier [SCH 89] SCHOLL M. ET VOISARD A., Thematic map Modeling, Int. Symposium on Large Spatial Databases, 1989, LNCS n409, p. 167-192 [SCH 96] SCHOLL M., VOISARD A., PELOUX J.P., RAYNAL L., RIGAUX P., SGBD Gographiques, Spcificits, Thomson Publishing, 1996, Paris [SHA 78] SHAMOS M. I., Computational Geometry, PHD, 1978, Yale University [SHL 88] SHLAER S, MELLOR S-J., Objet Oriented System Analysis : Modelling the World in Data, Englewood Cliffs, 1988, Prentice-Hall [SOU 86] SOURIS M., Systmes dinformation gographique et bases de donnes, Colloques et Sminaires sur le Traitement des donnes localises, Paris, Editions de lORSTOM, 1986, p. 29-87 [SOU 87] SOURIS M., A Geographic Information System with relational architecture : principles and example of use, in Primera conferencia sobre informatica y geografia, 1987, San Jose, Costa Rica, pp 703-728 [SOU 90] SOURIS M., Le systme SAVANE, Manuels de rfrence, 1990-2002, IRD [TAN 95] TANZI T., UBEDA T., Contrle topologique de la cohrence dans les bases de donnes gographiques : application aux rseaux , Revue Internationale de Gomatique, 1995, Vol. 5, n2, pp 133-155 [TOM 76] TOMLINSON, CALKINS AND MARBLE, Essential part of a geographic information system, Computer Handling of geographic Data, UNESCO Press, Paris, 1976 [UBE 96] UBEDA T., SERVIGNE S., Geometric and Topological Consistency of Spatial Data, 1996, in Proceedings: First International Conference on Geocomputation, Leeds, UK [UBE 97] UBEDA T., Contrle de la qualit spatiale dans les bases de donnes gographiques : Cohrence topologique et corrections d'erreurs, Thse soutenue l'INSA de Lyon, 1997 [ULL 88] ULMANN J.D., Principles of Database and Knowledge-Base Systems, 1988, Computer Science Press [VOI 92] VOISARD A., Bases de donnes gographiques : du modle de donnes linterface utilisateur. Thse de doctorat, Universit dOrsay, 1992 [VOI 95] VOIRON C., Analyse spatiale et analyse dimages, 1995, RECLUS, Montpellier

Bibliographie 357
[WOR 90] WORBOYS M.F., HEARNSHAW H.M., MAGUIRE D.J., Object-Oriented data Modelling for Spatial Databases, International Journal of Geographic Information Systems, 1990, vol. 4, p. 369-383 [WOR 95] WORBOYS M. F., GIS, a Computer Perspective, Taylor and Francis, 1995

Annexes

360

Annexe

Structures et mthodes : implmentation 361

Annexe A

Structures et mthodes : implmentation

Cette annexe prsente le code C++ de classes correspondant limplmentation des structures, des mthodes, et des algorithmes dcrits dans les chapitres qui prcdent. Nous ne prsentons ici quune partie des classes du systme, en excluant en particulier toutes les classes concernant linterface utilisateur, propre au systme de dveloppement utilis (Visual C++ de Microsoft). Chaque module fera lobjet dune section distincte. Lordre de prsentation des classes suivra en gnral leur apparition dans le texte principal de ce mmoire, car il est difficile dtablir une hirarchie selon leur importance dans la construction du systme. Certaines classes sont utilises dans lensemble des modules : elles ne seront bien sr prsentes quune seule fois. A.1. SAVATECA A.1.1. Les classes CAttribut et CRelation Ces classes reprsentent les objets fondamentaux que sont les relations et les attributs :
class CAttribut { public : CAttribut(); int m_iType; int m_iPtr; int m_iNbcar; int m_iNbvalb; int m_iPtrval; int m_iNumero; char m_chNom[20]; int m_iRangDansLaVue; };

362

Annexe

La variable iType donne le type de lattribut (1 ou 5 : nominal; 2 : ordinal; 3 : entier;4 : rel; 6 : pixel entier 8 bit; 7 : pixel entier 16 bitsclass ; 8 : pixel RVB ; 9 : pixel 32 rel bits). La variable m_iNbcar indique le nombre de caractres utilis pour les modalits dans le cas dun attribut nominal. La variable m_iNbvalb indique le nombre de modalits intgres dans la base de donnes. La variable m_iPtrval donne ladresse de la premire modalit dans le fichier fpvaleurs. Ces trois variables permettent de retrouver dans le fichier fpvaleurs une modalit partir de son codage interne iValeur :
iPtr=(m_iPtrval+iValeur-2)*m_iNbcarAttr; fseek(FileValeurs,iPtr,SEEK_SET); fread(chNomValeur,m_iNbcarAttr,1,FileValeurs);

La classe CRelation est galement utilise dans tous les modules du systme :
CRelation { public : int m_iPtr; int m_iNrec; int m_iType; int m_iNba; int m_iPtrLibreArc; int m_iPtrLibreTuple; char m_chNomFichF[16]; char m_chNomFichZ[16]; char m_chNomFichA[16]; char m_chNom[100]; char m_chFichierFeuille[_MAX_PATH]; char m_chFichierZone[_MAX_PATH]; char m_chFichierArc[_MAX_PATH]; CAttribut* m_pAttributs[NB_MAX_ATTRIBUTS]; int m_iRangDansLaVue; public: CRelation(); ~CRelation(); };

Le tableau CAttribut* m_pAttributs[NB_MAX_ATTRIBUTS] conserve la liste des pointeurs vers les objets de type CAttribut de la relation. La variable m_iType indique le type de la relation (1 : non localise ; 2 : ligne ; 3 : point ; 4 : zone ; 5 : pixel). A.1.2. La classe CBase La classe CBase dcrit dans SAVATECA la structure dune base de donnes :
class CBase { private: public: char char char char char char char char char m_chNomBase[100]; m_chDirAdmin[_MAX_PATH]; m_chDirBase[_MAX_PATH]; m_chDirDigit[_MAX_PATH]; m_chDirDoc[_MAX_PATH]; m_chNomFichierAcces[_MAX_PATH]; m_chNomFichierBase[_MAX_PATH]; m_chNomFichierValeurs[_MAX_PATH]; m_chNomFtmp[_MAX_PATH];

Structures et mthodes : implmentation 363

double m_dMaxx; double m_dMaxy; double m_dMinx; double m_dMiny; int m_iOuvert; int m_iNbrel; CRelation* m_pRelations[NB_MAX_RELATIONS]; public: CBase(); ~CBase(); int IsOuverte() {return m_iOuvert;}; void Ouverte() {m_iOuvert=1;}; void Fermer(); BOOL Init(char* chNomBase,char* chDirBase,char* chDirDoc); void InitRang(); BOOL Alloc(); void Desalloc(); BOOL Realloc(); int RelRecherche(const char *nom); int RelDupRecherche(int iNoth, int* itabNoth); int AttDupRecherche(int iNoth, int iNoatt, int* itabNothAtt); int FiczRecherche(char *nom); int FicfRecherche(char *nom); int FicaRecherche(char *nom); int AttrRecherche(int iNoth,char *nom); BOOL NouveauFichier(int iType,char *chNom); BOOL InsertionNewValeurs(char *ctabNewValeurs,int iNbNewValeurs,int iNoth,int iNoatt); int NbObjets(int iNoth); int NbValeurs(int iNoth,int iNoatt); }; void GeoToSav(double dLongitude,double dColatitude,float& fXSav,float& fYSav);

On remarquera en particulier la variable membre m_iNbrel, qui donne le nombre de relations de la base, lorsque celle-ci est ouverte, et CRelation* m_pRelations[NB_MAX_RELATIONS] qui donne les adresses des objets de type CRelation de la base. Les mthodes RelRecherche() et AttrRecherche() renvoie le numro interne dune la relation ou dun attribut partir de son nom. Les mthodes Alloc() ou ReAlloc() permettent de charger la structure de la base partir du dictionnaire, conserv dans le fichier base. Le fichier base est maintenu par la classe CDico.
BOOL CBase::Alloc() { //--- initialisation des accs aux donnes suivant le dictionnaire de la base ouverte int iPtr,j,k; int iNbRelations; int iTypeRelation,iNbAttributs,iNrec,plibz,pliba; int iTypeAttribut,iNbvalb,iPtrval,iNbcar; long adr; char chNomRelation[64]; char chNomAttribut[64]; char chDescription[128]; char chNom2[_MAX_PATH],chNom3[100],chNom4[100]; CDico dico; if(dico.Ouvrir(m_chNomFichierBase,MODE_READ) == FALSE)return FALSE; if(dico.LireNbRelations(iNbRelations) == FALSE)return FALSE; m_iNbrel=iNbRelations; iPtr=3; j=1; while(j <= m_iNbrel) { adr=(iPtr-1)*dico.GetTailleRecord();

364

Annexe

if(dico.LireRelation(adr,chNomRelation,iTypeRelation,iNbAttributs,iNrec,chNom2,chNom3,chNom4 ,plibz,pliba) == FALSE)return FALSE; m_pRelations[j]= new CRelation; m_pRelations[j]->m_iPtr=adr; strcpy(m_pRelations[j]->m_chNom,chNomRelation); m_pRelations[j]->m_iType=iTypeRelation; m_pRelations[j]->m_iNba=iNbAttributs; m_pRelations[j]->m_iNrec=iNrec; m_pRelations[j]->m_iRangDansLaVue=0; if(iTypeRelation == 5) { strcpy(m_pRelations[j]->m_chFichierZone,chNom2); strcpy(m_pRelations[j]->m_chFichierFeuille,""); strcpy(m_pRelations[j]->m_chFichierArc,""); strcpy(m_pRelations[j]->m_chNomFichF,""); strcpy(m_pRelations[j]->m_chNomFichZ,""); strcpy(m_pRelations[j]->m_chNomFichA,""); m_pRelations[j]->m_iPtrLibreArc=0; m_pRelations[j]->m_iPtrLibreTuple=0; } else { strcpy(m_pRelations[j]->m_chNomFichF,chNom2); strcpy(m_pRelations[j]->m_chNomFichZ,chNom3); strcpy(m_pRelations[j]->m_chNomFichA,chNom4); m_pRelations[j]->m_iPtrLibreArc=pliba; m_pRelations[j]->m_iPtrLibreTuple=plibz; strcpy(m_pRelations[j]->m_chFichierFeuille,m_chDirBase); strcat(m_pRelations[j]->m_chFichierFeuille,"\\"); strcat(m_pRelations[j]->m_chFichierFeuille,chNom2); strcpy(m_pRelations[j]->m_chFichierZone,m_chDirBase); strcat(m_pRelations[j]->m_chFichierZone,"\\"); strcat(m_pRelations[j]->m_chFichierZone,chNom3); strcpy(m_pRelations[j]->m_chFichierArc,m_chDirBase); strcat(m_pRelations[j]->m_chFichierArc,"\\"); strcat(m_pRelations[j]->m_chFichierArc,chNom4); } iPtr++; k=1; while(k <= iNbAttributs) { adr=(iPtr-1)*dico.GetTailleRecord(); if(dico.LireAttribut(adr,chNomAttribut,iTypeAttribut,iNbvalb,iPtrval,iNbcar,chDescription) == FALSE)return FALSE; m_pRelations[j]->m_pAttributs[k]= new CAttribut; m_pRelations[j]->m_pAttributs[k]->m_iNumero=k; m_pRelations[j]->m_pAttributs[k]->m_iPtr=adr; strcpy(m_pRelations[j]->m_pAttributs[k]->m_chNom,chNomAttribut); m_pRelations[j]->m_pAttributs[k]->m_iType=iTypeAttribut; if(iTypeAttribut == 1)m_pRelations[j]->m_pAttributs[k]->m_iNbcar=iNbcar; else m_pRelations[j]->m_pAttributs[k]->m_iNbcar=0; m_pRelations[j]->m_pAttributs[k]->m_iNbvalb=iNbvalb; m_pRelations[j]->m_pAttributs[k]->m_iPtrval=iPtrval; m_pRelations[j]->m_pAttributs[k]->m_iRangDansLaVue=0; iPtr++; k++; } j++; } dico.Fermer(); return TRUE; }

Structures et mthodes : implmentation 365 A.1.3. La classe CDico La classe CDico encapsule lensemble des variables et des fonctions ncessaires la lecture et lcriture du dictionnaire dune base de donnes SAVANE. Le dictionnaire est conserv dans le fichier base qui doit toujours se trouver dans le rpertoire de stockage de la base de donnes. Cette classe est utilise dans tous les modules du systme, pour charger en mmoire la structure dune base de donnes lors de son ouverture dans lun des modules. Les fonctions dcriture ne sont utilises que dans le module SAVATECA, lors de la cration ou de la modification dune base de donnes. Cette classe permet galement de grer lvolution de la structure du fichier base, en y ajoutant des mthodes de mise jour lorsque cela est ncessaire.
class CDico { private: FILE* m_FileBase; char m_chBuffer[256]; char m_chLecture[256]; int m_iTailleRecord; public: CDico(); ~CDico(); int GetTailleRecord() {return m_iTailleRecord;}; BOOL Ouvrir(const char* chNomFichierBase,int iMode); void Fermer(); BOOL LireEntete1(int& iDefecr,int& iPbl,int& iVersion,char* chUtilisateur); BOOL LireEntete2(char* chNomBase,int& iNbRelations,int& iXb,int& iYb,int& iXh,int& iYh,int& iPvl); BOOL LireNumero(int& iNumero); BOOL LirePbl(int& iPbl); BOOL LirePvl(int& iPvl); BOOL LireNbRelations(int& iNbRelations); BOOL LireRelation(long adr,char* chNomRelation,int& iType,int& iNbAttributs,int& iNrec,char* chNom2,char* chNom3,char* chNom4,int& plibz,int& pliba); BOOL LireRelationNom(long adr,char* chNomRelation); BOOL LireRelationTypeNbAttributs(long adr,int& iType,int& iNbAttributs); BOOL LireAttribut(long adr,char* chNomAttribut,int& iTypeAttribut,int& iNbvalb,int& iPtrval,int& iNbcar,char* chDescription); BOOL LireAttributNbvalbPtrval(long adr,int& iNbvalb,int& iPtrval); BOOL EcrireEntete1(int iDefecr,int iPbl,int iVersion,const char* chUtilisateur); BOOL EcrireEntete2(const char* chNomBase,int iNbRelations,int iXb,int iYb,int iXh,int iYh,int iPvl); BOOL EcrireUtilisateurAdmi(); BOOL EcrireUtilisateurNone(); BOOL EcrireNumero(); BOOL EcrirePbl(int iPbl); BOOL EcrirePvl(int iPvl); BOOL EcrireNbRelations(int iNbRelations); BOOL EcrireRelation(long adr,const char* chNomRelation,int iTypeRelation,int iNbAttributs,int iNrec,const char* chNom2,const char* chNom3,const char* chNom4,int plibz,int pliba); BOOL EcrireRelationNom(long adr,const char* chNomRelation); BOOL EcrireRelationDirMosaic(long adr,const char* chDirMosaic); BOOL EcrireRelationNbAttributsNrec(long adr,int iNbAttributs,int iNrec); BOOL EcrireRelationPlibz(long adr,int iPtrLibre); BOOL EcrireRelationPliba(long adr,int iPtrLibre); BOOL EcrireAttribut(long adr,const char* chNomAttribut,int iTypeAttribut,int iNbvalb,int iPtrval,int iNbcar,const char* chDescription); BOOL EcrireAttributNom(long adr,const char* chNomAttribut); BOOL EcrireAttributType(long adr,int iTypeAttribut); BOOL EcrireAttributNbvalPtrval(long adr,int iNbvalb,int iPtrval); BOOL EcrireAttributDescription(long adr,const char* chDescription); BOOL EcrireLigneBlanche(long adr); BOOL DecaleMoins(long adrDebut,long adrFin,int iDecalage); BOOL DecalePlus(long adrDebut,long adrFin,int iDecalage); };

366

Annexe

Nous avons dj vu dans le paragraphe prcdent (classe CBase) comment cette classe est utilise dans SAVATECA pour charger la structure dune base de donnes. Pour donner un exemple de la faon dont est maintenu le dictionnaire, voici le code de la mthode EcrireRelation() qui crit dans le fichier la description dune relation :
BOOL CDico::EcrireRelation(long adr,const char* chNomRelation,int iTypeRelation,int iNbAttributs,int iNrec,const char* chNom2,const char* chNom3,const char* chNom4,int plibz,int pliba) { if(m_FileBase == NULL)return FALSE; memset(m_chBuffer,' ',256); char chNomRelationLocal[20]; char chNom2Local[_MAX_PATH]; char chNom3Local[_MAX_PATH]; char chNom4Local[_MAX_PATH]; strcpy(chNomRelationLocal,chNomRelation); strcpy(chNom2Local,chNom2); strcpy(chNom3Local,chNom3); strcpy(chNom4Local,chNom4); if(strlen(chNom2Local) == 0)strcpy(chNom2Local,"aucun"); if(strlen(chNom3Local) == 0)strcpy(chNom3Local,"aucun"); if(strlen(chNom4Local) == 0)strcpy(chNom4Local,"aucun"); int iTaille=strlen(chNomRelationLocal); for(int i=iTaille;i < 16;i++)chNomRelationLocal[i]=' '; chNomRelationLocal[16]=0; iTaille=strlen(chNom2Local); for(i=iTaille;i < 55;i++)chNom2Local[i]=' '; chNom2Local[55]=0; iTaille=strlen(chNom3Local); for(i=iTaille;i < 8;i++)chNom3Local[i]=' '; chNom3Local[8]=0; iTaille=strlen(chNom4Local); for(i=iTaille;i < 8;i++)chNom4Local[i]=' '; chNom4Local[8]=0; if(fseek(m_FileBase,adr,SEEK_SET) != 0)return FALSE; if(iTypeRelation == 5) { int i=sprintf(m_chBuffer,"%-16.16s%1d%4d%4d%55.55s",chNomRelationLocal,iTypeRelation,iNbAttributs,iNrec,chNom2Local); m_chBuffer[80]=' '; if(i != 80) { Fermer(); return FALSE; } } else { chNom2Local[8]=0; int i=sprintf(m_chBuffer,"%-16.16s%1d%4d%4d%-8.8s%-8.8s%8.8s%8d%8d",chNomRelationLocal,iTypeRelation,iNbAttributs,iNrec,chNom2Local,chNom3Local,chNom4 Local,plibz,pliba); m_chBuffer[65]=' '; if(i != 65) { Fermer(); return FALSE; } } if(fwrite(m_chBuffer,m_iTailleRecord,1,m_FileBase) != 1) { Fermer(); return FALSE; }

Structures et mthodes : implmentation 367

return TRUE; }

De mme, la mthode EcrireAttribut() crit dans le fichier la description dun attribut dune relation :
BOOL CDico::EcrireAttribut(long adr,const char* chNomAttribut,int iTypeAttribut,int iNbvalb,int iPtrval,int iNbcar,const char* chDescription) { if(m_FileBase == NULL)return FALSE; memset(m_chBuffer,' ',256); //--- iNbcar non utilis pour le moment //--- mise en bonne forme des chaines de caracteres char chNomAttributLocal[20]; char chDescriptionLocal[100]; strcpy(chNomAttributLocal,chNomAttribut); strcpy(chDescriptionLocal,chDescription); int iTaille=strlen(chNomAttributLocal); for(int i=iTaille;i < 16;i++)chNomAttributLocal[i]=' '; chNomAttributLocal[16]=0; iTaille=strlen(chDescriptionLocal); for(i=iTaille;i < 40;i++)chDescriptionLocal[i]=' '; chDescriptionLocal[40]=0; i=sprintf(m_chBuffer,"%-16.16s%1d%8d%8d",chNomAttributLocal,iTypeAttribut,iNbvalb,iPtrval); m_chBuffer[33]=' '; if(i != 33) { Fermer(); return FALSE; } memcpy(&m_chBuffer[40],chDescriptionLocal,40); if(fseek(m_FileBase,adr,SEEK_SET) != 0)return FALSE; if(fwrite(m_chBuffer,m_iTailleRecord,1,m_FileBase) != 1) { Fermer(); return FALSE; } return TRUE; }

Voici le code utilis dans SAVATECA pour crire dans le dictionnaire des donnes la description dune nouvelle relation. Le type de la relation correspond au type dimplantation spatiale (zone, ligne, point, pixel, non localis) :
CDico dico; if(dico.Ouvrir(base.m_chNomFichierBase,MODE_READWRITE) == FALSE)return FALSE; dico.LirePbl(iPbl); dico.LireNbRelations(iNbRelations); adr=dico.GetTailleRecord()*(iPbl-1); adrRelation=adr; strcpy(m_chNomFichierData,"aucun "); strcpy(m_chNomFichierFeuille,"aucun "); strcpy(m_chNomFichierArc,"aucun "); switch(iTypeRelation) { case 1: if(base.NouveauFichier(1,m_chNomFichierData) == FALSE)return FALSE; dico.EcrireRelation(adrRelation,chNomRelation,iTypeRelation,m_iNbatt,iNrec,m_chNomFichierFeu ille,m_chNomFichierData,m_chNomFichierArc,1,1); iPbl++; iNbRelations++; break; case 3:

368

Annexe
if(base.NouveauFichier(1,m_chNomFichierData) == FALSE)return FALSE; if(base.NouveauFichier(2,m_chNomFichierFeuille) == FALSE)return FALSE;

dico.EcrireRelation(adrRelation,chNomRelation,iTypeRelation,m_iNbatt,iNrec,m_chNomFichierFeu ille,m_chNomFichierData,m_chNomFichierArc,1,1); iPbl++; iNbRelations++; break; case 2: case 4: if(base.NouveauFichier(1,m_chNomFichierData) == FALSE)return FALSE; if(base.NouveauFichier(2,m_chNomFichierFeuille) == FALSE)return FALSE; if(base.NouveauFichier(3,m_chNomFichierArc) == FALSE)return FALSE; dico.EcrireRelation(adrRelation,chNomRelation,iTypeRelation,m_iNbatt,iNrec,m_chNomFichierFeu ille,m_chNomFichierData,m_chNomFichierArc,1,1); iPbl++; iNbRelations++; break; case 5: //--- type mosaique { char chDirMosaic[_MAX_PATH]; strcpy(chDirMosaic,(LPCTSTR) m_strDirMosaic); if(CreerMosaique(chNomRelation,chDirMosaic) == FALSE) { switch(config.m_iLangage) { case FRANCAIS: default: AfxMessageBox("Mosaque : cration impossible !",MB_OK|MB_ICONEXCLAMATION); break; case ESPAGNOL: AfxMessageBox("Mosaico : creacin imposible !",MB_OK|MB_ICONEXCLAMATION); break; case ANGLAIS: AfxMessageBox("Mosaque : creation aborted !",MB_OK|MB_ICONEXCLAMATION); break; } return FALSE; } dico.EcrireRelation(adrRelation,chNomRelation,iTypeRelation,m_iNbatt,iNrec,chDirMosaic,m_chN omFichierData,m_chNomFichierArc,1,1); iPbl++; iNbRelations++; } break; default: break; } dico.EcrirePbl(iPbl); dico.EcrireNbRelations(iNbRelations); dico.EcrireNumero(); dico.Fermer();

La mthode EcrireNumero() permet dactualiser une variable indiquant la version du dictionnaire, aprs une modification du schma par ladministrateur. Tous les programmes client (comme SAVANE, SAVAMER, SAVEDIT) lisent ce numro dans le fichier base chaque utilisation de la base de donnes : si elle a t modifie depuis le dernier accs, le schma est mis jour en lisant de nouveau le dictionnaire. Cette procdure est essentielle lorsquune mme base est utilise en rseau et est modifie par ladministrateur pendant sa consultation par des utilisateurs.

Structures et mthodes : implmentation 369 A.1.4. La classe CFpacc9 La classe CFpacc9 permet de manipuler les vues externes. Elles est identique dans lensemble des modules du systme. Les procdures de lecture sont utilises par tous les modules qui utilisent les vues externes (SAVANE, SAVAMER, SAVEDIT). La classe permet de grer des groupes de relations ou dattributs au niveau des vues externes, de manire prsenter la vue externe avec des niveaux hirarchiques structurs.
class CFpaccV9 { public: void EcrireUneVue(FILE* FileAcces,const char* chCode); void EcrireEnteteAcces(FILE* FileAcces,const char* chNomBase,int iNbVues); void EcrireEnteteVue(FILE* FileAcces,const char* chCode,int iNbRelations,CGroupesDeRelationsDansVue* pGroupes); void EcrireEnteteRelation(FILE* FileAcces,int iNoRelation,int iNbAttributs,CGroupesDeAttributsDansVue* pGroupes); public: BOOL Upgrade(); void LireEnteteAcces(FILE* FileAcces,int& iNbVues); void LireEnteteVue(FILE* FileAcces,char* chCode,int& iNbRelations,CGroupesDeRelationsDansVue* pGroupes); void LireEnteteRelation(FILE* FileAcces,int& iNoRelation,int& iNbAttributs,CGroupesDeAttributsDansVue* pGroupes); BOOL BOOL BOOL BOOL LireUneVue(int iNumero,char* chCode,int& iNbRelations); ModifierUneVue(int iNumero); AjouterUneVue(char* chCode); SupprimerUneVue(int iNumero);

};

class CGroupesDeRelationsDansVue { private: public: int m_iNbGroupes; char m_ctabArbre[NB_MAX_RELATIONS + 2*NB_MAX_GROUPES_DE_RELATIONS]; char m_chtabNomGroupe[NB_MAX_GROUPES_DE_RELATIONS][33]; void Init(); void SupprimerUneRelation(int iNoRelation);

};

class CGroupesDeAttributsDansVue { private: public: int m_iNbGroupes; char m_ctabArbre[NB_MAX_ATTRIBUTS + 2*NB_MAX_GROUPES_DE_ATTRIBUTS]; char m_chtabNomGroupe[NB_MAX_GROUPES_DE_ATTRIBUTS][33]; void Init(); void Copier(CGroupesDeAttributsDansVue* pGroupeInitial); void SupprimerUnAttribut(int iNoAttribut);

};

Par exemple, la mthode LireEnteteVue() lit dans le fichier fpacc le nombre de relations de la vue, le nombre et la description des groupes de relation. Ces deux derniers paramtres sont conservs dans un objet de la classe CGroupesDeRelationsDansVue. La description des groupes de relation comprend une liste donnant la place de chaque groupe et de chaque relation dans la vue (m_ctabArbre), ainsi que le nom des groupes (m_chtabNomGroupe). La liste a la forme suivante : bbbbgbbgbbbbfbbfbbb (b reprsente une relation, g le

370

Annexe

dbut dun groupe, f la fin du groupe). La description des groupes dattribut pour chaque relation est bas sur le mme principe.
void CFpaccV9::LireEnteteVue(FILE* FileAcces,char* chCode,int& iNbRelations,CGroupesDeRelationsDansVue* pGroupes) { char chBuffer[33]; memset(chBuffer,' ',32); strcpy(chCode,""); iNbRelations=0; pGroupes->Init(); if(fread(chBuffer,28,1,FileAcces) == 1) { chBuffer[28]=0; sscanf(chBuffer,"%4s%4d%4d",chCode,&iNbRelations,&pGroupes->m_iNbGroupes); chCode[4]=0; //--- groupes de relations for(int i=0;i < pGroupes->m_iNbGroupes;i++) { fread(&pGroupes->m_chtabNomGroupe[i],32,1,FileAcces); pGroupes->m_chtabNomGroupe[i][32]=0; } i=iNbRelations + 2*pGroupes->m_iNbGroupes; if(i > 0)fread(pGroupes->m_ctabArbre,i,1,FileAcces); }

A.1.5. La classe CIndexAttribut La classe CIndexAttribut permet dindexer temporairement les modalits dun attribut nominal, de manire retrouver rapidement le code dune modalit si elle existe dans la base. Lindexation utilise une table dentre sur trois caractres laquelle correspond la fonction de hachage Paquet(). Elle est utilise dans SAVATECA lors de lintgration descriptive, et dans SAVANE pour trouver le code interne dune modalit.
class CIndexAttribut { private: CBase* m_pBase; int m_itabIndex[15626]; int m_itabNombre[15626]; unsigned char *m_ctabCle; int int int int m_iTypeAttr; m_iNbcarAttr; m_iNbvalb; m_iPtrval;

public: CIndexAttribut(CBase* pBase,int iNoth,int iNoatt); ~CIndexAttribut(); BOOL Init(); int Recherche(char *chNomValeur); void Fermer();

};

Limplmentation des mthodes Init() et Recherche() permet de montrer la structure de codage des valeurs nominales dans une base SAVANE :
BOOL CIndexAttribut::Init() { //--- allocation mmoire

Structures et mthodes : implmentation 371

m_ctabCle=(unsigned char *) malloc(m_iNbvalb*(m_iNbcarAttr + sizeof(int))*sizeof(unsigned char)); if(m_ctabCle == NULL) { ::ErreurDeMemoire(); return FALSE; } //--- initialisation de m_ctabCle memset(m_ctabCle,' ',m_iNbvalb*(m_iNbcarAttr + sizeof(int))); //--- initialisation de la table d'index int i; for(i=0;i < 15626;i++) { m_itabIndex[i]=0; m_itabNombre[i]=0; } if(m_iNbvalb > 0) { char chNomValeur[NB_MAX_CHARACTER]; int iVal=0; int iNbRec=m_iNbcarAttr+sizeof(int); //--- lecture des valeurs FILE* FileValeurs; FileValeurs=fopen(m_pBase->m_chNomFichierValeurs,"rb"); chNomValeur[m_iNbcarAttr]='\0'; int iPtrval=(m_iPtrval-1)*m_iNbcarAttr; fseek(FileValeurs,iPtrval,SEEK_SET); for(i=0;i < m_iNbvalb;i++) { iVal=i+1; fread(&chNomValeur[0],m_iNbcarAttr,1,FileValeurs); memcpy(&m_ctabCle[iNbRec*i],chNomValeur,m_iNbcarAttr); memcpy(&m_ctabCle[iNbRec*i+m_iNbcarAttr],&iVal,sizeof(int)); } fclose(FileValeurs); //--- tri des valeurs, ordre donn par paquet qsort(m_ctabCle,m_iNbvalb,iNbRec,ComparClePaquet); //--- creation de la table d'index int irep1,irep1bis; int iPtr=0; int iNbIndex=0; memcpy(chNomValeur,&m_ctabCle[iPtr],m_iNbcarAttr); chNomValeur[m_iNbcarAttr]=0; irep1=Paquet(chNomValeur); m_itabIndex[irep1]=iPtr; iPtr+=iNbRec; iNbIndex++; for(i=1;i < m_iNbvalb;i++) { memcpy(chNomValeur,&m_ctabCle[iPtr],m_iNbcarAttr); chNomValeur[m_iNbcarAttr]=0; irep1bis=Paquet(chNomValeur); if(irep1bis != irep1) { m_itabNombre[irep1]=iNbIndex; iNbIndex=0; irep1=irep1bis; m_itabIndex[irep1]=iPtr; } iNbIndex++; iPtr+=iNbRec; } m_itabNombre[irep1]=iNbIndex; } return TRUE; } int CIndexAttribut::Recherche(char* chNom) { int i,j,irep1,iPtr,iNb,iVal; char chNomValeur[NB_MAX_CHARACTER];

372

Annexe

char chNomTableau[NB_MAX_CHARACTER]; int iNbRec=m_iNbcarAttr+sizeof(int); i=0; while(i < m_iNbcarAttr) { if(chNom[i] == 0)break; chNomValeur[i]=chNom[i]; i++; } while(i < m_iNbcarAttr) { chNomValeur[i]=' '; i++; } chNomValeur[m_iNbcarAttr]=0; irep1=Paquet(chNomValeur); iPtr=m_itabIndex[irep1]; iNb=m_itabNombre[irep1]; iVal=0; for(i=0;i < iNb;i++) { memcpy(chNomTableau,&m_ctabCle[iPtr],m_iNbcarAttr); for(j=0;j < m_iNbcarAttr;j++) { if(chNomTableau[j] != chNomValeur[j])break; } if(j == m_iNbcarAttr) { memcpy(&iVal,&m_ctabCle[iPtr+m_iNbcarAttr],sizeof(int)); return iVal; } iPtr+=iNbRec; } return iVal; } static int __cdecl ComparClePaquet(const void *arg1,const void *arg2) { g_i1=Paquet((char *)arg1); g_i2=Paquet((char *)arg2); if(g_i1 < g_i2)return -1; if(g_i1 == g_i2)return 0; if(g_i1 > g_i2)return 1; return 0; } static int Paquet(char* chNom) { if(chNom[0] <= 47)g_irep1=0; else if(chNom[0] <= 57)g_irep1=int(chNom[0])-47; else if(chNom[0] <= 65)g_irep1=11; else if(chNom[0] <= 70)g_irep1=12; else if(chNom[0] <= 75)g_irep1=13; else if(chNom[0] <= 80)g_irep1=14; else if(chNom[0] <= 85)g_irep1=15; else if(chNom[0] <= 90)g_irep1=16; else if(chNom[0] <= 95)g_irep1=17; else if(chNom[0] <= 100)g_irep1=18; else if(chNom[0] <= 105)g_irep1=19; else if(chNom[0] <= 110)g_irep1=20; else if(chNom[0] <= 115)g_irep1=21; else if(chNom[0] <= 120)g_irep1=22; else if(chNom[0] <= 135)g_irep1=23; else g_irep1=24; if(chNom[1] <= 47)g_irep2=0; else if(chNom[1] <= 57)g_irep2=int(chNom[1])-47; else if(chNom[1] <= 65)g_irep2=11; else if(chNom[1] <= 70)g_irep2=12; else if(chNom[1] <= 75)g_irep2=13; else if(chNom[1] <= 80)g_irep2=14; else if(chNom[1] <= 85)g_irep2=15; else if(chNom[1] <= 90)g_irep2=16; else if(chNom[1] <= 95)g_irep2=17; else if(chNom[1] <= 100)g_irep2=18; else if(chNom[1] <= 105)g_irep2=19; else if(chNom[1] <= 110)g_irep2=20;

Structures et mthodes : implmentation 373

else else else else if(chNom[1] <= 115)g_irep2=21; if(chNom[1] <= 120)g_irep2=22; if(chNom[1] <= 135)g_irep2=23; g_irep2=24;

if(chNom[2] <= 47)g_irep3=0; else if(chNom[2] <= 57)g_irep3=int(chNom[2])-47; else if(chNom[2] <= 65)g_irep3=11; else if(chNom[2] <= 70)g_irep3=12; else if(chNom[2] <= 75)g_irep3=13; else if(chNom[2] <= 80)g_irep3=14; else if(chNom[2] <= 85)g_irep3=15; else if(chNom[2] <= 90)g_irep3=16; else if(chNom[2] <= 95)g_irep3=17; else if(chNom[2] <= 100)g_irep3=18; else if(chNom[2] <= 105)g_irep3=19; else if(chNom[2] <= 110)g_irep3=20; else if(chNom[2] <= 115)g_irep3=21; else if(chNom[2] <= 120)g_irep3=22; else if(chNom[2] <= 135)g_irep3=23; else g_irep3=24; //--- codage en base 25 return (g_irep1*625 + g_irep2*25 + g_irep3); }

A.1.6. La classe CIntegrationObjetsLocalises La classe CintegrationObjetLocaliss regroupe les oprations permettant deffectuer lintgration de nouveaux objets dans une relation. Elle est utilise dans toutes les oprations dintgration dobjets localiss, partir des documents de saisie graphique :
class CIntegrationObjetsLocalises { public: CIntegrationObjetsLocalises(int iNoth,int iNoatt); ~CIntegrationObjetsLocalises(); int Init(char *chNomDocumentMygale,const char *chRepertoire); void MessageErreur(int iNumero); BOOL Integrer(); private: int m_iNoth; int m_iNoatt; int m_iVersionMygale; int m_iTypeDocument; int m_iTypeSaisie; int m_iNbcharCle; char m_chRepertoire[_MAX_PATH]; char m_chNomDocument[_MAX_PATH]; double m_dXCalageProjection[2]; double m_dYCalageProjection[2]; int m_iXCalageTable[2]; int m_iYCalageTable[2]; double m_dA,m_dB; BOOL BOOL BOOL BOOL BOOL BOOL }; IntegrerObjetsZoneVersion1(); IntegrerObjetsZoneVersion7(); IntegrerObjetsLigneVersion1(); IntegrerObjetsLigneVersion7(); IntegrerObjetsPointVersion1(); IntegrerObjetsPointVersion7();

void CentreLigne(double* dtabX,double *dtabY,int iNbpt,double &dXSav, double &dYsav);

Par exemple, la mthode IntegrerObjetsPointVersion7() permet de crer une nouvelle feuille dans une relation de type point, partir dun document de type

374

Annexe

point provenant de SAVEDIT. Le processus cre les objets, cre la feuille dans le fichier dindexation, puis intgre la cl descriptive pour chaque objet.
BOOL CIntegrationObjetsLocalises::IntegrerObjetsPointVersion7() { int iStep,iCompteur; int i; long adr; float fXSav,fYSav; float fXminFeuille,fYminFeuille,fXmaxFeuille,fYmaxFeuille; double dLong,dColat; double dXSav,dYSav; double dVal; double dXminFeuille,dYminFeuille,dXmaxFeuille,dYmaxFeuille; char chTitreProgress[100]; char chNomFichier[_MAX_PATH]; char buffer[1000]; long fXSavUnix,fYSavUnix; memset(buffer,0,1000); int iSizeIdentifiantTuple=2*SIZECOOR; //--- vrification de l'criture dans le fichier base CDico dico; if(dico.Ouvrir(base.m_chNomFichierBase,MODE_READWRITE) == FALSE) return FALSE; dico.Fermer(); //--- ouverture des fichiers savedit strcpy(chNomFichier,m_chRepertoire); strcat(chNomFichier,"\\"); strcat(chNomFichier,m_chNomDocument); strcat(chNomFichier,".pt"); FILE* FileMygalePoint=fopen(chNomFichier,"rb"); if(FileMygalePoint == NULL) { strcpy(chNomFichier,m_chRepertoire); strcat(chNomFichier,"\\"); strcat(chNomFichier,m_chNomDocument); strcat(chNomFichier,".PT"); FileMygalePoint=fopen(chNomFichier,"rb"); if(FileMygalePoint == NULL) { ::ErreurDeFichier(chNomFichier); return FALSE; } } //--- init fentre de feuille dXminFeuille=21600.; dYminFeuille=10800.; dXmaxFeuille=-21600.; dYmaxFeuille=-10800.; //--- ouverture du fichier savane des tuples FILE* FileSavanePoint=fopen(base.m_pRelations[m_iNoth]->m_chFichierZone,"rb+"); if(FileSavanePoint == NULL)FileSavanePoint=fopen(base.m_pRelations[m_iNoth]>m_chFichierZone,"wb"); if(FileSavanePoint == NULL) { ::ErreurDeFichierEnEcriture(base.m_pRelations[m_iNoth]->m_chFichierZone); fclose(FileMygalePoint); return FALSE; } //--- init des valeurs d'attributs long vUnix[NB_MAX_ATTRIBUTS]; for(i=0;i < NB_MAX_ATTRIBUTS;i++)vUnix[i]=DosFloatToUnix(FINCONNU); for(i=1;i <= base.m_pRelations[m_iNoth]->m_iNba;i++) { if(base.m_pRelations[m_iNoth]->m_pAttributs[i]->m_iType == 1)vUnix[i1]=DosFloatToUnix(0.F); } //--- intgration graphique et descriptive //--- init des pointeurs int iSavanePtrTupleFeuille=base.m_pRelations[m_iNoth]->m_iPtrLibreTuple; int iNba=base.m_pRelations[m_iNoth]->m_iNba;

Structures et mthodes : implmentation 375

int iNbTupleFeuille=0; int iSavanePtrTuple=iSavanePtrTupleFeuille; int iTailleRecord=16; //--- pour dX et dY if(m_iTypeSaisie == SAISIE_VALEUR || m_iTypeSaisie == SAISIE_CLEVALEUR)iTailleRecord+=8; if(m_iTypeSaisie == SAISIE_CLE || m_iTypeSaisie == SAISIE_CLEVALEUR)iTailleRecord+=m_iNbcharCle; adr=(long) ((iSavanePtrTuple-1)*(iSizeIdentifiantTuple + (iNba*SIZEVAL))); fseek(FileSavanePoint,adr,SEEK_SET); while(fread(buffer,iTailleRecord,1,FileMygalePoint) == 1) { memcpy(&dLong,&buffer[0],sizeof(double)); memcpy(&dColat,&buffer[8],sizeof(double)); wind.GeoToSav(dLong,dColat,fXSav,fYSav); if(m_iNoatt > 0 && (m_iTypeSaisie == SAISIE_VALEUR || m_iTypeSaisie == SAISIE_CLEVALEUR)) { //--- lecture et intgration d'une valeur numrique memcpy(&dVal,&buffer[16],sizeof(double)); vUnix[m_iNoatt-1]=DosFloatToUnix((float) dVal); } fXSavUnix=DosFloatToUnix(fXSav); fYSavUnix=DosFloatToUnix(fYSav); //--- fenetre de la feuille dXSav=(double) fXSav; dYSav=(double) fYSav; if(dXSav < dXminFeuille)dXminFeuille=dXSav; if(dYSav < dYminFeuille)dYminFeuille=dYSav; if(dXSav > dXmaxFeuille)dXmaxFeuille=dXSav; if(dYSav > dYmaxFeuille)dYmaxFeuille=dYSav; //--- criture dans le fichier fwrite(&fXSavUnix,SIZECOOR,1,FileSavanePoint); fwrite(&fYSavUnix,SIZECOOR,1,FileSavanePoint); for(i=0;i < iNba;i++)fwrite(&vUnix[i],SIZEVAL,1,FileSavanePoint); iNbTupleFeuille++; iSavanePtrTuple++; } if(iNbTupleFeuille == 0) { fclose(FileMygalePoint); fclose(FileSavanePoint); return TRUE; } //--- mise jour du fichier feuille FILE* FileSavaneFeuille=fopen(base.m_pRelations[m_iNoth]->m_chFichierFeuille,"rb+"); if(FileSavaneFeuille == NULL)FileSavaneFeuille=fopen(base.m_pRelations[m_iNoth]>m_chFichierFeuille,"wb"); if(FileSavaneFeuille == NULL) { ::ErreurDeFichierEnEcriture(base.m_pRelations[m_iNoth]->m_chFichierFeuille); fclose(FileMygalePoint); fclose(FileSavanePoint); return FALSE; } fXminFeuille=(float) fYminFeuille=(float) fXmaxFeuille=(float) fYmaxFeuille=(float) dXminFeuille; dYminFeuille; dXmaxFeuille; dYmaxFeuille;

int iNumeroFeuille=0; int iNbArcFeuille=0; int iSavanePtrArcFeuille=0; while(fgets(buffer,90,FileSavaneFeuille) != 0)iNumeroFeuille++; iNumeroFeuille++; fprintf(FileSavaneFeuille,"%5d%-12.12s%8.2f%8.2f%8.2f%8.2f%8d%8d%8d%8d\n", iNumeroFeuille,m_chNomDocument, fXminFeuille,fYminFeuille,fXmaxFeuille,fYmaxFeuille, iNbTupleFeuille,iSavanePtrTupleFeuille, iNbArcFeuille,iSavanePtrArcFeuille); fclose(FileSavaneFeuille); //--- mise jour des pointeurs libres dans le fichier base pour la relation

376

Annexe

if(dico.Ouvrir(base.m_chNomFichierBase,MODE_READWRITE)) { adr=base.m_pRelations[m_iNoth]->m_iPtr; dico.EcrireRelationPlibz(adr,iSavanePtrTuple); dico.Fermer(); base.m_pRelations[m_iNoth]->m_iPtrLibreTuple=iSavanePtrTuple; base.m_pRelations[m_iNoth]->m_iPtrLibreArc=0; } //--- intgration de l'attribut cl if(m_iNoatt > 0 && (m_iTypeSaisie == SAISIE_CLE || m_iTypeSaisie == SAISIE_CLEVALEUR)) { char chCle[33],chClebis[33]; int iTypeAttribut=base.m_pRelations[m_iNoth]->m_pAttributs[m_iNoatt]->m_iType; int iNbvalb=base.m_pRelations[m_iNoth]->m_pAttributs[m_iNoatt]->m_iNbvalb; int iPtrval=base.m_pRelations[m_iNoth]->m_pAttributs[m_iNoatt]->m_iPtrval; int iNbcarSavane=base.m_pRelations[m_iNoth]->m_pAttributs[m_iNoatt]->m_iNbcar; int iNbcarMygale=m_iNbcharCle; if(iNbcarMygale > iNbcarSavane)iNbcarMygale=iNbcarSavane; //--- allocations mmoire pour les tableaux de code par objet float *ftabCode=(float *) malloc((iNbTupleFeuille + 1)*sizeof(float)); char *ctabNewCle=(char *) malloc((iNbTupleFeuille + 1)*iNbcarSavane + 1); if(ftabCode == NULL || ctabNewCle == NULL) { ::ErreurDeMemoire(); if(ftabCode != NULL)free(ftabCode); if(ctabNewCle != NULL)free(ctabNewCle); fclose(FileMygalePoint); fclose(FileSavanePoint); return FALSE; } for(i=0;i <= iNbTupleFeuille;i++)ftabCode[i]=0.F; memset(ctabNewCle,' ',(iNbTupleFeuille+1)*iNbcarSavane); //--- emplacement de la cl dans le document mygale int iDebutDansBuffer=16; if(m_iTypeSaisie == SAISIE_CLE || m_iTypeSaisie == SAISIE_VALEUR)iDebutDansBuffer=16; else if(m_iTypeSaisie == SAISIE_CLEVALEUR)iDebutDansBuffer=24; pMainFrame->StepProgress(); int iNbNewValeurs=0; int iCode; int iNoTuple=0; if(iNbvalb > 0) { //--- indexation des valeurs existentes CIndexAttribut index(&base,m_iNoth,m_iNoatt); if(index.Init()) { //--- codification des cls iNoTuple=0; fseek(FileMygalePoint,0L,SEEK_SET); while(fread(buffer,iTailleRecord,1,FileMygalePoint) == 1) { pMainFrame->StepProgress(); memset(chCle,' ',iNbcarMygale); memcpy(chCle,&buffer[iDebutDansBuffer],iNbcarMygale); chCle[iNbcarMygale]='\0'; strstripall(chCle); if(strlen(chCle) == 0)strcpy(chCle,"Valeur inconnue"); iCode=index.Recherche(chCle); if(iCode == 0) { //--- nouvelle valeur i=0; while(i < iNbNewValeurs && iCode == 0) { memcpy(chClebis,&ctabNewCle[i*iNbcarSavane],iNbcarSavane); chClebis[iNbcarSavane]='\0'; strstrip(chClebis); if(strcmp(chCle,chClebis) == 0)iCode=iNbvalb+i+1; i++; } if(iCode == 0)

Structures et mthodes : implmentation 377

{ i=strlen(chCle); memcpy(&ctabNewCle[iNbNewValeurs*iNbcarSavane],chCle,i); iNbNewValeurs++; iCode=iNbvalb + iNbNewValeurs; }

} } else { //--- pas de valeurs dj introduites, codification directe des cls iNoTuple=0; fseek(FileMygalePoint,0L,SEEK_SET); while(fread(buffer,iTailleRecord,1,FileMygalePoint) == 1) { memset(chCle,' ',iNbcarMygale); memcpy(chCle,&buffer[iDebutDansBuffer],iNbcarMygale); chCle[iNbcarMygale]='\0'; strstripall(chCle); if(strlen(chCle) == 0)strcpy(chCle,"Valeur inconnue"); iCode=0; i=0; while(i < iNbNewValeurs && iCode == 0) { memcpy(chClebis,&ctabNewCle[i*iNbcarSavane],iNbcarSavane); chClebis[iNbcarSavane]='\0'; strstrip(chClebis); if(strcmp(chCle,chClebis) == 0)iCode=iNbvalb+i+1; i++; } if(iCode == 0) { i=strlen(chCle); memcpy(&ctabNewCle[iNbNewValeurs*iNbcarSavane],chCle,i); iNbNewValeurs++; iCode=iNbvalb + iNbNewValeurs; } ftabCode[iNoTuple]=(float) iCode; iNoTuple++; }

} ftabCode[iNoTuple]=(float) iCode; iNoTuple++; }

//--- criture dans les tuples des relations long fValUnix; int iPtr=iSavanePtrTupleFeuille; iNoTuple=0; while(iNoTuple < iNbTupleFeuille) { pMainFrame->StepProgress(); fValUnix=DosFloatToUnix(ftabCode[iNoTuple]); adr=(long) ((iNba*SIZEVAL + iSizeIdentifiantTuple)*(iPtr - 1) + iSizeIdentifiantTuple + (m_iNoatt-1)*SIZEVAL); fseek(FileSavanePoint,adr,SEEK_SET); fwrite(&fValUnix,SIZEVAL,1,FileSavanePoint); iPtr++; iNoTuple++; } free(ftabCode); //--- insertion des nouvelles valeurs base.InsertionNewValeurs(ctabNewCle,iNbNewValeurs,m_iNoth,m_iNoatt); free(ctabNewCle); } fclose(FileMygalePoint); fclose(FileSavanePoint); return TRUE; }

378

Annexe

A.2. SAVANE Le module SAVANE contient de nombreuses classes, nous ne prsentons ici que les plus importantes pour la comprhension de la structure du programme. Nous avons regroup les classes en plusieurs sections : gestion de la base de donnes dans une requte, algorithmique graphique, gestion des changements de systme de coordonnes et de projection, et gestion dun document (cartographie, dition). Enfin, un dernier paragraphe donne des exemples de ralisation doprations relationnelles. A.2.1. La manipulation de la base de donnes dans un cadre A.2.1.1. Les classes CRelation et CAttribut Les classes utilises dans SAVANE diffrent lgrement de celles utilises dans SAVATECA. Elles comportent en particulier chacune une mthode permettant de sauvegarder lensemble de leurs paramtres dans le fichier de la carte auquel appartient le cadre.
class CAttribut { public : int m_iType; int m_iNbvalb; int m_iPtrval; int m_iNumero; int m_iTemporaire; int m_iNbcar; char m_chNom[20]; public: CAttribut(); CAttribut(FILE* Fichier); void Ecrire(FILE* Fichier); }; class CRelation { private: CSchema* m_pSchema; public : long m_lAdresse; int m_iNb0; int m_iType; int m_iNba; int m_iNbObjets; char m_chNom[100]; char m_chFichFeuille[_MAX_PATH]; char m_chFichZone[_MAX_PATH]; char m_chFichArc[_MAX_PATH]; int m_iNoFichDescriptif; int m_iNoFichArc; int m_iNoFichFeuille; int m_iNoFichImage; BOOL m_bARasteriser; CAttribut* m_pAttributs[NB_MAX_ATTRIBUTS]; public: CRelation(CSchema* pSchema); CRelation(CSchema* pSchema,BOOL bMemeBase,FILE* Fichier); ~CRelation(); void Ecrire(FILE* Fichier); int NbMaxObjetsParFeuille(); int NbMaxArcsParFeuille(); void MiseAJour(int iNoFichier);

Structures et mthodes : implmentation 379

void CalculDesCentroides(); unsigned char* ImageRaster(int iNoatt); void ExporterUneFeuille(const char* chNomFeuille,const char* chNomAttribut,const char* chNomFichier); };

Les mthodes NbMaxObjetsParFeuille() et NbMaxArcsParFeuille() permettent de connatre de nombre maximum dobjets ou darcs dans une feuille. Ces fonctions sont utilises pour dimensionner lallocation dynamique de mmoire dans certaines oprations sur la base de donnes qui utilisent lindexation gographique.
int CRelation::NbMaxObjetsParFeuille() { int iNbMaxObjetsParFeuille=0; FILE* FileFeuille; CWind* pWind=m_pSchema->GetCadre()->GetWind(); //--- traitement switch(m_iType) { case 5: case 15: case 25: case 1: case 11: default: iNbMaxObjetsParFeuille=0; break; case 4: case 3: case 2: FileFeuille=fopen(m_chFichFeuille,"rb"); if(FileFeuille != NULL) { float fXb,fYb,fXh,fYh; int iNbObj; while(fscanf(FileFeuille,"%*17c%8f%8f%8f%8f%8i%*25c",&fXb,&fYb,&fXh,&fYh,&iNbObj) == { if(iNbMaxObjetsParFeuille < iNbObj)iNbMaxObjetsParFeuille=iNbObj; } fclose(FileFeuille); } break; case 14: case 13: case 12: case 24: if(m_iNoFichFeuille == -1)FileFeuille=fopen(m_chFichFeuille,"rb"); else FileFeuille=fopen(m_pSchema->m_chFprovFeuille[m_iNoFichFeuille],"rb"); if(FileFeuille != NULL) { float fXb,fYb,fXh,fYh; int iNbObj; while(fscanf(FileFeuille,"%*17c%8f%8f%8f%8f%8i%*25c",&fXb,&fYb,&fXh,&fYh,&iNbObj) == { if(iNbMaxObjetsParFeuille < iNbObj)iNbMaxObjetsParFeuille=iNbObj; } fclose(FileFeuille); } break;

5)

5)

} return iNbMaxObjetsParFeuille; }

380

Annexe

A.2.1.2. La classe CSchema La classe CSchema de SAVANE permet dencapsuler variables et mthodes concernant la gestion du schma de la base correspond une requte dans un cadre. Ce schma volue au fur et mesure de la requte : un objet de cette classe permet de maintenir ltat du schma de la base au cours de la requte.
class CSchema { private: CCadre* m_pCadre; int m_iNumero; public : int m_iNbacc; CRelation* m_pRelations[NB_MAX_RELATIONS]; char char char char int int int int m_chFprovDescriptif[NB_MAX_FICHIERS_TEMP][_MAX_PATH]; m_chFprovArc[NB_MAX_FICHIERS_TEMP][_MAX_PATH]; m_chFprovFeuille[NB_MAX_FICHIERS_TEMP][_MAX_PATH]; m_chFprovImage[NB_MAX_FICHIERS_TEMP][_MAX_PATH];

m_iFdisDescriptif[NB_MAX_FICHIERS_TEMP]; m_iFdisArc[NB_MAX_FICHIERS_TEMP]; m_iFdisFeuille[NB_MAX_FICHIERS_TEMP]; m_iFdisImage[NB_MAX_FICHIERS_TEMP];

char m_chNomFtval[_MAX_PATH]; int m_iPvl; public: CSchema(CCadre* pCadre); CSchema(CCadre* pCadre,BOOL bMemeBase,FILE* Fichier); ~CSchema(); void Ecrire(FILE* Fichier); void InitNomFichiers(); void Alloc(); void Actualiser(); void Desalloc(); int FchoixDescriptif(); int FchoixImage(); int FchoixFeuille(); int FchoixArc(); int RelRecherche(const char *nom); int AttrRecherche(int iNoth,const char *nom); CCadre* GetCadre() {return m_pCadre;}; int NzMax(int iNoth); int NombreObjets(int iNoth); int NouvelleRelation(int iType,char *chNomRelation,int iNoFichierFeuille,int iNoFichierDescriptif,int iNoFichierArc); int NouvelleRelationMosaique(char *chNomRelation,double dResolution,int iTailleImagette,const char *chDirMosaique); int NouvelAttribut(int iNoth,int iType,int iNbcar,int iNbValb,int iPtrval,char *chNomAttribut,char *chDescription); BOOL ExporterShapeFile(int iNoth,int iNbAttributs,int iTypeExport,int iTypeCoordonnees,int* itabNoatt,CString strNomFichier); BOOL ExporterMosaique(int iNoth,int iNoatt,CString strNomFichier); BOOL ExporterDatabase(int iNoth,int iNbAttributs,int iTypeDatabase,int* itabNoatt,CString strNomFichier); };

Chaque schma correspond un cadre gographique (m_pCadre). La mthode Alloc() permet de charger le schma dans un objet de type CSchema, partir du dictionnaire et de la vue externe utilise. Elle utilise les classes CDico et CFpacc9 :
void CSchema::Alloc() { //--- initialisation des accs aux donnes suivant la vue externe int i,j,iNbrel,iNorel,iNoth,iNbatt,iNovar,iNoatt,iType,iNb0,iNrec,plibz,pliba; int iTypeRel[NB_MAX_RELATIONS],iNbattAbs[NB_MAX_RELATIONS]; long adr;

Structures et mthodes : implmentation 381

long iPtrRel[NB_MAX_RELATIONS]; //--- lecture des relations et attributs CDico dico; if(dico.Ouvrir(base.m_chNomFtbase,MODE_READ) == FALSE)return; dico.LireNumero(m_iNumero); dico.LireNbRelations(iNbrel); i=2; j=1; while(j <= iNbrel) { adr=i*dico.GetTailleRecord(); dico.LireRelationTypeNbAttributs(adr,iType,iNbatt); iTypeRel[j]=iType; iPtrRel[j]=adr; iNbattAbs[j]=iNbatt; i+=(iNbatt+1); j++; } dico.Fermer(); //--- lecture du fichier des accs et allocation FILE *FileAcces; char chBuffer[100]; i=_chdir(base.m_chDirBase); FileAcces=fopen("fpacc","rb"); CfpaccV9 fpacc; m_iNbacc=fpacc.RechercheEnteteVue(FileAcces,base.m_chNomVue); iNoth=1; while(iNoth <= m_iNbacc) { fpacc.LireEnteteRelation(FileAcces,iNorel,iNbatt); m_pRelations[iNoth]= new CRelation(this); m_pRelations[iNoth]->m_lAdresse=iPtrRel[iNorel]; m_pRelations[iNoth]->m_iNba=iNbatt; //--- initialisation des numros de fichiers temporaires pour les relations m_pRelations[iNoth]->m_iNoFichDescriptif=-1; m_pRelations[iNoth]->m_iNoFichImage=-1; m_pRelations[iNoth]->m_iNoFichFeuille=-1; m_pRelations[iNoth]->m_iNoFichArc=-1; for(iNoatt=1;iNoatt <= iNbatt;iNoatt++) { fread(chBuffer,4,1,FileAcces); chBuffer[4]=0; sscanf(chBuffer,"%4d",&iNovar); m_pRelations[iNoth]->m_pAttributs[iNoatt]= new CAttribut(); m_pRelations[iNoth]->m_pAttributs[iNoatt]->m_iNumero=iNovar; } iNoth++; } fclose(FileAcces); i=_chdir(base.m_chDirSav); //--- initialisation de la disponibilit des fichiers provisoires for(i=0;i < NB_MAX_FICHIERS_TEMP;i++) { m_iFdisDescriptif[i]=0; m_iFdisImage[i]=0; m_iFdisArc[i]=0; m_iFdisFeuille[i]=0; } //--- initialisations des noms de relations et de leurs noms de fichiers permanents char chNomRelation[100],chNom2[_MAX_PATH],chNom3[100],chNom4[100]; dico.Ouvrir(base.m_chNomFtbase,MODE_READ); iNoth=1; while(iNoth <= m_iNbacc) { adr=m_pRelations[iNoth]->m_lAdresse; dico.LireRelation(adr,chNomRelation,iType,iNb0,iNrec,chNom2,chNom3,chNom4,plibz,pliba);

382

Annexe
strcpy(m_pRelations[iNoth]->m_chNom,chNomRelation); m_pRelations[iNoth]->m_iType=iType; m_pRelations[iNoth]->m_iNb0=iNb0; if(iType == 5) { strcpy(m_pRelations[iNoth]->m_chFichFeuille,"aucun"); strcpy(m_pRelations[iNoth]->m_chFichZone,chNom2); strcat(m_pRelations[iNoth]->m_chFichZone,"\\"); strcat(m_pRelations[iNoth]->m_chFichZone,m_pRelations[iNoth]->m_chNom); strcpy(m_pRelations[iNoth]->m_chFichArc,"aucun"); } else { strcpy(m_pRelations[iNoth]->m_chFichFeuille,base.m_chDirBase); strcpy(m_pRelations[iNoth]->m_chFichZone,base.m_chDirBase); strcpy(m_pRelations[iNoth]->m_chFichArc,base.m_chDirBase); strcat(m_pRelations[iNoth]->m_chFichFeuille,"\\"); strcat(m_pRelations[iNoth]->m_chFichZone,"\\"); strcat(m_pRelations[iNoth]->m_chFichArc,"\\"); strcat(m_pRelations[iNoth]->m_chFichFeuille,chNom2); strcat(m_pRelations[iNoth]->m_chFichZone,chNom3); strcat(m_pRelations[iNoth]->m_chFichArc,chNom4); } iNoth++; }

//--- initialisations des noms d'attribut int iTypeAttr,iNbvalb,iPtrval,iNbcar; char chNomAttribut[100],chDescription[128]; iNoth=1; while(iNoth <= m_iNbacc) { iNoatt=1; while(iNoatt <= m_pRelations[iNoth]->m_iNba) { strcpy(chNomAttribut,""); iNovar=m_pRelations[iNoth]->m_pAttributs[iNoatt]->m_iNumero; adr=m_pRelations[iNoth]->m_lAdresse + (iNovar*dico.GetTailleRecord()); dico.LireAttribut(adr,chNomAttribut,iTypeAttr,iNbvalb,iPtrval,iNbcar,chDescription); strcpy(m_pRelations[iNoth]->m_pAttributs[iNoatt]->m_chNom,chNomAttribut); m_pRelations[iNoth]->m_pAttributs[iNoatt]->m_iType=iTypeAttr; m_pRelations[iNoth]->m_pAttributs[iNoatt]->m_iNbvalb=iNbvalb; m_pRelations[iNoth]->m_pAttributs[iNoatt]->m_iPtrval=iPtrval; iNoatt++; } iNoth++; } dico.Fermer(); m_iPvl=1; }

La mthode Actualiser() permet de recharger le schma aprs une modification externe du schma de la base (avec SAVATECA), tout en conservant ltat des relations temporaires (modifies par la requte en cours). La variable m_iNumero de la classe permet de connatre ltat du schma et de le comparer avec ltat actuel du dictionnaire.
void CSchema::Actualiser() { //--- vrifier les diffrences de schma int iNumero; CDico dico; if(dico.Ouvrir(base.m_chNomFtbase,MODE_READ) == FALSE)return; dico.LireNumero(iNumero); if(iNumero == m_iNumero) { dico.Fermer(); return;

Structures et mthodes : implmentation 383

} //--- vrifier que les relations appartiennent toujours la base, et mettre jour les divers pointeurs BOOL bModifie,bTrouve,bTrouveAttribut; int i,j,k,iNbRelations,iNoth,iTypeRelation,iNbAttributs,iNrec,plibz,pliba; int iNoatt,iTypeAttribut,iNbvalb,iPtrval,iNbcar,iTemporaire; long lAdresse,lAdresseAttribut; char chNomRelation[64],chNom2[_MAX_PATH],chNom3[100],chNom4[100],chNomFichier[_MAX_PATH]; char chNomAttribut[64],chDescription[128]; //--- actualisation m_iNumero=iNumero; bModifie=FALSE; //--- mise jour des relations dico.LireNbRelations(iNbRelations); iNoth=1; while(iNoth <= m_iNbacc) { if(m_pRelations[iNoth]->m_lAdresse > 0) { //--- relation non temporaire, recherche dans la base bTrouve=FALSE; i=2; j=1; while(j <= iNbRelations && bTrouve == FALSE) { lAdresse=i*dico.GetTailleRecord(); dico.LireRelation(lAdresse,chNomRelation,iTypeRelation,iNbAttributs,iNrec,chNom2 ,chNom3,chNom4,plibz,pliba); if(strcmp(chNomRelation,m_pRelations[iNoth]->m_chNom) == 0) { //--- on actualise les paramtres de la relation bTrouve=TRUE; if(m_pRelations[iNoth]->m_lAdresse != lAdresse) { m_pRelations[iNoth]->m_lAdresse=lAdresse; bModifie=TRUE; } if(m_pRelations[iNoth]->m_iNb0 != iNbAttributs) { m_pRelations[iNoth]->m_iNb0=iNbAttributs; bModifie=TRUE; } if(m_pRelations[iNoth]->m_iType == 5 || m_pRelations[iNoth]->m_iType == 15) { //--- cas mosaique strcpy(chNomFichier,chNom2); strcat(chNomFichier,"\\"); strcat(chNomFichier,m_pRelations[iNoth]->m_chNom); if(strcmp(m_pRelations[iNoth]->m_chFichZone,chNomFichier) != 0) { strcpy(m_pRelations[iNoth]->m_chFichZone,chNomFichier); bModifie=TRUE; } } else { if(m_pRelations[iNoth]->m_iNoFichFeuille == -1) { //--- vrifier l'emplacement du fichier feuille d'origine strcpy(chNomFichier,base.m_chDirBase); strcat(chNomFichier,"\\"); strcat(chNomFichier,chNom2); if(strcmp(m_pRelations[iNoth]->m_chFichFeuille,chNomFichier) != 0) { strcpy(m_pRelations[iNoth]->m_chFichFeuille,chNomFichier); bModifie=TRUE; } } if(m_pRelations[iNoth]->m_iNoFichDescriptif == -1) { //--- vrifier l'emplacement du fichier descriptif d'origine strcpy(chNomFichier,base.m_chDirBase); strcat(chNomFichier,"\\"); strcat(chNomFichier,chNom3); if(strcmp(m_pRelations[iNoth]->m_chFichZone,chNomFichier) != 0)

384

Annexe
{ strcpy(m_pRelations[iNoth]->m_chFichZone,chNomFichier); bModifie=TRUE; }

} if(m_pRelations[iNoth]->m_iNoFichArc == -1) { //--- vrifier l'emplacement du fichier arc d'origine strcpy(chNomFichier,base.m_chDirBase); strcat(chNomFichier,"\\"); strcat(chNomFichier,chNom4); if(strcmp(m_pRelations[iNoth]->m_chFichArc,chNomFichier) != 0) { strcpy(m_pRelations[iNoth]->m_chFichArc,chNomFichier); bModifie=TRUE; } } } //--- attributs iNoatt=1; while(iNoatt <= m_pRelations[iNoth]->m_iNba) { //--- recherche de l'attribut dans le dico bTrouveAttribut=FALSE; lAdresseAttribut=m_pRelations[iNoth]->m_lAdresse + dico.GetTailleRecord(); k=1; while(k <= iNbAttributs && bTrouveAttribut == FALSE) { dico.LireAttribut(lAdresseAttribut,chNomAttribut,iTypeAttribut,iNb valb,iPtrval,iNbcar,chDescription); lAdresseAttribut+=dico.GetTailleRecord(); if(strcmp(chNomAttribut,m_pRelations[iNoth]->m_pAttributs[iNoatt]->m_chNom) { //--- trouve bTrouveAttribut=TRUE; iTemporaire=m_pRelations[iNoth]->m_pAttributs[iNoatt]->m_iTemporaire; if(m_pRelations[iNoth]->m_iType < 10 && iTemporaire == 0) { //--- relation de base non modifie,attribut non temporaire if(m_pRelations[iNoth]->m_pAttributs[iNoatt]->m_iType != iTypeAttribut) { m_pRelations[iNoth]->m_pAttributs[iNoatt]->m_iType=iTypeAttribut; bModifie=TRUE; } if(m_pRelations[iNoth]->m_pAttributs[iNoatt]->m_iNumero != k) { m_pRelations[iNoth]->m_pAttributs[iNoatt]->m_iNumero=k; bModifie=TRUE; } } //--- vrifier les pointeurs des attributs nominaux de base if(m_pRelations[iNoth]->m_pAttributs[iNoatt]->m_iType == 1 && iTemporaire { if(m_pRelations[iNoth]->m_pAttributs[iNoatt]->m_iNbvalb != iNbvalb) { m_pRelations[iNoth]->m_pAttributs[iNoatt]->m_iNbvalb=iNbvalb; bModifie=TRUE; } if(m_pRelations[iNoth]->m_pAttributs[iNoatt]->m_iPtrval != iPtrval) { m_pRelations[iNoth]->m_pAttributs[iNoatt]->m_iPtrval=iPtrval; bModifie=TRUE; } }

== 0)

== 0)

} k++; }

if(m_pRelations[iNoth]->m_iType < 10 && bTrouveAttribut == FALSE) { //--- l'attribut iNoatt a t supprim de la base, le supprimer du schma delete m_pRelations[iNoth]->m_pAttributs[iNoatt]; for(k=iNoatt;k < m_pRelations[iNoth]->m_iNba;k++)m_pRelations[iNoth]>m_pAttributs[k]=m_pRelations[iNoth]->m_pAttributs[k+1]; m_pRelations[iNoth]->m_pAttributs[m_pRelations[iNoth]->m_iNba]=NULL; m_pRelations[iNoth]->m_iNba--;

Structures et mthodes : implmentation 385

bModifie=TRUE; } else iNoatt++; }

} i+=(iNbAttributs+1); j++; }

schma

if(bTrouve == FALSE) { //--- la relation a disparue depuis la dernire utilisation, il faut la supprimer du

CCadre* pCadre=GetCadre(); if(pCadre != NULL)XRelProj(pCadre,iNoth); } else iNoth++; } else iNoth++; }

dico.Fermer(); if(bModifie) { carte.ASauver(); //--- mise jour des explorateurs m_pCadre->MiseAJourExplorateurs(); } i=0; }

La mthode NouvelleRelation() permet de crer une nouvelle relation temporaire dans le schma :
int CSchema::NouvelleRelation(int iType,char *chNomRelation,int iNoFichierFeuille,int iNoFichierDescriptif,int iNoFichierArc) { //--- vrifier que la relation n'existe pas dj (normalement fait dans les dialogues) int iNoth=RelRecherche(chNomRelation); if(iNoth != 0) { switch(config.m_iLangage) { case FRANCAIS: default: AfxMessageBox("Cette relation existe dj !",MB_OK|MB_ICONEXCLAMATION); break; case ESPAGNOL: AfxMessageBox("Este relacin ya existe !",MB_OK|MB_ICONEXCLAMATION); break; case ANGLAIS: AfxMessageBox("This relation already exist !",MB_OK|MB_ICONEXCLAMATION); break; } return 0; } m_iNbacc++; iNoth=m_iNbacc; m_pRelations[iNoth]= new CRelation(this); strcpy(m_pRelations[iNoth]->m_chNom,chNomRelation); m_pRelations[iNoth]->m_iNoFichFeuille=iNoFichierFeuille; m_pRelations[iNoth]->m_iNoFichDescriptif=iNoFichierDescriptif; m_pRelations[iNoth]->m_iNoFichArc=iNoFichierArc; m_pRelations[iNoth]->m_iType=iType+10; m_pRelations[iNoth]->m_lAdresse=0L; //--- initialisation des numros de fichiers temporaires pour les relations if(iNoFichierFeuille >= 0)m_iFdisFeuille[iNoFichierFeuille]=1; if(iNoFichierDescriptif >= 0)m_iFdisDescriptif[iNoFichierDescriptif]=1; if(iNoFichierArc >= 0)m_iFdisArc[iNoFichierArc]=1; CCadre* pCadre=GetCadre(); pCadre->GetCarte()->SauverLesCadres();

386

Annexe

return iNoth; }

De mme, la mthode NouvelAttribut() permet de crer un nouvel attribut temporaire dans le schma :
int CSchema::NouvelAttribut(int iNoth,int iType,int iNbcar,int iNbvalb,int iPtrval,char *chNomAttribut,char *chDescription) { //--- creation d'un nouvel attribut dans le schema int iNoatt=m_pRelations[iNoth]->m_iNba+1; //--- rechercher d'abord pour voir si le nom n'existe pas int iTypeRelation=m_pRelations[iNoth]->m_iType; if(iTypeRelation != 5 && iTypeRelation != 15 && iTypeRelation != 25) { char chAjout[5]; int i=2; int iNoattIdem=AttrRecherche(iNoth,chNomAttribut); while(iNoattIdem > 0 && i < 10) { //--- l'attribut existe, on modifie le nom chNomAttribut[12]=0; sprintf(chAjout," (%1d)",i); chAjout[4]=0; strcat(chNomAttribut,chAjout); iNoattIdem=AttrRecherche(iNoth,chNomAttribut); i++; } } m_pRelations[iNoth]->m_iNba++; m_pRelations[iNoth]->m_pAttributs[iNoatt]= new CAttribut(); m_pRelations[iNoth]->m_pAttributs[iNoatt]->m_iNumero=iNoatt; strcpy(m_pRelations[iNoth]->m_pAttributs[iNoatt]->m_chNom,chNomAttribut); m_pRelations[iNoth]->m_pAttributs[iNoatt]->m_iType=iType; m_pRelations[iNoth]->m_pAttributs[iNoatt]->m_iNbvalb=iNbvalb; m_pRelations[iNoth]->m_pAttributs[iNoatt]->m_iPtrval=iPtrval; m_pRelations[iNoth]->m_pAttributs[iNoatt]->m_iTemporaire=1; if(iType == 1 || iType == 5)m_pRelations[iNoth]->m_pAttributs[iNoatt]->m_iNbcar=iNbcar; else m_pRelations[iNoth]->m_pAttributs[iNoatt]->m_iNbcar=0; if(strlen(chDescription) == 0) { switch(config.m_iLangage) { case FRANCAIS: default: strcpy(chDescription,"sans description"); break; case ESPAGNOL: strcpy(chDescription,"sin descripcin"); break; case ANGLAIS: strcpy(chDescription,"without description"); break; } } CCadre* pCadre=GetCadre(); pCadre->GetCarte()->SauverLesCadres(); return iNoatt; }

A.2.1.3. La classe CLecture La classe CLecture regroupe les oprations de lecture des objets dune relation. Elle est utilise dans toutes les oprations pour avoir accs aux donnes :
class CLecture { private: CCadre* m_pCadre;

Structures et mthodes : implmentation 387

CWind* m_pWind; int m_iNoth; int m_tabp[NB_MAX_ATTRIBUTS]; int m_iNb0; int m_iNba; int m_iNbnew; int m_iNbVariables; int m_iEcrire; int m_iType; int m_iNb; int m_iNbObj; int m_iSizeIdentifiantTuple; int nz; int m_iArc; long m_iPtrarc; long m_iPtrTuple; long m_iPtrarcFeuille; long m_iNbarcFeuille; float xc,yc,xb,yb,xh,yh; float m_fWindXb; float m_fWindYb; float m_fWindXh; float m_fWindYh; FILE* FILE* FILE* FILE* m_FileFeuille; m_FileDescriptif; m_FileArc; m_FileResultat;

public: CLecture(); ~CLecture(); BOOL Open(CCadre* pCadre,int iNoth); BOOL Open(CCadre* pCadre,int iNoth,int iNoFichier,int iNbnew); void Close(); BOOL Objet(float fXSav,float fYSav,float* v,FILE* FileResultat); int Lire(float* v); int LireSansTestFenetre(float* v); int LireTuple(long ptrFile,float* v); void SetFenetreLecture(float fXbSav,float fYbSav,float fXhSav,float fYhSav); long GetPointeurTuple() {return m_iPtrTuple;}; void GetCentroide(float &fXc,float &fYc) {fXc=xc;fYc=yc;}; int GetPointeurArc() {return m_iPtrarc;}; int GetNbarcFeuille() {return m_iNbarcFeuille;}; int GetPointeurArcFeuille() {return m_iPtrarcFeuille;}; int GetNz() {return nz;}; FILE* GetFileArc() {return m_FileArc;}; void GetRectangle(float &fXb,float &fYb,float &fXh,float &fYh) {fXb=xb;fYb=yb;fXh=xh;fYh=yh;}; void Ecrire(float* v); };

Le tableau m_tabp contient lindirection entre les numros externes et internes pour les attributs de la relation. Il est initialis, comme toutes les autres variables de la relation, par la mthode Open(). Les variables m_fWind permettent de dfinir le rectangle gographique de slection implicite. Voici par exemple limplmentation de la mthode de lecture des objets. On remarquera en particulier les diffrences de lecture entre les diffrents types, quils soient de base (5,4,3,2,1) ou temporaires (15,25,14,24,13,12,11). Cette procdure revoie 1 si la fin des objets a t atteinte, 0 si lobjet nest pas dans la fentre du cadre, 1 si un objet a t lu, 2 si lon change de feuille. Le tableau v renvoie les valeurs des attributs de lobjet lu :
int CLecture::Lire(float* v) { int i; switch(m_iType) {

388

Annexe
case 4: if(m_iNb <= m_iNbObj) { //--- il reste des objets a lire dans la feuille courante m_iPtrTuple=ftell(m_FileDescriptif); fread(&nz,SIZEINT,1,m_FileDescriptif); fread(&xc,SIZECOOR,1,m_FileDescriptif); fread(&yc,SIZECOOR,1,m_FileDescriptif); fread(&xb,SIZECOOR,1,m_FileDescriptif); fread(&yb,SIZECOOR,1,m_FileDescriptif); fread(&xh,SIZECOOR,1,m_FileDescriptif); fread(&yh,SIZECOOR,1,m_FileDescriptif); for(i=1;i <= m_iNb0;i++)fread(&v[i],SIZEVAL,1,m_FileDescriptif); m_iNb++; nz=UnixToDos(nz); xc=UnixToDos(xc); yc=UnixToDos(yc); xb=UnixToDos(xb); yb=UnixToDos(yb); xh=UnixToDos(xh); yh=UnixToDos(yh); if(xh >= m_fWindXb && xb <= m_fWindXh && yh >= m_fWindYb && yb <= m_fWindYh) { for(i=1;i <= m_iNb0;i++)v[i]=UnixToDos(v[i]); return 1; } return 0; } else { if(m_iEcrire && m_iNbObj > 0) { //--- fin de la feuille precedente nz=0; Ecrire(v); } //--- positionne sur le premier lment d'une nouvelle feuille int iPtr,iPtrObj,iNbarc,iPtrarc; float fXb,fYb,fXh,fYh; while(fscanf(m_FileFeuille,"%*17c%8f%8f%8f%8f%8i%8i%8i%8i%*c",&fXb,&fYb,&fXh,& fYh,&m_iNbObj,&iPtrObj,&iNbarc,&iPtrarc) == 8) { if(fXh >= m_fWindXb && fXb <= m_fWindXh && fYh >= m_fWindYb && fYb <= m_fWindYh) { //--- positionne sur le premier lment a lire, avec m_iNbObj objets a lire iPtr=(iPtrObj-1)*(m_iSizeIdentifiantTuple + m_iNb0*SIZEVAL); fseek(m_FileDescriptif,iPtr,SEEK_SET); m_iNb=1; if(m_iEcrire && m_iNbObj > 0) { fwrite(&iNbarc,SIZEINT,1,m_FileResultat); fwrite(&iPtrarc,SIZEINT,1,m_FileResultat); } m_iNbarcFeuille=iNbarc; m_iPtrarcFeuille=iPtrarc; return 2; } } //--- fin des feuilles if(m_iEcrire) { iNbarc=0; iPtrarc=0; fwrite(&iNbarc,SIZEINT,1,m_FileResultat); fwrite(&iPtrarc,SIZEINT,1,m_FileResultat); m_iNbarcFeuille=0; m_iPtrarcFeuille=0; } return -1; } break; case 3: if(m_iNb <= m_iNbObj) { //--- il reste des objets a lire dans la feuille courante m_iPtrTuple=ftell(m_FileDescriptif); fread(&xc,SIZECOOR,1,m_FileDescriptif);

Structures et mthodes : implmentation 389

fread(&yc,SIZECOOR,1,m_FileDescriptif); for(i=1;i <= m_iNb0;i++)fread(&v[i],SIZEVAL,1,m_FileDescriptif); m_iNb++; xc=UnixToDos(xc); yc=UnixToDos(yc); if(xc >= m_fWindXb && xc <= m_fWindXh && yc >= m_fWindYb && yc <= m_fWindYh) { for(i=1;i <= m_iNb0;i++)v[i]=UnixToDos(v[i]); return 1; } return 0; } else { //--- positionne sur le premier lment d'une feuille int iPtr,iPtrObj; float fXb,fYb,fXh,fYh; while(fscanf(m_FileFeuille,"%*17c%8f%8f%8f%8f%8i%8i%*8i%*8i%*c",&fXb,&fYb,&fXh,&fYh,&m_iNbOb j,&iPtrObj) == 6) { if(fXh >= m_fWindXb && fXb <= m_fWindXh && fYh >= m_fWindYb && fYb <= m_fWindYh) { //--- positionne sur le premier lment a lire, avec m_iNbObj objets a lire iPtr=(iPtrObj-1)*(m_iSizeIdentifiantTuple + m_iNb0*SIZEVAL); fseek(m_FileDescriptif,iPtr,SEEK_SET); m_iNb=1; return 2; } } //--- fin des feuilles return -1; } break; case 2: if(m_iNb <= m_iNbObj) { int iPtr; //--- il reste des objets a lire dans la feuille courante m_iPtrTuple=ftell(m_FileDescriptif); fread(&m_iArc,SIZEINT,1,m_FileDescriptif); fread(&m_iPtrarc,SIZEINT,1,m_FileDescriptif); fread(&xc,SIZECOOR,1,m_FileDescriptif); fread(&yc,SIZECOOR,1,m_FileDescriptif); m_iArc=UnixToDos(m_iArc); m_iPtrarc=UnixToDos(m_iPtrarc); xc=UnixToDos(xc); yc=UnixToDos(yc); for(i=1;i <= m_iNb0;i++)fread(&v[i],SIZEVAL,1,m_FileDescriptif); m_iNb++; iPtr=(m_iPtrarc-1)*SIZEREC + 4*SIZECOOR; fseek(m_FileArc,iPtr,SEEK_SET); fread(&xb,SIZECOOR,1,m_FileArc); fread(&yb,SIZECOOR,1,m_FileArc); fread(&xh,SIZECOOR,1,m_FileArc); fread(&yh,SIZECOOR,1,m_FileArc); xb=UnixToDos(xb); yb=UnixToDos(yb); xh=UnixToDos(xh); yh=UnixToDos(yh); if(xh >= m_fWindXb && xb <= m_fWindXh && yh >= m_fWindYb && yb <= m_fWindYh) { for(i=1;i <= m_iNb0;i++)v[i]=UnixToDos(v[i]); return 1; } return 0; } else { //--- positionne sur le premier lment d'une feuille int iPtr,iPtrObj,iNbarc,iPtrarc; float fXb,fYb,fXh,fYh;

390

Annexe

while(fscanf(m_FileFeuille,"%*17c%8f%8f%8f%8f%8i%8i%8i%8i%*c",&fXb,&fYb,&fXh,&fYh,&m_iNbObj, &iPtrObj,&iNbarc,&iPtrarc) == 8) { if(fXh >= m_fWindXb && fXb <= m_fWindXh && fYh >= m_fWindYb && fYb <= m_fWindYh) { //--- positionne sur le premier lment a lire, avec m_iNbObj objets a lire iPtr=(iPtrObj-1)*(m_iNb0*SIZEVAL + m_iSizeIdentifiantTuple); fseek(m_FileDescriptif,iPtr,SEEK_SET); m_iNb=1; m_iNbarcFeuille=iNbarc; m_iPtrarcFeuille=iPtrarc; return 2; } } //--- fin des feuilles m_iNbarcFeuille=0; m_iPtrarcFeuille=0; return -1; } break; case 1: m_iPtrTuple=ftell(m_FileDescriptif); for(i=1;i <= m_iNb0;i++)fread(&v[i],SIZEVAL,1,m_FileDescriptif); if(!feof(m_FileDescriptif)) { for(i=1;i <= m_iNb0;i++)v[i]=UnixToDos(v[i]); return 1; } else return -1; break; case 14: case 24: if(m_iNbObj) { //--- il reste des objets a lire m_iPtrTuple=ftell(m_FileDescriptif); fread(&nz,SIZEINT,1,m_FileDescriptif); fread(&xc,SIZECOOR,1,m_FileDescriptif); fread(&yc,SIZECOOR,1,m_FileDescriptif); fread(&xb,SIZECOOR,1,m_FileDescriptif); fread(&yb,SIZECOOR,1,m_FileDescriptif); fread(&xh,SIZECOOR,1,m_FileDescriptif); fread(&yh,SIZECOOR,1,m_FileDescriptif); for(i=1;i <= m_iNba;i++)fread(&v[i],SIZEVAL,1,m_FileDescriptif); if(nz != 0)return 1; else { if(m_iEcrire)Ecrire(v); m_iNbObj=0; return 3; } } else { int iNbarc,iPtrarc; fread(&iNbarc,SIZEINT,1,m_FileDescriptif); fread(&iPtrarc,SIZEINT,1,m_FileDescriptif); if(m_iEcrire) { fwrite(&iNbarc,SIZEINT,1,m_FileResultat); fwrite(&iPtrarc,SIZEINT,1,m_FileResultat); } if(iNbarc == 0)return -1; m_iNbObj=1; m_iNbarcFeuille=iNbarc; m_iPtrarcFeuille=iPtrarc; return 2; } break; case 13: m_iPtrTuple=ftell(m_FileDescriptif); fread(&xc,SIZECOOR,1,m_FileDescriptif); fread(&yc,SIZECOOR,1,m_FileDescriptif); for(i=1;i <= m_iNba;i++)fread(&v[i],SIZEVAL,1,m_FileDescriptif);

Structures et mthodes : implmentation 391

if(!feof(m_FileDescriptif))return 1; else return -1; break; case 12: m_iPtrTuple=ftell(m_FileDescriptif); fread(&m_iArc,SIZEINT,1,m_FileDescriptif); fread(&m_iPtrarc,SIZEINT,1,m_FileDescriptif); fread(&xc,SIZECOOR,1,m_FileDescriptif); fread(&yc,SIZECOOR,1,m_FileDescriptif); for(i=1;i <= m_iNba;i++)fread(&v[i],SIZEVAL,1,m_FileDescriptif); if(!feof(m_FileDescriptif))return 1; else return -1; break; case 11: m_iPtrTuple=ftell(m_FileDescriptif); for(i=1;i <= m_iNba;i++)fread(&v[i],SIZEVAL,1,m_FileDescriptif); if(!feof(m_FileDescriptif))return 1; else return -1; break; default: break; } return -1; }

Voici lutilisation typique de cette classe dans une procdure de lecture des valeurs des objets dune relation :
CLecture lecture; if(lecture.Open(pCadre,iNoth,iNoFichier,0)) { //--- lecture des objets float v[NB_MAX_ATTRIBUTS],fResultat; i=lecture.Lire(v); while(i != -1) { if(i == 1) { //--- traitement } i=lecture.Lire(v); } lecture.Close();

A.2.1.4. La classe CMacro La classe CMacro encapsule les oprations de dfinition et dexcution de macro-commandes et de mthodes :
class CMacro { private: CCadre* m_pCadre; int m_iExec; char m_chNomFichierMacro[_MAX_PATH]; BOOL LireCommande(FILE* FileMacro,char* chCommande); public: CMacro(CCadre* pCadre); ~CMacro(); BOOL Nouveau(const char* chNomFichierMacro); BOOL Ouvrir(const char* chNomFichierMacro); BOOL EnregistrerCommande(char* chCommande); BOOL Executer(const char* chNomMacro,const char* chNomFichierMacro,BOOL bEnregistrerDansMacroCadre); void Fermer(); BOOL New(); int GetMode() {return m_iExec;}; };

392

Annexe

La mthode EnregistrerCommande() permet denregistrer une opration dans une macro-commande, en crivant les paramtres de lopration dans le fichier de la macro-commande. Elle est utilise systmatiquement lors du dclenchement dune commande dans SAVANE, pour inscrire cette commande dans la macro-commande lie au cadre, et dans une macro-commande en cours de dfinition (si une telle macro-commande a t cre auparavant avec la mthode Nouveau()). Par exemple, voici le code de rponse au menu CRIS-Longueur :
void CMainFrame::OnCrisLongueur() { int iNoCadre; if(carte.m_iNbCadres == 1)iNoCadre=0; else iNoCadre=selection.m_iNoDuGroupe[0]; CCadre* pCadre=carte.m_pCadre[iNoCadre]; if(pCadre != NULL)pCadre->GetSchema()->Actualiser(); CDialogCrisLongueur dialogue(pCadre->GetSchema()); if(dialogue.DoModal() == IDOK) { FILE* FileMenu=fopen(base.m_chNomFtmp,"wb"); fprintf(FileMenu,"%d\n",dialogue.m_iNoth); fprintf(FileMenu,"%d\n",dialogue.m_iUnite); fclose(FileMenu); //--- calcul du nouvel attribut pCadre->GetMacro()->EnregistrerCommande("CRIS_LONGUEUR"); pCadre->GetMacroCadre()->EnregistrerCommande("CRIS_LONGUEUR"); XCrisLongueur(pCadre); carte.SauverLesCadres(); pCadre->GetDlgStatExplorateur()->MiseAJour(dialogue.m_iNoth); }

A.2.1.5. La classe CCalculateur La classe CCalculateur encapsule toutes les variables et mthodes permettant le calcul numrique partir dune expression numrique et de la valeur des attributs dun objet dune relation :
class CCalculateur { private: CSchema* m_pSchema; int m_iNoth; char* m_chExpressionChaine; Symbole m_SymboleCourant; double m_dValeurNombre; char m_chNomIdentifiant[_MAX_PATH]; char m_NomNombre[_MAX_PATH]; float* m_pVariables; int m_iNoErreur; Symbole LireSymbole(); double ConditionExpression(); double ConditionTerme(); double Expression(); double Terme(); double Primaire(); double ErreurDeCalcul(char* Texte); Symbole TestSymbole(); void TestConditionExpression(); void TestConditionTerme(); void TestExpression(); void TestTerme(); int TestPrimaire(); int ErreurDeSyntaxe(char* Texte); public:

Structures et mthodes : implmentation 393

CCalculateur(CSchema* pSchema,int iNoth); int Test(char* chFormule); double Calcul(char* chFormule, float* dVariables); int m_iNbErreurDeCalcul[20]; int m_iAttributs[NB_MAX_ATTRIBUTS]; };

Elle permet de tester les formules (Test()), et de calculer le rsultat (Calcul()). Le calcul est bien sr rcursif :
double CCalculateur::Calcul(char* chFormule, float* pVariables) { m_pVariables=pVariables; m_iNoErreur=0; m_chExpressionChaine=chFormule; m_SymboleCourant=DEBUT; LireSymbole(); double d=ConditionExpression(); if(m_iNoErreur != 0)d=DINCONNU; return d; } Symbole CCalculateur::LireSymbole() // lit un symbole pour le calcul { char caractere; if(m_SymboleCourant == FIN) return m_SymboleCourant; do { caractere=*m_chExpressionChaine; if(caractere == '\0') return m_SymboleCourant=FIN; m_chExpressionChaine++; } while (isspace(caractere)); switch (caractere) { case ';' : return m_SymboleCourant=FIN; case '*': return m_SymboleCourant=MUL; case '/': return m_SymboleCourant=DIV; case '+': return m_SymboleCourant=PLUS; case '-': return m_SymboleCourant=MOINS; case '(': return m_SymboleCourant=LP; case ')': return m_SymboleCourant=RP; case ',': return m_SymboleCourant=VIRGULE; case ':': return m_SymboleCourant=DEUXPOINT; case '=': return m_SymboleCourant=EGAL; case '<': caractere=*m_chExpressionChaine++; if(caractere == '>')return m_SymboleCourant=DIFFERENT; if(caractere == '=')return m_SymboleCourant=INFERIEUREGAL; m_chExpressionChaine--; return m_SymboleCourant=INFERIEUR; break; case '>': caractere=*m_chExpressionChaine++; if(caractere == '=')return m_SymboleCourant=SUPERIEUREGAL; m_chExpressionChaine--; return m_SymboleCourant=SUPERIEUR; break; case '0': case '1': case '2': case '3': case '4': case '5': case '6': case '7': case '8': case '9': case '.': { char* p=m_NomNombre; *p++=caractere; caractere=*m_chExpressionChaine++; while(isdigit(caractere) || caractere == '.') { *p++=caractere; caractere=*m_chExpressionChaine++; } m_chExpressionChaine--; *p=0; m_dValeurNombre=atof(m_NomNombre); return m_SymboleCourant=NOMBRE; } break;

394

Annexe
case 'v': // variable case 'V': { char* p=m_chNomIdentifiant; caractere=*m_chExpressionChaine++; while(isdigit(caractere)) { *p++=caractere; caractere=*m_chExpressionChaine++; } m_chExpressionChaine--; *p=0; int iIndice=atoi(m_chNomIdentifiant); int iNovar=m_pSchema->m_pRelations[m_iNoth]->m_pAttributs[iIndice]->m_iNumero; m_dValeurNombre=(double) *(m_pVariables+iNovar); return m_SymboleCourant=NOMBRE; } break; default : if(isalpha(caractere)) { char* p=m_chNomIdentifiant; *p++=(char ) tolower(caractere); caractere=*m_chExpressionChaine++; while(isalpha(caractere)) { *p++=(char ) tolower(caractere); caractere=*m_chExpressionChaine++; } m_chExpressionChaine--; *p=0; if(strcmp(m_chNomIdentifiant,"sin") == 0)return m_SymboleCourant=SIN; else if(strcmp(m_chNomIdentifiant,"cos") == 0)return m_SymboleCourant=COS; else if(strcmp(m_chNomIdentifiant,"tan") == 0)return m_SymboleCourant=TAN; else if(strcmp(m_chNomIdentifiant,"asin") == 0)return m_SymboleCourant=ASIN; else if(strcmp(m_chNomIdentifiant,"acos") == 0)return m_SymboleCourant=ACOS; else if(strcmp(m_chNomIdentifiant,"atan") == 0)return m_SymboleCourant=ATAN; else if(strcmp(m_chNomIdentifiant,"abs") == 0)return m_SymboleCourant=ABS; else if(strcmp(m_chNomIdentifiant,"exp") == 0)return m_SymboleCourant=EXP; else if(strcmp(m_chNomIdentifiant,"log") == 0)return m_SymboleCourant=LOG; else if(strcmp(m_chNomIdentifiant,"ln") == 0)return m_SymboleCourant=LN; else if(strcmp(m_chNomIdentifiant,"pow") == 0)return m_SymboleCourant=POW; else if(strcmp(m_chNomIdentifiant,"mod") == 0)return m_SymboleCourant=MOD; else if(strcmp(m_chNomIdentifiant,"sqrt") == 0)return m_SymboleCourant=SQRT; else if(strcmp(m_chNomIdentifiant,"int") == 0)return m_SymboleCourant=PARTINT; else else else else else else if(strcmp(m_chNomIdentifiant,"si") == 0)return m_SymboleCourant=SI; if(strcmp(m_chNomIdentifiant,"if") == 0)return m_SymboleCourant=SI; if(strcmp(m_chNomIdentifiant,"et") == 0)return m_SymboleCourant=AND; if(strcmp(m_chNomIdentifiant,"and") == 0)return m_SymboleCourant=AND; if(strcmp(m_chNomIdentifiant,"ou") == 0)return m_SymboleCourant=OR; if(strcmp(m_chNomIdentifiant,"or") == 0)return m_SymboleCourant=OR;

else if(strcmp(m_chNomIdentifiant,"pi") == 0) { m_dValeurNombre= PI; return m_SymboleCourant=NOMBRE; } else if(strcmp(m_chNomIdentifiant,"e") == 0) { m_dValeurNombre= E; return m_SymboleCourant=NOMBRE; } } ErreurDeSyntaxe("Erreur de syntaxe : symbole inconnu !"); return m_SymboleCourant=FIN; break;

double CCalculateur::ConditionExpression() { double dGauche = ConditionTerme(); for(;;) { switch (m_SymboleCourant)

Structures et mthodes : implmentation 395

{ case AND : { LireSymbole(); double dDroit=ConditionTerme(); if(dGauche != 0. && dDroit != 0.)dGauche=1.; else dGauche=0.; } break; case OR : { LireSymbole(); double dDroit=ConditionTerme(); if(dGauche != 0. || dDroit != 0.)dGauche=1.; else dGauche=0.; } break; default : return dGauche; }

} }

double CCalculateur::ConditionTerme() { double dGauche = Expression(); switch (m_SymboleCourant) { case EGAL : { LireSymbole(); double dDroit=Expression(); if(dGauche == dDroit)return 1.; else return 0.; } case DIFFERENT : { LireSymbole(); double dDroit=Expression(); if(dGauche != dDroit)return 1.; else return 0.; } case INFERIEUR : { LireSymbole(); double dDroit=Expression(); if(dGauche < dDroit)return 1.; else return 0.; } case INFERIEUREGAL : { LireSymbole(); double dDroit=Expression(); if(dGauche <= dDroit)return 1.; else return 0.; } case SUPERIEUR : { LireSymbole(); double dDroit=Expression(); if(dGauche > dDroit)return 1.; else return 0.; } case SUPERIEUREGAL : { LireSymbole(); double dDroit=Expression(); if(dGauche >= dDroit)return 1.; else return 0.; } default : return dGauche; } } double CCalculateur::Expression() { double dGauche = Terme(); for(;;) { switch (m_SymboleCourant) { case PLUS : LireSymbole(); dGauche+=Terme(); break; case MOINS : LireSymbole();

396

Annexe
dGauche-=Terme(); break; default : return dGauche; }

} }

double CCalculateur::Terme() { double dGauche = Primaire(); for(;;) { switch (m_SymboleCourant) { case MUL: LireSymbole(); dGauche*=Primaire(); break; case DIV: { LireSymbole(); double d=Primaire(); if(d == 0)return ErreurDeCalcul("division par zro"); dGauche/=d; } break; default : return dGauche; } } } double CCalculateur::Primaire() { switch (m_SymboleCourant) { case LP : { LireSymbole(); double d=ConditionExpression(); LireSymbole(); // parenthese fermante return d; } case NOMBRE : LireSymbole(); if(m_dValeurNombre <= DINCONNU)return ErreurDeCalcul("variable : valeur inconnue"); return m_dValeurNombre; case MOINS : LireSymbole(); return -Primaire(); case PLUS : LireSymbole(); return Primaire(); case COS : LireSymbole(); return cos(Primaire()); case ACOS : { LireSymbole(); double d=Primaire(); if(d<-1. || d>1.)return ErreurDeCalcul("acos : erreur de domaine"); return acos(d); } case SIN : LireSymbole(); return sin(Primaire()); case ASIN : { LireSymbole(); double d=Primaire(); if(d<-1. || d>1.)return ErreurDeCalcul("asin : erreur de domaine"); return asin(d); } case TAN : LireSymbole(); return tan(Primaire()); case ATAN : LireSymbole(); return atan(Primaire()); case EXP :

Structures et mthodes : implmentation 397

LireSymbole(); return exp(Primaire()); case LOG : { LireSymbole(); double d= Primaire(); if(d<=0)return ErreurDeCalcul("log : erreur de domaine"); return log(d); } case LN : { LireSymbole(); double d= Primaire(); if(d<=0)return ErreurDeCalcul("ln : erreur de domaine"); return log10(d); } case SQRT : { LireSymbole(); double d= Primaire(); if(d<0)return ErreurDeCalcul("sqrt : erreur de domaine"); return sqrt(d); } case ABS : LireSymbole(); return fabs(Primaire()); case PARTINT : LireSymbole(); return floor(Primaire()); case POW : { LireSymbole(); // parenthese ouvrante LireSymbole(); double d1= Expression(); LireSymbole(); // virgule double d2= Expression(); LireSymbole(); // parenthese fermante if(d1==0 || d2<0)return ErreurDeCalcul("pow : erreur de domaine"); double d3=double(int(d2)); if(d1<0 && d3 != d2)return ErreurDeCalcul("pow : exposant non entier"); return pow(d1,d2); } case MOD : { LireSymbole(); // parenthese ouvrante LireSymbole(); double d1= Expression(); LireSymbole(); // virgule double d2= Expression(); LireSymbole(); // parenthese fermante if(d2 == 0)return ErreurDeCalcul("mod : division par zro"); return fmod(d1,d2); } case SI : { LireSymbole(); // parenthese ouvrante LireSymbole(); double dCondition= ConditionExpression(); LireSymbole(); // parenthese fermante double dAlors= ConditionExpression(); LireSymbole(); // deux points double dSinon= ConditionExpression(); if(dCondition == 1.)return dAlors; else return dSinon; } case FIN : return 1.; default : return 1.; }

A.2.1.6. La classe CBabel pour linterpolation La classe CBabel encapsule lensemble des oprations de cration dune relation de type mosaque par interpolation.
class CBabel

398

Annexe

{ private: //--- variables gnrales CCadre* m_pCadre; int m_iInterpolation; BOOL m_bMasque; int m_iNbcol; int m_iNblig; int m_iMarge; int m_iDatasize; int m_iTypeAttribut; int m_iNbLecture; int m_iNbmaxObjets; unsigned char* m_ctabImageMasque; int m_iNbVoisins; float m_ftabValeurVoisin[100]; float m_ftabContrainteVoisin[100]; double m_dResolution; double m_dtabDistance[100]; double m_dZmin; double m_dZmax; BOOL m_bDistanceMax; double m_dDistanceMax; //--- variables pour l'interpolation sous contrainte BOOL m_bContrainte; int m_iNothContrainte; int m_iNoattContrainte; double m_dFacteurContrainte; float* m_ftabImagetteContrainte; //--- variables pour les objets de base (potentiel) float *m_ftabValeur; float *m_ftabContrainte; double *m_dtabX; double *m_dtabY; double m_dFlxCalcul; double m_dFlyCalcul; double m_dFhxCalcul; double m_dFhyCalcul; double m_dFlxRecherche; double m_dFlyRecherche; double m_dFhxRecherche; double m_dFhyRecherche; //--- variables pour le calcul int m_iXDebCalcul,m_iYDebCalcul,m_iXFinCalcul,m_iYFinCalcul; int m_iXDebRecherche,m_iYDebRecherche,m_iXFinRecherche,m_iYFinRecherche; //--- variables pour le lissage float *m_fLigne; double m_dw1[3]; double m_dw2[3]; double m_dp1[20]; double m_dp2[20]; double m_dC[20][20]; int m_iPas; void Voisin(float fValeur, float fValeurContrainte,double distance); float BaryCalcul(float fValeurContrainte); float PotentielCalcul(double dXProj,double dYProj); public: float *m_ftabImagette; int *m_itabNombre; unsigned char* m_ctabData; BOOL m_bMoyenne; CBabel(CCadre* pCadre,int iInterpolation,int iNbcol,int iNblig,int iMarge,double dResolution,BOOL bMasque,BOOL bMoyenne,unsigned char* ctabImageMasque); ~CBabel(); BOOL Alloc(); void SetDistanceMax(BOOL bDistanceMax,double dDistanceMax); void SetContrainte(BOOL bContrainte,int iNoth,int iNoatt,double dFacteur); void InitFenetre(CWind* pWind,double dFlx,double dFly); int Lecture(int iNoImagette,int iNbRelations,int *itabRelation,int *itabAttribut,double dConstante); void LectureContrainte(int iNoImagette); BOOL IntersectionMasque();

Structures et mthodes : implmentation 399

BOOL BOOL BOOL BOOL BOOL void Barycentre(int iNoImagette,int iPassage); Potentiel(); Lissage(int ideb); EcrireImagette(const char* chNomFichier,FILE* FileAttribut); RemplacerImagette(int ptrdeb,FILE* FileAttribut); ProjToImagette(double dXProj,double dYProj,double& dXRas,double& dYRas);

int GetNblig() {return m_iNblig;}; int GetNbcol() {return m_iNbcol;}; int GetMarge() {return m_iMarge;}; double GetMin() {return m_dZmin;}; double GetMax() {return m_dZmax;}; float* GetPtrImagette(int ilig) {return (float* ) &m_ftabImagette[m_iMarge + (ilig+m_iMarge)*m_iNbcol];}; };

Par exemple, la mthode Lecture() charge les points de rfrences dans la mmoire de limagette crer, partir des relations et attributs choisis (itabRelation, itabAttribut) :
int CBabel::Lecture(int iNoImagette,int iNbRelations,int *itabRelation,int *itabAttribut,double dConstante) { //--- lecture des donnes CSchema* pSchema=m_pCadre->GetSchema(); int i; int iNoth,iNoatt; int iNb0,iNba,iNovar; float fXSav,fYSav; float fWindXbSav,fWindYbSav,fWindXhSav,fWindYhSav; float v[NB_MAX_ATTRIBUTS]; double dXProj,dYProj; //--- fenetre de recherche en coordonnees savane m_pCadre->ProjToSav(m_dFlxRecherche,m_dFlyRecherche,fWindXbSav,fWindYbSav); m_pCadre->ProjToSav(m_dFhxRecherche,m_dFhyRecherche,fWindXhSav,fWindYhSav); ::Ordonner(fWindXbSav,fWindXhSav); ::Ordonner(fWindYbSav,fWindYhSav); //--CString strTexte; switch(config.m_iLangage) { case FRANCAIS: default: strTexte.Format(" Imagette %d : lecture des donnes...",iNoImagette); break; case ESPAGNOL: strTexte.Format(" Imagette %d :lectura de los datos...",iNoImagette); break; case ANGLAIS: strTexte.Format(" Imagette %d : reading the data...",iNoImagette); break; } pMainFrame->SetStatusTexte(strTexte); m_iNbLecture=0; switch(m_iInterpolation) { case INTERPOLATION_BARYCENTRE: { int iXRas,iYRas; double dXRasImagette,dYRasImagette; //--- init int iNbPixels=m_iNblig*m_iNbcol; for(i=0;i < iNbPixels;i++) { m_itabNombre[i]=0; m_ftabImagette[i]=0.F; } if(m_bMoyenne == FALSE) { for(i=0;i < iNbPixels;i++)m_ctabData[i]=0; } //--- crire dans la mmoire de l'imagette

400

Annexe
int iNoRelation=0; while(iNoRelation < iNbRelations) { iNoth=itabRelation[iNoRelation]; iNoatt=itabAttribut[iNoRelation]; iNb0=pSchema->m_pRelations[iNoth]->m_iNb0; iNba=pSchema->m_pRelations[iNoth]->m_iNba; iNovar=pSchema->m_pRelations[iNoth]->m_pAttributs[iNoatt]->m_iNumero; int iTypeRelation=pSchema->m_pRelations[iNoth]->m_iType; if(iTypeRelation != 2 && iTypeRelation != 12) { //--- zone ou point, par centrode CLecture lecture; if(lecture.Open(m_pCadre,iNoth)) { lecture.SetFenetreLecture(fWindXbSav,fWindYbSav,fWindXhSav,fWindYhSav); i=lecture.Lire(v); while(i != -1) { if(i == 1) { if(v[iNovar] > FINCONNU) { v[iNovar]*=(float) dConstante; if(v[iNovar] > m_dZmax)m_dZmax=(double) v[iNovar]; if(v[iNovar] < m_dZmin)m_dZmin=(double) v[iNovar]; lecture.GetCentroide(fXSav,fYSav); m_pCadre->SavToProj(fXSav,fYSav,dXProj,dYProj); ProjToImagette(dXProj,dYProj,dXRasImagette,dYRasImagette); iXRas=(int) (dXRasImagette +0.5); iYRas=(int) (dYRasImagette +0.5); if(iXRas >= 0 && iXRas < m_iNbcol && iYRas >= 0 && iYRas < m_iNblig) { if(m_bMoyenne == FALSE) { if(m_ctabData[iXRas+(iYRas*m_iNbcol)] == 0) { m_itabNombre[iXRas+(iYRas*m_iNbcol)]++; m_ftabImagette[iXRas+(iYRas*m_iNbcol)]+=v[iNovar]; m_iNbLecture++; } } else { m_itabNombre[iXRas+(iYRas*m_iNbcol)]++; m_ftabImagette[iXRas+(iYRas*m_iNbcol)]+=v[iNovar]; m_iNbLecture++; } } }

} else { int iPtrarc; float v[NB_MAX_ATTRIBUTS]; CArc arc; CLecture lecture; if(lecture.Open(m_pCadre,iNoth)) { lecture.SetFenetreLecture(fWindXbSav,fWindYbSav,fWindXhSav,fWindYhSav); FILE* FileArc=lecture.GetFileArc(); i=lecture.Lire(v); while(i != -1) { if(i == 1) { if(v[iNovar] > FINCONNU) { v[iNovar]*=(float) dConstante; if(v[iNovar] > m_dZmax)m_dZmax=(double) v[iNovar];

} i=lecture.Lire(v); } lecture.Close(); }

Structures et mthodes : implmentation 401

if(v[iNovar] < m_dZmin)m_dZmin=(double) v[iNovar]; iPtrarc=lecture.GetPointeurArc(); //--- tester la fentre de l'arc //--- lecture des points arc.LirePoints(FileArc,iPtrarc); m_iNbLecture++; arc.Draw(m_pCadre,v[iNovar],this); }

i=lecture.Lire(v); } lecture.Close(); }

if(m_bMoyenne == FALSE) { for(i=0;i < iNbPixels;i++) { if(m_itabNombre[i] > 0)m_ctabData[i]=1; } } iNoRelation++; } //--- calcul de la moyenne par pixel a partir de la somme for(i=0;i < iNbPixels;i++) { if(m_itabNombre[i] > 0)m_ftabImagette[i]/=m_itabNombre[i]; else m_ftabImagette[i]=FINCONNU; } } break; case INTERPOLATION_POTENTIEL: case INTERPOLATION_PLUSPROCHEVOISIN: case INTERPOLATION_SOMME: case INTERPOLATION_SOMME_DECROISSANTE: case INTERPOLATION_MOYENNE: case INTERPOLATION_MOYENNE_DECROISSANTE: { //--- init int iNbPixels=m_iNblig*m_iNbcol; for(i=0;i < iNbPixels;i++) { m_ftabImagette[i]=0.F; } //--- crire dans les tableaux int iNoRelation=0; while(iNoRelation < iNbRelations && m_iNbLecture < m_iNbmaxObjets) { iNoth=itabRelation[iNoRelation]; iNoatt=itabAttribut[iNoRelation]; iNb0=pSchema->m_pRelations[iNoth]->m_iNb0; iNba=pSchema->m_pRelations[iNoth]->m_iNba; iNovar=pSchema->m_pRelations[iNoth]->m_pAttributs[iNoatt]->m_iNumero; CLecture lecture; if(lecture.Open(m_pCadre,iNoth)) { i=lecture.LireSansTestFenetre(v); while(i != -1 && m_iNbLecture < m_iNbmaxObjets) { if(i == 1) { if(v[iNovar] > FINCONNU) { v[iNovar]*=(float) dConstante; if(v[iNovar] > m_dZmax)m_dZmax=(double) v[iNovar]; if(v[iNovar] < m_dZmin)m_dZmin=(double) v[iNovar]; lecture.GetCentroide(fXSav,fYSav); m_pCadre->SavToProj(fXSav,fYSav,dXProj,dYProj); m_dtabX[m_iNbLecture]=dXProj; m_dtabY[m_iNbLecture]=dYProj;

402

Annexe
m_ftabValeur[m_iNbLecture]=v[iNovar]; m_iNbLecture++; }

} i=lecture.Lire(v); } lecture.Close(); } iNoRelation++; }

//--- lecture de la contrainte pour tous les points, par appartenance if(m_bContrainte) { FILE *FileMosaic; FILE *FileFeuille; FILE *FileImage; int iMosaiqueNbcol,iMosaiqueNblig,nbcol,nblig; int no,ptr,ptrlib,ptrdeb; double dXbf,dYbf,dXhf,dYhf,dZmin,dZmax; double dMosaiqueResolution; char chNomFichierFeuille[_MAX_PATH]; char chNomFichierMosaique[_MAX_PATH]; char chNomFichierAttribut[_MAX_PATH]; char cValeur; short int sValeur; float fValeur; fValeur=0.; for(i=0;i < m_iNbLecture;i++) { m_ftabContrainte[i]=FINCONNU; } //--- ouverture des fichiers de la mosaque strcpy(chNomFichierMosaique,pSchema->m_pRelations[m_iNothContrainte]->m_chFichZone); strcat(chNomFichierMosaique,"\\"); strcat(chNomFichierMosaique,pSchema->m_pRelations[m_iNothContrainte]->m_chNom); strcat(chNomFichierMosaique,"_d"); //--- lecture des parametres de la mosaique FileMosaic=OuvrirMosaique(pSchema,chNomFichierMosaique,m_iNothContrainte); if(FileMosaic != NULL) { fscanf(FileMosaic,"%lf",&dMosaiqueResolution); fscanf(FileMosaic,"%d",&iMosaiqueNbcol); fscanf(FileMosaic,"%d",&iMosaiqueNblig); fclose(FileMosaic); int iTypeAttribut=pSchema->m_pRelations[m_iNothContrainte]>m_pAttributs[m_iNoattContrainte]->m_iType; int iTemporaire=pSchema->m_pRelations[m_iNothContrainte]>m_pAttributs[m_iNoattContrainte]->m_iTemporaire; if(iTemporaire) { strcpy(chNomFichierAttribut,carte.m_chNomDir); strcat(chNomFichierAttribut,"\\"); strcat(chNomFichierAttribut,m_pCadre->m_chNom); strcat(chNomFichierAttribut,"\\ft"); strcat(chNomFichierAttribut,pSchema->m_pRelations[m_iNothContrainte]->m_chNom); strcat(chNomFichierAttribut,"_"); strcat(chNomFichierAttribut,pSchema->m_pRelations[m_iNothContrainte]>m_pAttributs[m_iNoattContrainte]->m_chNom); } else { strcpy(chNomFichierAttribut,pSchema->m_pRelations[m_iNothContrainte]>m_chFichZone); strcat(chNomFichierAttribut,"\\"); strcat(chNomFichierAttribut,pSchema->m_pRelations[m_iNothContrainte]>m_pAttributs[m_iNoattContrainte]->m_chNom); } strcpy(chNomFichierFeuille,chNomFichierAttribut); strcat(chNomFichierFeuille,"_f"); FileFeuille=fopen(chNomFichierFeuille,"rb"); FileImage=fopen(chNomFichierAttribut,"rb");

Structures et mthodes : implmentation 403

if(FileImage == NULL || FileFeuille == NULL) { if(FileImage != NULL)fclose(FileImage); if(FileFeuille != NULL)fclose(FileFeuille); } else { //--- lecture des feuilles int iDatasize=1; if(iTypeAttribut == 1 || iTypeAttribut == 5 || iTypeAttribut == 6)iDatasize=1; else if(iTypeAttribut == 7)iDatasize=2; else if(iTypeAttribut == 8)iDatasize=3; else if(iTypeAttribut == 9)iDatasize=4; fscanf(FileFeuille,"%2d%20d%*c",&i,&ptrlib); while(fscanf(FileFeuille,"%2d%20lf%20lf%10d%10d%20lf%20lf%20d%*c", &no,&dXbf,&dYbf,&nbcol,&nblig,&dZmin,&dZmax,&ptrdeb) == 8) { if(no != 0) { dXhf=dXbf + (dMosaiqueResolution*(double) iMosaiqueNbcol); dYhf=dYbf + (dMosaiqueResolution*(double) iMosaiqueNblig); for(i=0;i < m_iNbLecture;i++) { if(m_ftabContrainte[i] == FINCONNU) { if(m_dtabX[i] >= dXbf && m_dtabX[i] <= dXhf && m_dtabY[i] >= dYbf && m_dtabY[i] <= dYhf) { ptr=ptrdeb + (((int) ((m_dtabY[i]dYbf)/dMosaiqueResolution))*iMosaiqueNbcol + (int) ((m_dtabX[i]dXbf)/dMosaiqueResolution))*iDatasize; fseek(FileImage,ptr,SEEK_SET); switch(iTypeAttribut) { case 1: case 5: case 6: fread(&cValeur,iDatasize,1,FileImage); if(cValeur != CINCONNU)m_ftabContrainte[i]=(float) cValeur; break; case 7: fread(&sValeur,iDatasize,1,FileImage); if(sValeur != SINCONNU)m_ftabContrainte[i]=(float) sValeur; break; case 9: fread(&fValeur,iDatasize,1,FileImage); if(fValeur != FINCONNU)m_ftabContrainte[i]=fValeur; break; default: break; } } } } } } fclose(FileImage); fclose(FileFeuille); }

} } } break; default: break; }

Dans le cas de linterpolation barycentrique sur les voisins, la mthode

Barycalcul() effectue le calcul barycentrique sur les voisins qui ont t prcdemment dtermins par la mthode Barycentre().
float CBabel::BaryCalcul(float fValeurContrainte) { int k;

404

Annexe

for(k=0;k < m_iNbVoisins;k++) { if(m_dtabDistance[k] <= 0.)return m_ftabValeurVoisin[k]; } float fz=0.F; double ds1,ds2,du; ds1=0.; ds2=0.; if(m_bContrainte && fValeurContrainte > FINCONNU) { for(k=0;k < m_iNbVoisins;k++) { du=1./m_dtabDistance[k]; ds1+=du; if(m_ftabContrainteVoisin[k] > FINCONNU) { ds2+=(((double)m_ftabValeurVoisin[k] + m_dFacteurContrainte*(m_ftabContrainteVoisin[k]- fValeurContrainte))*du); } else ds2+=((double)m_ftabValeurVoisin[k]*du); } fz=(float) (ds2/ds1); } else { for(k=0;k < m_iNbVoisins;k++) { du=1./m_dtabDistance[k]; ds1+=du; ds2+=((double)m_ftabValeurVoisin[k]*du); } fz=(float) (ds2/ds1); } return fz; }

Dans le cas de linterpolation sur tous les points sans contrainte, le calcul est effectu par la mthode PotentielCalcul(). Les points de rfrence pris en compte sont filtrs sur la distance au point interpoler (m_dDistanceMax) lorsque cette option a t choisie par lutilisateur (m_bDistanceMax) :
float CBabel::PotentielCalcul(double dXProj,double dYProj) { float fz=0.F; switch(m_iInterpolation) { case INTERPOLATION_POTENTIEL: //--- barycentre sur tous les points { double ds1,ds2,du,dDistance; ds1=0.; ds2=0.; if(m_bDistanceMax) { for(int i=0;i < m_iNbLecture;i++) { dDistance=sqrt((dXProj-m_dtabX[i])*(dXProj-m_dtabX[i]) + (dYProjm_dtabY[i])*(dYProj-m_dtabY[i])); if(dDistance == 0.) { fz=m_ftabValeur[i]; return fz; } if(dDistance <= m_dDistanceMax) { du=1./dDistance; ds1+=du; ds2+=((double) m_ftabValeur[i]*du); } } if(ds1 > 0.)fz=(float) (ds2/ds1); else fz=FINCONNU; }

Structures et mthodes : implmentation 405

else { for(int i=0;i < m_iNbLecture;i++) { dDistance=sqrt((dXProj-m_dtabX[i])*(dXProj-m_dtabX[i]) + (dYProjm_dtabY[i])*(dYProj-m_dtabY[i])); if(dDistance == 0.) { fz=m_ftabValeur[i]; return fz; } du=1./dDistance; ds1+=du; ds2+=((double) m_ftabValeur[i]*du); } fz=(float) (ds2/ds1); } return fz; } break; case INTERPOLATION_PLUSPROCHEVOISIN: //--- plus proche voisin { double dDistance,dDistanceMin; fz=m_ftabValeur[0]; dDistanceMin=(dXProj-m_dtabX[0])*(dXProj-m_dtabX[0]) + (dYProj-m_dtabY[0])*(dYProjm_dtabY[0]); for(int i=1;i < m_iNbLecture;i++) { dDistance=(dXProj-m_dtabX[i])*(dXProj-m_dtabX[i]) + (dYProj-m_dtabY[i])*(dYProjm_dtabY[i]); if(dDistance <= dDistanceMin) { fz=m_ftabValeur[i]; dDistanceMin=dDistance; } } return fz; } break; case INTERPOLATION_SOMME: { int iNb=0; float fSomme; double dDistance; fSomme=0.F; for(int i=0;i < m_iNbLecture;i++) { dDistance=sqrt((dXProj-m_dtabX[i])*(dXProj-m_dtabX[i]) + (dYProj-m_dtabY[i])*(dYProjm_dtabY[i])); if(dDistance <= m_dDistanceMax) { fSomme+=m_ftabValeur[i]; iNb++; } } if(iNb == 0)fSomme=FINCONNU; return fSomme; } break; case INTERPOLATION_SOMME_DECROISSANTE: { int iNb=0; float fSomme; double dSomme,dDistance; dSomme=0.; for(int i=0;i < m_iNbLecture;i++) { dDistance=sqrt((dXProj-m_dtabX[i])*(dXProj-m_dtabX[i]) + (dYProj-m_dtabY[i])*(dYProjm_dtabY[i])); if(dDistance <= m_dDistanceMax) { dSomme+=((double)m_ftabValeur[i]*(m_dDistanceMax - dDistance)/m_dDistanceMax); iNb++; }

406

Annexe
} if(iNb == 0)fSomme=FINCONNU; else fSomme=(float) dSomme; return fSomme; } break;

case INTERPOLATION_MOYENNE: { int iNb=0; float fSomme; double dDistance; fSomme=0.F; for(int i=0;i < m_iNbLecture;i++) { dDistance=sqrt((dXProj-m_dtabX[i])*(dXProj-m_dtabX[i]) + (dYProj-m_dtabY[i])*(dYProjm_dtabY[i])); if(dDistance <= m_dDistanceMax) { fSomme+=m_ftabValeur[i]; iNb++; } } if(iNb == 0)fSomme=FINCONNU; else fSomme/=iNb; return fSomme; } break; case INTERPOLATION_MOYENNE_DECROISSANTE: { int iNb=0; float fSomme; double dSomme,dDistance; dSomme=0.; for(int i=0;i < m_iNbLecture;i++) { dDistance=sqrt((dXProj-m_dtabX[i])*(dXProj-m_dtabX[i]) + (dYProj-m_dtabY[i])*(dYProjm_dtabY[i])); if(dDistance <= m_dDistanceMax) { dSomme+=((double)m_ftabValeur[i]*(m_dDistanceMax - dDistance)/m_dDistanceMax); iNb++; } } if(iNb == 0)fSomme=FINCONNU; else fSomme=(float) (dSomme/iNb); return fSomme; } break; default: break; } return fz; }

A.2.2. Algorithmique graphique A.2.2.1. La classe CArc La classe CArc reprsente un objet de type arc; les points sont conservs dans un tableau m_tpoint, allou dynamiquement lors de la cration de lobjet arc :
class CArc { private: int m_iNbpt; int m_iNz1;

Structures et mthodes : implmentation 407

int m_iNz2; int m_Ptrsuiv; float m_fXmin,m_fYmin,m_fXmax,m_fYmax; float* m_tpoint; public: CArc(); ~CArc(); int GetPtrSuivant() {return m_Ptrsuiv;}; int GetNbpt() {return m_iNbpt;}; void SetNbpt(int iNbpt) {m_iNbpt=iNbpt;}; void GetPoint(int i,float &fX,float &fY) {fX=m_tpoint[(i-1)*2]; fY=m_tpoint[(i-1)*2+1];}; void SetPoint(int i,float fX,float fY) {m_tpoint[(i-1)*2]=fX; m_tpoint[(i-1)*2+1]=fY;}; void LireEntete(FILE* FileArc,int ptr,int& iNz1,int& iNz2,int& ptrSuivant); void LireFenetre(FILE* FileArc,int ptr); int LireNbpt(FILE* FileArc,int ptr); void LirePoints(FILE* FileArc,int ptr); void LireBout(FILE* FileArc,int ptr,float &fX1,float &fY1,float &fX2,float &fY2); void GetFenetre(FILE* FileArc,int ptr,float& fX1,float& fY1,float& fX2,float& fY2); int Ecrire(FILE* FileArc,int iNz1,int iNz2,int iPtr); BOOL Intersect(float fX1,float fY1,float fX2,float fY2); BOOL IntersectMasque(CCadre* pCadre,unsigned char *itabImage); void Filtre(CCadre* pCadre,double dSurfaceMinimum); void Douglas(CCadre* pCadre,double dDistanceMinimum,int iNo1,int iNo2); void FinDouglas(); void Tracer(CDC* pDC,CCadre* pCadre); void Tracer(CDC* pDC,CCadre* pCadre,int iType); void Imprimer(CDC* pDC,CCadre* pCadre,BOOL bSens); void Chainer(CDC* pDC,CCadre* pCadre,BOOL bSens,int& iNbptTotal,LPPOINT tabPoint); void Chainer(CCadre* pCadre,BOOL bSens,int& iNbptTotal,int& iNbptPolygon,double* dtabPoints); double DistanceAUnPoint(CCadre* pCadre,double dX,double dY); double DistanceAUnPoint(float fXSav,float fYSav); double Longueur(CCadre* pCadre); void CalculCentroide(float &fX,float &fY); void CalculBBox(CDC* pDC,CCadre* pCadre,int &iXb,int &iYb,int &iXh,int &iYh); void CalculBBox(CCadre* pCadre,double &dXbProj,double &dYbProj,double &dXhProj,double &dYhProj); void Draw(CCadre* pCadre,unsigned char *itabImage,unsigned char iValeur); void Draw(CCadre* pCadre,int *itabImage,int iValeur); void Draw(CCadre* pCadre,float fValeur,CBabel* pBabel); void Draw0(CCadre* pCadre,unsigned char *itabImage,unsigned char iValeur); void Draw0(CCadre* pCadre,float *ftabImage,int *itabNombre,float fValeur,int iNbcol, int iNblig); };

Voici par exemple la procdure de recherche de lintersection dun arc avec un segment. La procdure utilise une autre procdure globale qui recherche lintersection de deux segments de droite (A.2.2.5) :
BOOL CArc::IntersectionAvecUnSegment(double dX1Seg,double dY1Seg,double dX2Seg,double dY2Seg,double& dXRes,double& dYRes) { dXRes=0.; dYRes=0.; //--- tester l'intersection du segment avec la fentre de larc ::Ordonner(dX1Seg,dX2Seg); ::Ordonner(dY1Seg,dY2Seg); if(Intersect(dX1Seg,dY1Seg,dX2Seg,dY2Seg) == FALSE)return FALSE; //--- tester l'intersection de l'arc et du segment double dX1,dY1,dX2,dY2; for(int i=1;i < m_iNbpt;i++) { GetPoint(i-1,dX1,dY1); GetPoint(i,dX2,dY2); if(SegmentIntersection(dX1Seg,dY1Seg,dX2Seg,dY2Seg,dX1,dY1,dX2,dY2,dXRes,dYRes))return TRUE; } return FALSE; }

408

Annexe

La mthode Draw() permet de dessiner un arc dans un tableau matriciel. Cette procdure est notamment utilise dans linterpolation pour charger les points de rfrences dans la matrice de limagette calculer :
void CArc::Draw(CCadre* pCadre,float fValeur,CBabel* pBabel) { int ipt,nbpix,iX,iY,iXp,iYp,nb; int iNbcol,iNblig; float fX,fY; double dCosinus,dSinus,dDistance,dR; double dXProj,dYProj,dXa,dYa,dXb,dYb,dX,dY; iNbcol=pBabel->GetNbcol(); iNblig=pBabel->GetNblig(); fX=m_tpoint[0]; fY=m_tpoint[1]; pCadre->SavToProj(fX,fY,dXProj,dYProj); pBabel->ProjToImagette(dXProj,dYProj,dXa,dYa); iX=(int) dXa; iY=(int) dYa; if(iX >= 0 && iX < iNbcol && iY >= 0 && iY < iNblig) { if(pBabel->m_bMoyenne) { pBabel->m_ftabImagette[iX+(iY*iNbcol)]+=fValeur; pBabel->m_itabNombre[iX+(iY*iNbcol)]++; } else { if(pBabel->m_ctabData[iX+(iY*iNbcol)] == 0) { pBabel->m_ftabImagette[iX+(iY*iNbcol)]+=fValeur; pBabel->m_itabNombre[iX+(iY*iNbcol)]++; } } } iXp=iX; iYp=iY; ipt=1; int j=2; while(ipt < m_iNbpt) { fX=m_tpoint[j]; fY=m_tpoint[j+1]; j+=2; pCadre->SavToProj(fX,fY,dXProj,dYProj); pBabel->ProjToImagette(dXProj,dYProj,dXb,dYb); dX=dXb-dXa; dY=dYb-dYa; dDistance=sqrt(dX*dX + dY*dY); if(dDistance > 0.) { dCosinus=dX/dDistance; dSinus=dY/dDistance; nbpix=int(dDistance); nb=1; while(nb < nbpix) { dR=(double) nb; iX=(int) (dXa + dR*dCosinus); iY=(int) (dYa + dR*dSinus); if(iX != iXp || iY != iYp) { if(iX >= 0 && iX < iNbcol && iY >= 0 && iY < iNblig) { if(pBabel->m_bMoyenne) { pBabel->m_ftabImagette[iX+(iY*iNbcol)]+=fValeur; pBabel->m_itabNombre[iX+(iY*iNbcol)]++; } else { if(pBabel->m_ctabData[iX+(iY*iNbcol)] == 0) { pBabel->m_ftabImagette[iX+(iY*iNbcol)]+=fValeur; pBabel->m_itabNombre[iX+(iY*iNbcol)]++; }

Structures et mthodes : implmentation 409

} } iXp=iX; iYp=iY; } nb++; } iX=(int) dXb; iY=(int) dYb; if(iX != iXp || iY != iYp) { if(iX >= 0 && iX < iNbcol && iY >= 0 && iY < iNblig) { if(pBabel->m_bMoyenne) { pBabel->m_ftabImagette[iX+(iY*iNbcol)]+=fValeur; pBabel->m_itabNombre[iX+(iY*iNbcol)]++; } else { if(pBabel->m_ctabData[iX+(iY*iNbcol)] == 0) { pBabel->m_ftabImagette[iX+(iY*iNbcol)]+=fValeur; pBabel->m_itabNombre[iX+(iY*iNbcol)]++; } } } } } dXa=dXb; dYa=dYb; ipt++; }

A.2.2.2. Les classes CCellule et CYX Les classes CCellule et CYX sont utilises pour les procdures de rasterisation. Un objet CCellule reprsente une cellule dun chanage, et conserve une coordonne (m_iX), ainsi que les codes gauche et droite du point sur la ligne chane. Les cellules peuvent tre chanes grce la variable m_ptrSuivant. La classe CYX contient un tableau de pointeurs de cellules : chaque pointeur correspond la premire cellule dune ligne horizontale.
class CCellule { public: int m_iX; int m_iCode1; int m_iCode2; CCellule* m_ptrSuivant; public: CCellule(); }; class CYX { private: CCadre* m_pCadre; CCellule* m_Y[NB_MAX_DEFY]; int m_iNoth; void YX(char *chNomFichierImage); void Points(FILE* FileArc,int iNbarc,int iPtrarc,int *itabZone,int iNzMax); void InsererCellule(int iY,int iX,int iCode1,int iCode2); public: CYX(CCadre* pCadre); ~CYX(); void Rasteriser(int iNoth); void RasteriserParAttribut(int iNoth,int iNoatt,int* itabImage); void MasqueRasteriser(char *chNomFichierMasque,char *chNomFichierImage);

410
};

Annexe

La procdure Points() calcule lintersection des arcs de la relation avec les lignes horizontales et cre le chanage des points par ligne. La procdure YX() calcule le fichier image partir du chanage par ligne. Voici limplmentation des principales procdures de cette classe :
void CYX::Points(FILE* FileArc,int iNbarc,int iPtrarc,int *itabZone,int iNzMax) { int i; int iCode1,iCode2,iX,iXb,iXh,iYb,iYh; int ligsup,iNb,iNbpt,nocol,nolig,iNz1,iNz2; int ptr,ptrSuivant; float fPx1,fPy1,fPx2,fPy2,fP,fX,fY; CArc arc; int iXMaximum=config.m_iDefX-1; ptr=iPtrarc; iNb=0; while(iNb < iNbarc) { arc.LireEntete(FileArc,ptr,iNz1,iNz2,ptrSuivant); if(iNz1 <= iNzMax)iCode1=itabZone[iNz1]; else iCode1=0; if(iNz2 <= iNzMax)iCode2=itabZone[iNz2]; else iCode2=0; if(iCode1 != iCode2) { arc.LirePoints(FileArc,ptr); arc.GetPoint(1,fX,fY); m_pCadre->SavToRas(fX,fY,fPx1,fPy1); iNbpt=arc.GetNbpt(); i=2; while(i <= iNbpt) { fPx2=fPx1; fPy2=fPy1; arc.GetPoint(i,fX,fY); m_pCadre->SavToRas(fX,fY,fPx1,fPy1); if(fPy1 < fPy2) { iXb=(int) (fPx1+0.5); iYb=(int) fPy1; iXh=(int) (fPx2+0.5); iYh=(int) fPy2; } else { iXb=(int) (fPx2+0.5); iYb=(int) fPy2; iXh=(int) (fPx1+0.5); iYh=(int) fPy1; } if(iYh != iYb) { if(iYb >= 0 && iYb < config.m_iDefY) { nocol=__max(0,__min(iXMaximum,iXb)); InsererCellule(iYb,nocol,iCode1,iCode2); } fP=(float)(iXh-iXb)/(float)(iYh-iYb); fX=(float)iXb+fP; nolig=iYb+1; ligsup=__min(config.m_iDefY,iYh); if(nolig < ligsup) { while(nolig < 0) { fX+=fP; nolig++; } while(nolig < ligsup) { iX=(int) (fX+0.5); nocol=__max(0,__min(iXMaximum,iX));

Structures et mthodes : implmentation 411

InsererCellule(nolig,nocol,iCode1,iCode2); nolig++; fX+=fP; }

} ptr=ptrSuivant; iNb++; }

} i++; }

void CYX::YX(char *chNomFichierImage) { FILE *FileImage; CCellule *ptr; int i,iC,recherche; int iCode,iCode1,iCode2; int iXc,iXp,iXs,iSegment,iNbpt; int multiple[1000]; FileImage=fopen(chNomFichierImage,"wb"); if(FileImage == NULL)return; int iXMaximum=config.m_iDefX-1; int ilig=0; while(ilig < config.m_iDefY) { ptr=m_Y[ilig]; if(ptr == 0) { //--- ligne vide iCode=0; fprintf(FileImage,"%d %d\n",iCode,config.m_iDefX); } else { //--- calcul des segments iCode=0; iSegment=0; iNbpt=0; iXc=ptr->m_iX; iCode1=ptr->m_iCode1; iCode2=ptr->m_iCode2; if(iXc > 0) { fprintf(FileImage,"%d %d\n",iCode,iXc); iNbpt+=iXc; } iC=1; multiple[1]=0; iXp=iXc; do { //--- repeat tant qu'il y a des points dans la ligne do { //--- repeat tant qu'il y a des points confondus i=1; recherche=1; while(i <= iC && recherche) { if(iCode1 != multiple[i])i++; else { recherche=0; while(i < iC) { multiple[i]=multiple[i+1]; i++; } iC--; } } if(recherche) { iC++;

412

Annexe
multiple[iC]=iCode1; } i=1; recherche=1; while(i <= iC && recherche) { if(iCode2 != multiple[i])i++; else { recherche=0; while(i < iC) { multiple[i]=multiple[i+1]; i++; } iC--; } } if(recherche) { iC++; multiple[iC]=iCode2; } ptr=ptr->m_ptrSuivant; if(ptr != 0) { iXs=ptr->m_iX; iCode1=ptr->m_iCode1; iCode2=ptr->m_iCode2; } } while(ptr != 0 && iXs == iXc); if(ptr != 0) { //--- determiner le code sortant if(iC == 1) { iCode=multiple[1]; iSegment=iXs-iXp; if(iXs == iXMaximum)iSegment++; fprintf(FileImage,"%d %d\n",iCode,iSegment); iNbpt+=iSegment; iC=1; iXp=iXs; } iXc=iXs; } } while(ptr != 0);

if(iNbpt < config.m_iDefX) { iCode=0; iSegment=config.m_iDefX-iNbpt; fprintf(FileImage,"%d %d\n",iCode,iSegment); } } ilig++; } fclose(FileImage); } void CYX::InsererCellule(int iY,int iX,int iCode1,int iCode2) { CCellule* ptrNew; CCellule* ptrTete; //--- creation d'une cellule ptrNew=new CCellule(); ptrNew->m_iX=iX; ptrNew->m_iCode1=iCode1; ptrNew->m_iCode2=iCode2; ptrTete=m_Y[iY]; if(ptrTete == 0) { //--- premier lment de la ligne m_Y[iY]=ptrNew;

Structures et mthodes : implmentation 413

ptrNew->m_ptrSuivant=0; } else { //--- insertion if(ptrTete->m_iX > iX) { ptrNew->m_ptrSuivant=ptrTete; m_Y[iY]=ptrNew; } else { CCellule* ptr; CCellule* ptrPred; ptrPred=ptrTete; ptr=ptrTete->m_ptrSuivant; while(ptr > 0) { if(ptr->m_iX <= iX) { ptrPred=ptr; ptr=ptr->m_ptrSuivant; } else break; } //--- chainage ptrNew->m_ptrSuivant=ptr; ptrPred->m_ptrSuivant=ptrNew; }

A.2.2.3. la classe CVectoriser La classe CVectoriser permet de raliser lopration inverse de la rasterisation. Elle cre des arcs partir dune image raster :
class CVectoriser { private: CCadre* m_pCadre; int m_iNoth; int m_iNbObjets; int m_iNbArcCree; int m_iPtrlib; char m_chNomFichierArc[_MAX_PATH]; int *m_itabImage; unsigned char *m_ctabSegment; float* m_ligx; float* m_ligy; int m_iNbpoint; FILE* m_FileArc; BOOL m_bPasDePixelsIsoles; int SegmentType(int iX,int iY); void CreationDesArcs(void); void EcrireUneLigne(int iNza,int iNzb); public: CVectoriser(CCadre* pCadre,BOOL bPasDePixelsIsoles); ~CVectoriser(); int GetNbarc() {return m_iNbArcCree;}; }; BOOL Relation(int iNoth);

Par exemple, la procdure SegmentType() permet dinitialiser les valeurs de chaque configuration de quatre pixel adjacents :
int CVectoriser::SegmentType(int iX,int iY) { int iIndice; int iType; int iNz1,iNz2,iNz3,iNz4;

414

Annexe

iIndice=iY*config.m_iDefX+iX; iNz1=m_itabImage[iIndice]; iNz2=m_itabImage[iIndice+1]; iIndice+=config.m_iDefX; iNz3=m_itabImage[iIndice]; iNz4=m_itabImage[iIndice+1]; if(iNz1 == iNz2 else if(iNz1 == else if(iNz1 == else if(iNz1 == else if(iNz2 == else if(iNz1 == else if(iNz1 == else if(iNz1 == else if(iNz1 == else if(iNz1 == else if(iNz1 == else if(iNz3 == else if(iNz2 == else if(iNz2 == else iType=13; return iType; } && iNz1 == iNz3 iNz2 && iNz1 == iNz2 && iNz1 == iNz3 && iNz1 == iNz3 && iNz2 == iNz2 && iNz3 == iNz3 && iNz2 == iNz4 && iNz2 == iNz2)iType=5; iNz3)iType=6; iNz4)iType=7; iNz4)iType=8; iNz3)iType=9; iNz4)iType=10; && iNz1 == iNz4)iType=0; iNz4)iType=1; iNz3)iType=2; iNz4)iType=3; iNz4)iType=4; iNz4)iType=11; iNz4)iType=12; iNz3)iType=13;

Le code de la procdure CreationDesArcs() est trs long, car le programme teste toutes les configurations possibles. En voici un extrait :
int iDefX=config.m_iDefX-1; int iDefY=config.m_iDefY-1; ilig=0; while(ilig < iDefY) { icol=0; while(icol < iDefX) { iIndiceDebut=icol+(config.m_iDefX*ilig); iseg=m_ctabSegment[iIndiceDebut]; if(iseg != 0) { //--- un segment non chaine, dbut d'une ligne, initialisation icol1=icol; ilig1=ilig; icol2=icol; ilig2=ilig; col=(float)icol; lig=(float)ilig; icote1=0; icote2=0; fin1=0; fin2=1; switch(iseg) { case 1: iType=SegmentType(icol,ilig); if(iType == 1 || iType == 7 || iType == 10) { x0=col; y0=lig+0.5F; xc=col+0.5F; yc=lig+1.F; icote1=2; ilig1++; if(ilig1 >= iDefY)fin1=1; fin2=1; iNz1=m_itabImage[iIndiceDebut+config.m_iDefX]; iNz2=m_itabImage[iIndiceDebut+config.m_iDefX+1]; } else if(iType == 5) { x0=col; y0=lig+0.5F; xc=col+0.5F; yc=lig+1.F; fin1=1; iNz1=m_itabImage[iIndiceDebut];

Structures et mthodes : implmentation 415

iNz2=m_itabImage[iIndiceDebut+config.m_iDefX]; } m_ctabSegment[iIndiceDebut]=0; break; case 2: iType=SegmentType(icol,ilig); if(iType == 2 || iType == 9) { x0=col+0.5F; y0=lig+1.F; xc=col+1.F; yc=lig+0.5F; icote1=1; icol1++; if(icol1 >= iDefX)fin1=1; iNz1=m_itabImage[iIndiceDebut+1]; iNz2=m_itabImage[iIndiceDebut+1+config.m_iDefX]; icote2=2; ilig2++; fin2=0; if(ilig2 >= iDefY)fin2=1; } else if(iType == 5) { x0=col+0.5F; y0=lig+1.F; xc=col+1.F; yc=lig+0.5F; icote1=1; icol1++; if(icol1 >= iDefX)fin1=1; iNz1=m_itabImage[iIndiceDebut+1]; iNz2=m_itabImage[iIndiceDebut+1+config.m_iDefX]; } else if(iType == 6) { x0=col+1.F; y0=lig+0.5F; xc=col+0.5F; yc=lig+1.F; icote1=2; ilig1++; if(ilig1 >= iDefY)fin1=1; iNz1=m_itabImage[iIndiceDebut+config.m_iDefX]; iNz2=m_itabImage[iIndiceDebut+1+config.m_iDefX]; } m_ctabSegment[iIndiceDebut]=0; break; case 26: x0=col+0.5F; y0=lig; xc=col+0.5F; yc=lig+0.5F; fin1=1; iNz1=m_itabImage[iIndiceDebut]; iNz2=m_itabImage[iIndiceDebut+1]; m_ctabSegment[iIndiceDebut]=0; break; case 27: x0=col; y0=lig+0.5F; xc=col+0.5F; yc=lig+0.5F; fin1=1; iNz1=m_itabImage[iIndiceDebut]; iNz2=m_itabImage[iIndiceDebut+config.m_iDefX]; m_ctabSegment[iIndiceDebut]=0; break; default: break; } iNza=19+iNz1; iNzb=19+iNz2; nbpt1=0; lig1x[nbpt1]=x0; lig1y[nbpt1]=y0;

416

Annexe
nbpt1++; //--- fin initialisation de la ligne, debut chainage avant while(fin1 == 0) { iIndice=icol1+(ilig1*config.m_iDefX); iseg=m_ctabSegment[iIndice]; if(iseg == 0)fin1=1; else { col=(float)icol1; lig=(float)ilig1; switch(icote1) { case 1: //--- icote1 switch(iseg) { case 1: //--- iseg iType=SegmentType(icol1,ilig1); if(iType == 1 || iType == 7) { m_ctabSegment[iIndice]=0; lig1x[nbpt1]=xc; lig1y[nbpt1]=yc; nbpt1++; xc=col+0.5F; yc=lig+1.F; icote1=2; ilig1++; } else if(iType == 5) { m_ctabSegment[iIndice]=0; lig1x[nbpt1]=xc; lig1y[nbpt1]=yc; nbpt1++; xc=col+0.5F; yc=lig+1.F; fin1=1; } else if(iType == 10)fin1=1; break; case 4: //--- iseg iType=SegmentType(icol1,ilig1); if(iType == 4 || iType == 9) { m_ctabSegment[iIndice]=0; lig1x[nbpt1]=xc; lig1y[nbpt1]=yc; nbpt1++; xc=col+0.5F; yc=lig; icote1=4; ilig1--; } else if(iType == 8) { m_ctabSegment[iIndice]=0; lig1x[nbpt1]=xc; lig1y[nbpt1]=yc; nbpt1++; xc=col+0.5F; yc=lig; fin1=1; } else if(iType == 10)fin1=1; break;

etc.

Le programme teste ainsi lensemble des configurations possibles en fonction du segment prcdent, du segment courant, et du type temporaire de segment. Il avance ainsi de segment en segment ou sarrte sil rencontre un nud. La recherche est effectue dans les deux sens. Il passe la cration dun nouvel arc sil reste encore des segments non chans dans limage.

Structures et mthodes : implmentation 417 A.2.2.4. DilaterImage() Cette fonction globale permet de crer un masque en dilatant une image de
iDistancePixel pixels :
void DilaterImage(int* itabImage,int iDistancePixel,unsigned char* ctabMasque) { int* itabNewImage=(int *) malloc(config.m_iDefX*config.m_iDefY*sizeof(int)); if(itabNewImage == NULL) { ::ErreurDeMemoire(); return; } //--- existence du masque BOOL bMasque=TRUE; if(ctabMasque == NULL)bMasque=FALSE; if(iDistancePixel > 200)iDistancePixel=200; //--- prparation des pixels de la recherche int i,j,ilig,icol,iligAuCarre,iD; int iDistancePixelAuCarre=iDistancePixel*iDistancePixel; int iNbPixels=(2*iDistancePixel+1)*(2*iDistancePixel+1); int iSizeElement=3*sizeof(int); unsigned char* ctabElements=(unsigned char *) malloc(iNbPixels*iSizeElement); if(ctabElements == NULL) { ::ErreurDeMemoire(); free(itabNewImage); return; } //--- tableau non tri des pixels int iNbElements=0; j=0; for(ilig=-iDistancePixel;ilig <= iDistancePixel;ilig++) { iligAuCarre=ilig*ilig; for(icol=-iDistancePixel;icol <= iDistancePixel;icol++) { iD=iligAuCarre + icol*icol; if(iD > 0 && iD <= iDistancePixelAuCarre) { //--- ajouter au tableau trier memcpy(&ctabElements[j],&iD,sizeof(int)); j+=sizeof(int); memcpy(&ctabElements[j],&icol,sizeof(int)); j+=sizeof(int); memcpy(&ctabElements[j],&ilig,sizeof(int)); j+=sizeof(int); iNbElements++; } } } //--- tri sur la distance qsort(ctabElements,iNbElements,iSizeElement,comparnumDistance); //--- traitement int iCode,iCodeARemplir; unsigned char cCodeMasque=1; int iX,iY,iX0,iY0,iIndice; iCodeARemplir=0; iY=0; while(iY < config.m_iDefY) { iIndice=iY*config.m_iDefX; iX=0; while(iX < config.m_iDefX) { iCode=itabImage[iIndice]; if(bMasque)cCodeMasque=ctabMasque[iIndice]; if(iCode == iCodeARemplir && cCodeMasque == 1) { j=0;

418

Annexe
for(i=0;i < iNbElements;i++) { j+=sizeof(int); memcpy(&iX0,&ctabElements[j],sizeof(int)); j+=sizeof(int); memcpy(&iY0,&ctabElements[j],sizeof(int)); j+=sizeof(int); icol=iX+iX0; ilig=iY+iY0; if(ilig >= 0 && ilig < config.m_iDefY && icol >= 0 && icol < config.m_iDefX) { iCode=itabImage[ilig*config.m_iDefX + icol]; if(iCode != iCodeARemplir)break; } } } itabNewImage[iIndice]=iCode; iX++; iIndice++; } iY++; }

iNbPixels=config.m_iDefX*config.m_iDefY; memcpy(itabImage,itabNewImage,iNbPixels*sizeof(int)); free(ctabElements); free(itabNewImage); }

A.2.2.5. SegmentIntersection() La procdure SegmentIntersection() teste lintersection de deux segments et calcule les coordonnes de lintersection si elle existe. Elle est utilise dans de nombreuses procdures faisant intervenir les arcs dcrivant des zones ou des lignes. Lorsquil y a intersection possible des deux segments, le calcul est effectu en changeant de repre pour aligner lun des segment avec laxe des abscisses.
BOOL SegmentIntersection(double dX1,double dY1,double dX2,double dY2,double dX3,double dY3,double dX4,double dY4,double& dXRes,double& dYRes) { double dPx1,dPx2,dPx3,dPx4; double dPy1,dPy2,dPy3,dPy4; double dF1xmin,dF1xmax,dF2xmin,dF2xmax,dF1ymin,dF1ymax,dF2ymin,dF2ymax; //--- si deux extremits sont gales, retourner FALSE //if(dX1 == dX3 && dY1 == dY3)return FALSE; //if(dX1 == dX4 && dY1 == dY4)return FALSE; //if(dX2 == dX3 && dY2 == dY3)return FALSE; //if(dX2 == dX4 && dY2 == dY4)return FALSE; if(dX1 == dX2 && dY1 == dY2)return FALSE; if(dX3 == dX4 && dY3 == dY4)return FALSE; //--- ordonner le premier segment en y et calculer sa fentre dXRes=0.; dYRes=0.; if(dY1 < dY2) { dPx1=dX1; dPy1=dY1; dPx2=dX2; dPy2=dY2; dF1ymin=dY1; dF1ymax=dY2; if(dX1 <= dX2) { dF1xmin=dX1; dF1xmax=dX2; } else { dF1xmin=dX2; dF1xmax=dX1; } }

Structures et mthodes : implmentation 419

else if(dY1 > dY2) { dPx1=dX2; dPy1=dY2; dPx2=dX1; dPy2=dY1; dF1ymin=dY2; dF1ymax=dY1; if(dX1 <= dX2) { dF1xmin=dX1; dF1xmax=dX2; } else { dF1xmin=dX2; dF1xmax=dX1; } } else if(dY1 == dY2) { if(dX1 <= dX2) { dPx1=dX1; dPy1=dY1; dPx2=dX2; dPy2=dY2; dF1xmin=dX1; dF1xmax=dX2; } else { dPx1=dX2; dPy1=dY2; dPx2=dX1; dPy2=dY1; dF1xmin=dX2; dF1xmax=dX1; } dF1ymin=dY1; dF1ymax=dY2; } //--- ordonner le second segment if(dY3 < dY4) { dPx3=dX3; dPy3=dY3; dPx4=dX4; dPy4=dY4; dF2ymin=dY3; dF2ymax=dY4; if(dX3 <= dX4) { dF2xmin=dX3; dF2xmax=dX4; } else { dF2xmin=dX4; dF2xmax=dX3; } } else if(dY3 > dY4) { dPx3=dX4; dPy3=dY4; dPx4=dX3; dPy4=dY3; dF2ymin=dY4; dF2ymax=dY3; if(dX3 <= dX4) { dF2xmin=dX3; dF2xmax=dX4; } else { dF2xmin=dX4; dF2xmax=dX3; }

420

Annexe

} else if(dY3 == dY4) { if(dX3 <= dX4) { dPx3=dX3; dPy3=dY3; dPx4=dX4; dPy4=dY4; dF2xmin=dX3; dF2xmax=dX4; } else { dPx3=dX4; dPy3=dY4; dPx4=dX3; dPy4=dY3; dF2xmin=dX4; dF2xmax=dX3; } dF2ymin=dY3; dF2ymax=dY4; } if(dF1xmax > dF2xmin && dF2xmax > dF1xmin && dF1ymax > dF2ymin && dF2ymax > dF1ymin) { //--- test d'intersection double dP1P2=sqrt((dPx2-dPx1)*(dPx2-dPx1) + (dPy2-dPy1)*(dPy2-dPy1)); if(dP1P2 == 0.)return FALSE; double cosTeta=(dPx2-dPx1)/dP1P2; double sinTeta=(dPy2-dPy1)/dP1P2; dX2=(dPx2-dPx1)*cosTeta+(dPy2-dPy1)*sinTeta; dX3=(dPx3-dPx1)*cosTeta+(dPy3-dPy1)*sinTeta; dY3=-(dPx3-dPx1)*sinTeta+(dPy3-dPy1)*cosTeta; dX4=(dPx4-dPx1)*cosTeta+(dPy4-dPy1)*sinTeta; dY4=-(dPx4-dPx1)*sinTeta+(dPy4-dPy1)*cosTeta; double dYmin,dYmax; if(dY3 < dY4) { dYmin=dY3; dYmax=dY4; } else { dYmin=dY4; dYmax=dY3; } if(dY3 == dY4) { if(dY3 == 0) { Ordonner(dX3,dX4); if(dX3 >= dX2)return FALSE; if(dX4 <= 0.)return FALSE; dXRes=dX3*cosTeta + dPx1; dYRes=dX3*sinTeta + dPy1; return TRUE; } else return FALSE; } if(dYmin >= 0.)return FALSE; if(dYmax <= 0.)return FALSE; if(dX3 == dX4) { //--- parallle l'axe des Y if(dX3 <= 0.)return FALSE; if(dX3 >= dX2)return FALSE; //--- rotation inverse pour le resultat dXRes=dX3*cosTeta + dPx1; dYRes=dX3*sinTeta + dPy1; return TRUE; } else { //--- point d'intersection avec l'axe des X double dX=dX3-(dY3*(dX4-dX3)/(dY4-dY3));

Structures et mthodes : implmentation 421

if(dX <= 0.)return FALSE; if(dX >= dX2)return FALSE; //--- rotation inverse pour le resultat dXRes=dX*cosTeta + dPx1; dYRes=dX*sinTeta + dPy1; return TRUE; }

} return FALSE; }

A.2.2.6. Les classes CZone et CTache Les classes CZone et CTache permettent, pour les zones, de passer dune reprsentation par arc frontire une reprsentation par arcs chans. Une tache reprsente le contour dun polygone. Une zone est un ensemble de polygones. Les taches dune mme zone peuvent tre imbriques et la principale difficult du chanage consiste dterminer cette imbrication uniquement partir des arcs frontires.
class CTache { private: int m_iNbpt; int m_iIndex; int m_iPere; double m_dSurface; double m_dXMin; double m_dYMin; double m_dXMax; double m_dYMax; CZone* m_pZone; public: CTache(CZone* pZone,int iIndex,int iNbpt); BOOL BoundingBox(double& dXMin,double& dYMin,double& dXMax,double& dYMax); BOOL IsPointInside(double dX,double dY); void CalculCentroide(double &dX,double &dY); BOOL GetPointInterieur(double &dX,double &dY); void SetPere(int iPere) {m_iPere=iPere;}; int GetNbpt() {return m_iNbpt;}; int GetIndex() {return m_iIndex;}; int GetPere() {return m_iPere;}; double GetSurface() {return m_dSurface;}; void GetBB(double& dXMin,double& dYMin,double& dXMax,double& dYMax) { dXMin=m_dXMin; dYMin=m_dYMin; dXMax=m_dXMax; dYMax=m_dYMax; return; }; void ChangerLeSens(); double Surface(); }; class CZone { private: FILE* m_FileArc; CCadre* m_pCadre; int m_iNbArc; int* m_itabPtrArc; int m_iNz; int m_iNbTaches; int m_iNbptTotal; public: CTache* m_ptabTache[NB_MAX_TACHES]; double *m_dtabPoints; private: public:

422

Annexe
CZone(); ~CZone(); BOOL Init(CCadre* pCadre,FILE* FileArc,int iNbarcDeLaZone,int* itabPtr); BOOL BoundingBox(double& dXMin,double& dYmin,double& dXMax,double& dYmax); BOOL Chainer(); int NbptTotal(); int GetNbTaches() {return m_iNbTaches;}; void Desalloc(); };

Voici limplmentation de la procdure Chainer() qui cre le chanage des arcs appartenant une zone, partir de lensemble des arcs de la relation. Cette procdure est notamment utilise pour exporter en format ShapeFile (ArcView) des donnes graphiques SAVANE.
BOOL CZone::Chainer() { m_iNbTaches=0; m_iNbptTotal=0; //--- chainage par tache double* dtabX1=(double *) double* dtabY1=(double *) double* dtabX2=(double *) double* dtabY2=(double *)

malloc(sizeof(double)*m_iNbArcZone); malloc(sizeof(double)*m_iNbArcZone); malloc(sizeof(double)*m_iNbArcZone); malloc(sizeof(double)*m_iNbArcZone);

BOOL *btabLibre=(BOOL *) malloc(sizeof(BOOL)*m_iNbArcZone); BOOL *btabSens=(BOOL *) malloc(sizeof(int)*m_iNbArcZone); int *itabArcDeLaTache=(int *) malloc(sizeof(int)*m_iNbArcZone); //--- vrification des allocations mmoire if(dtabX1 == NULL || dtabY1 == NULL || dtabX2 == NULL || dtabY2 == NULL || btabLibre == NULL || btabSens == NULL || itabArcDeLaTache == NULL) { if(dtabX1 != NULL)free(dtabX1); if(dtabY1 != NULL)free(dtabY1); if(dtabX2 != NULL)free(dtabX2); if(dtabY2 != NULL)free(dtabY2); if(btabLibre != NULL)free(btabLibre); if(btabSens != NULL)free(btabSens); if(itabArcDeLaTache != NULL)free(itabArcDeLaTache); return FALSE; } //--- initialisations int i,iArc,iNbpt; CArcMygale* pArc; double dX1,dY1,dX2,dY2; for(iArc=0;iArc < m_iNbArcZone;iArc++) { pArc=m_ptabArc[iArc]; if(pArc != NULL) { iNbpt=pArc->GetNbpt(); pArc->GetPoint(0,dX1,dY1); pArc->GetPoint(iNbpt-1,dX2,dY2); dtabX1[iArc]=dX1; dtabY1[iArc]=dY1; dtabX2[iArc]=dX2; dtabY2[iArc]=dY2; btabLibre[iArc]=TRUE; } } //--- chainage par tche double dXDebut,dYDebut,dXFin,dYFin; int iNbTachesNonFermees=0; CTache* pTache=NULL; iArc=0; while(iArc < m_iNbArcZone && m_iNbTaches < NB_MAX_TACHES) { //--- chainage par tache while(iArc < m_iNbArcZone && btabLibre[iArc] == FALSE)iArc++;

Structures et mthodes : implmentation 423

if(iArc == m_iNbArcZone)break; //--- dbut du ring dXDebut=dtabX1[iArc]; dYDebut=dtabY1[iArc]; dXFin=dtabX2[iArc]; dYFin=dtabY2[iArc]; int iNbarcTache=0; itabArcDeLaTache[iNbarcTache]=iArc; btabSens[iNbarcTache]=0; iNbarcTache++; btabLibre[iArc]=FALSE; iArc++; BOOL bFerme=FALSE; if(dXDebut == dXFin && dYDebut == dYFin)bFerme=TRUE; int jArc=iArc; while(jArc < m_iNbArcZone && bFerme == FALSE) { if(btabLibre[jArc] == TRUE) { if(dtabX1[jArc] == dXFin && dtabY1[jArc] == dYFin) { itabArcDeLaTache[iNbarcTache]=jArc; btabSens[iNbarcTache]=0; iNbarcTache++; dXFin=dtabX2[jArc]; dYFin=dtabY2[jArc]; btabLibre[jArc]=FALSE; jArc=iArc; if(dXFin == dXDebut && dYFin == dYDebut)bFerme=TRUE; } else if(dtabX2[jArc] == dXFin && dtabY2[jArc] == dYFin) { itabArcDeLaTache[iNbarcTache]=jArc; btabSens[iNbarcTache]=1; iNbarcTache++; dXFin=dtabX1[jArc]; dYFin=dtabY1[jArc]; btabLibre[jArc]=FALSE; jArc=iArc; if(dXFin == dXDebut && dYFin == dYDebut)bFerme=TRUE; } else jArc++; } else jArc++; } //--- fin du chainage d'une tche, criture du polygone if(bFerme) { //--- chainage dans m_dtabPoints int iIndex=m_iNbptTotal; int iNbptPolygon=0; for(i=0;i < iNbarcTache;i++) { pArc=m_ptabArc[itabArcDeLaTache[i]]; pArc->Chainer(btabSens[i],m_iTypeCoordonnees,m_iNbptTotal,iNbptPolygon,m_dtabPoints); } if(iNbptPolygon > 3) { //--- trois points ou moins : surface nulle ! pTache=new CTache(this,iIndex,iNbptPolygon); if(pTache != NULL) { m_ptabTache[m_iNbTaches]=pTache; m_iNbTaches++; } } } else iNbTachesNonFermees++; } free(dtabX1); free(dtabY1); free(dtabX2); free(dtabY2); free(btabLibre); free(btabSens);

424

Annexe

free(itabArcDeLaTache); if(iNbTachesNonFermees > 0)return FALSE; //--- calcul du sens pour chaque tche if(m_iNbTaches == 0)return FALSE; else if(m_iNbTaches == 1) { double dSurface=m_ptabTache[0]->Surface(); if(dSurface > 0.)m_ptabTache[0]->ChangerLeSens(); } else if(m_iNbTaches == 2) { //--- zone de deux tches double dX0b,dY0b,dX0h,dY0h; double dX1b,dY1b,dX1h,dY1h; double dXInterieur,dYInterieur; m_ptabTache[0]->BoundingBox(dX0b,dY0b,dX0h,dY0h); m_ptabTache[1]->BoundingBox(dX1b,dY1b,dX1h,dY1h); double dSurface0=m_ptabTache[0]->Surface(); double dSurface1=m_ptabTache[1]->Surface(); if(fabs(dSurface0) > fabs(dSurface1)) { if(dSurface0 > 0.)m_ptabTache[0]->ChangerLeSens(); //--- tester si 1 est inclus dans 0 if(dSurface1 != 0. && dX1b >= dX0b && dX1h <= dX0h && dY1b >= dY0b && dY1h <= dY0h) { //--- tester l'appartenance d'un point de la 1 dans la 0 m_ptabTache[1]->GetPointInterieur(dXInterieur,dYInterieur); if(m_ptabTache[0]->IsPointInside(dXInterieur,dYInterieur)) if(dSurface1 < 0.)m_ptabTache[1]->ChangerLeSens(); else if(dSurface1 > 0.)m_ptabTache[1]->ChangerLeSens(); } else { //--- on est sr que la tache 1 n'est pas incluse if(dSurface1 > 0.)m_ptabTache[1]->ChangerLeSens(); } } else { if(dSurface1 > 0.)m_ptabTache[1]->ChangerLeSens(); //--- tester si 0 est inclus dans 1 if(dSurface0 != 0. && dX0b >= dX1b && dX0h <= dX1h && dY0b >= dY1b && dY0h <= dY1h) { //--- tester l'appartenance d'un point de la 0 dans la 1 m_ptabTache[0]->GetPointInterieur(dXInterieur,dYInterieur); if(m_ptabTache[1]->IsPointInside(dXInterieur,dYInterieur)) if(dSurface0 < 0.)m_ptabTache[0]->ChangerLeSens(); else if(dSurface0 > 0.)m_ptabTache[0]->ChangerLeSens(); } else { //--- on est sr que la tache 0 n'est pas incluse if(dSurface0 > 0.)m_ptabTache[0]->ChangerLeSens(); } }

} else { //--- zones de plusieurs taches BOOL bIncluse; int j,iIndice,iNoTache,iNoTacheBis,iSize,iNbTachesNonNulles; double dSurface,dXInterieur,dYInterieur; double dX0b,dY0b,dX0h,dY0h; double dX1b,dY1b,dX1h,dY1h;

iSize=sizeof(double) + sizeof(int); unsigned char *ctabSurface=(unsigned char *) malloc(m_iNbTaches*iSize); int *itabTri=(int *) malloc(m_iNbTaches*sizeof(int)); if(ctabSurface == NULL || itabTri == NULL) { ::ErreurDeMemoire(); if(ctabSurface != NULL)free(ctabSurface); if(itabTri != NULL)free(itabTri);

Structures et mthodes : implmentation 425

return FALSE; } //--- trier les taches sur leur surface, tablir le tableau des indices des taches tries iNbTachesNonNulles=0; iIndice=0; for(i=0;i < m_iNbTaches;i++) { m_ptabTache[i]->BoundingBox(dX0b,dY0b,dX0h,dY0h); dSurface=fabs(m_ptabTache[i]->Surface()); if(dSurface > 0.) { memcpy(&ctabSurface[iIndice],&dSurface,sizeof(double)); memcpy(&ctabSurface[iIndice + sizeof(double)],&i,sizeof(int)); iIndice+=iSize; iNbTachesNonNulles++; } } qsort(ctabSurface,iNbTachesNonNulles,iSize,compareDoubleAsc); iIndice=0; for(i=0;i < iNbTachesNonNulles;i++) { memcpy(&iNoTache,&ctabSurface[iIndice + sizeof(double)],sizeof(int)); itabTri[i]=iNoTache; iIndice+=iSize; } //--- en partant de la plus petite tache, on cherche le premier incluant, pour chaque tache for(i=0;i < iNbTachesNonNulles;i++) { iNoTache=itabTri[i]; m_ptabTache[iNoTache]->SetPere(-2); m_ptabTache[iNoTache]->GetBB(dX0b,dY0b,dX0h,dY0h); m_ptabTache[iNoTache]->GetPointInterieur(dXInterieur,dYInterieur); for(j=i+1;j < iNbTachesNonNulles;j++) { iNoTacheBis=itabTri[j]; m_ptabTache[iNoTacheBis]->GetBB(dX1b,dY1b,dX1h,dY1h); if(dX0b >= dX1b && dX0h <= dX1h && dY0b >= dY1b && dY0h <= dY1h) { //--- vrifier l'inclusion par un point bIncluse=m_ptabTache[iNoTacheBis]->IsPointInside(dXInterieur,dYInterieur); if(bIncluse) { m_ptabTache[iNoTache]->SetPere(iNoTacheBis); break; } } } } //--- en partant du plus grand, on ecrit la tache (clockwise) et tous les fils (counterclock) jusqu'a ecrire toutes les taches for(i=iNbTachesNonNulles-1;i >= 0;i--) { iNoTache=itabTri[i]; if(m_ptabTache[iNoTache]->GetPere() != -2) { //--- ecriture de la tache iNoTache clockwise if(m_ptabTache[iNoTache]->GetSurface() > 0.)m_ptabTache[iNoTache]->ChangerLeSens(); m_ptabTache[iNoTache]->SetPere(-2); for(j=i-1;j >= 0;j--) { iNoTacheBis=itabTri[j]; if(m_ptabTache[iNoTacheBis]->GetPere() == iNoTache) { //--- ecriture de la tache iNoTacheBis counterclockwise if(m_ptabTache[iNoTacheBis]->GetSurface() < 0.)m_ptabTache[iNoTacheBis]>ChangerLeSens(); m_ptabTache[iNoTacheBis]->SetPere(-2); } } } }

free(ctabSurface); free(itabTri);

426
}

Annexe

return TRUE; }

A.2.3. Fentre et projections A.2.3.1. La classe CWind La classe CWind encapsule donnes et mthodes permettant de manipuler la fentre de slection gographique dans un cadre. Chaque cadre contient un objet de type CWind.
class CWind { public: CCadre* m_pCadre; double m_dFi1; double m_dFi2; double m_dFi3; double m_dFi4; float m_fFx1; float m_fFy1; float m_fFx2; float m_fFy2; double m_dFlx; double m_dFly; double m_dFhx; double m_dFhy; double m_dCoefRas; double m_dFpixRas; // taille en metre du pixel rasterisation savane int m_iNbWind; // pour l'historique des fenetres float m_fFx1Undo[NB_MAX_WIND]; float m_fFy1Undo[NB_MAX_WIND]; float m_fFx2Undo[NB_MAX_WIND]; float m_fFy2Undo[NB_MAX_WIND]; public: CWind(CCadre* pCadre); CWind(CCadre* pCadre,FILE* Fichier); void Ecrire(FILE* Fichier); void Copier(CWind* pWindInit); void ProjToRas(double dProjX,double dProjY,float &fRasX,float &fRasY); void RasToProj(float fRasX,float fRasY,double &dProjX,double &dProjY); void NouvelleFenetre(float fFx1,float fFy1,float fFx2,float fFy2); void NouvelleFenetre(double dFlx,double dFly,double dFpixRas); void NouvelleFenetre(double dFlx,double dFly,double dFhx,double dFhy); void NouvelleFenetre(double dFlx,double dFly,double dFhx,double dFhy,double dFpixRas); void Undo(); void NouvelleProjection();

};

Par exemple, voici le code de la procdure permettant de modifier la fentre par coordonnes de projection :
void CWind::NouvelleFenetre(double dFlx,double dFly,double dFhx,double dFhy) { //--- mise a jour du undo if(m_iNbWind < NB_MAX_WIND) { m_fFx1Undo[m_iNbWind]=m_fFx1; m_fFy1Undo[m_iNbWind]=m_fFy1; m_fFx2Undo[m_iNbWind]=m_fFx2; m_fFy2Undo[m_iNbWind]=m_fFy2; m_iNbWind++; } else {

Structures et mthodes : implmentation 427

for(int i=1;i < m_iNbWind;i++) { m_fFx1Undo[i-1]=m_fFx1Undo[i]; m_fFy1Undo[i-1]=m_fFy1Undo[i]; m_fFx2Undo[i-1]=m_fFx2Undo[i]; m_fFy2Undo[i-1]=m_fFy2Undo[i]; } m_fFx1Undo[m_iNbWind-1]=m_fFx1; m_fFy1Undo[m_iNbWind-1]=m_fFy1; m_fFx2Undo[m_iNbWind-1]=m_fFx2; m_fFy2Undo[m_iNbWind-1]=m_fFy2; } //--- nouvelle fentre par coordonnes de projection m_dFlx=dFlx; m_dFly=dFly; m_dFhx=dFhx; m_dFhy=dFhy; //--- calcul des coefficients pour le raster Savane if((m_dFhx-m_dFlx) > 0. && (m_dFhy-m_dFly) > 0.) { double d1=(double)(config.m_iDefX)/(m_dFhx-m_dFlx); double d2=(double)(config.m_iDefY)/(m_dFhy-m_dFly); if(d1 < d2)m_dCoefRas=d1; else m_dCoefRas=d2; m_dFpixRas=1./m_dCoefRas; } //--- calcul de Fx1,Fy1,Fx2,Fy2 m_pCadre->ProjToSav(dFlx,dFly,m_fFx1,m_fFy1); m_pCadre->ProjToSav(dFhx,dFhy,m_fFx2,m_fFy2); //--- rinitialisation des rasterisations pour le cadre CSchema* pSchema=m_pCadre->GetSchema(); int iNoth=1; while(iNoth <= pSchema->m_iNbacc) { pSchema->m_pRelations[iNoth]->m_iNbObjets=-1; int iTypeRel=pSchema->m_pRelations[iNoth]->m_iType; if(iTypeRel == 24) { pSchema->m_pRelations[iNoth]->m_iType=14; int iFim=pSchema->m_pRelations[iNoth]->m_iNoFichImage; pSchema->m_iFdisImage[iFim]=0; } iNoth++; } //--- suppression de la relation Raster int iNothRaster=pSchema->RelRecherche("Raster"); if(iNothRaster > 0)XRelProj(m_pCadre,iNothRaster); //--- dimensionner le cadre la nouvelle fenetre m_pCadre->ReAjuster(); groupes.TailleDesCadres(); }

B.2.3.2. La classe CProjection La classe CProjection se charge de la gestion et du calcul des projection gographique dans un cadre. Chaque cadre contient un objet de type CProjection :
class CProjection { private: //--- projection courante int m_iProjection; CString m_strNomProjection; //--- description de l'ellipsode double m_dEllipseA; double m_dEllipseE; double m_dEllipseE2;

428

Annexe

double m_dEllipseEprim; double m_dEllipseEprim2; double m_dEllipseEsur2; //--- description de la projection double m_dXOrigine; double m_dYOrigine; int m_iZoneUtm; double m_dFacteur; int m_iMeridienCentralD; int m_iMeridienCentralM; double m_dMeridienCentralS; int m_iMeridienCentralHem; int m_iParalleleOrigineD; int m_iParalleleOrigineM; double m_dParalleleOrigineS; int m_iParalleleOrigineHem; int m_iParallele1D; int m_iParallele1M; double m_dParallele1S; int m_iParallele1Hem; int m_iParallele2D; int m_iParallele2M; double m_dParallele2S; int m_iParallele2Hem; //--- membres pour les calculs double m_dPi; double m_dPisur2; double m_dPisur4; double m_dMinuteToRadian; double m_dRadianToMinute; double m_dMeridienCentral; double m_dParalleleOrigine; double m_dParallele1; double m_dParallele2; double m_dGelMer[5]; double m_dXs; double m_dYs; double m_dN; double m_dC; double m_dRh; double m_dSin0; double m_dCos0; //--- procedures d'initialisation void LambertTangenteInit(); void LambertSecanteInit(); void StereographicInit(); void OrthographicInit(); void AlbertEquivInit(); //--- procedures de calcul void GeographicToGeo(double dX,double dY,double &dLongitude,double &dColatitude); void GeoToGeographic(double dLongitude,double dColatitude,double &dX,double &dY); void UtmToGeo(double dX,double dY,double &dLongitude,double &dColatitude); void GeoToUtm(double dLongitude,double dColatitude,double &dX,double &dY); void LambertToGeo(double dX,double dY,double &dLongitude,double &dColatitude); void GeoToLambert(double dLongitude,double dColatitude,double &dX,double &dY); void MercatorToGeo(double dX,double dY,double &dLongitude,double &dColatitude); void GeoToMercator(double dLongitude,double dColatitude,double &dX,double &dY); void StereographicToGeo(double dX,double dY,double &dLongitude,double &dColatitude); void GeoToStereographic(double dLongitude,double dColatitude,double &dX,double &dY); void OrthographicToGeo(double dX,double dY,double &dLongitude,double &dColatitude); void GeoToOrthographic(double dLongitude,double dColatitude,double &dX,double &dY); void AlbertEquivToGeo(double dX,double dY,double &dLongitude,double &dColatitude); void GeoToAlbertEquiv(double dLongitude,double dColatitude,double &dX,double &dY); void GeodegreToGeo(double dX,double dY,double &dLongitude,double &dColatitude); void GeoToGeodegre(double dLongitude,double dColatitude,double &dX,double &dY); //--- procedures de double Msfnz(double double Qsfnz(double double Phi1z(double public: calcul sinphi,double cosphi); sinphi,double cosphi); qs);

Structures et mthodes : implmentation 429

CProjection(); CProjection(FILE* Fichier); void Ecrire(FILE* Fichier); BOOL SetProjection(int iProjection); BOOL SetProjection(double dProj[20]); int GetProjection(); void GetProjection(double dProj[20]); CString GetNomProjection(); CString GetNomProjection(int iProjection); BOOL SetEllipse(double dA,double dE2); void GetEllipse(double &dA,double &dE2); BOOL SetFacteur(double dFacteur); double GetFacteur(); BOOL SetOrigine(double dX,double dY); void GetOrigine(double &dX,double &dY); void SetZoneUtm(int iZone); int GetZoneUtm(); void SetMeridienCentral(class CLongitude); void SetMeridienCentral(int iDegre,int iMinute,double dSeconde,int iHem); BOOL SetMeridienCentral(double dMeridienCentral); class CLongitude GetMeridienCentral(); void SetParalleleOrigine(class CLatitude); void SetParalleleOrigine(int iDegre,int iMinute,double dSeconde,int iHem); BOOL SetParalleleOrigine(double dColatitude); class CLatitude GetParalleleOrigine(); void SetParallele1(class CLatitude); void SetParallele1(int iDegre,int iMinute,double dSeconde,int iHem); BOOL SetParallele1(double dColatitude); class CLatitude GetParallele1(); void SetParallele2(class CLatitude); void SetParallele2(int iDegre,int iMinute,double dSeconde,int iHem); BOOL SetParallele2(double dColatitude); class CLatitude GetParallele2(); void Init(); void GeoToProj(double dLongitude,double dColatitude,double &dX,double &dY); void ProjToGeo(double dX,double dY,double &dLongitude,double &dColatitude); };

Les coordonnes gographiques (dLongitude, dColatitude) sont toujours exprimes en minutes dcimales dans la classe CProjection. Voici par exemple le code permettant de calculer les transformations de coordonnes pour la projection Mercator :
void CProjection::MercatorToGeo(double dX,double dY,double &dLongitude,double &dColatitude) { int i,iHem; double v,phibis,phi,u,puissance,dLatitude; dLongitude=m_dMeridienCentral+((dX/m_dEllipseA)*m_dRadianToMinute); if(dLongitude < 0.)dLongitude+=21600.; else if(dLongitude >= 21600.)dLongitude-=21600.; if(dY <= 0.) { iHem=SUD; dY=-dY; } else iHem=NORD; v=exp(dY/m_dEllipseA); phibis=2.*atan(v)-m_dPisur2; phi=phibis; u=m_dEllipseE*sin(phi); puissance=pow(((1.+u)/(1.-u)),m_dEllipseEsur2); phibis=2.*(atan(v*puissance))-m_dPisur2; i=1; while(phibis != phi && i < 50) { phi=phibis; u=m_dEllipseE*sin(phi); puissance=pow(((1.+u)/(1.-u)),m_dEllipseEsur2);

430

Annexe
phibis=2.*(atan(v*puissance))-m_dPisur2; i++; }

dLatitude=phi*m_dRadianToMinute; if(iHem==NORD)dColatitude=5400.-dLatitude; else dColatitude=5400.+dLatitude; } void CProjection::GeoToMercator(double dLongitude,double dColatitude,double &dX,double &dY) { int iLongitudeHem; double rl,dLatitude,phi,u; if(dLongitude < 0.)dLongitude+=21600.; else if(dLongitude >= 21600.)dLongitude-=21600.; if(dLongitude < 10800.)iLongitudeHem=EST; else iLongitudeHem=OUEST; if(m_iMeridienCentralHem == iLongitudeHem)rl=dLongitude-m_dMeridienCentral; else if(m_iMeridienCentralHem == EST && iLongitudeHem == OUEST) { rl=dLongitude-m_dMeridienCentral; if(rl > 10800.)rl-= 21600.; } else if(m_iMeridienCentralHem == OUEST && iLongitudeHem == EST) { rl=dLongitude+21600.-m_dMeridienCentral; if(rl > 10800.)rl-= 21600.; } if(dColatitude > 5400.)dLatitude=dColatitude-5400.; else dLatitude=5400.-dColatitude; dX=(rl*m_dMinuteToRadian)*m_dEllipseA; phi=dLatitude*m_dMinuteToRadian; u=m_dEllipseE*sin(phi); dY=m_dEllipseA*(log(tan(m_dPisur4+(phi/2.)))-(m_dEllipseEsur2*log((1.+u)/(1.-u)))); if(dColatitude > 5400.)dY=-dY; }

La projection UTM ncessite de nombreux paramtres, dont ceux permettant de calculer la longueur dun arc de mridien sur lellipsode. Les paramtres sont calculs lors du chargement ou de la modification de lellipsode :
BOOL CProjection::SetEllipse(double dA,double dE2) { //--- indique en retour si l'ellipsode a chang if(m_dEllipseA == dA && m_dEllipseE2 == dE2)return FALSE; m_dEllipseA=dA; m_dEllipseE2=dE2; //--- calcul de e, e'2 et e/2 m_dEllipseE=sqrt(dE2); m_dEllipseEsur2=m_dEllipseE/2.; m_dEllipseEprim2=dE2/(1.-dE2); m_dEllipseEprim=sqrt(m_dEllipseEprim2); //--- calcul du nouveau gelmer pour UTM m_dGelMer[0]=1.+ dE2*(3./4.+dE2*(45./64.+dE2*(175./256.+dE2*11025./16384.))); m_dGelMer[1]=dE2*(3./4.+dE2*(15./16.+dE2*(525./512.+dE2*2205./2048.))); m_dGelMer[2]=dE2*dE2*(15./64.+dE2*(105./256.+dE2*2205./4096.)); m_dGelMer[3]=dE2*dE2*dE2*(35./512.+dE2*315./2048.); m_dGelMer[4]=dE2*dE2*dE2*dE2*315./16384.; return TRUE; }

Voici les calculs de transformations de coordonnes pour la projection UTM :

void CProjection::UtmToGeo(double dX,double dY,double &dLongitude,double &dColatitude) { int iLatitudeHem; double y1,x1,rp,b,db,gelmer,x11,x12,rl,rp1,u,dLatitude;

Structures et mthodes : implmentation 431

y1=dY-10000000.; x1=dX-500000.; if(y1 < 0.) { iLatitudeHem=SUD; y1=-y1; } else iLatitudeHem=NORD; x1=x1/m_dFacteur; y1=y1/m_dFacteur; rp=m_dPi*y1/2.e+07; b=m_dGelMer[0]*rp; db=m_dGelMer[1]*sin(2.*rp)/2.; b=b-db; db=m_dGelMer[2]*sin(4.*rp)/4.; b=b+db; db=m_dGelMer[3]*sin(6.*rp)/6.; b=b-db; db=m_dGelMer[4]*sin(8.*rp)/8.; b=b+db; gelmer=b*m_dEllipseA*(1.- m_dEllipseE2); y1=y1-gelmer; u=sin(rp); u=u*u; x11=m_dEllipseA/sqrt(1.-m_dEllipseE2*u); x12=m_dEllipseE2*(1.-u)/6./(1.- m_dEllipseE2); y1=y1*(1.-3.*x12*x1*x1/x11/x11)/x11; x1=x1*(1.-x12*x1*x1/x11/x11)/x11; y1=y1+rp; x1=2.*atan(exp(x1))-m_dPisur2; rl=atan(tan(x1)/cos(y1)); dLongitude=m_dMeridienCentral+rl*m_dRadianToMinute; if(dLongitude < 0.)dLongitude+=21600.; else if(dLongitude >= 21600.)dLongitude-=21600.; rp1=asin(sin(y1)*cos(x1)); rp=rp+(1.-m_dEllipseE2*sin(rp)*sin(rp))/(1.-m_dEllipseE2)*(rp1-rp)*(1.1.5*m_dEllipseEprim2*sin(rp)*cos(rp)*(rp1-rp)); dLatitude=rp*m_dRadianToMinute; if(iLatitudeHem == NORD) dColatitude=5400.-dLatitude; else dColatitude=5400.+dLatitude; } void CProjection::GeoToUtm(double dLongitude,double dColatitude,double &dX,double &dY) { int iLongitudeHem,iLatitudeHem; double rl,rp,dLatitude; double cpsi,spsi,tpsi,tpsi2,tpsi4,nu,nu2,N,u,u2,u3,x; double y,b,db,gelmer; if(dLongitude < 0.)dLongitude+=21600.; else if(dLongitude >= 21600.)dLongitude-=21600.; if(dLongitude < 10800.)iLongitudeHem=EST; else iLongitudeHem=OUEST; if(m_iMeridienCentralHem == iLongitudeHem)rl=dLongitude-m_dMeridienCentral; else if(m_iMeridienCentralHem == EST && iLongitudeHem == OUEST) { rl=dLongitude-m_dMeridienCentral; if(rl > 10800.)rl-=21600.; } else if(m_iMeridienCentralHem == OUEST && iLongitudeHem == EST) { rl=dLongitude+21600.-m_dMeridienCentral; if(rl > 10800.)rl-=21600.; } if(dColatitude > 5400.) { iLatitudeHem=SUD; dLatitude=dColatitude-5400.; }

432

Annexe

else { iLatitudeHem=NORD; dLatitude=5400.-dColatitude; } rl=rl*m_dMinuteToRadian; rp=dLatitude*m_dMinuteToRadian; cpsi=cos(rp); spsi=sin(rp); tpsi=spsi/cpsi; tpsi2=tpsi*tpsi; tpsi4=tpsi2*tpsi2; nu=cpsi*m_dEllipseEprim; nu2=nu*nu; N=m_dEllipseA/sqrt(1.- m_dEllipseE2*spsi*spsi); u=rl*cpsi; u2=u*u; u3=u2*u; //--- calcul de x x=N*u+(N*u3*(1.-tpsi2+nu2)/6.); x=x+(N*u2*u3*(5.-(18.*tpsi2)+tpsi4+(14.*nu2)-(58.*tpsi2*nu2))/120.); dX=500000.+ m_dFacteur*x; //--- calcul de la longueur de l'arc de meridien central b=m_dGelMer[0]*rp; db=m_dGelMer[1]*sin(2.*rp)/2.; b=b-db; db=m_dGelMer[2]*sin(4.*rp)/4.; b=b+db; db=m_dGelMer[3]*sin(6.*rp)/6.; b=b-db; db=m_dGelMer[4]*sin(8.*rp)/8.; b=b+db; gelmer=b*m_dEllipseA*(1.- m_dEllipseE2); //--- termes du developpement pour la projection y=gelmer+(N*u2*tpsi/2.); y=y+(N*u2*u2*tpsi*(5.-tpsi2+(9.*nu2)+(4.*nu2*nu2))/24.); y=y+(N*u3*u3*tpsi*(61.-(58.*tpsi2)+tpsi4+(270.*nu2)-(330.*nu2*tpsi2))/720.); y=m_dFacteur*y; if(iLatitudeHem == SUD)dY=10000000.-y; else dY=y+10000000.; }

La projection Lambert est une conique. Les paramtres sont initialiss lors de la dfinition de la projection dans le cadre :
void CProjection::LambertTangenteInit() { double dPar,phi0,W0,N0,u,L0,R0; if(m_dParalleleOrigine>5400.)dPar=m_dParalleleOrigine-5400.; else dPar=5400.-m_dParalleleOrigine; phi0=dPar*m_dMinuteToRadian; m_dN=sin(phi0); W0=sqrt((1.-(m_dEllipseE2*m_dN*m_dN))); N0=m_dEllipseA/W0; u=m_dEllipseE*m_dN; L0=log(tan(m_dPisur4+(phi0/2.)))-(m_dEllipseEsur2*log((1.+u)/(1.-u))); R0=m_dFacteur*(N0/tan(phi0)); m_dC=R0*exp(m_dN*L0); m_dXs=m_dXOrigine; m_dYs=m_dYOrigine+R0; } void CProjection::LambertSecanteInit() { double dPar,phi0,phi1,phi2,u,w1,n1,l1,w2,n2,l2,l0,r0; if(m_dParalleleOrigine > 5400.)dPar=m_dParalleleOrigine-5400.; else dPar=5400.-m_dParalleleOrigine; phi0=dPar*m_dMinuteToRadian; if(m_dParallele1 > 5400.)dPar=m_dParallele1-5400.;

Structures et mthodes : implmentation 433

else dPar=5400.-m_dParallele1; phi1=dPar*m_dMinuteToRadian; if(m_dParallele2 > 5400.)dPar=m_dParallele2-5400.; else dPar=5400.-m_dParallele2; phi2=dPar*m_dMinuteToRadian; u=sin(phi1); w1=sqrt(1.-(m_dEllipseE2*u*u)); n1=m_dEllipseA/w1; u=m_dEllipseE*u; l1=log(tan(m_dPisur4+(phi1/2.)))-(m_dEllipseEsur2*log((1.+u)/(1.-u))); u=sin(phi2); w2=sqrt(1.-(m_dEllipseE2*u*u)); n2=m_dEllipseA/w2; u=m_dEllipseE*u; l2=log(tan(m_dPisur4+(phi2/2.)))-(m_dEllipseEsur2*log((1.+u)/(1.-u))); m_dN=(log((n2*cos(phi2))/(n1*cos(phi1))))/(l1-l2); m_dC=((n1*cos(phi1))/m_dN)*exp(m_dN*l1); u=m_dEllipseE*sin(phi0); l0=log(tan(m_dPisur4+(phi0/2.)))-(m_dEllipseEsur2*log((1.+u)/(1.-u))); r0=m_dC*exp(-m_dN*l0); m_dXs=m_dXOrigine; m_dYs=m_dYOrigine+r0; } void CProjection::GeoToLambert(double dLongitude,double dColatitude,double &dX,double &dY) { int iLongitudeHem,iLatitudeHem; double rl,dLatitude,phi,u,L,gama,r; if(dLongitude < 0.)dLongitude+=21600.; else if(dLongitude >= 21600.)dLongitude-=21600.; if(dLongitude < 10800.)iLongitudeHem=EST; else iLongitudeHem=OUEST; if(m_iMeridienCentralHem == iLongitudeHem)rl=dLongitude-m_dMeridienCentral; else if(m_iMeridienCentralHem == EST && iLongitudeHem == OUEST) { rl=dLongitude-m_dMeridienCentral; if(rl > 10800.)rl-=21600.; } else if(m_iMeridienCentralHem == OUEST && iLongitudeHem == EST) { rl=dLongitude+21600.-m_dMeridienCentral; if(rl > 10800.)rl-=21600.; } if(dColatitude > 5400.) { iLatitudeHem=SUD; dLatitude=dColatitude-5400.; } else { iLatitudeHem=NORD; dLatitude=5400.-dColatitude; } if(iLatitudeHem != m_iParalleleOrigineHem)dLatitude=-dLatitude; phi=dLatitude*m_dMinuteToRadian; rl*=m_dMinuteToRadian; u=m_dEllipseE*sin(phi); L=log(tan(m_dPisur4+(phi/2.)))-(m_dEllipseEsur2*log((1.+u)/(1.-u))); gama=m_dN*rl; r=m_dC*exp(-m_dN*L); //--- traitement en fonction de l'hmisphre if(m_iParalleleOrigineHem == NORD) { dX=m_dXs+(r*sin(gama)); dY=m_dYs-(r*cos(gama)); } else { dX=m_dXs-(r*sin(gama)); dY=-m_dYs+(r*cos(gama)); }

434
}

Annexe

void CProjection::LambertToGeo(double dX,double dY,double &dLongitude,double &dColatitude) { int i; double u,v,r,gama,l,phibis,phi,puissance,dLatitude; //--- calcul de la longitude u=dX-m_dXs; v=dY-m_dYs; r=sqrt(u*u+v*v); gama=atan(-(u/v)); dLongitude=(gama/m_dN); dLongitude=m_dMeridienCentral+(dLongitude*m_dRadianToMinute); if(dLongitude < 0.)dLongitude+=21600.; else if(dLongitude >= 21600.)dLongitude-=21600.; //--- calcul de la colatitude l=-(log(r/m_dC))/m_dN; phibis=l; v=exp(l); phi=phibis; u=m_dEllipseE*sin(phi); puissance=pow(((1.+u)/(1.-u)),m_dEllipseEsur2); phibis=2.*(atan(v*puissance))-m_dPisur2; i=1; while(phibis != phi && i<50) { phi=phibis; u=m_dEllipseE*sin(phi); puissance=pow(((1.+u)/(1.-u)),m_dEllipseEsur2); phibis=2.*(atan(v*puissance))-m_dPisur2; i++; } dLatitude=phi*m_dRadianToMinute; if(m_iParalleleOrigineHem == NORD)dColatitude=5400.-dLatitude; else dColatitude=5400.+dLatitude; }

A.2.3.3. La classe CMolodensky La classe CModolensky permet de calculer des changements de datum. Le calcul utilise les formules de Molodensky. La prcision absolue de ces formules est denviron deux mtres. Dans SAVANE, toutes les donnes dune mme base doivent tre dans le mme datum. Le changement de datum dans SAVEDIT concerne le seul document de digitalisation ouvert. Le changement de datum dans le module SAVANE concerne lensemble des objets de la base de donnes.
class CMolodensky { private: double m_dA; double m_dF; double m_dDeltaX; double m_dDeltaY; double m_dDeltaZ; double m_dDeltaA; double m_dDeltaF; double m_dBsurA; double m_dAsurB; double m_dE2; public: CMolodensky(); void Init(double dA,double dE2,double dDeltaX,double dDeltaY,double dDeltaZ,double dDeltaA,double dDeltaF); void Calcul(double dLongitude,double dColatitude,double dHauteur,double& dLongRes,double& dLatRes,double& dHauteurRes); }; void CMolodensky::Init(double dA,double dE2,double dDeltaX,double dDeltaY,double dDeltaZ,double dDeltaA,double dDeltaF)

Structures et mthodes : implmentation 435

{ m_dA=dA; m_dE2=dE2; m_dDeltaX=dDeltaX; m_dDeltaY=dDeltaY; m_dDeltaZ=dDeltaZ; m_dDeltaA=dDeltaA; m_dDeltaF=dDeltaF; m_dF=1.- sqrt(1.-m_dE2); m_dBsurA=1.-m_dF; m_dAsurB=1./m_dBsurA; } void CMolodensky::Calcul(double dLongitude,double dColatitude,double dHauteur,double& dLongitudeRes,double& dColatitudeRes,double& dHauteurRes) { double dMinuteToRadian=acos(-1.)/10800.; //--- longitude double dLong=dLongitude; if(dLong > 10800.)dLong=21600.-dLong; dLong*=dMinuteToRadian; double dSinLong=sin(dLong); double dCosLong=cos(dLong); //--- latitude double dLat=dColatitude; dLat=5400.-dLat; dLat*=dMinuteToRadian; double dSinLat=sin(dLat); double dCosLat=cos(dLat); double dRn=m_dA/sqrt(1.-m_dE2*dSinLat*dSinLat); double dRm=m_dA*(1.-m_dE2)/pow(1.-m_dE2*dSinLat*dSinLat,1.5); double dDeltaLong=(-m_dDeltaX*dSinLong + m_dDeltaY*dCosLong)/((dRn+dHauteur)*dCosLat); dDeltaLong/=dMinuteToRadian; double dDeltaLat=-m_dDeltaX*dSinLat*dCosLong-m_dDeltaY*dSinLat*dSinLong+m_dDeltaZ*dCosLat; dDeltaLat=dDeltaLat + m_dDeltaA*(dRn*m_dE2*dSinLat*dCosLat)/m_dA; dDeltaLat=dDeltaLat + m_dDeltaF*(dRm*m_dAsurB + dRn*m_dBsurA)*dSinLat*dCosLat; dDeltaLat=dDeltaLat/(dRm + dHauteur); dDeltaLat/=dMinuteToRadian; double dDeltaH=m_dDeltaX*dCosLat*dCosLong+m_dDeltaY*dCosLat*dSinLong+m_dDeltaZ*dSinLat; dDeltaH=dDeltaH-m_dDeltaA*sqrt(1.- m_dE2*dSinLat*dSinLat) + m_dDeltaF*m_dBsurA*dRn*dSinLat*dSinLat; if(dLongitude < 0. || dLongitude > 10800.)dLongitudeRes=dLongitude-dDeltaLong; else dLongitudeRes=dLongitude+dDeltaLong; dColatitudeRes=dColatitude-dDeltaLat; dHauteurRes=dHauteur+dDeltaH; }

dA, dE2 sont les paramtres de l'ellipsode de dpart ; dDeltaX,dDeltaY,dDeltaZ sont les diffrences de position des centres des datum ; dDeltaA et dDeltaF sont les diffrences de grand cot et d'aplatissement entre les deux ellipsodes.

436

Annexe

A.2.4. Documents et cartographie A.2.4.1. La classe CCarte La classe CCarte encapsule donnes et mthodes pour le document de base du module SAVANE. Le module SAVANE ne contient quune seule instance de cette classe.
class CCarte { //--- attributs private: BOOL m_bASauver; int m_iVersion; long m_ptrlib; void DeleteObjets(); public: char m_chNom[_MAX_PATH]; char m_chNomDir[_MAX_PATH]; int m_iLargeur; //--- largeur de la feuille (mm/100) int m_iHauteur; //--- hauteur de la feuille (mm/100) int m_iTaille; //--- taille de la feuille, cod int m_iOrientation; //--- orientation de la feuille (0 portrait,1 paysage) int m_iNbCadres; //--- nombre de cadres gographiques //--- pointeur des objets cadres CCadre* m_pCadre[NB_MAX_CADRES]; int m_iXVueDansCarte; //--- position du point (0,0) de la vue (espace de visualisation) dans la carte (mm) int m_iYVueDansCarte; double m_dFacteur; //--- facteur de zoom de trac pour la carte double m_dCoef; //--- coefficient de zoom pour la carte double m_dMMToPrint; //--- pour passer des coordonnes en MM/100 aux coordonnes du DCPrint int int int int int int int int m_iRegle; //--- active ou desactive le trac des rgles m_iGrille; //--- active ou desactive les repres magntiques m_iGapPixel; //--- taille de la grille magnetique en pixel ecran m_iGapMM; //--- taille de la grille magnetique en mm/10 m_iGuideCarteX[NB_MAX_GUIDES]; //--- position des guides de trac m_iGuideCarteY[NB_MAX_GUIDES]; m_iGuideVueX[NB_MAX_GUIDES]; //--- position des guides de trac dans la vue m_iGuideVueY[NB_MAX_GUIDES];

int m_iNbObjets; CODD m_tabObjets[NB_MAX_OBJET]; //--- tableau des objets tracer dans la carte //--- mmoire des zoom successifs int m_iMemoireNbZoom; int m_itabMemoireXVueDansCarte[10]; int m_itabMemoireYVueDansCarte[10]; double m_dtabMemoireFacteur[10]; //--- implmentation public: CCarte(); BOOL Nouveau(void); BOOL Ouvrir(char* chNomCarte); BOOL Fermer(void); BOOL Sauver(void); BOOL SauverSous(void); BOOL ChargerLesCadres(); BOOL SauverLesCadres(); BOOL ChargerLesObjets(); BOOL SauverLesObjets(); void ReInit(); int QuelCadre(CPoint point); void ASauver() {m_bASauver=TRUE;}; BOOL IsASauver() {return m_bASauver;}; BOOL IsPointDansCadre(CCadre* pCadre,int iXVue,int iYVue); void TailleDesGroupes(void);

Structures et mthodes : implmentation 437

void ModifierLaSelection(int iMode,int iX,int iY); void SauverLeZoom(); void ZoomDansCarte(); void ZoomDansCadre(int iNoCadre); void EffacerPixmap(); void ToutTracer(); void TracerUnCadre(CCadre* pCadre); void TracerLePapier(); void TracerLePapier(int iXbas,int iYbas,int iXhaut,int iYHaut); void TracerLesObjets(CDC* pDC); void TracerTexte(CDC* pDC,int iXbCarte,int iYbCarte,int iXhCarte,int iYhCarte,int iSizePoint,COLORREF Couleur,LOGFONT* pLogfont,const char* chTexte); int EpaisseurMMToVue(double dEpaisseur,int iPrint); int MMToVue(double dMM,int iPrint); };

Les seuls membres lies la base de donnes sont les pointeurs des objets de type CCadre (CCadre* m_pCadre[NB_MAX_CADRES]). Tous les autres membres et mthodes de cette classe sont lies la reprsentation graphique de la carte, sur lcran ou sur imprimante. Outre des cadres, une carte peut contenir des objets graphiques provenant du dessin direct effectu lcran. Ces objets sont grs par la classe CODD (B.2.4.2). Les ODD reprsentent des classes propres chaque type dobjet graphique (texte, ligne, polyligne, polygone, rectangle, rectangle dgrad, cercle, ellipse, symbole, chelle graphique, bitmap). Les objets graphiques sont conservs dans la carte par le tableau des pointeurs des objets de type CODD correspondants. A.2.4.2. Les classes CODD Les ODD reprsentent des classes propres chaque type dobjet graphique pouvant tre dessin lcran par lutilisateur du systme (texte, ligne, polyligne, polygone, rectangle, rectangle dgrad, cercle, ellipse, symbole, chelle graphique, bitmap). Les classe CODD_ encapsulent toutes les informations ncessaires la manipulation des objets graphiques, selon leur type. Voici par exemple les classes CODD_Symbole et CODD_Texte :
class CODD_Symbole { public: int m_iNumero; int m_iXCarte; int m_iYCarte; int m_iTaille; //--- taille en mm/100 double m_dEpaisseur; //--- epaisseur en mm/100 int m_iDetourage; int m_iTrame; COLORREF m_CouleurInt; COLORREF m_CouleurExt; }; class CODD_Texte { public: int m_itabX[6]; int m_itabY[6]; int m_iSizePoint; COLORREF m_Couleur; LOGFONT m_logfont; char m_chTexte[500]; public: CODD_Texte(); };

438

Annexe

Ces classes ne contiennent pas de mthodes. La classe CODD regroupe lensemble des mthodes de manipulation des objets graphiques, quelque soit leur type :
class CODD { public: BOOL m_bValid; int m_iType; //--- type (texte, rectangle, ...) int m_iGroupe; int m_iXbCarte; //--- position de l'objet dans la carte int m_iYbCarte; int m_iXhCarte; int m_iYhCarte; double m_dAngle; //--- angle de rotation,sens trigo, en radian LPVOID m_lpODD; //--- pointeur vers un ODD public: CODD(); void Deplacer(int iX,int iY); int Dupliquer(int iX,int iY); void Modifier(int iAction,int iX,int iY); void Symetrie(BOOL bVertical=TRUE); void Rotation(double dAngle); void Couleur(COLORREF Couleur,BOOL bInterieur=TRUE); void Trait(int iType,double dEpaisseur,COLORREF Couleur); void Taille(int iX1,int iY1,int iX2,int iY2); int Lire(FILE* Fichier); BOOL Ecrire(FILE* Fichier); };

A.2.4.3. Les classes CGroupe et CSelection Les classes CGroupe et CSelection permettent de grer le groupement dobjets graphiques et de manipuler les objets graphiques sur lcran.
class CGroupes { private: BOOL m_bOccupe[NB_MAX_GROUP]; public: int m_iXbCarte[NB_MAX_GROUP]; int m_iYbCarte[NB_MAX_GROUP]; int m_iXhCarte[NB_MAX_GROUP]; int m_iYhCarte[NB_MAX_GROUP]; public: void Init(void); int Nouveau(void); int NbObjets(int iNoGroupe); BOOL IsOccupe(int iNoGroupe) {return m_bOccupe[iNoGroupe];}; void TailleDesCadres(); void TailleDesObjets(); };

La variable m_iGroupe de CODD donne le numro du groupe auquel appartient lobjet.

class CSelection { public: int m_iNb; int m_iNoDuGroupe[NB_MAX_SELECTION]; int m_iFirst; public: BOOL IsPointInside(int iXVue,int iYVue); void RectangleCarte(int& iXb,int& iYb,int& iXh,int& iYh); CRect RectangleVue(); };

Structures et mthodes : implmentation 439 La variable m_iNoDuGroupe est un tableau qui donne lensemble des groupes dobjets graphiques slectionns sur lcran. A.2.4.4. La classe CCadre La classe CCadre est une des plus importantes du module SAVANE. Elle dcrit un cadre gographique. Elle contient des variables dcrivant lapparence graphique du cadre (position dans la carte, type bord, chelle, amorces gographiques, etc.), et des variables dcrivant la requte sur la base de donnes (m_pWind, m_pSchema, etc.) :
class CCadre { private: //--- carte propritaire CCarte* m_pCarte; //--- wind et projection, schma d'interrogation SGBD, macro, explorateur CProjection* m_pProjection; CWind* m_pWind; CSchema* m_pSchema; CMacro* m_pMacro; CMacro* m_pMacroCadre; CCartExplorateur* m_pExplorateur; CDialogStatExplorateur* m_pDlgStatExplorateur; public: //--- fenetre du cadre en projection, normalement identique la fenetre wind double m_dFgxb; double m_dFgyb; double m_dFgxh; double m_dFgyh; //--- proprits de dessin du cadre int m_iType; int m_iXDansCarte; int m_iYDansCarte; double m_dEchelle; //--- echelle en metre du cadre geo dans la carte double m_dEchelleMM; //--- echelle en mm/100 du cadre geo dans la carte double m_dUnite; //--- unite pour le bord et la legende (metres) //--- amorces de projection BOOL m_bAmorcesProj; double m_dAmorcesProjIntervalle; int m_iAmorcesProjLignes; double m_dAmorcesProjEpaisseur; COLORREF m_couleurAmorcesProj; BOOL m_bAmorcesProjTexte; LOGFONT m_logfontAmorcesProj; COLORREF m_couleurAmorcesProjTexte; int m_iAmorcesProjSizeFont; //--- amorces geographiques BOOL m_bAmorcesGeo; int m_iAmorcesGeoDeg; int m_iAmorcesGeoMin; int m_iAmorcesGeoSec; int m_iAmorcesGeoLignes; double m_dAmorcesGeoEpaisseur; COLORREF m_couleurAmorcesGeo; BOOL m_bAmorcesGeoTexte; LOGFONT m_logfontAmorcesGeo; COLORREF m_couleurAmorcesGeoTexte; int m_iAmorcesGeoSizeFont; //--- amorces de coin BOOL m_bAmorcesCoin; LOGFONT m_logfontAmorcesCoin; COLORREF m_couleurAmorcesCoin; int m_iAmorcesCoinSizeFont; public: char m_chNom[_MAX_PATH]; //--- nom du rpertoire de sauvegarde pour le cadre public:

440

Annexe
CCadre(CCarte* pCarte,int iNoCadre); CCadre(CCarte* pCarte,int iNoCadre,BOOL bMemeBase,FILE* Fichier); ~CCadre(); CCarte* GetCarte() {return m_pCarte;}; CProjection* GetProjection() {return m_pProjection;}; CWind* GetWind() {return m_pWind;}; CSchema* GetSchema() {return m_pSchema;}; CMacro* GetMacro() {return m_pMacro;}; CMacro* GetMacroCadre() {return m_pMacroCadre;}; CCartExplorateur* GetExplorateur() {return m_pExplorateur;}; CDialogStatExplorateur* GetDlgStatExplorateur() {return m_pDlgStatExplorateur;}; //--- procdures de changement de repre void SavToProj(float fSavX,float fSavY,double& dProjX,double& dProjY); void SavToRas(float fSavX,float fSavY,float& fRasX,float& fRasY); void SavToRas(float fXSav,float fYSav,int& iXRas,int& iYRas); void SavToCarte(float fSavX,float fSavY,int& iCarteX,int& iCarteY); void SavToVue(float fSavX,float fSavY,int& iVueX,int& iVueY,int iPrint); void void void void ProjToSav(double dProjX,double dProjY,float& fSavX,float& fSavY); ProjToCarte(double dProjX,double dProjY,int& iCarteX,int& iCarteY); ProjToVue(double dProjX,double dProjY,int& iVueX,int& iVueY); ProjToVue(double dProjX,double dProjY,int& iVueX,int& iVueY,int iPrint);

void VueToSav(int iVueX,int iVueY,float& fSavX,float& fSavY); void VueToProj(int iVueX,int iVueY,double& dProjX,double& dProjY); void VueToRas(int iVueX,int iVueY,float& fRasX,float& fRasY); void RasToVue(float fRasX,float fRasY,int& iVueX,int& iVueY); void RasToSav(float fRasX,float fRasY,float& fSavX,float& fSavY); void void void void void void Unite(); ReAjuster(); Effacer(); ToutEffacer(); TracerBord(CDC* pDC); CoordonneesDansLaVue(int& iXb,int& iYb,int& iXh,int& iYh,int iPrint=0);

};

La classe contient des mthodes permettant de changer de repre, entre coordonnes gographiques, coordonnes de projection, coordonnes carte, coordonnes cran ou imprimante. Par exemple, voici l'implmentation de la fonction GeoToVue, permettant de passer des coordonnes gographiques d'un point sa position dans la vue (cran ou imprimante) :
void CCadre::GeoToVue(double dXGeo,double dYGeo,int& iVueX,int& iVueY,int iPrint) { double dX,dY; GeoToProj(dXGeo,dYGeo,dX,dY); if(iPrint) { dX=((double)m_iXDansCarte)+((dX-m_dFgxb)*m_dEchelleMM); dY=((double)m_iYDansCarte)+((dY-m_dFgyb)*m_dEchelleMM); iVueX=(int) (dX*carte.m_dMMToPrint); iVueY=(int) ((dY - carte.m_iHauteur)*carte.m_dMMToPrint); if(config.m_bMetaFile)iVueY=-iVueY; if(iVueX > INFINI)iVueX=INFINI;else if(iVueX < -INFINI)iVueX=-INFINI; if(iVueY > INFINI)iVueY=INFINI;else if(iVueY < -INFINI)iVueY=-INFINI; } else { dX=((double)m_iXDansCarte)+((dX-m_dFgxb)*m_dEchelleMM); dY=((double)m_iYDansCarte)+((dY-m_dFgyb)*m_dEchelleMM); iVueX= (int) ((dX - (double)carte.m_iXVueDansCarte)*carte.m_dCoef); iVueY=config.m_iVueHauteurRes-1 -(int) ((dY(double)carte.m_iYVueDansCarte)*carte.m_dCoef); if(iVueX > INFINI)iVueX=INFINI;else if(iVueX < -INFINI)iVueX=-INFINI; if(iVueY > INFINI)iVueY=INFINI;else if(iVueY < -INFINI)iVueY=-INFINI; } }

Structures et mthodes : implmentation 441 Un certain nombre de procdures globales permettent de passer dun systme de coordonnes un autre. Par exemple, la procdure globale permettant de passer des coordonnes carte aux coordonnes vue est la suivante :
void CarteToVue(int iCarteX,int iCarteY,int& iVueX,int& iVueY,int iPrint) { if(iPrint) { iVueX=(int) (iCarteX*carte.m_dMMToPrint); iVueY=(int) ((iCarteY - carte.m_iHauteur)*carte.m_dMMToPrint); } else { iVueX= (int) ((double)(iCarteX - carte.m_iXVueDansCarte)*carte.m_dCoef); iVueY=config.m_iVueHauteurRes-1 - (int) ((double)(iCarteY carte.m_iYVueDansCarte)*carte.m_dCoef); } if(iVueX > INFINI)iVueX=INFINI;else if(iVueX < -INFINI)iVueX=-INFINI; if(iVueY > INFINI)iVueY=INFINI;else if(iVueY < -INFINI)iVueY=-INFINI; }

A.2.4.5. La classe CCartExplorateur La classe CCartExplorateur correspond lexplorateur cartographique dun cadre. Elle regroupe lensemble des informations permettant de dessiner dans un cadre partir des objets de la base de donnes. Les paramtres de dessin sont contenus dans les variables membres de type CDessin, que nous allons dcrire au paragraphe suivant. La classe CCartExplorateur permet surtout de grer la liste des relations, masques, ou fonds graphiques dessiner. A chaque entre correspondent un objet de chaque type dimplantation graphique (CDessinPixel, CDessinZone, ) contenant les paramtres reliant base de donnes et variables visuelles, et que nous prsenterons dans le paragraphe suivant.
class CCartExplorateur { public: CDessinPixel* m_pDessinPixel[NB_MAX_DESSIN]; CDessinZone* m_pDessinZone[NB_MAX_DESSIN]; CDessinLigne* m_pDessinLigne[NB_MAX_DESSIN]; CDessinSymbole* m_pDessinSymbole[NB_MAX_DESSIN]; CDessinMasque* m_pDessinMasque[NB_MAX_DESSIN]; CDessinFond* m_pDessinFond[NB_MAX_DESSIN]; int m_iType[NB_MAX_DESSIN]; char m_chNom[NB_MAX_DESSIN][100]; BOOL m_btabTracer[NB_MAX_DESSIN]; private: CCadre* m_pCadre; int m_iNbEntree; public: CCartExplorateur(CCadre* pCadre); CCartExplorateur(CCadre* pCadre,FILE* Fichier); ~CCartExplorateur(); void Ecrire(FILE* Fichier); void AjouterUneRelation(int iNoth); void AjouterUnMasque(const char *chNomMasque); void AjouterUnFond(const char *chNomFond); void SupprimerUneEntree(int iIndex); int GetNbEntree() {return m_iNbEntree;}; CCadre* GetCadre() {return m_pCadre;}; BOOL IsRelationInside(const char* chNomRelation); BOOL IsRelationInside(int iNoth); void MiseAJour(); void TracerUneEntree(CDC* pDC,int iIndex);

442

Annexe
void ExporterUneEntreeEnBMP(int iIndex,const char* chNomFichierBMP); void ToutTracer(CDC* pDC);

};

A.2.4.6. Les classes CDessin Les classes CDessin correspondent aux diffrentes implantations graphiques en cartographie (par pixel, par zone, par ligne, par point). Chaque objet contient lensemble des paramtres permettant de relier les valeurs des objets de la relation dessiner et les variables visuelles choisies par lutilisateur. Ces classes contiennent donc de trs nombreuses variables. Elles contiennent galement les mthodes de trac ou dimpression, ainsi que les procdures de srialisation de lensemble des paramtres.
class CDessinPixel { //--- classe pour le dessin de pixel private: CCadre* m_pCadre; public: char m_chNomRelation[100]; //--- type de dessin (palette, valeurs, illumination, rvb) int m_iDessin; //--- attribut tracer int m_iNoatt; char m_chNomAttribut[100]; //--- trac par palette int m_iPalNbValeurs; char m_chPalValeurs[TAILLE_PALETTE_VALEUR][NB_MAX_CHARACTER]; int m_iPalTrame[TAILLE_PALETTE_VALEUR]; int m_iPalCouleur[TAILLE_PALETTE_VALEUR]; //--- trac par valeur float m_fA; float m_fB; int m_iIndexDeCouleur1; int m_iIndexDeCouleur2; int m_iIndexDeTrame; int m_iEtalement; //--- trac par illumination int m_iIllumOrientation; //--- en degr int m_iIllumInclinaison; double m_dIllumFacteur; //--- trac avec estompage int m_iEstompage; char m_chNomRelationEstompage[100]; char m_chNomAttributEstompage[100]; int m_iInclinaisonEstompage; int m_iOrientationEstompage; double m_dFacteurEstompage; private: void TracerPalette(CDC* pDC); void TracerValeur(CDC* pDC); void TracerIllum(CDC* pDC); void TracerRVB(CDC* pDC); void ImprimerPalette(CDC* pDC); void ImprimerValeur(CDC* pDC); void ImprimerIllum(CDC* pDC); void ImprimerRVB(CDC* pDC); void TracerPaletteRaster(CDC* pDC); void TracerValeurRaster(CDC* pDC); void TracerIllumRaster(CDC* pDC); void TracerRVBRaster(CDC* pDC); void ExporterPalette(const char* chNomFichier); void ExporterValeur(const char* chNomFichier); void ExporterIllum(const char* chNomFichier); void ExporterRVB(const char* chNomFichier); public: CDessinPixel(CCadre* pCadre); void Lire(FILE* Fichier);

Structures et mthodes : implmentation 443

void Ecrire(FILE* Fichier); void Tracer(CDC* pDC); void TracerRaster(CDC* pDC); void Exporter(const char* chNomFichierBmp); CCadre* GetCadre() {return m_pCadre;}; BOOL MiseAJour();

};

class CDessinZone { //--- classe pour le dessin de zones et contours de zones private: CCadre* m_pCadre; public: //--- attributs gnraux char m_chNomRelation[100]; //--- attributs pour le trac de zones par plages //--- type de dessin (palette, valeurs) int m_iDessinPlage; int m_iTypeDessinPlage; int m_iNoattPlage; char m_chNomAttributPlage[100]; //--- trac par palette int m_iPalNbValeursPlage; char m_chPalValeursPlage[TAILLE_PALETTE_VALEUR][NB_MAX_CHARACTER]; int m_iPalTramePlage[TAILLE_PALETTE_VALEUR]; int m_iPalCouleurPlage[TAILLE_PALETTE_VALEUR]; //--- trac par valeurs float m_fAPlage; float m_fBPlage; int m_iIndexDeCouleur1Plage; int m_iIndexDeCouleur2Plage; int m_iIndexDeTrame1Plage; int m_iIndexDeTrame2Plage; int m_iEtalementPlage; //--- trac par trame float m_fATrame; float m_fBTrame; int m_iMotifTrame; int m_iIntervalle1Trame; int m_iEpaisseur1Trame; int m_iIntervalle2Trame; int m_iEpaisseur2Trame; COLORREF m_CouleurTrame; //--- trac avec estompage int m_iEstompage; char m_chNomRelationEstompage[100]; char m_chNomAttributEstompage[100]; int m_iInclinaisonEstompage; int m_iOrientationEstompage; double m_dFacteurEstompage; //--- attributs pour le trac des contours des zones //--- type de dessin (rien, tout, attribut) int m_iDessinContour; int m_iIndexDeCouleurContour; double m_dEpaisseurContour; //--- en mm/100 int m_iTypeDeTraitContour; int m_iNoattContour; char m_chNomAttributContour[100]; int m_bDessinArcEgalite; int m_bDessinArcDifference; int m_iIndexDeCouleurContourEgalite; double m_dEpaisseurContourEgalite; int m_iTypeDeTraitContourEgalite; int m_iIndexDeCouleurContourDifference; double m_dEpaisseurContourDifference; int m_iTypeDeTraitContourDifference; private: void TracerPlage(CDC* pDC); void TracerPlageRaster(CDC* pDC,int iModeSuperposition,CPerspective* pPerspective); void TracerParEstompage(CDC* pDC); void TracerContours(CDC* pDC);

444

Annexe

void ImprimerPlage(CDC* pDC); void ImprimerParEstompage(CDC* pDC); void ImprimerZones(CDC* pDC); BOOL ImprimerUneZone(CDC* pDC,FILE* FileArc,COLORREF couleur,int iTrame,int iNbarc,int* itabPtrarc); public: CDessinZone(CCadre* pCadre); void Lire(FILE* Fichier); void Ecrire(FILE* Fichier); void Tracer(CDC* pDC); void TracerRaster(CDC* pDC,int iModeSuperposition,CPerspective* pPerspective); CCadre* GetCadre() {return m_pCadre;}; BOOL MiseAJour(); void ExporterParEstompage(const char* chNomFichier); }; class CDessinLigne { //--- classe pour le dessin de ligne private: CCadre* m_pCadre; public: //--- attributs gnraux char m_chNomRelation[100]; int m_iDessin; //--- tous les objets identiques COLORREF m_Couleur; int m_iTypeDeTrait; double m_dEpaisseur; //--- courbes de niveaux int m_iTrace1Courbe; int m_iTrace2Courbe; double m_dIntervalle1Courbe; double m_dIntervalle2Courbe; double m_dEpaisseur1Courbe; //--- en mm/100 double m_dEpaisseur2Courbe; //--- en mm/100 COLORREF m_Couleur1Courbe; COLORREF m_Couleur2Courbe; int m_iTraceDesValeurs1Courbe; int m_iTraceDesValeurs2Courbe; COLORREF m_CouleurTexte1Courbe; COLORREF m_CouleurTexte2Courbe; LOGFONT m_logfontTexte1Courbe; LOGFONT m_logfontTexte2Courbe; int m_iSizePointTexte1Courbe; //--- taille en points int m_iSizePointTexte2Courbe; //--- taille en points //--- paisseur par attribut numrique, couleur et type constant (ou venant du nominal si existe) int m_iNoattNum; char m_chNomAttributNum[100]; float m_fA; float m_fB; int m_iEtalement; double m_dEpaisseur1; //--- en mm/100 double m_dEpaisseur2; //--- en mm/100 //--- couleur, type, epaisseur par attribut nominal (epaisseur venant du numerique si existe) int m_iNoattNom; char m_chNomAttributNom[100]; int m_iPalNbValeurs; char m_chtabPalValeurs[TAILLE_PALETTE_VALEUR][NB_MAX_CHARACTER]; int m_tabPalCouleur[TAILLE_PALETTE_VALEUR]; int m_itabPalType[TAILLE_PALETTE_VALEUR]; double m_dtabPalEpaisseur[TAILLE_PALETTE_VALEUR]; public: CDessinLigne(CCadre* pCadre); void Lire(FILE* Fichier); void Ecrire(FILE* Fichier); void Tracer(CDC* pDC); CCadre* GetCadre() {return m_pCadre;}; BOOL MiseAJour(); }; class CDessinSymbole { //--- classe pour le dessin de symboles et de valeurs

Structures et mthodes : implmentation 445

private: CCadre* m_pCadre; void TracerSymboles(CDC* pDC); void TracerValeurs(CDC* pDC); void TracerDiagrammes(CDC* pDC); public: char m_chNomRelation[100]; //--- attributs gnraux pour les symboles int m_iNoSymbole; double m_dEpaisseurSymbole; double m_dTailleSymbole; int m_iTrameSymbole; COLORREF m_CouleurIntSymbole; COLORREF m_CouleurExtSymbole; int m_iDetourageSymbole; int m_iTriSymbole; //--- attributs pour le dessin de symboles int m_iDessinSymbole; int m_iNoattNomSymbole; int m_iNoattNumSymbole; char m_chNomAttributNomSymbole[100]; char m_chNomAttributNumSymbole[100]; //--- trac par palette de valeur pour l'attribut nominal ou l'attribut nominal associ int m_iPalNbValeurs; char m_chtabPalValeurs[TAILLE_PALETTE_VALEUR][NB_MAX_CHARACTER]; int m_itabPalNoSymbole[TAILLE_PALETTE_VALEUR]; double m_dtabPalEpaisseur[TAILLE_PALETTE_VALEUR]; //--- taille en mm/100 double m_dtabPalTaille[TAILLE_PALETTE_VALEUR]; //--- taille en mm/100 int m_itabPalTrame[TAILLE_PALETTE_VALEUR]; COLORREF m_tabPalCouleurInt[TAILLE_PALETTE_VALEUR]; COLORREF m_tabPalCouleurExt[TAILLE_PALETTE_VALEUR]; //--- trac par valeurs pour attribut numrique int m_iEtalementSymbole; int m_iProportionaliteSymbole; float m_fASymbole; float m_fBSymbole; float m_fCSymbole; double m_dTailleMinSymbole; double m_dTailleMaxSymbole; double m_dTaillePourCSymbole; //--- attributs pour le dessin de valeurs int m_iDessinTexte; int m_iNoattTexte; char m_chNomAttributTexte[100]; COLORREF m_CouleurTexte; LOGFONT m_logfontTexte; int m_iSizePointTexte; //--- taille en points int m_iXDeplacementTexte; int m_iYDeplacementTexte; int m_iNbCaracteresTexte; int m_iDebutTexte; int m_iNbDecimalesTexte; BOOL m_bConditionTexte; char m_chConditionTexte[100]; //--- Attributs pour le dessin de diagrammes sectoriels int m_iDessinDiagrammes; int m_iNbAttributDiagrammes; char m_chtabNomAttributDiagrammes[NB_MAX_ATTRIBUTS][100]; COLORREF m_tabCouleurDiagrammes[NB_MAX_ATTRIBUTS]; COLORREF m_CouleurDuBordDiagrammes; int m_iTypeDeTailleDiagrammes; char m_chNomAttributTailleDiagrammes[100]; float m_fCDiagrammes; double m_dTaillePourCDiagrammes; int m_iEtalementValeursDiagrammes; int m_iEtalementTailleDiagrammes; public: CDessinSymbole(CCadre* pCadre); void Lire(FILE* Fichier); void Ecrire(FILE* Fichier); void Tracer(CDC* pDC); CCadre* GetCadre() {return m_pCadre;}; BOOL MiseAJour(); };

446

Annexe

class CDessinMasque { //--- classe pour le dessin de masque private: CCadre* m_pCadre; BOOL ImprimerUneZone(CDC* pDC,FILE* FileArc,COLORREF couleur,int iTrame,int iNbarc,int* itabPtrarc); public: //--- attributs gnraux char m_chNom[100]; int m_bContour; int m_bInterieur; int m_bExterieur; int m_iIndexDeCouleurTrait; int m_iTypeDeTrait; double m_dEpaisseurTrait; int m_iIndexDeCouleurInterieur; int m_iTrameInterieur; int m_iIndexDeCouleurExterieur; int m_iTrameExterieur; public: CDessinMasque(CCadre* pCadre); void Lire(FILE* Fichier); void Ecrire(FILE* Fichier); void Tracer(CDC *pDC); void TracerPlage(CDC *pDC); void ImprimerPlage(CDC *pDC); void TracerRaster(CDC *pDC,int iModeSuperposition,CPerspective* pPerspective); CCadre* GetCadre() {return m_pCadre;}; BOOL MiseAJour(); }; class CDessinFond { //--- classe pour le dessin de fond graphique private: CCadre* m_pCadre; public: //--- attributs gnraux char m_chNom[100]; int m_bNiveau[256]; public: CDessinFond(CCadre* pCadre); void Lire(FILE* Fichier); void Ecrire(FILE* Fichier); void Tracer(CDC *pDC); CCadre* GetCadre() {return m_pCadre;}; BOOL MiseAJour(); };

Par exemple, la classe CDessinPixel permet de tracer ou dimprimer une relation de type mosaque. Les procdures de tracer sur cran sont quelque peu diffrentes des procdures de trac sur imprimante : le trac sur cran se fait pixel par pixel, alors que limpression utilise des procdures de la MFC pour la gestion des DIB (StretchDibBits()). Les procdures de trac ou dimpression sont diffrentes selon le type de lattribut reprsenter : si lattribut tracer est nominal, la procdure TracerPalette() sera utilise pour affecter chaque pixel la couleur et la trame dfinies par lutilisateur dans la palette de valeur. TracerValeur() est utilise pour le trac dun attribut numrique (sans palette de valeurs), TracerIllum() pour tracer un attribut numrique par illumination, TracerRVB() pour tracer un attribut de type RVB. Par exemple, voici le code de la procdure TracerIllum() :

Structures et mthodes : implmentation 447

void CDessinPixel::TracerIllum(CDC* pDC) { //--- paramtres double dPI=acos(-1.); int iPrint=config.IsPrinting(pDC); CSchema* pSchema=m_pCadre->GetSchema(); int iNoth=pSchema->RelRecherche(m_chNomRelation); if(iNoth == 0)return; int iNoatt=pSchema->AttrRecherche(iNoth,m_chNomAttribut); if(iNoatt == 0)return; FILE *FileMosaic; FILE *FileFeuille; FILE *FileImage; int iMosaiqueNbcol,iMosaiqueNblig; double dMosaiqueResolution; int iTypeAttribut,iDatasize; int iLargeur,iHauteur,iX,iY; int iVueX,iVueY; int iImageX,iImageY,iPrecedentY; int i,iColor,no,nbcol,nblig; int ptr,ptrdeb,ptrlib; double dAvanceX,dAvanceY,dFacteur; double d1,d2,dZmin,dZmax; double dXbf,dYbf,dXhf,dYhf; char chNomFichierFeuille[_MAX_PATH]; char chNomFichierMosaique[_MAX_PATH]; char chNomFichierAttribut[_MAX_PATH]; BYTE bColor; unsigned char cval1,cval2,cval3,cval4; short int sval1,sval2,sval3,sval4; float fval1,fval2,fval3,fval4; double dCol,dSol,dCil,dSil,dNxl,dNyl,dNzl; double dA,dB,dNx,dNy,dNz,dNz2,dTeta,dNorme,dAngle; unsigned char *bufima1,*bufima2; //--- coordonnees du cadre double dCadreXbProj,dCadreYbProj,dCadreXhProj,dCadreYhProj; int iCadreXbVue,iCadreYbVue,iCadreXhVue,iCadreYhVue; //--- coordonnees de l'imagette double dImagetteXbProj,dImagetteYbProj,dImagetteXhProj,dImagetteYhProj; int iImagetteXbVue,iImagetteYbVue,iImagetteXhVue,iImagetteYhVue; double dImagetteXbImage,dImagetteYbImage; int iImagetteXbImage,iImagetteYbImage; strcpy(chNomFichierMosaique,pSchema->m_pRelations[iNoth]->m_chFichZone); strcat(chNomFichierMosaique,"\\"); strcat(chNomFichierMosaique,pSchema->m_pRelations[iNoth]->m_chNom); strcat(chNomFichierMosaique,"_d"); //--- lecture des parametres de la mosaique FileMosaic=OuvrirMosaique(pSchema,chNomFichierMosaique,iNoth); ::SetCursor(LoadCursor(NULL, IDC_WAIT)); if(FileMosaic != NULL) { fscanf(FileMosaic,"%lf",&dMosaiqueResolution); fscanf(FileMosaic,"%d",&iMosaiqueNbcol); fscanf(FileMosaic,"%d",&iMosaiqueNblig); fclose(FileMosaic); } else return; int iTemporaire=pSchema->m_pRelations[iNoth]->m_pAttributs[iNoatt]->m_iTemporaire; if(iTemporaire) { strcpy(chNomFichierAttribut,carte.m_chNomDir); strcat(chNomFichierAttribut,"\\"); strcat(chNomFichierAttribut,m_pCadre->m_chNom); strcat(chNomFichierAttribut,"\\ft"); strcat(chNomFichierAttribut,pSchema->m_pRelations[iNoth]->m_chNom); strcat(chNomFichierAttribut,"_"); strcat(chNomFichierAttribut,pSchema->m_pRelations[iNoth]->m_pAttributs[iNoatt]->m_chNom); } else { strcpy(chNomFichierAttribut,pSchema->m_pRelations[iNoth]->m_chFichZone);

448

Annexe
strcat(chNomFichierAttribut,"\\"); strcat(chNomFichierAttribut,pSchema->m_pRelations[iNoth]->m_pAttributs[iNoatt]->m_chNom); }

strcpy(chNomFichierFeuille,chNomFichierAttribut); strcat(chNomFichierFeuille,"_f"); FileFeuille=fopen(chNomFichierFeuille,"rb"); FileImage=fopen(chNomFichierAttribut,"rb"); if(FileImage == NULL || FileFeuille == NULL) { if(FileImage != NULL)fclose(FileImage); if(FileFeuille != NULL)fclose(FileFeuille); return; } //--- caracteristiques du cadre dans la vue dCadreXbProj=m_pCadre->m_dFgxb; dCadreYbProj=m_pCadre->m_dFgyb; dCadreXhProj=m_pCadre->m_dFgxh; dCadreYhProj=m_pCadre->m_dFgyh; iLargeur=(int) ((dCadreXhProj-dCadreXbProj)*m_pCadre->m_dEchelleMM); iHauteur=(int) ((dCadreYhProj-dCadreYbProj)*m_pCadre->m_dEchelleMM); ::CarteToVue(m_pCadre->m_iXDansCarte,m_pCadre>m_iYDansCarte,iCadreXbVue,iCadreYbVue,iPrint); iX=m_pCadre->m_iXDansCarte + iLargeur; iY=m_pCadre->m_iYDansCarte + iHauteur; ::CarteToVue(iX,iY,iCadreXhVue,iCadreYhVue,iPrint); ::Ordonner(iCadreYbVue,iCadreYhVue); if(iCadreXhVue < 0 || iCadreXbVue >= config.m_iVueLargeurRes || iCadreYhVue < 0 || iCadreYbVue >= config.m_iVueHauteurRes) { fclose(FileImage); fclose(FileFeuille); return; } if((iCadreXhVue-iCadreXbVue) == 0 || (iCadreYhVue-iCadreYbVue) == 0) { fclose(FileImage); fclose(FileFeuille); return; } //--- allocation memoire iDatasize=1; iTypeAttribut=pSchema->m_pRelations[iNoth]->m_pAttributs[iNoatt]->m_iType; if(iTypeAttribut == 1 || iTypeAttribut == 5 || iTypeAttribut == 6)iDatasize=1; else if(iTypeAttribut == 7)iDatasize=2; else if(iTypeAttribut == 8)iDatasize=3; else if(iTypeAttribut == 9)iDatasize=4; bufima1=(unsigned char *) malloc(iMosaiqueNbcol*iDatasize); bufima2=(unsigned char *) malloc(iMosaiqueNbcol*iDatasize); if(bufima1 == NULL || bufima2 == NULL) { ::ErreurDeMemoire(); if(bufima1 != NULL)free(bufima1); if(bufima2 != NULL)free(bufima2); fclose(FileImage); fclose(FileFeuille); return; } //--- facteur de lecture double dFpix; d1=(dCadreXhProj-dCadreXbProj)/((double)(iCadreXhVue-iCadreXbVue)); d2=(dCadreYhProj-dCadreYbProj)/((double)(iCadreYhVue-iCadreYbVue)); if(d1 < d2)dFpix=d2; else dFpix=d1; dFacteur=dFpix/dMosaiqueResolution; //--- parametres de visualisation dAngle=(double) m_iIllumOrientation; dAngle=dAngle+90.; //--- pour rattraper mon erreur... if(dAngle > 360.)dAngle=dAngle-360.; dAngle = (dAngle/180.)*dPI; dCol= cos(dAngle);

Structures et mthodes : implmentation 449

dSol= sin(dAngle); dAngle = (double) (m_iIllumInclinaison/180.)*dPI; dCil = cos(dAngle); dSil = sin(dAngle); dNxl=dCil*dSol; dNyl=(-1.)*dCil*dCol; dNzl=dSil; dNz= 2.*dMosaiqueResolution/m_dIllumFacteur; dNz2=dNz*dNz; //--- lecture des feuilles BOOL bInconnu; fscanf(FileFeuille,"%2d%20d%*c",&i,&ptrlib); while(fscanf(FileFeuille,"%2d%20lf%20lf%10d%10d%20lf%20lf%20d%*c", &no,&dXbf,&dYbf,&nbcol,&nblig,&dZmin,&dZmax,&ptrdeb) == 8) { if(no != 0) { dXhf=dXbf + (dMosaiqueResolution*(double) iMosaiqueNbcol); dYhf=dYbf + (dMosaiqueResolution*(double) iMosaiqueNblig); if(dXhf >= dCadreXbProj && dXbf <= dCadreXhProj && dYhf >= dCadreYbProj && dYbf <= dCadreYhProj) { //--- au moins un bout de l'imagette dans le cadre m_pCadre->ProjToVue(dXbf,dYbf,iImagetteXbVue,iImagetteYbVue); m_pCadre->ProjToVue(dXhf,dYhf,iImagetteXhVue,iImagetteYhVue); ::Ordonner(iImagetteYbVue,iImagetteYhVue); if(iImagetteXbVue if(iImagetteXhVue if(iImagetteYbVue if(iImagetteYhVue < > < > iCadreXbVue)iImagetteXbVue=iCadreXbVue; iCadreXhVue)iImagetteXhVue=iCadreXhVue; iCadreYbVue)iImagetteYbVue=iCadreYbVue; iCadreYhVue)iImagetteYhVue=iCadreYhVue;

if(iImagetteXhVue >= 0 && iImagetteXbVue < config.m_iVueLargeurRes && iImagetteYhVue >= 0 && iImagetteYbVue < config.m_iVueHauteurRes) { //--- au moins un bout de l'imagette dans la vue if(iImagetteXbVue < 0)iImagetteXbVue=0; if(iImagetteXhVue >= config.m_iVueLargeurRes)iImagetteXhVue=config.m_iVueLargeurRes-1; if(iImagetteYbVue < 0)iImagetteYbVue=0; if(iImagetteYhVue >= config.m_iVueHauteurRes)iImagetteYhVue=config.m_iVueHauteurRes-1; //--- coordonnes du trac en projection m_pCadre>VueToProj(iImagetteXbVue,iImagetteYhVue,dImagetteXbProj,dImagetteYbProj); m_pCadre>VueToProj(iImagetteXhVue,iImagetteYhVue,dImagetteXhProj,dImagetteYhProj); ::Ordonner(dImagetteYbProj,dImagetteYhProj); //--- coordonnes du trac dans l'image if(dXbf >= dImagetteXbProj)dImagetteXbImage=0.; else dImagetteXbImage=(dImagetteXbProj - dXbf)/dMosaiqueResolution; if(dYbf >= dImagetteYbProj)dImagetteYbImage=0.; else dImagetteYbImage=(dImagetteYbProj - dYbf)/dMosaiqueResolution; iImagetteXbImage=(int) (dImagetteXbImage); iImagetteYbImage=(int) (dImagetteYbImage); //--- trac de l'image dAvanceY=dImagetteYbImage - (double)iImagetteYbImage; iImageY=0; iPrecedentY=-1; int iNbcolALire=nbcol-iImagetteXbImage; iVueY=iImagetteYhVue; while(iVueY >= iImagetteYbVue && iImageY < nblig) { //--- lire la ligne if(iImageY != iPrecedentY) { if(iImageY < nblig-1) { ptr=ptrdeb+(iImagetteXbImage+(iImageY*nbcol))*iDatasize; fseek(FileImage,ptr,SEEK_SET); fread(bufima1,iNbcolALire,iDatasize,FileImage); ptr=ptrdeb+(iImagetteXbImage+((iImageY+1)*nbcol))*iDatasize;

450

Annexe
fseek(FileImage,ptr,SEEK_SET); fread(bufima2,iNbcolALire,iDatasize,FileImage); } else { ptr=ptrdeb+(iImagetteXbImage+((iImageY-1)*nbcol))*iDatasize; fseek(FileImage,ptr,SEEK_SET); fread(bufima1,iNbcolALire,iDatasize,FileImage); ptr=ptrdeb+(iImagetteXbImage+(iImageY*nbcol))*iDatasize; fseek(FileImage,ptr,SEEK_SET); fread(bufima2,iNbcolALire,iDatasize,FileImage); }

dAvanceX=dImagetteXbImage-(double)iImagetteXbImage; iImageX=0; iVueX=iImagetteXbVue; while(iVueX < iImagetteXhVue && iImageX < iNbcolALire-1) { bInconnu=FALSE; if(iTypeAttribut == 6) { memcpy(&cval1,&bufima1[iImageX],1); memcpy(&cval2,&bufima1[iImageX+1],1); memcpy(&cval3,&bufima2[iImageX],1); memcpy(&cval4,&bufima2[iImageX+1],1); if(cval1 == CINCONNU || cval2 == CINCONNU || cval3 == CINCONNU || cval4 == CINCONNU)bInconnu=TRUE; else { fval1=(float) cval1; fval2=(float) cval2; fval3=(float) cval3; fval4=(float) cval4; } } else if(iTypeAttribut == 7) { memcpy(&sval1,&bufima1[iImageX*iDatasize],iDatasize); memcpy(&sval2,&bufima1[(iImageX+1)*iDatasize],iDatasize); memcpy(&sval3,&bufima2[iImageX*iDatasize],iDatasize); memcpy(&sval4,&bufima2[(iImageX+1)*iDatasize],iDatasize); if(sval1 == SINCONNU || sval2 == SINCONNU || sval3 == SINCONNU || sval4 == SINCONNU)bInconnu=TRUE; else { fval1=(float) sval1; fval2=(float) sval2; fval3=(float) sval3; fval4=(float) sval4; } } else if(iTypeAttribut == 8) { bInconnu=TRUE; } else if(iTypeAttribut == 9) { memcpy(&fval1,&bufima1[iImageX*iDatasize],iDatasize); memcpy(&fval2,&bufima1[(iImageX+1)*iDatasize],iDatasize); memcpy(&fval3,&bufima2[iImageX*iDatasize],iDatasize); memcpy(&fval4,&bufima2[(iImageX+1)*iDatasize],iDatasize); if(fval1 <= FINCONNU || fval2 <= FINCONNU || fval3 <= FINCONNU || fval4 <= FINCONNU)bInconnu=TRUE; } if(bInconnu == FALSE) { dA=(double) (fval4-fval1); dB=(double) (fval2-fval3); dNx= (dB-dA); dNy= -(dA+dB); dNorme= sqrt(dNx*dNx + dNy*dNy + dNz2); dTeta= dNx*dNxl + dNy*dNyl + dNz*dNzl; dTeta= dTeta/dNorme; if(config.m_iPalette == 0) { //--- pas de palette de couleur, valeur directe de gris bColor = (BYTE) (127.*dTeta + 128.);

Structures et mthodes : implmentation 451

pDC->SetPixelV(iVueX,iVueY,RGB(bColor,bColor,bColor)); } else { iColor = (int) (PALETTE_IMAGE_MIN + 60.*dTeta +61.); pDC->SetPixelV(iVueX,iVueY,PALETTEINDEX((WORD)iColor)); } } dAvanceX+=dFacteur; iImageX=(int)dAvanceX; iVueX++; } while(iVueX < iImagetteXhVue) { pDC->SetPixelV(iVueX,iVueY,PALETTEINDEX((WORD)iColor)); iVueX++; } iPrecedentY=iImageY; dAvanceY+=dFacteur; iImageY=iImagetteYbImage + (int)dAvanceY; iVueY--; }

} free(bufima1); free(bufima2); fclose(FileImage); fclose(FileFeuille); }

Le trac de zones sur lcran utilise limage matricielle interne de la relation. La couleur et la trame de chaque pixel sont dtermines par la valeur de la zone correspondante. La vitesse du trac est ainsi trs rapide. Par contre, limpression utilise les arcs constituant le contour des objets pour conserver une prcision optimale, mais lalgorithme doit recrer le contour de chaque zone :
void CDessinZone::ImprimerZones(CDC* pDC) { if(m_iDessinPlage == 0)return; int iPrint=config.IsPrinting(pDC); if(iPrint == 0)return; if(m_iEstompage != 0 && strlen(m_chNomRelationEstompage) != 0 && strlen(m_chNomAttributEstompage) != 0) { ImprimerParEstompage(pDC); return; } pDC->SetPolyFillMode(ALTERNATE); //--- paramtres gnraux int iXb,iYb,iXh,iYh; int i,iNoth,iNoatt,iX,iY,iLargeur,iHauteur; int iCadreXbVue,iCadreYbVue,iCadreXhVue,iCadreYhVue; double dCadreXbProj,dCadreYbProj,dCadreXhProj,dCadreYhProj; CSchema* pSchema=m_pCadre->GetSchema(); CWind* pWind=m_pCadre->GetWind(); iNoth=pSchema->RelRecherche(m_chNomRelation); if(iNoth == 0)return; iNoatt=pSchema->AttrRecherche(iNoth,m_chNomAttributPlage); if(iNoatt == 0)return; //--- caracteristiques du cadre dCadreXbProj=m_pCadre->m_dFgxb; dCadreYbProj=m_pCadre->m_dFgyb; dCadreXhProj=m_pCadre->m_dFgxh; dCadreYhProj=m_pCadre->m_dFgyh;

452

Annexe

iLargeur=(int) ((dCadreXhProj-dCadreXbProj)*m_pCadre->m_dEchelleMM); iHauteur=(int) ((dCadreYhProj-dCadreYbProj)*m_pCadre->m_dEchelleMM); ::CarteToVue(m_pCadre->m_iXDansCarte,m_pCadre>m_iYDansCarte,iCadreXbVue,iCadreYbVue,iPrint); iX=m_pCadre->m_iXDansCarte + iLargeur; iY=m_pCadre->m_iYDansCarte + iHauteur; ::CarteToVue(iX,iY,iCadreXhVue,iCadreYhVue,iPrint); ::Ordonner(iCadreYbVue,iCadreYhVue); ::CarteToVue(0,0,iXb,iYb,iPrint); ::CarteToVue(carte.m_iLargeur,carte.m_iHauteur,iXh,iYh,iPrint); ::Ordonner(iYb,iYh); //--- le cadre est-il dans la carte ? if(iCadreXhVue < iXb || iCadreXbVue >= iXh || iCadreYhVue < iYb || iCadreYbVue >= iYh)return; //--- la fenetre d'etude est-elle dans le cadre ? if(pWind->m_dFhx < dCadreXbProj || pWind->m_dFlx >= dCadreXhProj || pWind->m_dFhy < dCadreYbProj || pWind->m_dFly >= dCadreYhProj)return; int iNbMaxArcParFeuille=pSchema->m_pRelations[iNoth]->NbMaxArcsParFeuille(); int* itabNz1=(int *) malloc(iNbMaxArcParFeuille*sizeof(int)); int* itabNz2=(int *) malloc(iNbMaxArcParFeuille*sizeof(int)); int* itabPtrarc=(int *) malloc(iNbMaxArcParFeuille*sizeof(int)); int* itabPtr=(int *) malloc(iNbMaxArcParFeuille*sizeof(int)); if(itabNz1 == NULL || itabNz2 == NULL || itabPtrarc == NULL || itabPtr == NULL) { ::ErreurDeMemoire(); if(itabNz1 != if(itabNz2 != if(itabPtrarc if(itabPtr != return; } NULL)free(itabNz1); NULL)free(itabNz2); != NULL)free(itabPtrarc); NULL)free(itabPtr);

BOOL bTrouve; int iSizeIdentifiantTuple; int iIndexDeCouleur,iTrame,iValeur; int nz,iNz1,iNz2; int iObjet,iNbObj,iPtrObj,iNbarc,iPtr,iArc,iPtrarc,iPtrsuiv; int iIndexMin; long lAdresse; float fU; float xc,yc,xb,yb,xh,yh; float fXb,fYb,fXh,fYh; float fValeur,v[NB_MAX_ATTRIBUTS]; char chNomValeur[128]; FILE* FileValeurs; FILE* FileFeuille; FILE* FileDescriptif; FILE* FileArc; CArc arc; int int int int int int int int iTypeRelation=pSchema->m_pRelations[iNoth]->m_iType; iTypeAttribut=pSchema->m_pRelations[iNoth]->m_pAttributs[iNoatt]->m_iType; iNb0=pSchema->m_pRelations[iNoth]->m_iNb0; iNba=pSchema->m_pRelations[iNoth]->m_iNba; iNovar=pSchema->m_pRelations[iNoth]->m_pAttributs[iNoatt]->m_iNumero; iNbcarAttr=pSchema->m_pRelations[iNoth]->m_pAttributs[iNoatt]->m_iNbcar; iNbvalb=pSchema->m_pRelations[iNoth]->m_pAttributs[iNoatt]->m_iNbvalb; iPtrval=pSchema->m_pRelations[iNoth]->m_pAttributs[iNoatt]->m_iPtrval;

FileValeurs=NULL; if(iTypeAttribut == 4) { //--- trace par valeurs numeriques iIndexMin=0; if(m_iIndexDeCouleur2Plage >= m_iIndexDeCouleur1Plage) { switch(m_iEtalementPlage) { case 0: default: fU=((float)(m_iIndexDeCouleur2Plage-m_iIndexDeCouleur1Plage))/(m_fBPlagem_fAPlage);

Structures et mthodes : implmentation 453

break; case 1: fU=((float)(m_iIndexDeCouleur2Plagem_iIndexDeCouleur1Plage))/(float)log(1.+m_fBPlage-m_fAPlage); break; case 2: fU=((float)(m_iIndexDeCouleur2Plagem_iIndexDeCouleur1Plage))/(float)sqrt(m_fBPlage-m_fAPlage); break; } iIndexMin=m_iIndexDeCouleur1Plage; } else { switch(m_iEtalementPlage) { case 0: default: fU=((float)(m_iIndexDeCouleur1Plage-m_iIndexDeCouleur2Plage))/(m_fBPlagem_fAPlage); break; case 1: fU=((float)(m_iIndexDeCouleur1Plagem_iIndexDeCouleur2Plage))/(float)log(1.+m_fBPlage-m_fAPlage); break; case 2: fU=((float)(m_iIndexDeCouleur1Plagem_iIndexDeCouleur2Plage))/(float)sqrt(m_fBPlage-m_fAPlage); break; } iIndexMin=m_iIndexDeCouleur2Plage; }

else if(iTypeAttribut == 1 || iTypeAttribut == 5) { //--- attribut nominal, trac par palette de valeurs if(iTypeAttribut == 1)FileValeurs=fopen(base.m_chNomFichierValeurs,"rb"); else FileValeurs=fopen(pSchema->m_chNomFtval,"rb"); } //--- dbut iSizeIdentifiantTuple=SIZEINT + 6*SIZECOOR; if(iTypeRelation == 4) { FileFeuille=fopen(pSchema->m_pRelations[iNoth]->m_chFichFeuille,"rb"); FileDescriptif=fopen(pSchema->m_pRelations[iNoth]->m_chFichZone,"rb"); FileArc=fopen(pSchema->m_pRelations[iNoth]->m_chFichArc,"rb"); while(fscanf(FileFeuille,"%*17c%8f%8f%8f%8f%8i%8i%8i%8i%*c",&fXb,&fYb,&fXh,&fYh,&iNbObj,&iPt rObj,&iNbarc,&iPtrarc) == 8) { if(fXh >= pWind->m_fFx1 && fXb <= pWind->m_fFx2 && fYh >= pWind->m_fFy1 && fYb <= pWind->m_fFy2) { iPtr=iPtrarc; iArc=0; while(iArc < iNbarc) { arc.LireEntete(FileArc,iPtr,iNz1,iNz2,iPtrsuiv); itabNz1[iArc]=iNz1; itabNz2[iArc]=iNz2; itabPtrarc[iArc]=iPtr; iArc++; iPtr=iPtrsuiv; } iPtr=(iPtrObj-1)*(iNb0*SIZEVAL + iSizeIdentifiantTuple); fseek(FileDescriptif,iPtr,SEEK_SET); iObjet=0; while(iObjet < iNbObj) { fread(&nz,SIZEINT,1,FileDescriptif); fread(&xc,SIZECOOR,1,FileDescriptif); fread(&yc,SIZECOOR,1,FileDescriptif); fread(&xb,SIZECOOR,1,FileDescriptif); fread(&yb,SIZECOOR,1,FileDescriptif);

454

Annexe
fread(&xh,SIZECOOR,1,FileDescriptif); fread(&yh,SIZECOOR,1,FileDescriptif); for(i=1;i <= iNb0;i++)fread(&v[i],SIZEVAL,1,FileDescriptif); iObjet++;

nz=UnixToDos(nz); xc=UnixToDos(xc); yc=UnixToDos(yc); xb=UnixToDos(xb); yb=UnixToDos(yb); xh=UnixToDos(xh); yh=UnixToDos(yh); if(xh >= pWind->m_fFx1 && xb <= pWind->m_fFx2 && yh >= pWind->m_fFy1 && yb <= pWind->m_fFy2) { for(i=1;i <= iNb0;i++)v[i]=UnixToDos(v[i]); //--- couleur et trame de la zone nz iIndexDeCouleur=-1; iTrame=m_iIndexDeTrame1Plage; if(iTypeAttribut == 4) { //--- attribut numrique fValeur=v[iNovar]; if(fValeur > FINCONNU && fValeur >= m_fAPlage && fValeur <= m_fBPlage) { switch(m_iEtalementPlage) { case 0: default: iIndexDeCouleur=int((fU*(fValeur-m_fAPlage)) + iIndexMin); break; case 1: iIndexDeCouleur=int((fU*(float)log(1+fValeur-m_fAPlage)) + iIndexMin); break; case 2: iIndexDeCouleur=int((fU*(float)sqrt(fValeur-m_fAPlage)) + iIndexMin); break; } } } else if(iTypeAttribut == 1 || iTypeAttribut == 5) { //--- attribut nominal, trac par palette de valeurs iValeur= (int) (v[iNovar] + 0.1); if(iValeur > 0) { lAdresse=(iPtrval+iValeur-2)*iNbcarAttr; fseek(FileValeurs,lAdresse,SEEK_SET); fread(chNomValeur,iNbcarAttr,1,FileValeurs); chNomValeur[iNbcarAttr]=0; strstrip(chNomValeur); } else { switch(config.m_iLangage) { case FRANCAIS: default: strcpy(chNomValeur,"valeur manquante"); break; case ESPAGNOL: strcpy(chNomValeur,"valor faltante"); break; case ANGLAIS: strcpy(chNomValeur,"unknow value"); break; } } bTrouve=FALSE; i=0; while(i < m_iPalNbValeursPlage && bTrouve == FALSE) { if(strcmp(m_chPalValeursPlage[i],chNomValeur) == 0) { bTrouve=TRUE; iIndexDeCouleur=m_iPalCouleurPlage[i]; iTrame=m_iPalTramePlage[i];

Structures et mthodes : implmentation 455

} i++; }

if(iIndexDeCouleur != -1) { //--- chainage de la zone en tches et impression int iNbarcDeLaZone=0; for(iArc=0;iArc < iNbarc;iArc++) { if(itabNz1[iArc] == nz || itabNz2[iArc] == nz) { itabPtr[iNbarcDeLaZone]=itabPtrarc[iArc]; iNbarcDeLaZone++; } } COLORREF Couleur=PALETTERGB(palette.rouge[iIndexDeCouleur],palette.vert[iIndexDeCouleur],palette.bleu[i IndexDeCouleur]); ImprimerUneZone(pDC,FileArc,Couleur,iTrame,iNbarcDeLaZone,itabPtr); } } } } } fclose(FileFeuille); fclose(FileDescriptif); fclose(FileArc); } else if(iTypeRelation == 14 || iTypeRelation == 24) { int iNo=pSchema->m_pRelations[iNoth]->m_iNoFichDescriptif; FileDescriptif=fopen(pSchema->m_chFprovDescriptif[iNo],"rb"); iNo=pSchema->m_pRelations[iNoth]->m_iNoFichArc; if(iNo == -1)FileArc=fopen(pSchema->m_pRelations[iNoth]->m_chFichArc,"rb"); else FileArc=fopen(pSchema->m_chFprovArc[iNo],"rb"); fread(&iNbarc,SIZEINT,1,FileDescriptif); fread(&iPtrarc,SIZEINT,1,FileDescriptif); while(iNbarc > 0) { //--- lire les arcs de la feuille iPtr=iPtrarc; iArc=0; while(iArc < iNbarc) { arc.LireEntete(FileArc,iPtr,iNz1,iNz2,iPtrsuiv); itabNz1[iArc]=iNz1; itabNz2[iArc]=iNz2; itabPtrarc[iArc]=iPtr; iPtr=iPtrsuiv; iArc++; } fread(&nz,SIZEINT,1,FileDescriptif); fread(&xc,SIZECOOR,1,FileDescriptif); fread(&yc,SIZECOOR,1,FileDescriptif); fread(&xb,SIZECOOR,1,FileDescriptif); fread(&yb,SIZECOOR,1,FileDescriptif); fread(&xh,SIZECOOR,1,FileDescriptif); fread(&yh,SIZECOOR,1,FileDescriptif); for(i=1;i <= iNba;i++)fread(&v[i],SIZEVAL,1,FileDescriptif); while(nz > 0) { if(xh >= pWind->m_fFx1 && xb <= pWind->m_fFx2 && yh >= pWind->m_fFy1 && yb <= pWind>m_fFy2) { //--- couleur et trame de la zone nz iIndexDeCouleur=-1; iTrame=m_iIndexDeTrame1Plage; if(iTypeAttribut == 4) { //--- attribut numrique fValeur=v[iNovar]; if(fValeur > FINCONNU && fValeur >= m_fAPlage && fValeur <= m_fBPlage) {

456

Annexe
switch(m_iEtalementPlage) { case 0: default: iIndexDeCouleur=int((fU*(fValeur-m_fAPlage)) + iIndexMin); break; case 1: iIndexDeCouleur=int((fU*(float)log(1+fValeur-m_fAPlage)) + iIndexMin); break; case 2: iIndexDeCouleur=int((fU*(float)sqrt(fValeur-m_fAPlage)) + iIndexMin); break; } }

else if(iTypeAttribut == 1 || iTypeAttribut == 5) { //--- attribut nominal, trac par palette de valeurs iValeur= (int) (v[iNovar] + 0.1); if(iValeur > 0) { lAdresse=(iPtrval+iValeur-2)*iNbcarAttr; fseek(FileValeurs,lAdresse,SEEK_SET); fread(chNomValeur,iNbcarAttr,1,FileValeurs); chNomValeur[iNbcarAttr]=0; strstrip(chNomValeur); } else { switch(config.m_iLangage) { case FRANCAIS: default: strcpy(chNomValeur,"valeur manquante"); break; case ESPAGNOL: strcpy(chNomValeur,"valor faltante"); break; case ANGLAIS: strcpy(chNomValeur,"unknow value"); break; } } bTrouve=FALSE; i=0; while(i < m_iPalNbValeursPlage && bTrouve == FALSE) { if(strcmp(m_chPalValeursPlage[i],chNomValeur) == 0) { bTrouve=TRUE; iIndexDeCouleur=m_iPalCouleurPlage[i]; iTrame=m_iPalTramePlage[i]; } i++; } } if(iIndexDeCouleur != -1) { //--- chainage de la zone en tches et impression int iNbarcDeLaZone=0; for(iArc=0;iArc < iNbarc;iArc++) { if(itabNz1[iArc] == nz || itabNz2[iArc] == nz) { itabPtr[iNbarcDeLaZone]=itabPtrarc[iArc]; iNbarcDeLaZone++; } } COLORREF Couleur=PALETTERGB(palette.rouge[iIndexDeCouleur],palette.vert[iIndexDeCouleur],palette.bleu[i IndexDeCouleur]); ImprimerUneZone(pDC,FileArc,Couleur,iTrame,iNbarcDeLaZone,itabPtr); } } fread(&nz,SIZEINT,1,FileDescriptif); fread(&xc,SIZECOOR,1,FileDescriptif);

Structures et mthodes : implmentation 457

fread(&yc,SIZECOOR,1,FileDescriptif); fread(&xb,SIZECOOR,1,FileDescriptif); fread(&yb,SIZECOOR,1,FileDescriptif); fread(&xh,SIZECOOR,1,FileDescriptif); fread(&yh,SIZECOOR,1,FileDescriptif); for(i=1;i <= iNba;i++)fread(&v[i],SIZEVAL,1,FileDescriptif); } fread(&iNbarc,SIZEINT,1,FileDescriptif); fread(&iPtrarc,SIZEINT,1,FileDescriptif); } fclose(FileDescriptif); fclose(FileArc); } if(FileValeurs != NULL)fclose(FileValeurs); free(itabNz1); free(itabNz2); free(itabPtrarc); free(itabPtr); } BOOL CDessinZone::ImprimerUneZone(CDC* pDC,FILE* FileArc,COLORREF Couleur,int iTrame,int iNbArc,int* itabPtrarc) { //--- impression d'une zone avec chainage par tche double* dtabX1=(double *) malloc(sizeof(double)*iNbArc); double* dtabY1=(double *) malloc(sizeof(double)*iNbArc); double* dtabX2=(double *) malloc(sizeof(double)*iNbArc); double* dtabY2=(double *) malloc(sizeof(double)*iNbArc); BOOL *btabLibre=(BOOL *) malloc(sizeof(BOOL)*iNbArc); BOOL *btabSens=(BOOL *) malloc(sizeof(int)*iNbArc); int *itabPtrTache=(int *) malloc(sizeof(int)*iNbArc); //--- vrification des allocations mmoire if(dtabX1 == NULL || dtabY1 == NULL || dtabX2 == NULL || dtabY2 == NULL || btabLibre == NULL || btabSens == NULL || itabPtrTache == NULL) { if(dtabX1 != NULL)free(dtabX1); if(dtabY1 != NULL)free(dtabY1); if(dtabX2 != NULL)free(dtabX2); if(dtabY2 != NULL)free(dtabY2); if(btabLibre != NULL)free(btabLibre); if(btabSens != NULL)free(btabSens); if(itabPtrTache != NULL)free(itabPtrTache); return FALSE; } //--- initialisations CArc arc; float fX1,fY1,fX2,fY2; for(int iArc=0;iArc < iNbArc;iArc++) { arc.LireBout(FileArc,itabPtrarc[iArc],fX1,fY1,fX2,fY2); dtabX1[iArc]=fX1; dtabY1[iArc]=fY1; dtabX2[iArc]=fX2; dtabY2[iArc]=fY2; btabLibre[iArc]=TRUE; } //--- bounding box de la zone int iXbZone,iYbZone,iXhZone,iYhZone; int iXbArc,iYbArc,iXhArc,iYhArc; if(iTrame > 1) { for(iArc=0;iArc < iNbArc;iArc++) { arc.LirePoints(FileArc,itabPtrarc[iArc]); arc.CalculBBox(pDC,m_pCadre,iXbArc,iYbArc,iXhArc,iYhArc); if(iArc == 0) { iXbZone=iXbArc; iYbZone=iYbArc; iXhZone=iXhArc; iYhZone=iYhArc; } else

458

Annexe
{ if(iXbArc if(iXhArc if(iYbArc if(iYhArc } < > < > iXbZone)iXbZone=iXbArc; iXhZone)iXhZone=iXhArc; iYbZone)iYbZone=iYbArc; iYhZone)iYhZone=iYhArc;

pDC->BeginPath(); //--- chainage par tche double dXDebut,dYDebut,dXFin,dYFin; int iNbTachesNonFermees=0; CTrame trame; trame.Set(iTrame); iArc=0; while(iArc < iNbArc) { //--- chainage par ring while(iArc < iNbArc && btabLibre[iArc] == FALSE)iArc++; if(iArc == iNbArc)break; //--- dbut du ring dXDebut=dtabX1[iArc]; dYDebut=dtabY1[iArc]; dXFin=dtabX2[iArc]; dYFin=dtabY2[iArc]; int iNbarcTache=0; itabPtrTache[iNbarcTache]=itabPtrarc[iArc]; btabSens[iNbarcTache]=0; iNbarcTache++; btabLibre[iArc]=FALSE; iArc++; BOOL bFerme=FALSE; if(dXDebut == dXFin && dYDebut == dYFin)bFerme=TRUE; int jArc=iArc; while(jArc < iNbArc && bFerme == FALSE) { if(btabLibre[jArc] == TRUE) { if(dtabX1[jArc] == dXFin && dtabY1[jArc] == dYFin) { itabPtrTache[iNbarcTache]=itabPtrarc[jArc]; btabSens[iNbarcTache]=0; iNbarcTache++; dXFin=dtabX2[jArc]; dYFin=dtabY2[jArc]; btabLibre[jArc]=FALSE; jArc=iArc; if(dXFin == dXDebut && dYFin == dYDebut)bFerme=TRUE; } else if(dtabX2[jArc] == dXFin && dtabY2[jArc] == dYFin) { itabPtrTache[iNbarcTache]=itabPtrarc[jArc]; btabSens[iNbarcTache]=1; iNbarcTache++; dXFin=dtabX1[jArc]; dYFin=dtabY1[jArc]; btabLibre[jArc]=FALSE; jArc=iArc; if(dXFin == dXDebut && dYFin == dYDebut)bFerme=TRUE; } else jArc++; } else jArc++; } //--- fin du chainage d'une tche, criture du polygone dans le path if(bFerme) { //--- allocation mmoire pour le bigarc int iNbpt=0; int iNbptTotal=0; for(int i=0;i < iNbarcTache;i++) { iNbpt=arc.LireNbpt(FileArc,itabPtrTache[i]); iNbptTotal+=iNbpt; }

Structures et mthodes : implmentation 459

CPoint* tabPoint=(CPoint *) malloc(sizeof(CPoint)*iNbptTotal); if(tabPoint == NULL)return FALSE; //--- chainage dans le bigarc int iNbptPolygon=0; for(i=0;i < iNbarcTache;i++) { arc.LirePoints(FileArc,itabPtrTache[i]); arc.Chainer(pDC,m_pCadre,btabSens[i],iNbptPolygon,tabPoint); } //--- tracer dans le path pDC->Polygon(tabPoint,iNbptPolygon); free(tabPoint); } else iNbTachesNonFermees++; } pDC->EndPath(); free(dtabX1); free(dtabY1); free(dtabX2); free(dtabY2); free(btabLibre); free(btabSens); free(itabPtrTache); if(iNbTachesNonFermees == 0) { //--- remplir avec la couleur CBrush brosse,*pBrosseOld; if(iTrame == 1) { brosse.CreateSolidBrush(Couleur); pBrosseOld=(CBrush *) pDC->SelectObject(&brosse); pDC->FillPath(); pDC->SelectObject(pBrosseOld); } else { //--- clipping dans le polygone int iSave=pDC->SaveDC(); if(iSave != 0) { pDC->SelectClipPath(RGN_AND); //--- tracer le rectangle avec la trame choisie trame.Rectangle(pDC,iXbZone,iYbZone,iXhZone,iYhZone,Couleur); pDC->RestoreDC(iSave); } } return TRUE; } return FALSE; }

A.2.4.7. Les classes CLegende Les classes CLegende encapsulent toutes les oprations de dfinition et de trac de lgendes, partir des donnes de lexplorateur cartographique du cadre. La lgende dpend bien sr du type des objets reprsents et du type des variables visuelles utilises. Diffrentes classes permettent de grer les diffrents types de lgendes : lgendes par caissons, lgendes de symboles, de diagrammes, etc. :
class CLegendeCaisson { private: int m_iNbCaissons; char m_chTexte[TAILLE_PALETTE_VALEUR][NB_MAX_CHARACTER]; CSize m_tabSizeTexte[TAILLE_PALETTE_VALEUR]; int m_itabXbCaisson[TAILLE_PALETTE_VALEUR]; int m_itabYbCaisson[TAILLE_PALETTE_VALEUR]; int m_itabXhCaisson[TAILLE_PALETTE_VALEUR]; int m_itabYhCaisson[TAILLE_PALETTE_VALEUR]; int m_itabXbTexte[TAILLE_PALETTE_VALEUR]; int m_itabYbTexte[TAILLE_PALETTE_VALEUR]; int m_itabXhTexte[TAILLE_PALETTE_VALEUR];

460

Annexe
int m_itabYhTexte[TAILLE_PALETTE_VALEUR]; char m_chTitre[80];

public: CLegendeCaisson(); void Init(CDC* pDC); void TraceRapide(CDC* pDC,int iXVue,int iYVue); void TraceDansCarte(CDC* pDC,int iXVue,int iYVue); }; class CLegendeDegrade { private: int m_iNbCaissons; char m_chTexte[TAILLE_PALETTE_VALEUR][NB_MAX_CHARACTER]; CSize m_tabSizeTexte[TAILLE_PALETTE_VALEUR]; int m_itabXbCaisson[TAILLE_PALETTE_VALEUR]; int m_itabYbCaisson[TAILLE_PALETTE_VALEUR]; int m_itabXhCaisson[TAILLE_PALETTE_VALEUR]; int m_itabYhCaisson[TAILLE_PALETTE_VALEUR]; int m_itabXbTexte[TAILLE_PALETTE_VALEUR]; int m_itabYbTexte[TAILLE_PALETTE_VALEUR]; int m_itabXhTexte[TAILLE_PALETTE_VALEUR]; int m_itabYhTexte[TAILLE_PALETTE_VALEUR]; char m_chTitre[80]; public: CLegendeDegrade(); void Init(CDC* pDC); void TraceRapide(CDC* pDC,int iXVue,int iYVue); void TraceDansCarte(CDC* pDC,int iXVue,int iYVue); }; class CLegendeSymbole { private: int m_iLargeurTexte; int m_iHauteurTexte; int m_iNoSymbole; double m_dTailleSymbole; char m_chTexte[100]; public: CLegendeSymbole(); void Init(CDC* pDC); void TraceRapide(CDC* pDC,int iXVue,int iYVue); void TraceDansCarte(CDC* pDC,int iXVue,int iYVue); }; class CLegendeSymboleParTaille { private: int m_iDisposition; int m_iNoSymbole; int m_iNbSymboles; int m_iSizePoint; COLORREF m_CouleurTexte; LOGFONT m_logfont; double m_dtabTailleSymbole[20]; char m_chTexte[20][100]; char m_chTitre[80]; public: CLegendeSymboleParTaille(); void Init(); void TraceRapide(CDC* pDC,int iXVue,int iYVue); void TraceDansCarte(CDC* pDC,int iXVue,int iYVue); }; class CLegendeSymboleParValeur { private: int m_iNbSymboles; int m_itabNoSymbole[TAILLE_PALETTE_VALEUR]; int m_itabTailleSymbole[TAILLE_PALETTE_VALEUR]; int m_itabXSymbole[TAILLE_PALETTE_VALEUR]; int m_itabYSymbole[TAILLE_PALETTE_VALEUR]; int m_itabXTexte[TAILLE_PALETTE_VALEUR]; int m_itabYTexte[TAILLE_PALETTE_VALEUR]; int m_itabLargeurTexte[TAILLE_PALETTE_VALEUR];

Structures et mthodes : implmentation 461

int m_itabHauteurTexte[TAILLE_PALETTE_VALEUR]; char m_chTitre[80]; int m_iXbTitre; int m_iYbTitre; int m_iXhTitre; int m_iYhTitre; public: CLegendeSymboleParValeur(); void Init(CDC* pDC); void TraceRapide(CDC* pDC,int iXVue,int iYVue); void TraceDansCarte(CDC* pDC,int iXVue,int iYVue); }; class CLegendeDiagrammeCaisson { private: int m_iNbCaissons; char m_chTexte[TAILLE_PALETTE_VALEUR][NB_MAX_CHARACTER]; CSize m_tabSizeTexte[TAILLE_PALETTE_VALEUR]; int m_itabXbCaisson[TAILLE_PALETTE_VALEUR]; int m_itabYbCaisson[TAILLE_PALETTE_VALEUR]; int m_itabXhCaisson[TAILLE_PALETTE_VALEUR]; int m_itabYhCaisson[TAILLE_PALETTE_VALEUR]; int m_itabXbTexte[TAILLE_PALETTE_VALEUR]; int m_itabYbTexte[TAILLE_PALETTE_VALEUR]; int m_itabXhTexte[TAILLE_PALETTE_VALEUR]; int m_itabYhTexte[TAILLE_PALETTE_VALEUR]; public: CLegendeDiagrammeCaisson(); void Init(CDC* pDC); void TraceRapide(CDC* pDC,int iXVue,int iYVue); void TraceDansCarte(CDC* pDC,int iXVue,int iYVue); }; class CLegendeDiagrammeParTaille { private: int m_iDisposition; int m_iNbSymboles; int m_iSizePoint; COLORREF m_CouleurTexte; LOGFONT m_logfont; double m_dtabTailleSymbole[20]; char m_chtabTexte[20][100]; char m_chTitre[80]; public: CLegendeDiagrammeParTaille(); void Init(); void TraceRapide(CDC* pDC,int iXVue,int iYVue); void TraceDansCarte(CDC* pDC,int iXVue,int iYVue); };

Les procdures de trac rapide (TraceRapide()) permettent de trac rapidement sur lcran le contour des objets graphiques constituant la lgende, pour la positionner dans la carte de manire interactive. Les procdures TraceDansCarte() inscrivent les objets graphiques dans la carte, sous forme dobjets de type CODD. A.2.4.8. La classe CPaletteSavane La classe CPaletteSavane est drive de la classe CPalette de la MFC. Elle ajoute des fonctionnalits permettant de grer les deux ensembles de couleurs (thmatique et imagerie), de charger des palettes standards, de grer le passage couleur-index. La gestion de la couleur dpend du mode daffichage de la carte graphique de lordinateur (8 bits, 16 bits, 24 ou 32 bits). La classe CPaletteSavane permet de maintenir la gestion dune palette dans le mode 24 ou

462

Annexe

32 bits, mode o Windows permet dafficher directement les couleurs sans lindirection dune palette.
class CPaletteSavane : public CPalette { public : CPaletteSavane(); int int int int int int int int int int int int int int int int int int int int rouge[PALETTE_SIZE]; vert[PALETTE_SIZE]; bleu[PALETTE_SIZE]; rouge_tmp[PALETTE_SIZE]; vert_tmp[PALETTE_SIZE]; bleu_tmp[PALETTE_SIZE]; rouge_image[256]; vert_image[256]; bleu_image[256]; m_iCouleur; m_iColor1; m_iColor2; m_iCouleurTheme; m_iCouleurImage; m_iIndex; m_iIndexOld; m_iTrame; m_iMini; m_iMaxi; m_iTheme;

void SetThematique(); void SetImagerie(); void CouleursSysteme(); int GetExactPaletteIndex(int iDebut,COLORREF couleur); COLORREF RGBColorFromIndex(int iIndex) {return PALETTERGB(rouge[iIndex],vert[iIndex],bleu[iIndex]);}; void Tetascan(); void Gris(); void Ntsc(); void Pseudocolor(); void Telecolor(); void Compocolor(); void Animer(); void SetColorInPaletteLogique(int iIndex,COLORREF Couleur);

};

A.2.4.9. La classe CPerspective La classe CPerspective contient mthodes et variables permettant de tracer une mosaque en perspective. Un attribut dune autre relation peut tre superpos la mosaque.
class CPerspective { private: CCadre* m_pCadre; CImage* m_pImage; double* m_dtabZBuffer; int m_iLargeurVisu; int m_iHauteurVisu; int m_iNbcolImage; int m_iNbligImage; int m_iDatasize; int m_iTypeImage; double m_dFpix; double m_dRapportVisu; double m_dPi; double m_dDegreToRadian; //--- lumiere double m_dCol; double m_dSol; double m_dCil; double m_dSil;

Structures et mthodes : implmentation 463

double m_dNxl; double m_dNyl; double m_dNzl; //--- camera intrinsic int m_iCameraLargeurVisuMM; int m_iCameraHauteurVisuMM; int m_iCameraLargeurVisuPixel; int m_iCameraHauteurVisuPixel; int m_iCameraFocaleMM; //--- camera extrinsic int m_iCameraOrientationDegre; int m_iCameraInclinaisonDegre; int m_iCameraAssietteDegre; double m_dCameraLongitude; double m_dCameraColatitude; double m_dCameraAltitudeMetre; double double double double CBrush m_dCoo; m_dSoo; m_dCio; m_dSio; m_tabBrosse[256];

private: int m_iMargeXBas; int m_iMargeYBas; int m_iMargeXHaut; int m_iMargeYHaut; int m_iMargeXBasVisu; int m_iMargeYBasVisu; int m_iMargeXHautVisu; int m_iMargeYHautVisu; void SauverEnBmp(CDC* pDC,char* chNomFichierBmp); //--- pour la perspective conique double m_dX0; double m_dY0; double m_dZ0; double m_dLG; double m_dD; double m_dXC; double m_dYC; double m_dCouleurMinimum; double m_dCouleurLargeur; int m_iNbSegment; POINT3D m_dtabMaille[4]; POINT3D m_dPolygone[80]; unsigned char EclairMaille(); void AffecteMaille(int i,int j,int iCadran); void ChangeRepere(POINT3D &point); BOOL TestVisibilite(POINT3D point1,POINT3D point2); BOOL CalculIntersecPlan(POINT3D point1,POINT3D point2,POINT3D &point_inter); BOOL PointVisual(POINT3D point); void InitConique(int iPas); BOOL Conique(int i,int j,int &iX,int &iY); void TracerConiqueFilaire(CDC* pDC); public: double m_dZmin; private: //--- pour la perspective cavaliere int m_iPas; double m_dA; double m_dB; double m_dU; double m_dV; double m_dXmin; double m_dYmin; double m_dCoef; double m_dCtx; double m_dCty; void InitCavaliere(int iPas); BOOL Cavaliere(int i,int j,int &iX,int &iY); void TracerCavaliereFilaire(CDC* pDC); void TracerCavaliereEclairement(CDC* pDC); void TracerCavaliereTheme(CDC* pDC,int iNbSelection,int* itabSelection,int iModeSuperposition);

464

Annexe

public: CPerspective(CCadre* pCadre,CImage* pImage); void GetParametreVisu(int &iLargeurVisu,int &iHauteurVisu); void SetRapport(double dFacteur) {m_dRapportVisu=dFacteur/m_dFpix;}; void SetSoleilIntensite(int iIntensite); void SetMarge(int iMargeXBas,int iMargeYBas,int iMargeXHaut,int iMargeYHaut) {m_iMargeXBas=iMargeXBas;m_iMargeYBas=iMargeYBas;m_iMargeXHaut=iMargeXHaut;m_iMargeYHaut=iMarg eYHaut;}; unsigned char GetEclairement(int i,int j); BOOL Tracer(CDC* pDC,int iPas,int iXOrigine,int iYOrigine,int iLargeurVisu,int iHauteurVisu,int iPerspective,int iMode,int iOLumiere,int iILumiere,int iOObserv,int iIObserv); BOOL TracerBmp(int iLargeurVisu,int iHauteurVisu,int iPerspective,int iMode,int iOLumiere,int iILumiere,int iOObserv,int iIObserv,int iNbSelection,int* itabSelection,int iMoseSuperposition,char* chNomFichierBmp); BOOL Animer(int iLargeurVisu,int iHauteurVisu,int iPerspective,int iMode,int iOLumiere,int iILumiere,int iOObservDebut,int iOObservFin,int iIObservDebut,int iIObservFin,int iNbImages,int iNbSelection,int* itabSelection,int iModeSuperposition,char* chNomFichierBmp); void PreviewAnimation(CDC* pDC,int iXOrigine,int iYOrigine,int iLargeurVisu,int iHauteurVisu,int iPerspective,int iMode,int iOLumiere,int iILumiere,int iOObservDebut,int iOObservFin,int iIObservDebut,int iIObservFin,int iNbImages); };

A.2.5. Exemples doprations dans un cadre Cette section prsente des exemples dimplantation de procdures dexcution de commande, correspondant des oprations sur les donnes dune base SAVANE. Elles permettent notamment de montrer lutilisation de la classe CLecture, et les mthodes de cration de nouveaux attributs ou relations. A.2.5.1. XQuestUnion() La procdure XQuestUnion() effectue une union entre deux relations. Comme pour toutes les procdures dexcution de commande, la procdure commence par la lecture des paramtres de la commande, en provenance du dialogue utilisateur ou dune macro-commande. Elle cre ensuite dans un tableau contenant ladresse des tuples metteurs en fonction de la valeur de la cl de jointure de la relation mettrice, puis, pour chaque tuple de la relation rceptrice, lunion avec un tuple metteur est recherche. Ds quune union est dtecte, les valeurs de attributs metteurs sont ajouts au tuple rcepteur, qui est rcrit dans le nouveau fichier descriptif de la relation. Enfin, la procdure met jour le schma de la relation pour reflter lajout de nouveaux attributs temporaires.
void XQuestUnion(CCadre* pCadre) { HCURSOR hcurSave = ::SetCursor(LoadCursor(NULL, IDC_WAIT)); //--- union CSchema* pSchema=pCadre->GetSchema(); CWind* pWind=pCadre->GetWind(); int int int int i,j,k,iNothEmetteur,iNothRecepteur; iNoattCleEmetteur,iNoattCleRecepteur; iNbAttributsEmetteur,itabNoattEmetteur[NB_MAX_ATTRIBUTS]; iJointure;

//--- lecture des paramtres FILE* f=fopen(base.m_chNomFtmp,"rb"); fscanf(f,"%d%*c",&iNothEmetteur); fscanf(f,"%d%*c",&iNoattCleEmetteur); fscanf(f,"%d%*c",&iNbAttributsEmetteur);

Structures et mthodes : implmentation 465

for(i=0;i < iNbAttributsEmetteur;i++) { fscanf(f,"%d%*c",&itabNoattEmetteur[i]); } fscanf(f,"%d%*c",&iNothRecepteur); fscanf(f,"%d%*c",&iNoattCleRecepteur); fscanf(f,"%d%*c",&iJointure); fclose(f); //--- traitement int iNoFichier=pSchema->FchoixDescriptif(); if(iNoFichier == -1) { ::SetCursor(hcurSave); return; } CString strTexte; int iNbObjetsRecepteur=pSchema->NombreObjets(iNothRecepteur); int tabpRecepteur[NB_MAX_ATTRIBUTS]; int iNbaRecepteur=pSchema->m_pRelations[iNothRecepteur]->m_iNba; for(i=1;i <= iNbaRecepteur;i++)tabpRecepteur[i]=pSchema->m_pRelations[iNothRecepteur]>m_pAttributs[i]->m_iNumero; int iNovarCleRecepteur=tabpRecepteur[iNoattCleRecepteur]; int iNbObjetsEmetteur=pSchema->NombreObjets(iNothEmetteur); int tabpEmetteur[NB_MAX_ATTRIBUTS]; int iNbaEmetteur=pSchema->m_pRelations[iNothEmetteur]->m_iNba; for(i=1;i <= iNbaEmetteur;i++)tabpEmetteur[i]=pSchema->m_pRelations[iNothEmetteur]>m_pAttributs[i]->m_iNumero; int iNovarCleEmetteur=tabpEmetteur[iNoattCleEmetteur]; float float float float vEmetteur[NB_MAX_ATTRIBUTS]; vRecepteur[NB_MAX_ATTRIBUTS]; fValCleEmetteur,fValCleRecepteur; vprim[NB_MAX_ATTRIBUTS];

//--- tableaux pour la cl mettrice et les pointeurs dans le fichier metteur float* ftabCle=NULL; long* itabPtr=NULL; ftabCle=(float *) malloc((iNbObjetsEmetteur + 1)*sizeof(float)); itabPtr=(long *) malloc((iNbObjetsEmetteur + 1)*sizeof(long)); //--- lecture de l'metteur pour remplir les tableaux CLecture lectureEmetteur; if(lectureEmetteur.Open(pCadre,iNothEmetteur) == FALSE) { free(ftabCle); free(itabPtr); ::SetCursor(hcurSave); return; } int iObjet=0; j=lectureEmetteur.Lire(vEmetteur); while(j != -1) { if(j == 1) { iObjet++; ftabCle[iObjet]=vEmetteur[iNovarCleEmetteur]; itabPtr[iObjet]=lectureEmetteur.GetPointeurTuple(); } j=lectureEmetteur.Lire(vEmetteur); } lectureEmetteur.Close(); //--- codification des valeurs dans le cas d'une cl de jointure nominale int iTypeCleEmetteur=pSchema->m_pRelations[iNothEmetteur]->m_pAttributs[iNoattCleEmetteur]>m_iType; int iTypeCleRecepteur=pSchema->m_pRelations[iNothRecepteur]>m_pAttributs[iNoattCleRecepteur]->m_iType; if(iTypeCleEmetteur == 1 || iTypeCleEmetteur == 5) { int iNbvalbRecepteur=pSchema->m_pRelations[iNothRecepteur]>m_pAttributs[iNoattCleRecepteur]->m_iNbvalb; int iPtrvalRecepteur=pSchema->m_pRelations[iNothRecepteur]>m_pAttributs[iNoattCleRecepteur]->m_iPtrval;

466

Annexe

int iNbcarAttrRecepteur=pSchema->m_pRelations[iNothRecepteur]>m_pAttributs[iNoattCleRecepteur]->m_iNbcar; int iNbvalbEmetteur=pSchema->m_pRelations[iNothEmetteur]>m_pAttributs[iNoattCleEmetteur]->m_iNbvalb; int iPtrvalEmetteur=pSchema->m_pRelations[iNothEmetteur]>m_pAttributs[iNoattCleEmetteur]->m_iPtrval; int iNbcarAttrEmetteur=pSchema->m_pRelations[iNothEmetteur]>m_pAttributs[iNoattCleEmetteur]->m_iNbcar; if(iPtrvalEmetteur != iPtrvalRecepteur) { //--- indexation des modalites de l'attribut de rfrence CIndexAttribut index(pSchema,iNothRecepteur,iNoattCleRecepteur); if(index.Init()) { FILE* FileValeurs=NULL; if(iTypeCleEmetteur == 1)FileValeurs=fopen(base.m_chNomFichierValeurs,"rb"); else FileValeurs=fopen(pSchema->m_chNomFtval,"rb"); if(FileValeurs != NULL) { //--- recodification int iRes,iVal,iPtr; char chNomValeur[33]; for(i=1;i <= iNbObjetsEmetteur;i++) { iVal=(int) (ftabCle[i] + 0.5); if(iVal > 0) { iPtr=(iPtrvalEmetteur+iVal-2)*iNbcarAttrEmetteur; fseek(FileValeurs,iPtr,SEEK_SET); fread(chNomValeur,iNbcarAttrEmetteur,1,FileValeurs); chNomValeur[iNbcarAttrEmetteur]=0; strstrip(chNomValeur); iRes=index.Recherche(chNomValeur); ftabCle[i]=(float) iRes; } } fclose(FileValeurs); } index.Fermer(); }

//--- union int iType; float vInconnu[NB_MAX_ATTRIBUTS]; for(i=0;i < iNbAttributsEmetteur;i++) { iType=pSchema->m_pRelations[iNothEmetteur]->m_pAttributs[itabNoattEmetteur[i]]->m_iType; if(iType == 1 || iType == 5)vInconnu[i]=0.; else vInconnu[i]=FINCONNU; } int iObjetRecepteur=1; CLecture lectureRecepteur; if(lectureRecepteur.Open(pCadre,iNothRecepteur,iNoFichier,iNbAttributsEmetteur) == FALSE) { free(ftabCle); free(itabPtr); ::SetCursor(hcurSave); return; } CLecture lecture2Emetteur; if(lecture2Emetteur.Open(pCadre,iNothEmetteur) == FALSE) { free(ftabCle); free(itabPtr); ::SetCursor(hcurSave); return; } i=lectureRecepteur.Lire(vRecepteur); while(i != -1) { if(i == 1) { //--- initialisation du tupe

Structures et mthodes : implmentation 467

for(j=1;j <= iNbaRecepteur;j++)vprim[j]=vRecepteur[tabpRecepteur[j]]; for(j=0;j < iNbAttributsEmetteur;j++)vprim[iNbaRecepteur+1+j]=vInconnu[j]; fValCleRecepteur=vRecepteur[iNovarCleRecepteur]; strTexte.Format("Objet %d sur %d",iObjetRecepteur,iNbObjetsRecepteur); pMainFrame->SetStatusTexte(strTexte); if(iTypeCleRecepteur == 1 || iTypeCleRecepteur == 5) { //--- cas cls de jointure nominales if(fValCleRecepteur > 0.) { j=0; iObjet=1; while(iObjet <= iNbObjetsEmetteur && j == 0) { fValCleEmetteur=ftabCle[iObjet]; if(fValCleEmetteur > 0.) { switch(iJointure) { default: break; case 0: //--- equijointure if(fValCleEmetteur == fValCleRecepteur)j=1; break; case 1: //--- different if(fValCleEmetteur != fValCleRecepteur)j=1; break; } if(j == 1) { //--- lire le tuple emetteur lecture2Emetteur.LireTuple(itabPtr[iObjet],vEmetteur); for(k=0;k < iNbAttributsEmetteur;k++) { vprim[iNbaRecepteur+1+k]=vEmetteur[tabpEmetteur[itabNoattEmetteur[k]]]; } } } iObjet++; } } } else { //--- cas cls de jointure numriques if(fValCleRecepteur > FINCONNU) { j=0; iObjet=1; while(iObjet <= iNbObjetsEmetteur && j == 0) { fValCleEmetteur=ftabCle[iObjet]; if(fValCleEmetteur > FINCONNU) { switch(iJointure) { default: break; case 0: //--- equijointure if(fValCleEmetteur == fValCleRecepteur)j=1; break; case 1: //--- different if(fValCleEmetteur != fValCleRecepteur)j=1; break; case 2: if(fValCleEmetteur <= fValCleRecepteur)j=1; break; case 3: //--if(fValCleEmetteur >= fValCleRecepteur)j=1; break; case 4: //--if(fValCleEmetteur < fValCleRecepteur)j=1; break; case 5: //--if(fValCleEmetteur > fValCleRecepteur)j=1; break; } if(j == 1)

468

Annexe
{ //--- lire le tuple emetteur lecture2Emetteur.LireTuple(itabPtr[iObjet],vEmetteur); for(k=0;k < iNbAttributsEmetteur;k++) { vprim[iNbaRecepteur+1+k]=vEmetteur[tabpEmetteur[itabNoattEmetteur[k]]]; } }

} iObjet++; }

//--- criture des valeurs dans le rcepteur lectureRecepteur.Ecrire(vprim); } i=lectureRecepteur.Lire(vRecepteur); iObjetRecepteur++; } lectureRecepteur.Close(); lecture2Emetteur.Close(); free(ftabCle); free(itabPtr); //--- schema if(pSchema->m_pRelations[iNothRecepteur]->m_iType < 10) { pSchema->m_pRelations[iNothRecepteur]->m_iType+=10; pSchema->m_pRelations[iNothRecepteur]->m_iNoFichDescriptif=iNoFichier; pSchema->m_iFdisDescriptif[iNoFichier]=1; for(i=1;i <= pSchema->m_pRelations[iNothRecepteur]->m_iNba;i++)pSchema>m_pRelations[iNothRecepteur]->m_pAttributs[i]->m_iNumero=i; } else { int iNo=pSchema->m_pRelations[iNothRecepteur]->m_iNoFichDescriptif; unlink(pSchema->m_chFprovDescriptif[iNo]); pSchema->m_pRelations[iNothRecepteur]->m_iNoFichDescriptif=iNoFichier; pSchema->m_iFdisDescriptif[iNoFichier]=1; pSchema->m_iFdisDescriptif[iNo]=0; } //--- creation des nouveaux attributs dans le schema int iNbcar,iNoatt,iNbvalb,iPtrval; char chNom[20]; char chDescription[128]; for(k=0;k < iNbAttributsEmetteur;k++) { iNoatt=itabNoattEmetteur[k]; strcpy(chNom,pSchema->m_pRelations[iNothEmetteur]->m_pAttributs[iNoatt]->m_chNom); iType=pSchema->m_pRelations[iNothEmetteur]->m_pAttributs[iNoatt]->m_iType; iNbcar=pSchema->m_pRelations[iNothEmetteur]->m_pAttributs[iNoatt]->m_iNbcar; iNbvalb=pSchema->m_pRelations[iNothEmetteur]->m_pAttributs[iNoatt]->m_iNbvalb; iPtrval=pSchema->m_pRelations[iNothEmetteur]->m_pAttributs[iNoatt]->m_iPtrval; strcpy(chDescription,""); pSchema->NouvelAttribut(iNothRecepteur,iType,iNbcar,iNbvalb,iPtrval,chNom,chDescription); } ::SetCursor(hcurSave); }

A.2.5.2. XQuestJoinGeo() La procdure XQuestJoinGeo() cre une nouvelle relation par qui-jointure gomtrique, en utilisant les reprsentations matricielles des deux relations. Elle cre une image matricielle rsultant de lintersection des deux images matricielles des deux relations initiales, cre ensuite les tuples correspondant cette image, partir des valeurs des tuples des deux relations initiales. Enfin, limage rsultante est vectorise pour crer les arcs correspondants aux zones de la nouvelle relation.
void XQuestJoindreGeoEqui(CCadre* pCadre)

Structures et mthodes : implmentation 469

{ HCURSOR hcurSave = ::SetCursor(LoadCursor(NULL, IDC_WAIT)); //--- equijointure gomtrique CSchema* pSchema=pCadre->GetSchema(); CWind* pWind=pCadre->GetWind(); int iNoth1,iNoth2,iIntersection; char chNomRelation[_MAX_PATH]; //--- lecture des paramtres FILE* FileMenu=fopen(base.m_chNomFtmp,"rb"); fscanf(FileMenu,"%d%*c",&iNoth1); fscanf(FileMenu,"%d%*c",&iNoth2); fscanf(FileMenu,"%d%*c",&iIntersection); fgets(chNomRelation,_MAX_PATH,FileMenu); fclose(FileMenu); chNomRelation[strlen(chNomRelation)-1]='\0'; //--- rasterisation si ncessaire int iTypeRelation=pSchema->m_pRelations[iNoth1]->m_iType; if(iTypeRelation == 4 || iTypeRelation == 14) { CYX cyx(pCadre); cyx.Rasteriser(iNoth1); } iTypeRelation=pSchema->m_pRelations[iNoth2]->m_iType; if(iTypeRelation == 4 || iTypeRelation == 14) { CYX cyx(pCadre); cyx.Rasteriser(iNoth2); } int i,iNo,iNbarc,iPtrarc,nz,iNzNew,iNbpt; int iNba1,iNba2; int iNbObjets1,iNbObjets2; int iCode,iCode1,iCode2; int iX,iY; long adresse; float xc,yc,xb,yb,xh,yh,v1[NB_MAX_ATTRIBUTS],v2[NB_MAX_ATTRIBUTS]; float xcNew,ycNew,xbNew,ybNew,xhNew,yhNew; float vInconnu1[NB_MAX_ATTRIBUTS],vInconnu2[NB_MAX_ATTRIBUTS]; FILE *FileDescriptif1,*FileDescriptif2,*FileDescriptif3; FILE *FileImage1,*FileImage2,*FileImage3; long *ltabObjets1,*ltabObjets2; //--- indexation des objets de la relation 1 iNbObjets1=pSchema->m_pRelations[iNoth1]->m_iNbObjets; if(iNbObjets1 == -1)iNbObjets1=pSchema->NombreObjets(iNoth1); ltabObjets1=(long *) malloc((iNbObjets1+1)*sizeof(long)); if(ltabObjets1 == NULL) { ::SetCursor(hcurSave); ::ErreurDeMemoire(); return; } iNba1=pSchema->m_pRelations[iNoth1]->m_iNba; iCode=0; Clecture lecture1; if(lecture1.Open(iNoth1)) { int i=lecture1.Lire(v); while(i != -1) { if(i == 1) { iCode++; ltabObjets1[iCode]=lecture1.GetPointeurTuple(); } i=lecture1.Lire(v); } lecture1.Close(); } //--- indexation des objets de la relation 2 iNbObjets2=pSchema->m_pRelations[iNoth2]->m_iNbObjets; if(iNbObjets2 == -1)iNbObjets2=pSchema->NombreObjets(iNoth2); ltabObjets2=(long *) malloc((iNbObjets2+1)*sizeof(long));

470

Annexe

if(ltabObjets2 == NULL) { ::SetCursor(hcurSave); ::ErreurDeMemoire(); free(ltabObjets1); return; } iNba2=pSchema->m_pRelations[iNoth2]->m_iNba; iCode=0; Clecture lecture2; if(lecture2.Open(iNoth2)) { int i=lecture2.Lire(v); while(i != -1) { if(i == 1) { iCode++; ltabObjets2[iCode]=lecture2.GetPointeurTuple(); } i=lecture2.Lire(v); } lecture2.Close(); } //--- remplissage des inconnus int iTypeAttr; for(i=1; i <= iNba1;i++) { iTypeAttr=pSchema->m_pRelations[iNoth1]->m_pAttributs[i]->m_iType; switch(iTypeAttr) { case 1: case 5: case 6: vInconnu1[i]=(float) CINCONNU; break; case 2: case 3: case 4: default: vInconnu1[i]=FINCONNU; break; } } for(i=1; i <= iNba2;i++) { iTypeAttr=pSchema->m_pRelations[iNoth2]->m_pAttributs[i]->m_iType; switch(iTypeAttr) { case 1: case 5: case 6: vInconnu2[i]=(float) CINCONNU; break; case 2: case 3: case 4: default: vInconnu2[i]=FINCONNU; break; } } //--- pour la nouvelle relation int iNoFichierDescriptif=pSchema->FchoixDescriptif(); if(iNoFichierDescriptif == -1) { free(ltabObjets1); free(ltabObjets2); return; } int iNoFichierImage=pSchema->FchoixImage(); if(iNoFichierImage == -1) { free(ltabObjets1); free(ltabObjets2);

Structures et mthodes : implmentation 471

return; } int *itabImage1=(int *) malloc(config.m_iDefX*(sizeof(int))); int *itabImage2=(int *) malloc(config.m_iDefX*(sizeof(int))); if(itabImage1 == NULL || itabImage2 == NULL) { ::ErreurDeMemoire(); free(ltabObjets1); free(ltabObjets2); if(itabImage1 != NULL)free(itabImage1); if(itabImage2 != NULL)free(itabImage2); return; } int iNo1=pSchema->m_pRelations[iNoth1]->m_iNoFichImage; int iNo2=pSchema->m_pRelations[iNoth2]->m_iNoFichImage; FileImage1=fopen(pSchema->m_chFprovImage[iNo1],"rb"); FileImage2=fopen(pSchema->m_chFprovImage[iNo2],"rb"); FileImage3=fopen(pSchema->m_chFprovImage[iNoFichierImage],"wb"); if(FileImage1 == NULL || FileImage2 == NULL || FileImage3 == NULL) { free(itabImage1); free(itabImage2); free(ltabObjets1); free(ltabObjets2); if(FileImage1 != NULL)fclose(FileImage1); if(FileImage2 != NULL)fclose(FileImage2); if(FileImage3 != NULL)fclose(FileImage3); return; } CTableauCode* pTableauCode=new CTableauCode(); iY=0; while(iY < config.m_iDefY) { iX=0; while(iX < config.m_iDefX) { fscanf(FileImage1,"%d %d%*c",&iCode1,&iNbpt); for(i=0;i < iNbpt;i++){itabImage1[iX]=iCode1;iX++;} } iX=0; while(iX < config.m_iDefX) { fscanf(FileImage2,"%d %d%*c",&iCode2,&iNbpt); for(i=0;i < iNbpt;i++){itabImage2[iX]=iCode2;iX++;} } //--- croisement des images iCode1=itabImage1[0]; iCode2=itabImage2[0]; iNbpt=1; iX=1; while(iX < config.m_iDefX) { while(iX < config.m_iDefX) { if(itabImage1[iX] != iCode1 || itabImage2[iX] != iCode2)break; iX++; iNbpt++; } //--- traiter le segment if((iIntersection == TRUE && (iCode1 == 0 || iCode2 == 0)) || (iIntersection == FALSE && iCode1 == 0 && iCode2 == 0))iCode=0; else iCode=pTableauCode->AjouterCellule(iCode1,iCode2); fprintf(FileImage3,"%d %d\n",iCode,iNbpt); //--- segment suivant iNbpt=0; if(iX < config.m_iDefX) { iCode1=itabImage1[iX]; iCode2=itabImage2[iX]; iX++; iNbpt=1; } } if(iNbpt > 0)fprintf(FileImage3,"%d %d\n",iCode,iNbpt);

472

Annexe

iY++; } fclose(FileImage1); fclose(FileImage2); fclose(FileImage3); //--- fichier descriptif iNo=pSchema->m_pRelations[iNoth1]->m_iNoFichDescriptif; FileDescriptif1=fopen(pSchema->m_chFprovDescriptif[iNo],"rb"); iNo=pSchema->m_pRelations[iNoth2]->m_iNoFichDescriptif; FileDescriptif2=fopen(pSchema->m_chFprovDescriptif[iNo],"rb"); FileDescriptif3=fopen(pSchema->m_chFprovDescriptif[iNoFichierDescriptif],"wb"); iNbarc=1; iPtrarc=1; fwrite(&iNbarc,SIZEINT,1,FileDescriptif3); fwrite(&iPtrarc,SIZEINT,1,FileDescriptif3); iNzNew=20; xcNew=(pWind->m_fFx1+pWind->m_fFx2)/2.F; ycNew=(pWind->m_fFy1+pWind->m_fFy2)/2.F; xbNew=pWind->m_fFx1; ybNew=pWind->m_fFy1; xhNew=pWind->m_fFx2; yhNew=pWind->m_fFy2; CCelluleCode* ptrCellule=pTableauCode->GetTete(); while(ptrCellule != NULL) { ptrCellule=pTableauCode->LireCellule(ptrCellule,iCode1,iCode2); if(iCode1 > 0) { fseek(FileDescriptif1,ltabObjets1[iCode1],SEEK_SET); for(i=1;i <= iNba1;i++)fread(&v1[i],SIZEVAL,1,FileDescriptif1); } else { for(i=1;i <= iNba1;i++)v1[i]=vInconnu1[i]; } if(iCode2 > 0) { fseek(FileDescriptif2,ltabObjets2[iCode2],SEEK_SET); for(i=1;i <= iNba2;i++)fread(&v2[i],SIZEVAL,1,FileDescriptif2); } else { for(i=1;i <= iNba2;i++)v2[i]=vInconnu2[i]; } fwrite(&iNzNew,SIZEINT,1,FileDescriptif3); fwrite(&xcNew,SIZECOOR,1,FileDescriptif3); fwrite(&ycNew,SIZECOOR,1,FileDescriptif3); fwrite(&xbNew,SIZECOOR,1,FileDescriptif3); fwrite(&ybNew,SIZECOOR,1,FileDescriptif3); fwrite(&xhNew,SIZECOOR,1,FileDescriptif3); fwrite(&yhNew,SIZECOOR,1,FileDescriptif3); for(i=1;i <= iNba1;i++)fwrite(&v1[i],SIZEVAL,1,FileDescriptif3); for(i=1;i <= iNba2;i++)fwrite(&v2[i],SIZEVAL,1,FileDescriptif3); iNzNew++; } iNzNew=0; fwrite(&iNzNew,SIZEINT,1,FileDescriptif3); fwrite(&xcNew,SIZECOOR,1,FileDescriptif3); fwrite(&ycNew,SIZECOOR,1,FileDescriptif3); fwrite(&xbNew,SIZECOOR,1,FileDescriptif3); fwrite(&ybNew,SIZECOOR,1,FileDescriptif3); fwrite(&xhNew,SIZECOOR,1,FileDescriptif3); fwrite(&yhNew,SIZECOOR,1,FileDescriptif3); for(i=1;i <= iNba1;i++)fwrite(&vInconnu1[i],SIZEVAL,1,FileDescriptif3); for(i=1;i <= iNba2;i++)fwrite(&vInconnu2[i],SIZEVAL,1,FileDescriptif3); iNbarc=0; iPtrarc=0; fwrite(&iNbarc,SIZEINT,1,FileDescriptif3); fwrite(&iPtrarc,SIZEINT,1,FileDescriptif3); fclose(FileDescriptif1);

Structures et mthodes : implmentation 473

fclose(FileDescriptif2); fclose(FileDescriptif3); delete pTableauCode; free(itabImage1); free(itabImage2); free(ltabObjets1); free(ltabObjets2); //--- cration du schma int iNoFichierFeuille=-1; int iNoFichierArc=-1; int iNoth3=pSchema>NouvelleRelation(4,chNomRelation,iNoFichierFeuille,iNoFichierDescriptif,iNoFichierArc); if(iNoth3 > 0) { pSchema->m_pRelations[iNoth3]->m_iNoFichImage=iNoFichierImage; if(iNoFichierImage >= 0)pSchema->m_iFdisImage[iNoFichierImage]=1; pSchema->m_pRelations[iNoth3]->m_iType=24; //--- attributs int iType,iNbcar,iNbvalb,iPtrval; char chNomAttribut[20]; char chDescription[128]; strcpy(chDescription,""); for(i=1;i <= iNba1; i++) { strcpy(chNomAttribut,pSchema->m_pRelations[iNoth1]->m_pAttributs[i]->m_chNom); iNbcar=pSchema->m_pRelations[iNoth1]->m_pAttributs[i]->m_iNbcar; iNbvalb=pSchema->m_pRelations[iNoth1]->m_pAttributs[i]->m_iNbvalb; iPtrval=pSchema->m_pRelations[iNoth1]->m_pAttributs[i]->m_iPtrval; iType=pSchema->m_pRelations[iNoth1]->m_pAttributs[i]->m_iType; pSchema>NouvelAttribut(iNoth3,iType,iNbcar,iNbvalb,iPtrval,chNomAttribut,chDescription); } for(i=1;i <= iNba2; i++) { strcpy(chNomAttribut,pSchema->m_pRelations[iNoth2]->m_pAttributs[i]->m_chNom); iNbcar=pSchema->m_pRelations[iNoth2]->m_pAttributs[i]->m_iNbcar; iNbvalb=pSchema->m_pRelations[iNoth2]->m_pAttributs[i]->m_iNbvalb; iPtrval=pSchema->m_pRelations[iNoth2]->m_pAttributs[i]->m_iPtrval; iType=pSchema->m_pRelations[iNoth2]->m_pAttributs[i]->m_iType; pSchema>NouvelAttribut(iNoth3,iType,iNbcar,iNbvalb,iPtrval,chNomAttribut,chDescription); } //--- vectorisation et recupration du nombre d'arcs CVectoriser vectoriser(pCadre,TRUE); vectoriser.Relation(iNoth3); iNbarc=vectoriser.GetNbarc(); FileDescriptif3=fopen(pSchema->m_chFprovDescriptif[iNoFichierDescriptif],"rb+"); if(FileDescriptif3 != NULL) { fwrite(&iNbarc,SIZEINT,1,FileDescriptif3); fclose(FileDescriptif3); } //--- calcul des centrodes et fentres de zones pSchema->m_pRelations[iNoth3]->CalculDesCentroides(); } ::SetCursor(hcurSave); }

A.2.5.3. XCrisCalcul() Le code prsent ici est une partie de limplmentation de la procdure gnrale de cration dun attribut par calcul. Il sagit dune opration interne une relation, comme toutes les oprations du menu CRIS. Le code montre les tapes importantes de cette procdures : cration du tableau dindirection schma interne-schma externe, lecture des objets (avec la classe CLecture) et utilisation de la classe CCalculateur pour dterminer la valeur du nouvel attribut partir des attributs de lobjet, mise jour du schma de la relation avec cration dun nouvel attribut.

474

Annexe

//--- tableau dindirection schma interne-schma externe int tabp[NB_MAX_ATTRIBUTS]; int iNba=pSchema->m_pRelations[iNoth]->m_iNba; for(i=1;i <= iNba;i++)tabp[i]=pSchema->m_pRelations[iNoth]->m_pAttributs[i]->m_iNumero; int iNoFichier=pSchema->FchoixDescriptif(); if(iNoFichier == -1)return; CLecture lecture; if(lecture.Open(pCadre,iNoth,iNoFichier,1)) { //--- lecture des objets double v[NB_MAX_ATTRIBUTS],fResultat; double vprim[NB_MAX_ATTRIBUTS]; i=lecture.Lire(v); while(i != -1) { if(i == 1) { dResultat=calculateur.Calcul(chFormule,v); iNbObjets++; if(pSchema->m_pRelations[iNoth]->m_iType < 10) { for(i=1;i <= iNba;i++)vprim[i]=v[tabp[i]]; vprim[iNba+1]=fResultat; lecture.Ecrire(vprim); } else { v[iNba+1]=fResultat; lecture.Ecrire(v); } } i=lecture.Lire(v); } lecture.Close(); //--- mise a jour de la relation if(pSchema->m_pRelations[iNoth]->m_iType < 10) { pSchema->m_pRelations[iNoth]->m_iType+=10; pSchema->m_pRelations[iNoth]->m_iNoFichDescriptif=iNoFichier; pSchema->m_iFdisDescriptif[iNoFichier]=1; for(i=1;i <= pSchema->m_pRelations[iNoth]->m_iNba;i++)pSchema->m_pRelations[iNoth]>m_pAttributs[i]->m_iNumero=i; } else { int iNo=pSchema->m_pRelations[iNoth]->m_iNoFichDescriptif; unlink(pSchema->m_chFprovDescriptif[iNo]); pSchema->m_pRelations[iNoth]->m_iNoFichDescriptif=iNoFichier; pSchema->m_iFdisDescriptif[iNoFichier]=1; pSchema->m_iFdisDescriptif[iNo]=0; } //--- creation du nouvel attribut dans le schema pSchema->NouvelAttribut(iNoth,4,0,0,0,chNomAttribut,chDescription); iOperationOk=1; }

A.2.5.4. XTri() La procdure Xtri() est utilise plusieurs reprises dans SAVANE pour trier les valeurs dun attribut dune relation (par exemple, dans la procdure XCrisTri(), dans la procdure de dtermination de quantiles, dans le calcul de la mdiane, etc.). Elle utilise la classe CLecture pour lire la valeur des objets de la relation, et la procdure qsort() de la librairie standard C++ pour trier les valeurs.
void XTri(CCadre* pCadre,int iNoth, int iNoatt,float *fTableau) { //--- tri des valeurs d'un attribut, relations non image

Structures et mthodes : implmentation 475

CSchema* pSchema=pCadre->GetSchema(); if(pSchema->m_pRelations[iNoth]->m_iType != 5 && pSchema->m_pRelations[iNoth]->m_iType != 15 && pSchema->m_pRelations[iNoth]->m_iType != 25) { //--- initialisation de la lecture float v[NB_MAX_ATTRIBUTS]; int i; int iNovar=pSchema->m_pRelations[iNoth]->m_pAttributs[iNoatt]->m_iNumero; CLecture lecture; if(lecture.Open(pCadre,iNoth)) { int iNbObjets=0; i=lecture.Lire(v); while(i != -1) { if(i == 1) { if(v[iNovar] > FINCONNU) { fTableau[iNbObjets]=v[iNovar]; iNbObjets++; } } i=lecture.Lire(v); } lecture.Close(); qsort(fTableau,iNbObjets,sizeof(float),comparnum); }

int comparnum(const void *arg1,const void *arg2) { if(*((float *) arg1) < *((float *) arg2))return -1; if(*((float *) arg1) > *((float *) arg2))return 1; return 0; }

A.3. Savamer A.3.1. La classe CAmers La classe CAmers de SAVAMER gre les couples de points saisis entre image redresser et espace gographique. Elle est utilise dans de nombreuses autres classes du programme. On peut saisir jusqu 10 000 amers pour une image.
class CAmers { friend class friend class friend class friend class friend class CTranslation; CSimilitude; CSysteme1; CSysteme3; CTessel;

private: double m_dtabXDiff[NB_MAX_AMER]; double m_dtabYDiff[NB_MAX_AMER]; //--- coordonnes dans la vue de la base int m_itabXVue[NB_MAX_AMER]; int m_itabYVue[NB_MAX_AMER]; //--- coordonnes dans la base savane double m_dtabXSav[NB_MAX_AMER]; double m_dtabYSav[NB_MAX_AMER]; //--- coordonnes image int m_itabXImage[NB_MAX_AMER]; int m_itabYImage[NB_MAX_AMER]; int m_iNbpt;

476

Annexe
int m_iSelection; BOOL m_bASauver; char m_chNomFichier[_MAX_PATH];

public: CAmers(); void BOOL void BOOL Init(); Lire(char *chNomFichierAmers); Ecrire(); Fermer();

void SavToVue(); void Tracer(int iTarget,CDC* pDc); void TracerLesLiens(int iTarget,CDC* pDc); void TracerUnPoint(int iTarget,CDC* pDc,int iNo,COLORREF couleur); void Supprimer(int iNo); void AjouterSavane(double dXSav,double dYSav,int iXImage,int iYImage); void AjouterProjection(double dXProj,double dYProj,int iXImage,int iYImage); int Selectionner(int iTarget,CPoint point); int SelectionnerParNumero(int iNo); int GetSelection() {return m_iSelection;}; void SetPointVue(int iNo,int iXVue,int iYVue,int iXImage,int iYImage); void SetPointProjection(int iNo,double dXProj,double dYProj,int iXImage,int iYImage); void GetPointVue(int iNo,int &iXVue,int &iYVue,int &iXImage,int &iYImage); void GetPointSavane(int iNo,double &dXSav,double &dYSav,int &iXImage,int &iYImage); void GetPointProjection(int iNo,double &dXProj,double &dYproj,int &iXImage,int &iYImage); int GetNbpt() {return m_iNbpt;}; void ASauver() {m_bASauver=TRUE;}; BOOL IsASauver() {return m_bASauver;}; void Echanger(int,int); }; BOOL Fenetre(double &dXMin,double &dYMin,double &dXMax,double &dYMax);

A.3.2. La classe CSysteme1 La classe Csystme1 permet deffectuer un redressement polynomial avec trois points damers.
class CSysteme1 { private: double m_dResolution; CAmers* m_pAmers; CImage* m_pImage; double double double double double double double double double double double double m_aPToI; m_bPToI; m_cPToI; m_aprimPToI; m_bprimPToI; m_cprimPToI; m_aIToP; m_bIToP; m_cIToP; m_aprimIToP; m_bprimIToP; m_cprimIToP;

//--- fenetre d'arrivee, en projection double m_dFx1; double m_dFy1; double m_dFx2; double m_dFy2; int m_iNbligDestination; int m_iNbcolDestination; public: CSysteme1(CAmers* pAmers,CImage* pImage,double dResolution); BOOL Equations(); void ImageToProjection(int iX,int iY,double &dX,double &dY);

Structures et mthodes : implmentation 477

void void void void void ProjectionToImage(double dX,double dY, int &iX,int &iY); ProjectionToImage(double dX,double dY,double &dXImage,double &dYImage); FenetreDestination(); Recalage(int iModeRecalage); RecalageAmers();

double GetResolution() {return m_dResolution;}; void GetFenetreDestination(double &dXb,double &dYb,double &dXh,double &dYh,int &iNbcol,int &iNblig); };

La mthode Equations() de la classe calcule, partir des trois premiers points damers, les coefficients des formules de calculs. Les mthodes ProjectionToImage() et ImageToProjection() effectuent les calculs de changement de repre :
BOOL CSysteme1::Equations() { double dX,dY,dX0,dY0; double double double double double double dXi0=(double) dYi0=(double) dXi1=(double) dYi1=(double) dXi2=(double) dYi2=(double) m_pAmers->m_itabXImage[0]; m_pAmers->m_itabYImage[0]; m_pAmers->m_itabXImage[1]; m_pAmers->m_itabYImage[1]; m_pAmers->m_itabXImage[2]; m_pAmers->m_itabYImage[2];

::SavToProj(m_pAmers->m_dtabXSav[0],m_pAmers->m_dtabYSav[0],dX0,dY0); ::SavToProj(m_pAmers->m_dtabXSav[0],m_pAmers->m_dtabYSav[0],dX,dY); double dXp0=dX-dX0; double dYp0=dY-dY0; ::SavToProj(m_pAmers->m_dtabXSav[1],m_pAmers->m_dtabYSav[1],dX,dY); double dXp1=dX-dX0; double dYp1=dY-dY0; ::SavToProj(m_pAmers->m_dtabXSav[2],m_pAmers->m_dtabYSav[2],dX,dY); double dXp2=dX-dX0; double dYp2=dY-dY0; double dDelta=(dXi1-dXi0)*(dYi2-dYi0)-(dXi2-dXi0)*(dYi1-dYi0); if(dDelta == 0)return FALSE; m_aIToP=((dXp1-dXp0)*(dYi2-dYi0)-(dXp2-dXp0)*(dYi1-dYi0))/dDelta; m_bIToP=((dXp2-dXp0)*(dXi1-dXi0)-(dXp1-dXp0)*(dXi2-dXi0))/dDelta; m_cIToP=dXp0-m_aIToP*dXi0-m_bIToP*dYi0; m_aprimIToP=((dYp1-dYp0)*(dYi2-dYi0)-(dYp2-dYp0)*(dYi1-dYi0))/dDelta; m_bprimIToP=((dYp2-dYp0)*(dXi1-dXi0)-(dYp1-dYp0)*(dXi2-dXi0))/dDelta; m_cprimIToP=dYp0-m_aprimIToP*dXi0-m_bprimIToP*dYi0; dDelta=(dXp1-dXp0)*(dYp2-dYp0)-(dXp2-dXp0)*(dYp1-dYp0); if(dDelta == 0)return FALSE; m_aPToI=((dXi1-dXi0)*(dYp2-dYp0)-(dXi2-dXi0)*(dYp1-dYp0))/dDelta; m_bPToI=((dXi2-dXi0)*(dXp1-dXp0)-(dXi1-dXi0)*(dXp2-dXp0))/dDelta; m_cPToI=dXi0-m_aPToI*dXp0-m_bPToI*dYp0; m_aprimPToI=((dYi1-dYi0)*(dYp2-dYp0)-(dYi2-dYi0)*(dYp1-dYp0))/dDelta; m_bprimPToI=((dYi2-dYi0)*(dXp1-dXp0)-(dYi1-dYi0)*(dXp2-dXp0))/dDelta; m_cprimPToI=dYi0-m_aprimPToI*dXp0-m_bprimPToI*dYp0; return TRUE; } void CSysteme1::ImageToProjection(int iX,int iY,double &dXProj,double &dYProj) { dXProj=m_aIToP*((double) iX) + m_bIToP*((double) iY) + m_cIToP; dYProj=m_aprimIToP*((double) iX) + m_bprimIToP*((double) iY) + m_cprimIToP; } void CSysteme1::ProjectionToImage(double dXProj,double dYProj,int &iX,int &iY) { iX=(int) (m_aPToI*dXProj + m_bPToI*dYProj + m_cPToI);

478

Annexe

iY=(int) (m_aprimPToI*dXProj + m_bprimPToI*dYProj + m_cprimPToI); }

Le calcul de la fentre de redressement est effectu par la fonction

FenetreDestination() :
void CSysteme1::FenetreDestination() { double dX,dY; ImageToProjection(0,0,m_dFx1,m_dFy1); m_dFx2=m_dFx1; m_dFy2=m_dFy1; ImageToProjection(m_pImage->m_iNbcol,0,dX,dY); if(dX < m_dFx1)m_dFx1=dX; if(dY < m_dFy1)m_dFy1=dY; if(dX > m_dFx2)m_dFx2=dX; if(dY > m_dFy2)m_dFy2=dY; ImageToProjection(m_pImage->m_iNbcol,m_pImage->m_iNblig,dX,dY); if(dX < m_dFx1)m_dFx1=dX; if(dY < m_dFy1)m_dFy1=dY; if(dX > m_dFx2)m_dFx2=dX; if(dY > m_dFy2)m_dFy2=dY; ImageToProjection(0,m_pImage->m_iNblig,dX,dY); if(dX < m_dFx1)m_dFx1=dX; if(dY < m_dFy1)m_dFy1=dY; if(dX > m_dFx2)m_dFx2=dX; if(dY > m_dFy2)m_dFy2=dY; double dXProj1,dYProj1,dXProj2,dYProj2; m_pAmers->Fenetre(dXProj1,dYProj1,dXProj2,dYProj2); if(dXProj1 < m_dFx1)m_dFx1=dXProj1; if(dYProj1 < m_dFy1)m_dFy1=dYProj1; if(dXProj2 > m_dFx2)m_dFx2=dXProj2; if(dYProj2 > m_dFy2)m_dFy2=dYProj2; //--- aligner la fentre de recalage sur la rsolution des pixels double dXProj0,dYProj0; ::SavToProj(m_pAmers->m_dtabXSav[0],m_pAmers->m_dtabYSav[0],dXProj0,dYProj0); double double double double dXb=m_dFx1+dXProj0; dYb=m_dFy1+dYProj0; dXh=m_dFx2+dXProj0; dYh=m_dFy2+dYProj0; (dXb/m_dResolution))*m_dResolution; (dYb/m_dResolution))*m_dResolution; (dXh/m_dResolution)+1)*m_dResolution; (dYh/m_dResolution)+1)*m_dResolution;

dXb=((long) dYb=((long) dXh=((long) dYh=((long)

m_dFx1=dXb-dXProj0; m_dFy1=dYb-dYProj0; m_dFx2=dXh-dXProj0; m_dFy2=dYh-dYProj0; m_iNbligDestination=(int) ((m_dFy2-m_dFy1)/m_dResolution); m_iNbcolDestination=(int) ((m_dFx2-m_dFx1)/m_dResolution); int iReste=4-(m_iNbcolDestination % 4); if(iReste != 4)m_iNbcolDestination+=iReste; m_dFx2=m_dFx1 + m_iNbcolDestination*m_dResolution; }

La mthode Recalage() effectue la fois le redressement et le rchantillonage. Par exemple, pour un r-chantillonnage par plus proche voisin, le calcul est le suivant :
//--- recalage plus proche voisin ilig=0; dY=m_dFy1+(m_dResolution/2.); while(ilig < m_iNbligDestination) { icol=0; dX=m_dFx1+(m_dResolution/2.); while(icol < m_iNbcolDestination) {

Structures et mthodes : implmentation 479

ProjectionToImage(dX,dY,iX,iY); if(iX >= 0 && iX < m_pImage->m_iNbcol && iY >= 0 && iY < m_pImage->m_iNblig) buffer[icol]=m_pImage->m_bPixels[(iY*m_pImage->m_iNbcol)+iX]; else buffer[icol]=0; dX+=m_dResolution; icol++; } fwrite(buffer,1,m_iNbcolDestination,FileBmp); dY+=m_dResolution; ilig++; }

ilig=0; dY=m_dFy1+(m_dResolution/2.); while(ilig < m_iNbligDestination) { icol=0; dX=m_dFx1+(m_dResolution/2.); while(icol < m_iNbcolDestination) { ProjectionToImage(dX,dY,dXImage,dYImage); alfa0=dXImage-floor(dXImage); alfa1=1.-alfa0; beta0=dYImage-floor(dYImage); beta1=1.-beta0; iX=(int) dXImage; iY=(int) dYImage; if(iX >= 0 && iX < m_pImage->m_iNbcol-1 && iY >= 0 && iY < m_pImage->m_iNblig-1) { dVal00=(double) m_pImage->m_bPixels[(iY*m_pImage->m_iNbcol)+iX]; dVal01=(double) m_pImage->m_bPixels[(iY*m_pImage->m_iNbcol)+iX+1]; dVal10=(double) m_pImage->m_bPixels[((iY+1)*m_pImage->m_iNbcol)+iX]; dVal11=(double) m_pImage->m_bPixels[((iY+1)*m_pImage->m_iNbcol)+iX+1]; buffer[icol]=(int) (beta0*alfa0*dVal00+beta0*alfa1*dVal01+beta1*alfa0*dVal10+beta1*alfa1*dVal11); } else buffer[icol]=0; dX+=m_dResolution; icol++; } fwrite(buffer,1,m_iNbcolDestination,FileBmp); dY+=m_dResolution; ilig++; }

Le calcul bicubique calcule la valeur en fonction de la position du point sur une fentre de 4*4 voisins :
ilig=0; dY=m_dFy1+(m_dResolution/2.); while(ilig < m_iNbligDestination) { icol=0; dX=m_dFx1+(m_dResolution/2.); while(icol < m_iNbcolDestination) { ProjectionToImage(dX,dY,dXImage,dYImage); iX=(int) dXImage; iY=(int) dYImage; if(iX >= 1 && iX < m_pImage->m_iNbcol-2 && iY >= 1 && iY < m_pImage->m_iNblig-2) { alfa1=dXImage-floor(dXImage); alfa0=1.+alfa1; alfa2=1.-alfa1; alfa3=2.-alfa1; beta1=dYImage-floor(dYImage); beta0=1.+beta1; beta2=1.-beta1;

480

Annexe
beta3=2.-beta1; CX0=alfa0*(-alfa0*alfa0 + 5.*alfa0 - 8.) + 4.; CX1=alfa1*alfa1*(alfa1 - 2.) + 1.; CX2=alfa2*alfa2*(alfa2 - 2.) + 1.; CX3=alfa3*(-alfa3*alfa3 + 5*alfa3 - 8.) + 4.; CY0=beta0*(-beta0*beta0 + 5*beta0 - 8.) + 4.; CY1=beta1*beta1*(beta1 - 2.) + 1.; CY2=beta2*beta2*(beta2 - 2.) + 1.; CY3=beta3*(-beta3*beta3 + 5.*beta3 - 8.) + 4.; iIndice=(iY-1)*m_pImage->m_iNbcol+iX; dVal00=(double) m_pImage->m_bPixels[iIndice-1]; dVal01=(double) m_pImage->m_bPixels[iIndice]; dVal02=(double) m_pImage->m_bPixels[iIndice+1]; dVal03=(double) m_pImage->m_bPixels[iIndice+2]; iIndice=iY*m_pImage->m_iNbcol+iX; dVal10=(double) m_pImage->m_bPixels[iIndice-1]; dVal11=(double) m_pImage->m_bPixels[iIndice]; dVal12=(double) m_pImage->m_bPixels[iIndice+1]; dVal13=(double) m_pImage->m_bPixels[iIndice+2]; iIndice=(iY+1)*m_pImage->m_iNbcol+iX; dVal20=(double) m_pImage->m_bPixels[iIndice-1]; dVal21=(double) m_pImage->m_bPixels[iIndice]; dVal22=(double) m_pImage->m_bPixels[iIndice+1]; dVal23=(double) m_pImage->m_bPixels[iIndice+2]; iIndice=(iY+2)*m_pImage->m_iNbcol+iX; dVal30=(double) m_pImage->m_bPixels[iIndice-1]; dVal31=(double) m_pImage->m_bPixels[iIndice]; dVal32=(double) m_pImage->m_bPixels[iIndice+1]; dVal33=(double) m_pImage->m_bPixels[iIndice+2]; dVal=CY0*(CX0*dVal00 + CX1*dVal01 + CX2*dVal02 + CX3*dVal03); dVal+=CY1*(CX0*dVal10 + CX1*dVal11 + CX2*dVal12 + CX3*dVal13); dVal+=CY2*(CX0*dVal20 + CX1*dVal21 + CX2*dVal22 + CX3*dVal23); dVal+=CY3*(CX0*dVal30 + CX1*dVal31 + CX2*dVal32 + CX3*dVal33); buffer[icol]=(int) dVal; } else buffer[icol]=0;

dX+=m_dResolution; icol++; } fwrite(buffer,1,m_iNbcolDestination,FileBmp); dY+=m_dResolution; ilig++; }

A.3.3. La classe CTessel La classe CTessel permet deffectuer le calcul de la triangulation de Delaunay partir des points damers, et le redressement polynomail de degr 1 dans chacun des triangles. La triangulation de Delaunay est calcule par insertion successive des points damer. Le redressement utilise une image rasterise de la triangulation pour dterminer le triangle auquel appartient le point redresser, et dterminer ainsi les coefficients du redressement de degr 1.
class CTessel { friend class CYX; private: double m_dResolution; CAmers* m_pAmers; CImage* m_pImage;

Structures et mthodes : implmentation 481

CSimilitude *m_pSimilitude; CSysteme1 *m_pSysteme1; int m_iRecalageInitial; //--- fenetre d'arrivee, en projection double m_dFx1; double m_dFy1; double m_dFx2; double m_dFy2; double m_dXProj0; double m_dYProj0; int m_iNbligDestination; int m_iNbcolDestination; //--- structures NOEUD *m_TableNoeuds; int m_iNombredeNoeuds; int m_iNumeroTriangle; //--- fonctions locales de tesselation void GenerationTriangle(FILE *FileArc,FILE *FileDat,int ,int ,int ); void InitTriangulation(int *triangle,double flxb,double flyb,double flxh,double flyh); int InsertionPoint(POINTR2 point,TRIANGLE *triangle ); void supprimerliste(LISTE *tete) ; LISTE *init_liste(); void suppression(LISTE *tete, int indice); int prede_succ(LISTE *tete, int indice, int *predecesseur, int *successeur) ; int succ(LISTE *tete, int indice) ; LISTE *insertion(LISTE *tete, LISTE *noeud, int indice); void init_pile(); void supprimepile(); void empiler(int a, int b, int c, int d) ; void depiler(int *a, int *b, int *c, int *d); int pile_vide() ; void insertion_liste_ordonnee(int a, int b, int c); int chercher_le_triangle(int *a, int *b, int *c, POINTR2 point); int cherche_point_oppose(int a, int b, int c); int adjacent(int a, int b, int c); int est_un_triangle(int a, int b, int c); void creation_triangle(int a, int b, int c); void del_triangle(int a, int b, int c); int split_triangle(int a, int b, int c, POINTR2 point, TRIANGLE *triangle); void split3_triangle(int a, int b, int c, int d, TRIANGLE *triangle); void split4_triangle(int a, int b, int c, int d, int e, TRIANGLE *triangle); int swap(int a, int b, int c, int d); void split_quad(int a, int b, int c, int d, TRIANGLE *triangle); int position_point_segment(POINTR2 p1, POINTR2 p2, POINTR2 p0s, POINTR2 p1s); double pseudo_angle(POINTR2 p1, POINTR2 p2); double angle_point(POINTR2 a, POINTR2 b, POINTR2 c); int point_non_alignes(POINTR2 p1, POINTR2 p2, POINTR2 p3); int quadrilatere_strictement_convexe(POINTR2 pa, POINTR2 pb, POINTR2 pc, POINTR2 pd); int compare_point(POINTR2 p1, POINTR2 p2); int modulo(int i, int j, int k); void copier_point(POINTR2 p1, POINTR2 *p2); public: CTessel(CAmers* pAmers); CTessel(CAmers* pAmers,CImage* pImage,CSimilitude* pSimilitude); CTessel(CAmers* pAmers,CImage* pImage,CSysteme1* pSysteme1); ~CTessel(); int Tesselation(); int TesselationSansRecalage(); void Raster(); void Recalage(int iNbTriangles,int iModeRecalage); };

Voici une partie du code de la procdure de redressement par triangulation :

void CTessel::Recalage(int iNbTriangle,int iModeRecalage) { char chNomFichierDat[_MAX_PATH]; strcpy(chNomFichierDat,schema.m_chDirUser); strcat(chNomFichierDat,"\\ftdat"); char chNomFichierTriangle[_MAX_PATH]; strcpy(chNomFichierTriangle,schema.m_chDirUser); strcat(chNomFichierTriangle,"\\ftImageTriangle"); char chNomFichier[_MAX_PATH];

482

Annexe

char chNomFichierDepl[_MAX_PATH]; FILE *FileBmp,*FileDepl; strcpy(chNomFichier,m_pImage->m_chNomFichier); strcat(chNomFichier,"R.bmp"); strcpy(chNomFichierDepl,m_pImage->m_chNomFichier); strcat(chNomFichierDepl,"RDiff.bmp"); if((FileBmp=fopen(chNomFichier,"wb")) != NULL NULL) { //--- fichier dplacement BITMAPFILEHEADER BitmapFileHeaderDepl; BITMAPINFOHEADER BitmapInfoHeaderDepl; RGBQUAD PaletteEntriesDepl[256]; //--- BITMAPFILEHEADER char bm[3]; strcpy(bm,"BM"); memcpy(&BitmapFileHeaderDepl.bfType,bm,2); int iSize=sizeof(BITMAPFILEHEADER)+sizeof(BITMAPINFOHEADER)+sizeof(PaletteEntriesDepl); iSize+=(m_iNbligDestination*m_iNbcolDestination); BitmapFileHeaderDepl.bfSize=iSize; BitmapFileHeaderDepl.bfReserved1=0; BitmapFileHeaderDepl.bfReserved2=0; BitmapFileHeaderDepl.bfOffBits=sizeof(BITMAPFILEHEADER) + sizeof(BITMAPINFOHEADER) + sizeof(PaletteEntriesDepl); //--- BITMAPINFOHEADER BitmapInfoHeaderDepl.biSize=(DWORD) sizeof(BITMAPINFOHEADER); BitmapInfoHeaderDepl.biWidth=m_iNbcolDestination; BitmapInfoHeaderDepl.biHeight=m_iNbligDestination; BitmapInfoHeaderDepl.biPlanes=(WORD) 1; BitmapInfoHeaderDepl.biBitCount=(WORD) 8; BitmapInfoHeaderDepl.biCompression=BI_RGB; BitmapInfoHeaderDepl.biSizeImage=(DWORD) (m_iNbligDestination*m_iNbcolDestination); BitmapInfoHeaderDepl.biXPelsPerMeter=(LONG) m_dResolution; BitmapInfoHeaderDepl.biYPelsPerMeter=(LONG) m_dResolution; BitmapInfoHeaderDepl.biClrUsed=(DWORD) 0; BitmapInfoHeaderDepl.biClrImportant=(DWORD) 0; for(int i=0;i < 128;i++) { PaletteEntriesDepl[i].rgbBlue= (BYTE) i*2; PaletteEntriesDepl[i].rgbGreen= (BYTE) i*2; PaletteEntriesDepl[i].rgbRed= (BYTE) i*2; PaletteEntriesDepl[i].rgbReserved= (BYTE) 0; } for(i=128;i < 256;i++) { PaletteEntriesDepl[i].rgbBlue= (BYTE) 255; PaletteEntriesDepl[i].rgbGreen= (BYTE) 255; PaletteEntriesDepl[i].rgbRed= (BYTE) 255; PaletteEntriesDepl[i].rgbReserved= (BYTE) 0; } fwrite(&BitmapFileHeaderDepl,sizeof(BITMAPFILEHEADER),1,FileDepl); fwrite(&BitmapInfoHeaderDepl,sizeof(BITMAPINFOHEADER),1,FileDepl); fwrite(&PaletteEntriesDepl,sizeof(PaletteEntriesDepl),1,FileDepl); //--- creation du tableau des coefficients int iCode; double *alpha; double *beta; double *gamma; double *alphaprim; double *betaprim; double *gammaprim; unsigned char *bufferDiff; int *itabImage; alpha=(double *) malloc(iNbTriangle*sizeof(double)); beta=(double *) malloc(iNbTriangle*sizeof(double)); gamma=(double *) malloc(iNbTriangle*sizeof(double)); if(alpha == NULL || beta == NULL || gamma == NULL) { ::ErreurDeMemoire(); if(alpha != NULL)free(alpha); && (FileDepl=fopen(chNomFichierDepl,"wb")) !=

Structures et mthodes : implmentation 483

if(beta != NULL)free(beta); if(gamma != NULL)free(gamma); fclose(FileBmp); fclose(FileDepl); unlink(chNomFichier); unlink(chNomFichierDepl); unlink(chNomFichierTriangle); unlink(chNomFichierDat); return; } alphaprim=(double *) malloc(iNbTriangle*sizeof(double)); betaprim=(double *) malloc(iNbTriangle*sizeof(double)); gammaprim=(double *) malloc(iNbTriangle*sizeof(double)); if(alphaprim == NULL || betaprim == NULL || gammaprim == NULL) { ::ErreurDeMemoire(); if(alphaprim != NULL)free(alphaprim); if(betaprim != NULL)free(betaprim); if(gammaprim != NULL)free(gammaprim); free(alpha); free(beta); free(gamma); fclose(FileBmp); fclose(FileDepl); unlink(chNomFichier); unlink(chNomFichierDepl); unlink(chNomFichierTriangle); unlink(chNomFichierDat); return; } bufferDiff=(unsigned char *) malloc(m_iNbcolDestination*sizeof(unsigned char)); itabImage=(int *) malloc(m_iNbcolDestination*sizeof(int)); if(bufferDiff == NULL || itabImage == NULL) { ::ErreurDeMemoire(); if(bufferDiff != NULL)free(bufferDiff); if(itabImage != NULL)free(itabImage); free(alpha); free(beta); free(gamma); free(alphaprim); free(betaprim); free(gammaprim); fclose(FileBmp); fclose(FileDepl); unlink(chNomFichier); unlink(chNomFichierDepl); unlink(chNomFichierTriangle); unlink(chNomFichierDat); return; } FILE* FileDat=fopen(chNomFichierDat,"rb"); if(FileDat == NULL) { free(bufferDiff); free(itabImage); free(alpha); free(beta); free(gamma); free(alphaprim); free(betaprim); free(gammaprim); fclose(FileBmp); fclose(FileDepl); unlink(chNomFichier); unlink(chNomFichierDepl); unlink(chNomFichierTriangle); } fread(&iCode,sizeof(int),1,FileDat); while(!feof(FileDat)) { fread(&alpha[iCode],sizeof(double),1,FileDat);

484

Annexe
fread(&beta[iCode],sizeof(double),1,FileDat); fread(&gamma[iCode],sizeof(double),1,FileDat); fread(&alphaprim[iCode],sizeof(double),1,FileDat); fread(&betaprim[iCode],sizeof(double),1,FileDat); fread(&gammaprim[iCode],sizeof(double),1,FileDat); fread(&iCode,sizeof(int),1,FileDat); } fclose(FileDat); unlink(chNomFichierDat); FILE* FileImage=fopen(chNomFichierTriangle,"rb"); if(FileImage == NULL) { ::ErreurDeFichier(chNomFichierTriangle); free(bufferDiff); free(itabImage); free(alpha); free(beta); free(gamma); free(alphaprim); free(betaprim); free(gammaprim); fclose(FileBmp); fclose(FileDepl); unlink(chNomFichier); unlink(chNomFichierDepl); unlink(chNomFichierTriangle); return; } if(m_pImage->m_iType == 6) { //--- 8 bits BITMAPFILEHEADER BitmapFileHeader; BITMAPINFOHEADER BitmapInfoHeader; //--- BITMAPFILEHEADER char bm[3]; strcpy(bm,"BM"); memcpy(&BitmapFileHeader.bfType,bm,2);

int iSize=sizeof(BITMAPFILEHEADER)+sizeof(BITMAPINFOHEADER)+sizeof(m_pImage>m_PaletteEntries); iSize+=(m_iNbligDestination*m_iNbcolDestination); BitmapFileHeader.bfSize=iSize; BitmapFileHeader.bfReserved1=0; BitmapFileHeader.bfReserved2=0; BitmapFileHeader.bfOffBits=sizeof(BITMAPFILEHEADER) + sizeof(BITMAPINFOHEADER) + sizeof(m_pImage->m_PaletteEntries); //--- BITMAPINFOHEADER BitmapInfoHeader.biSize=(DWORD) sizeof(BITMAPINFOHEADER); BitmapInfoHeader.biWidth=m_iNbcolDestination; BitmapInfoHeader.biHeight=m_iNbligDestination; BitmapInfoHeader.biPlanes=(WORD) 1; BitmapInfoHeader.biBitCount=(WORD) 8; BitmapInfoHeader.biCompression=BI_RGB; BitmapInfoHeader.biSizeImage=(DWORD) (m_iNbligDestination*m_iNbcolDestination); BitmapInfoHeader.biXPelsPerMeter=(LONG) m_dResolution; BitmapInfoHeader.biYPelsPerMeter=(LONG) m_dResolution; BitmapInfoHeader.biClrUsed=(DWORD) 0; BitmapInfoHeader.biClrImportant=(DWORD) 0; fwrite(&BitmapFileHeader,sizeof(BITMAPFILEHEADER),1,FileBmp); fwrite(&BitmapInfoHeader,sizeof(BITMAPINFOHEADER),1,FileBmp); fwrite(&m_pImage->m_PaletteEntries,sizeof(m_pImage->m_PaletteEntries),1,FileBmp); //--- calcul et criture des pixels unsigned char *buffer; buffer=(unsigned char *) malloc(m_iNbcolDestination*sizeof(unsigned char)); if(buffer == NULL) { ::ErreurDeMemoire(); free(bufferDiff); free(itabImage); free(alpha);

Structures et mthodes : implmentation 485

free(beta); free(gamma); free(alphaprim); free(betaprim); free(gammaprim); fclose(FileBmp); fclose(FileDepl); fclose(FileImage); unlink(chNomFichier); unlink(chNomFichierDepl); unlink(chNomFichierTriangle); return; } double dX,dY,dXProj,dYProj,dDistance; int j,iX,iY,ilig,icol,iDiff; int iNbpt; //--- init du progressCtrl char chTitreProgress[100]; switch(config.m_iLangage) { case FRANCAIS: default: strcpy(chTitreProgress," Recalage en cours :"); break; case ESPAGNOL: strcpy(chTitreProgress," Calculo en curso :"); break; case ANGLAIS: strcpy(chTitreProgress," Working :"); break; } pMainFrame->InitProgress(chTitreProgress); int iStep,iCount; iStep=m_iNbligDestination/10; if(iStep == 0)iStep=1; iCount=0; if(iModeRecalage == 0) { //--- recalage deux points ilig=0; dY=m_dFy1+(m_dResolution/2.); while(ilig < m_iNbligDestination) { //--- lire la ligne triangle for(icol=0;icol < m_iNbcolDestination;icol++)itabImage[icol]=0; icol=0; while(icol < m_iNbcolDestination) { fscanf(FileImage,"%d %d%*c",&iCode,&iNbpt); j=0; while(j < iNbpt) { itabImage[icol]=iCode; icol++; j++; } } icol=0; dX=m_dFx1+(m_dResolution/2.); while(icol < m_iNbcolDestination) { //--- recalage Voronoi iCode=itabImage[icol]; if(iCode > 0) { dXProj=alpha[iCode]*dX + beta[iCode]*dY + gamma[iCode]; dYProj=alphaprim[iCode]*dX + betaprim[iCode]*dY + gammaprim[iCode]; //--- deplacement du au voronoi dDistance=sqrt((dX-dXProj)*(dX-dXProj)+(dY-dYProj)*(dY-dYProj)); iDiff=(int) (dDistance/m_dResolution); if(iDiff > 255)iDiff=255; bufferDiff[icol]=iDiff;

486

Annexe

if(m_iRecalageInitial == SIMILITUDE)m_pSimilitude>ProjectionToImage(dXProj,dYProj,iX,iY); else m_pSysteme1->ProjectionToImage(dXProj,dYProj,iX,iY); if(iX >= 0 && iX < m_pImage->m_iNbcol && iY >= 0 && iY < m_pImage->m_iNblig) buffer[icol]=m_pImage->m_bPixels[(iY*m_pImage->m_iNbcol)+iX]; else buffer[icol]=0; } else { buffer[icol]=0; bufferDiff[icol]=255; } dX+=m_dResolution; icol++; } fwrite(buffer,1,m_iNbcolDestination,FileBmp); if(config.m_bImageDifference)fwrite(bufferDiff,1,m_iNbcolDestination,FileDepl); dY+=m_dResolution; ilig++; iCount++; if(iCount > iStep) { iCount=0; pMainFrame->StepProgress(); } }

else if(iModeRecalage == 1) { //--- recalage bilineaire double dXImage,dYImage; double alfa0,alfa1,beta0,beta1; double dVal00,dVal01,dVal10,dVal11; ilig=0; dY=m_dFy1+(m_dResolution/2.); while(ilig < m_iNbligDestination) { //--- lire la ligne triangle for(icol=0;icol < m_iNbcolDestination;icol++)itabImage[icol]=0; icol=0; while(icol < m_iNbcolDestination) { fscanf(FileImage,"%d %d%*c",&iCode,&iNbpt); j=0; while(j < iNbpt) { itabImage[icol]=iCode; icol++; j++; } } icol=0; dX=m_dFx1+(m_dResolution/2.); while(icol < m_iNbcolDestination) { //--- recalage Voronoi iCode=itabImage[icol]; if(iCode > 0) { dXProj=alpha[iCode]*dX + beta[iCode]*dY + gamma[iCode]; dYProj=alphaprim[iCode]*dX + betaprim[iCode]*dY + gammaprim[iCode]; //--- deplacement du au voronoi dDistance=sqrt((dX-dXProj)*(dX-dXProj)+(dY-dYProj)*(dY-dYProj)); iDiff=(int) (dDistance/m_dResolution); if(iDiff > 255)iDiff=255; bufferDiff[icol]=iDiff; if(m_iRecalageInitial == SIMILITUDE)m_pSimilitude>ProjectionToImage(dXProj,dYProj,dXImage,dYImage); else m_pSysteme1->ProjectionToImage(dXProj,dYProj,dXImage,dYImage); alfa0=dXImage-floor(dXImage); alfa1=1.-alfa0; beta0=dYImage-floor(dYImage);

Structures et mthodes : implmentation 487

beta1=1.-beta0; iX=(int) dXImage; iY=(int) dYImage; >m_iNblig-1) if(iX >= 0 && iX < m_pImage->m_iNbcol-1 && iY >= 0 && iY < m_pImage{ dVal00=(double) dVal01=(double) dVal10=(double) dVal11=(double) m_pImage->m_bPixels[(iY*m_pImage->m_iNbcol)+iX]; m_pImage->m_bPixels[(iY*m_pImage->m_iNbcol)+iX+1]; m_pImage->m_bPixels[((iY+1)*m_pImage->m_iNbcol)+iX]; m_pImage->m_bPixels[((iY+1)*m_pImage->m_iNbcol)+iX+1];

buffer[icol]=(int) (beta0*alfa0*dVal00+beta0*alfa1*dVal01+beta1*alfa0*dVal10+beta1*alfa1*dVal11); } else buffer[icol]=0; } else { buffer[icol]=0; bufferDiff[icol]=255; } dX+=m_dResolution; icol++; } fwrite(buffer,1,m_iNbcolDestination,FileBmp); if(config.m_bImageDifference)fwrite(bufferDiff,1,m_iNbcolDestination,FileDepl); dY+=m_dResolution; ilig++; iCount++; if(iCount > iStep) { iCount=0; pMainFrame->StepProgress(); } }

else if(iModeRecalage == 2) { //--- recalage bicubique int iIndice; double dXImage,dYImage; double alfa0,alfa1,alfa2,alfa3,beta0,beta1,beta2,beta3; double CX0,CX1,CX2,CX3,CY0,CY1,CY2,CY3; double dVal00,dVal01,dVal02,dVal03; double dVal10,dVal11,dVal12,dVal13; double dVal20,dVal21,dVal22,dVal23; double dVal30,dVal31,dVal32,dVal33; double dVal; ilig=0; dY=m_dFy1+(m_dResolution/2.); while(ilig < m_iNbligDestination) { //--- lire la ligne triangle for(icol=0;icol < m_iNbcolDestination;icol++)itabImage[icol]=0; icol=0; while(icol < m_iNbcolDestination) { fscanf(FileImage,"%d %d%*c",&iCode,&iNbpt); j=0; while(j < iNbpt) { itabImage[icol]=iCode; icol++; j++; } } icol=0; dX=m_dFx1+(m_dResolution/2.); while(icol < m_iNbcolDestination) { //--- recalage Voronoi iCode=itabImage[icol]; if(iCode > 0)

488

Annexe
{ dXProj=alpha[iCode]*dX + beta[iCode]*dY + gamma[iCode]; dYProj=alphaprim[iCode]*dX + betaprim[iCode]*dY + gammaprim[iCode]; //--- deplacement du au voronoi dDistance=sqrt((dX-dXProj)*(dX-dXProj)+(dY-dYProj)*(dY-dYProj)); iDiff=(int) (dDistance/m_dResolution); if(iDiff > 255)iDiff=255; bufferDiff[icol]=iDiff;

if(m_iRecalageInitial == SIMILITUDE)m_pSimilitude>ProjectionToImage(dXProj,dYProj,dXImage,dYImage); else m_pSysteme1->ProjectionToImage(dXProj,dYProj,dXImage,dYImage); iX=(int) dXImage; iY=(int) dYImage; >m_iNblig-2) if(iX >= 1 && iX < m_pImage->m_iNbcol-2 && iY >= 1 && iY < m_pImage{ alfa1=dXImage-floor(dXImage); alfa0=1.+alfa1; alfa2=1.-alfa1; alfa3=2.-alfa1; beta1=dYImage-floor(dYImage); beta0=1.+beta1; beta2=1.-beta1; beta3=2.-beta1; CX0=alfa0*(-alfa0*alfa0 + 5.*alfa0 - 8.) + 4.; CX1=alfa1*alfa1*(alfa1 - 2.) + 1.; CX2=alfa2*alfa2*(alfa2 - 2.) + 1.; CX3=alfa3*(-alfa3*alfa3 + 5*alfa3 - 8.) + 4.; CY0=beta0*(-beta0*beta0 + 5*beta0 - 8.) + 4.; CY1=beta1*beta1*(beta1 - 2.) + 1.; CY2=beta2*beta2*(beta2 - 2.) + 1.; CY3=beta3*(-beta3*beta3 + 5.*beta3 - 8.) + 4.; iIndice=(iY-1)*m_pImage->m_iNbcol+iX; dVal00=(double) m_pImage->m_bPixels[iIndice-1]; dVal01=(double) m_pImage->m_bPixels[iIndice]; dVal02=(double) m_pImage->m_bPixels[iIndice+1]; dVal03=(double) m_pImage->m_bPixels[iIndice+2]; iIndice=iY*m_pImage->m_iNbcol+iX; dVal10=(double) m_pImage->m_bPixels[iIndice-1]; dVal11=(double) m_pImage->m_bPixels[iIndice]; dVal12=(double) m_pImage->m_bPixels[iIndice+1]; dVal13=(double) m_pImage->m_bPixels[iIndice+2]; iIndice=(iY+1)*m_pImage->m_iNbcol+iX; dVal20=(double) m_pImage->m_bPixels[iIndice-1]; dVal21=(double) m_pImage->m_bPixels[iIndice]; dVal22=(double) m_pImage->m_bPixels[iIndice+1]; dVal23=(double) m_pImage->m_bPixels[iIndice+2]; iIndice=(iY+2)*m_pImage->m_iNbcol+iX; dVal30=(double) m_pImage->m_bPixels[iIndice-1]; dVal31=(double) m_pImage->m_bPixels[iIndice]; dVal32=(double) m_pImage->m_bPixels[iIndice+1]; dVal33=(double) m_pImage->m_bPixels[iIndice+2]; dVal=CY0*(CX0*dVal00 + CX1*dVal01 + CX2*dVal02 + CX3*dVal03); dVal+=CY1*(CX0*dVal10 + CX1*dVal11 + CX2*dVal12 + CX3*dVal13); dVal+=CY2*(CX0*dVal20 + CX1*dVal21 + CX2*dVal22 + CX3*dVal23); dVal+=CY3*(CX0*dVal30 + CX1*dVal31 + CX2*dVal32 + CX3*dVal33); buffer[icol]=(int) dVal; } else buffer[icol]=0; } else { buffer[icol]=0; bufferDiff[icol]=255; } dX+=m_dResolution; icol++; } fwrite(buffer,1,m_iNbcolDestination,FileBmp);

Structures et mthodes : implmentation 489

if(config.m_bImageDifference)fwrite(bufferDiff,1,m_iNbcolDestination,FileDepl); dY+=m_dResolution; ilig++; iCount++; if(iCount > iStep) { iCount=0; pMainFrame->StepProgress(); } }

pMainFrame->CloseProgress(); free(buffer); } else if(m_pImage->m_iType == 8) { //--- 24 bits, 3 octets par pixel, processus identique . } free(bufferDiff); free(itabImage); free(alpha); free(beta); free(gamma); free(alphaprim); free(betaprim); free(gammaprim); fclose(FileImage); fclose(FileBmp); fclose(FileDepl); if(config.m_bImageDifference == FALSE)unlink(chNomFichierDepl); unlink(chNomFichierTriangle); } //--- fichier .car double dProj[20]; projection.GetProjection(dProj); double dXProj0,dYProj0; ::SavToProj(m_pAmers->m_dtabXSav[0],m_pAmers->m_dtabYSav[0],dXProj0,dYProj0); char chNomImage[_MAX_PATH]; strcpy(chNomImage,m_pImage->m_chNomFichier); strcat(chNomImage,"R"); double dXb=m_dFx1+dXProj0; double dYb=m_dFy1+dYProj0; ::CreationFichierCar(chNomImage,m_dResolution,1,dXb,dYb,m_iNbcolDestination,m_iNbligDestinat ion,m_pImage->GetType(),dProj); if(config.m_bImageDifference) { strcpy(chNomImage,m_pImage->m_chNomFichier); strcat(chNomImage,"RDiff"); dXb=m_dFx1+dXProj0; dYb=m_dFy1+dYProj0; ::CreationFichierCar(chNomImage,m_dResolution,1,dXb,dYb,m_iNbcolDestination,m_iNbligDestinat ion,m_pImage->GetType(),dProj); } }

A.4. Savedit A.4.1. La classe CArc La classe CArc de SAVEDIT est plus complte que la classe CArc de SAVANE. Elle comprend en particulier des variables membres conservant ltat de larc

490

Annexe

(simplicit, extra-simplicit) et permettant de dessiner ces arcs avec une couleur dpendant de leur tat de validit. Lallocation mmoire pour les points (tableau m_ArrayPoint) est dynamique. Elle utilise les fonctionnalits de la classe CArray de la MFC.
class CArc { private: int m_iNbpt; //--- nombre de points de larc int m_iNz1; //--- numro de zone adjacente dans le cas dun document de type zone int m_iNz2; //--- numro de zone adjacente dans le cas dun document de type zone int m_iSens; //--- sens de larc int m_iSelection; //--- point slectionn dans l'arc double m_dXminSav,m_dYminSav,m_dXmaxSav,m_dYmaxSav; //--- fentre de larc public: CArray<CPoint,CPoint> m_ArrayPoint; / :--- tableau des points int m_iSimplicite; //--- indicateur de simplifict int m_iExtraSimplicite; //--- indicateur dextra-simplifict int m_iTestAngleFerme; //--- indicateur dangle entre deux points public: CArc(); CArc(int iNbpt); ~CArc(); int GetNbpt() {return m_iNbpt;} int GetSens() {return m_iSens;} int GetNoZone1() {return m_iNz1;}; int GetNoZone2() {return m_iNz2;}; void SetNbpt(int iNbpt) {m_iNbpt=iNbpt;}; void SetSens(int iSens) {m_iSens=iSens;}; void SetNoZone1(int iNo) {m_iNz1=iNo;}; void SetNoZone2(int iNo) {m_iNz2=iNo;}; void GetPoint(int i,double &dX,double &dY) { dX=m_ArrayPoint[i].m_dX; dY=m_ArrayPoint[i].m_dY; }; void SetPoint(int i,double &dX,double &dY) { m_ArrayPoint[i].m_dX=dX; m_ArrayPoint[i].m_dY=dY; }; void AddPoint(CPoint point) {m_ArrayPoint.Add(point);}; void AddPoint(double dX,double dY) { CPoint point(dX,dY); m_ArrayPoint.Add(point); }; void SetPointGrow(int i,CPoint point) {m_ArrayPoint.SetAtGrow(i,point);} void SetPointGrow(int i,double dX,double dY) { CPointMygale point(dX,dY); m_ArrayPoint.SetAtGrow(i,point); } int GetSelection() {return m_iSelection;} void SetSelection(int iNo) {if(iNo >= 0 && iNo < m_iNbpt)m_iSelection=iNo; else m_iSelection=-1;} int SelectionnerUnPoint(double dXGeo,double dYGeo); void SupprimerUnPoint(int iNoPoint); void GetFenetreSav(double &dXmin,double &dYmin,double &dXmax,double &dYmax) { dXmin=m_dXminSav; dYmin=m_dYminSav; dXmax=m_dXmaxSav; dYmax=m_dYmaxSav; } BOOL Intersect(double dX1,double dY1,double dX2,double dY2); BOOL TestSimplicite(double& dXRes,double& dYRes); BOOL TestExtraSimplicite(CArc* pArc,double& dXRes,double& dYRes,int& iNoPointArc1,int& iNoPointArc2); BOOL TestAngleEntreSegments(double dAngleMinimum,double& dXRes,double& dYRes); BOOL TestIntersection(double dLong1,double dColat1,double dLong2,double dColat2,double& dXRes,double& dYRes); void CalculFenetreSav(); void CalculCentroide(double &dX,double &dY);

Structures et mthodes : implmentation 491

void GetCentroide(double &dXGeo,double &dYGeo); double DistanceAUnPoint(double dXGeo,double dYGeo); int DistanceAUnPoint(int iXVue,int iYVue); int InsererUnPoint(double dXGeo,double dYGeo); BOOL InsererUnPoint(double dXGeo,double dYGeo,int iNoPoint); int PointLePlusProche(double dXGeo,double dYGeo,double dDistanceRecherche,double dDistanceJointure,double& dXGeoRes,double& dYGeoRes,double &dDistance,int& iNoPoint); void Filtrer(double dSurfaceMinimum); void FiltrerMetre(double dSurfaceMinimum); void Nettoyer(); void Arrondir(int iPrecision); void Molodensky(CMolodensky* pMolodensky); void Translation(double dXProj,double dYProj); void Tracer(CDC* pDc); void TracerAvecTranslation(CDC* pDc,int iTranslationX,int iTranslationY); void Tracer(CDC* pDc,COLORREF Couleur); void TracerAvecLesPoints(CDC* pDC); void TracerAvecLesPoints(CDC* pDC,COLORREF Couleur); void EffacerLesPoints(CDC* pDC); void TracerUnPoint(CDC* pDC,int iNoPoint,COLORREF Couleur); void Recopier(CArcMygale* pArc); void ChangerLeSens(); void Chainer(BOOL bSens,int iTypeCoordonnees,int& iIndex,int& iNbptPolygon,double *dtabPoints); };

La mthode TestSimplicite() permet de tester la simplicit dun arc. Elle utilise la procdure SegmentIntersection() qui contrle lintersection de deux segments de droite :
BOOL CArc::TestSimplicite(double& dXRes,double& dYRes) { dXRes=0.; dYRes=0.; m_iSimplicite=0; if(m_iNbpt < 3)return TRUE; double dX1,dY1,dX2,dY2,dX3,dY3,dX4,dY4; int j,k; for(j=1;j < m_iNbpt;j++) { GetPoint(j-1,dX1,dY1); GetPoint(j,dX2,dY2); for(k=j+1;k < m_iNbpt;k++) { GetPoint(k-1,dX3,dY3); GetPoint(k,dX4,dY4); if(SegmentIntersection(dX1,dY1,dX2,dY2,dX3,dY3,dX4,dY4,dXRes,dYRes)) { m_iSimplicite=1; return FALSE; } } } return TRUE; }

La mthode TestExtraSimplicite() permet de tester lintersection dun arc avec un autre. Elle utilise galement la procdure SegmentIntersection() qui contrle lintersection de deux segments de droite, aprs avoir test lintersection possible des arcs en utilisant les BoundingBox des deux arcs (mthode Intersect() de CArc).
BOOL CArc::TestExtraSimplicite(CArc* pArc,double& dXRes,double& dYRes,int& iNoPointArc1,int& iNoPointArc2) { dXRes=0.; dYRes=0.; iNoPointArc1=0; iNoPointArc2=0; if(pArc == NULL)return TRUE; if(pArc == this)return TRUE;

492

Annexe

//--- tester l'intersection des fentre des arcs double dXMin,dYMin,dXMax,dYMax; pArc->GetFenetreSav(dXMin,dYMin,dXMax,dYMax); if(Intersect(dXMin,dYMin,dXMax,dYMax) == FALSE)return TRUE; double dX1,dY1,dX2,dY2,dX3,dY3,dX4,dY4; int j,k; int iNbpt=pArc->GetNbpt(); for(j=1;j < m_iNbpt;j++) { GetPoint(j-1,dX1,dY1); GetPoint(j,dX2,dY2); for(k=1;k < iNbpt;k++) { pArc->GetPoint(k-1,dX3,dY3); pArc->GetPoint(k,dX4,dY4); if(SegmentIntersection(dX1,dY1,dX2,dY2,dX3,dY3,dX4,dY4,dXRes,dYRes)) { iNoPointArc1=j-1; iNoPointArc2=k-1; return FALSE; } } } return TRUE; }

La mthode PointLePlusProche() permet de dterminer les coordonnes du point de larc le plus proche dun point donn :
int CArc::PointLePlusProche(double dXGeo,double dYGeo,double dDistanceRecherche,double dDistanceJointure,double& dXGeoRes,double& dYGeoRes,double &dDistance,int& iNoPoint) { //--- dDistanceRecherche en minutes //--- retourne le type, la distance avec l'arc, le point rsultat, le numro du point dans l'arc //--- type : -1 echec, 0 nouveau point, 1 premier noeud, 2 dernier noeud, 3 point de l'arc int i; iNoPoint=-1; dXGeoRes=0.; dYGeoRes=0.; dDistance=-DINCONNU; if(m_iNbpt < 2)return -1; double dX1,dY1,dX2,dY2,dXSav,dYSav; dX1=m_dXminSav - dDistanceRecherche; dX2=m_dXmaxSav + dDistanceRecherche; dY1=m_dYminSav - dDistanceRecherche; dY2=m_dYmaxSav + dDistanceRecherche; wind.GeoToSav(dXGeo,dYGeo,dXSav,dYSav); if(dXSav < dX1 || dXSav > dX2 || dYSav < dY1 || dYSav > dY2)return -1; //--- premier passage : test sur les points de l'arc double dP1P2; int iType=-1; iNoPoint=-1; double dDistanceAuCarre=dDistanceRecherche*dDistanceRecherche; for(i=0;i < m_iNbpt;i++) { GetPoint(i,dX1,dY1); dP1P2=((dXGeo-dX1)*(dXGeo-dX1))+((dYGeo-dY1)*(dYGeo-dY1)); if(dP1P2 < dDistanceAuCarre) { iNoPoint=i; dXGeoRes=dX1; dYGeoRes=dY1; dDistanceAuCarre=dP1P2; } } if(iNoPoint == 0)iType=1; //--- premier point else if(iNoPoint == m_iNbpt-1)iType=2; //--- dernier point else if(iNoPoint > 0)iType=3; //--- un point de l'arc

Structures et mthodes : implmentation 493

dDistance=sqrt(dDistanceAuCarre); if(dDistance < dDistanceJointure) { //--- le point de l'arc rpond la question, on sort return iType; } //--- deuxime passage : test sur les segments de l'arc double d,dX,dY,cosTeta,sinTeta,dXPrim,dYPrim; GetPoint(0,dX1,dY1); for(i=1;i < m_iNbpt;i++) { GetPoint(i,dX2,dY2); dP1P2=((dX2-dX1)*(dX2-dX1))+((dY2-dY1)*(dY2-dY1)); if(dP1P2 > 0.) { dP1P2=sqrt(dP1P2); //--- changement de repere pour les calculs cosTeta=(dX2-dX1)/dP1P2; sinTeta=(dY2-dY1)/dP1P2; dX=dXGeo-dX1; dY=dYGeo-dY1; dXPrim=dX*cosTeta+dY*sinTeta; dYPrim=dY*cosTeta-dX*sinTeta; if(dXPrim >= 0. && dXPrim <= dP1P2) { d=fabs(dYPrim); if(d < dDistance) { dDistance=d; iNoPoint=i-1; iType=0; //--- nouveau point crer //--- rechangement de repre pour avoir le point d'intersection sur le segment (dYPrim = 0) dXGeoRes=dXPrim*cosTeta + dX1; dYGeoRes=dXPrim*sinTeta + dY1; } } } dX1=dX2; dY1=dY2; } if(iNoPoint >= 0) { return iType; } return -1; }

A.4.2. La classe CSaveditDocument Toutes les variables et procdures lie document de saisie sont regroupes dans une classe nomme CSaveditDocument. On notera en particulier les variables qui conservent les coordonnes des lments graphiques et la valeur ou la cl des objets (CArc* m_ptabArc; double* m_dtabPoint; double* m_dtabValeur; char* m_ctabCle). Lallocation mmoire de ces variables est effectue dans les mthodes Nouveau() ou Ouvrir() de lobjet CSaveditDocument, en fonction du type des objets.
class CSaveditDocument { private: BOOL m_bOuvert; BOOL m_bASauver; BOOL m_bARasteriser; char m_chNomFichier[_MAX_PATH]; //--- paramtres du .car int m_iVersion;

494

Annexe
int m_iTypeObjet; int m_iTypeSaisie; char m_chNomDocument[100]; int m_iEchelle; char m_chOperateur[100]; char m_chDatum[100]; char m_chDate[100]; char m_chCreation[100]; double m_dX1,m_dY1,m_dX2,m_dY2; int m_iNbcharCle; //--- objets graphiques, mmoire alloue en fonction du type int m_iNoZoneLibre; int m_iNbObjet; int m_iNbArc; CArc* m_ptabArc[NB_MAX_ARC]; int m_itabNoZone[NB_MAX_OBJET]; double* m_dtabPoint; double* m_dtabValeur; char* m_ctabCle; //--- dition et slection int m_iNbObjetSelection; int m_iObjetSelection; int m_itabObjetSelection[NB_MAX_SELECTION]; int m_iNbArcSelection; int m_iArcSelection; int m_itabArcSelection[NB_MAX_SELECTION];

//--- pour le undo public: CArcMygale* m_ptabArcModifie[NB_MAX_UNDO]; CArcMygale* m_ptabArcSauvegarde[NB_MAX_UNDO]; int m_itabTypeUndo[NB_MAX_UNDO + 1]; //--- tracer public: BOOL m_bDegrade; double m_dIntervalleDegrade; //--- pour l'initialisation des cls nominales public: int m_iCleValeurInitiale; int m_iCleIncrement; int m_iCleNbChiffres; CString m_strClePrefixe; CString m_strCleSuffixe; private: BOOL Sauver(); public: CMygaleDocument(); ~CMygaleDocument(); //--- procdures de gestion des fichiers void Init(); BOOL Nouveau(const char* chNom,int iEchelle,const char* chOperateur,int iType,int iSaisie,int iNbcharCle); BOOL Ouvrir(const char* chNomFichier); BOOL Ajouter(const char* chNomFichier); BOOL ImporterShapefile(const char* chNomFichier,int iNoattCle,const char* strPrefixe,BOOL bCleToujoursNominal,CProjection* pProjection,int iHemisphere,BOOL bTypeShape,int iTypeMygale); BOOL ImporterMygale(const char* chNomFichier,CProjection* pProjection); BOOL ImporterPoint(const char* chNomFichier,CDecodage* pDecodage,const char* chPrefixe, const char* chNom,const char* chOperateur,int iEchelle,int iCleMygale,int iNbcharCle); BOOL ImporterDxf(const char* chNomFichier,CProjection* pProjection,int iHemisphere, int iTousLesLayers,bool* btabLayer, const char* chNom,const char* chOperateur,int iEchelle,int iTypeObjet,int iTypeSaisie,int iNbcharCle); BOOL ImporterLignes(const char* chNomFichier,CProjection* pProjection,int iHemisphere, const char* chPrefixe,const char* chNom,const char* chOperateur,int iEchelle,int iTypeSaisie,int iNbcharCle); BOOL Enregistrer(); BOOL EnregistrerCar(); BOOL EnregistrerSous(); BOOL ExporterEnShapefile(const char* chNomFichier,int iTypeShapefile,int iTypeCoordonnees); BOOL Fermer();

Structures et mthodes : implmentation 495

void SupprimerToutesLesZones(); int SupprimerLesZonesSansArcs(); int SupprimerLesArcsLibres(); int SupprimerLesArcsEnDouble(); int NettoyerTousLesArcs(); void Precision(int iPrecision); //--- changement de datum par Molodensky void Molodensky(CMolodensky* pMolodensky); BOOL IsTypeZone() {if(m_iTypeObjet == TYPE_ZONE_MYGALE)return TRUE; else return FALSE;}; BOOL IsTypeLigne() {if(m_iTypeObjet == TYPE_LIGNE_MYGALE)return TRUE; else return FALSE;}; BOOL IsTypePoint() {if(m_iTypeObjet == TYPE_POINT_MYGALE)return TRUE; else return FALSE;}; int GetTypeObjet() {return m_iTypeObjet;}; int GetTypeSaisie() {return m_iTypeSaisie;}; void GetNomFichier(char* chNom) {strcpy(chNom,m_chNomFichier);}; void GetNomDocument(char* chNom) {strcpy(chNom,m_chNomDocument);}; void SetNomDocument(const char* chNom) {strcpy(m_chNomDocument,chNom);}; void GetOperateur(char* chNom) {strcpy(chNom,m_chOperateur);}; void SetOperateur(const char* chNom) {strcpy(m_chOperateur,chNom);}; void GetDatum(char* chNom) {strcpy(chNom,m_chDatum);}; void SetDatum(const char* chNom) {strcpy(m_chDatum,chNom);m_bASauver=TRUE;}; int GetEchelle() {return m_iEchelle;}; void SetEchelle(int iEchelle) {m_iEchelle=iEchelle;}; void GetDate(char* chNom) {strcpy(chNom,m_chDate);}; void GetCreation(char* chNom) {strcpy(chNom,m_chCreation);}; BOOL IsOuvert() {return m_bOuvert;}; BOOL IsASauver() {return m_bASauver;}; void ASauver() {m_bASauver=TRUE;m_bARasteriser=TRUE;}; void ARasteriser() {m_bARasteriser=TRUE;}; BOOL FenetreSav(double &dFx1,double &dFy1,double &dFx2,double &dFy2); //--- procdures sur les objets void GetValue(int iNoObjet,char* chCle,double &dValeur); void GetValuePourDBIII(int iNoObjet,char *chCle,double &dValeur); CArc* GetPtrArc(int iNoArc) {if(iNoArc >= 0 && iNoArc < m_iNbArc)return m_ptabArc[iNoArc]; else return NULL;}; int GetNoZone(int iObjet) {if(iObjet >= 0 && iObjet < m_iNbObjet)return m_itabNoZone[iObjet]; else return -1;}; int GetNbObjet() {return m_iNbObjet;}; int GetNbArc() {return m_iNbArc;}; int GetNbPoints(); void Translation(double dXProj,double dYProj); //--- procdures de slection int SelectionnerUnObjet(double dX,double dY,double& dDistance); int SelectionnerUnArc(double dX,double dY,double& dDistance); int GetObjetSelection() {return m_iObjetSelection;}; int GetObjetSelection(int i) {if(i >= 0 && i < m_iNbObjetSelection)return m_itabObjetSelection[i]; else return -1;}; int GetNbObjetSelection() {return m_iNbObjetSelection;}; void SetObjetSelection(int iNo,int iModeSelection); void InitObjetSelection() {m_iObjetSelection=-1;m_iNbObjetSelection=0;}; int GetArcSelection() {return m_iArcSelection;}; int GetArcSelection(int i) {if(i >= 0 && i < m_iNbArcSelection)return m_itabArcSelection[i]; else return -1;}; int GetNbArcSelection() {return m_iNbArcSelection;}; void SetArcSelection(int iNo,int iModeSelection); void InitArcSelection(); BOOL IsSelectionFermee(); BOOL IsSelectionFermee(CDC* pDC); void SetArcSelectionZone(int iNoObjet,int iMode); void SelectionnerTousLesArcs(); void SelectionnerTousLesObjets(); void SelectionSurLaValeur(const char* chCle,double dValeurSelection); //--- procdures sur le undo void InitUndo() {m_itabTypeUndo[0]=UNDO_RIEN;m_ptabArcModifie[0]=NULL;} void RestaurerUnArc(int i); int AjouterUnObjet(double dXGeo,double dYGeo,const char* chCle,double dValeur); void ModifierUnObjet(int iNoObjet,const char* chCle,double dValeur);

496

Annexe
void SupprimerUnObjet(int iNoObjet,BOOL bSupprimerLesArcs); void void void void void GetPosVue(int iNoObjet,int &iXVue,int &iYVue); SetPosVue(int iNoObjet,int iXVue,int iYVue); GetCentreZoneVue(int iNoZone,int &iXVue,int &iYVue); GetPosGeo(int iNoObjet,double &dXGeo,double &dYGeo); SetPosGeo(int iNoObjet,double dXGeo,double dYGeo);

//--- pour le type ligne ou zone, fonctions sur les arcs int AjouterUnArc(int iNz1,int iNz2); void SupprimerUnArc(int iNoArc); BOOL FermerUnArc(int iNoArc); BOOL JoindreDeuxArcs(int iNoArcReference,int iNoArcAModifier); BOOL ReunirDeuxArcs(int iNoArc1,int iNoArc2); BOOL FusionnerDeuxArcs(int iNoArcReference,int iNoArcAModifier); int DiviserUnArc(int iNoArc,double dXGeo,double dYGeo); int CouperUnArc(int iNoArc,double dXGeo,double dYGeo,int iNoPoint); int CouperUnArc(int iNoArc,int iNoPoint); BOOL UnirUnArc(int iNoArc); void DeplacerLaSelection(int iTranslationX,int iTranslationY); void DupliquerLaSelection(int iTranslationX,int iTranslationY); void ExclureTousLesArcs(); void FiltrerTousLesArcs(double dSurfaceMinimum); int JoindreTousLesArcsValeur(double dDistanceEnMetre,int iNbIterations); int JoindreTousLesArcs(double dDistanceEnMetre,int iNbIterations); int ReunirTousLesArcs(); int DiviserEtJoindreParIntersection(); int DiviserEtJoindreParExtremite(double dDistanceEnMetre); void CalculFenetreDesArcs(); void ModifierParIntersection(BOOL bValeurInitiale,double dValeurMinimum,double dIntervalle,double dLong1,double dColat1,double dLong2,double dColat2); void BougerLesNoeuds(double dXGeoOld,double dYGeoOld,double dXGeo,double dYGeo); //--- procdures de test void TestValeur(double dIntervalleMaximum,double dIntervalleMinimum); void TestLigneValeur(CDC* pDC,int iNoArc,double dIntervalleMaximum,double dIntervalleMinimum); void TestSimplicite(); void TestExtraSimplicite(); void Rasteriser(const char* chNomFichierImage); BOOL IsZoneFermee(int iNoZone); //--- procdures de trac des documents void Tracer(CDC* pDC); void TracerUnObjet(CDC* pDC,int iNoObjet,COLORREF Couleur); void TracerUnArc(CDC* pDC,int iNoArc); void TracerUnArc(CDC* pDC,int iNoArc,COLORREF Couleur); void TracerLaSelection(CDC* pDC,int iTranslationX,int iTranslationY); void TracerFermeture(CDC* pDC);

};

De nombreuses mthodes de cette classe sont lies la vrification de contraintes dintgrit spatiale ou au netoyage de documents imports partir dautres systmes. Par exemple, la mthode SupprimerLesArcsEnDouble() permet dliminer les arcs qui apparaissent deux fois dans le document, comme cest la cas de tous les arcs directement imports dun document au format ShapeFile.
int CSaveditDocument::SupprimerLesArcsEnDouble() { if(IsOuvert() == FALSE)return -1; if(IsTypeZone() == FALSE)return -1; int iNbArcSupprimes=0; CArcMygale *pArc1,*pArc2; bool bOui; int iNoZone1,iNoZone2,iNoZone3,iNoZone4; int iArc1,iArc2,iNbpt1,iNbpt2,iPointDebut1,iPointDebut2,iPointFin1,iPointFin2,iNbCommuns; int i,j,iSens; double dX,dY,dX1,dY1,dX2,dY2; double dXMinArc1,dYMinArc1,dXMaxArc1,dYMaxArc1; double dXMinArc2,dYMinArc2,dXMaxArc2,dYMaxArc2; CPointMygale point; iArc1=0;

Structures et mthodes : implmentation 497

while(iArc1 < m_iNbArc) { pArc1=m_ptabArc[iArc1]; if(pArc1 != NULL) { iNoZone1=pArc1->GetNoZone1(); iNoZone2=pArc1->GetNoZone2(); if(iNoZone1 < 20 || iNoZone2 < 20) { //--- l'arc 1 est candidat pArc1->GetFenetreSav(dXMinArc1,dYMinArc1,dXMaxArc1,dYMaxArc1); iArc2=iArc1+1; while(iArc2 < m_iNbArc) { pArc2=m_ptabArc[iArc2]; if(pArc2 != NULL) { iNoZone3=pArc2->GetNoZone1(); iNoZone4=pArc2->GetNoZone2(); if(iNoZone3 < 20 || iNoZone4 < 20) { //--- intersection des fentres ? pArc2->GetFenetreSav(dXMinArc2,dYMinArc2,dXMaxArc2,dYMaxArc2); if(dXMaxArc2 >= dXMinArc1 && dXMinArc2 <= dXMaxArc1 && dYMaxArc2 >= dYMinArc1 && dYMinArc2 <= dYMaxArc1) { //--- recherche d'une squence commune entre arc 1 et arc 2 iNbpt1=pArc1->GetNbpt(); iNbpt2=pArc2->GetNbpt(); iPointDebut1=0; while(iPointDebut1 < iNbpt1) { pArc1->GetPoint(iPointDebut1,dX1,dY1); iPointDebut2=0; while(iPointDebut2 < iNbpt2) { pArc2->GetPoint(iPointDebut2,dX2,dY2); if(dX1 == dX2 && dY1 == dY2) { //--- un point identique, on cherche les suivants dans un sens iNbCommuns=1; iPointFin1=iPointDebut1; iPointFin2=iPointDebut2; bOui=TRUE; while(iPointFin1 < iNbpt1-1 && iPointFin2 < iNbpt2-1 && bOui) { pArc1->GetPoint(iPointFin1+1,dX1,dY1); pArc2->GetPoint(iPointFin2+1,dX2,dY2); if(dX1 == dX2 && dY1 == dY2) { iNbCommuns++; iPointFin1++; iPointFin2++; } else bOui=FALSE; } if(iNbCommuns == 1) { //--- on essaye dans l'autre sens iPointFin1=iPointDebut1; iPointFin2=iPointDebut2; bOui=TRUE; while(iPointFin1 < iNbpt1-1 && iPointFin2 > 0 && bOui) { pArc1->GetPoint(iPointFin1+1,dX1,dY1); pArc2->GetPoint(iPointFin2-1,dX2,dY2); if(dX1 == dX2 && dY1 == dY2) { iNbCommuns++; iPointFin1++; iPointFin2--; } else bOui=FALSE; } } if(iNbCommuns > 1) { //--- des points en commun, arc 1 dcouper iSens=pArc1->GetSens(); if(iPointFin1 < iNbpt1-1)

498

Annexe
{ //--- bout final if(m_iNbArc >= NB_MAX_ARC)return iNbArcSupprimes; m_ptabArc[m_iNbArc]=new CArcMygale(iNbpt1-iPointFin1+1); if(m_ptabArc[m_iNbArc] == NULL)return iNbArcSupprimes; j=0; for(i=iPointFin1;i < iNbpt1;i++) { pArc1->GetPoint(i,dX,dY); point.Set(dX,dY); m_ptabArc[m_iNbArc]->SetPointGrow(j,point); j++; } m_ptabArc[m_iNbArc]->SetSens(iSens); m_ptabArc[m_iNbArc]->SetNbpt(j); m_ptabArc[m_iNbArc]->SetNoZone1(iNoZone1); m_ptabArc[m_iNbArc]->SetNoZone2(iNoZone2); m_ptabArc[m_iNbArc]->CalculFenetreSav(); m_iNbArc++; } if(iPointDebut1 > 0) { //--- bout initial if(m_iNbArc >= NB_MAX_ARC)return iNbArcSupprimes; m_ptabArc[m_iNbArc]=new CArcMygale(iPointDebut1+1); if(m_ptabArc[m_iNbArc] == NULL)return iNbArcSupprimes; j=0; for(i=0;i <= iPointDebut1;i++) { pArc1->GetPoint(i,dX,dY); point.Set(dX,dY); m_ptabArc[m_iNbArc]->SetPointGrow(j,point); j++; } m_ptabArc[m_iNbArc]->SetSens(iSens); m_ptabArc[m_iNbArc]->SetNbpt(j); m_ptabArc[m_iNbArc]->SetNoZone1(iNoZone1); m_ptabArc[m_iNbArc]->SetNoZone2(iNoZone2); m_ptabArc[m_iNbArc]->CalculFenetreSav(); m_iNbArc++; } if(iNoZone1 == iNoZone3 && iNoZone1 >= 20) { //--- suppression de l'arc qui reste, car mme zone adjacente SupprimerUnArc(iArc1); iNbArcSupprimes++; } else { //--- arranger l'arc iArc1 avec les points communs j=0; for(i=iPointDebut1;i <= iPointFin1;i++) { pArc1->GetPoint(i,dX,dY); pArc1->SetPoint(j,dX,dY); j++; } pArc1->SetNbpt(j); if(iNoZone1 < 20) { if(iNoZone3 >= 20) { pArc1->SetNoZone1(iNoZone3); pArc1->SetNoZone2(2); } else { pArc1->SetNoZone1(0); pArc1->SetNoZone2(0); } } else { if(iNoZone1 < iNoZone3) { pArc1->SetNoZone1(iNoZone1); pArc1->SetNoZone2(iNoZone3); }

Structures et mthodes : implmentation 499

else

} } //--- arc 2 Ordonner(iPointDebut2,iPointFin2); iSens=pArc2->GetSens(); if(iPointFin2 < iNbpt2-1) { //--- bout final if(m_iNbArc >= NB_MAX_ARC)return iNbArcSupprimes; m_ptabArc[m_iNbArc]=new CArcMygale(iNbpt2-iPointFin2+1); if(m_ptabArc[m_iNbArc] == NULL)return iNbArcSupprimes; j=0; for(i=iPointFin2;i < iNbpt2;i++) { pArc2->GetPoint(i,dX,dY); point.Set(dX,dY); m_ptabArc[m_iNbArc]->SetPointGrow(j,point); j++; } m_ptabArc[m_iNbArc]->SetSens(iSens); m_ptabArc[m_iNbArc]->SetNbpt(j); m_ptabArc[m_iNbArc]->SetNoZone1(iNoZone3); m_ptabArc[m_iNbArc]->SetNoZone2(iNoZone4); m_ptabArc[m_iNbArc]->CalculFenetreSav(); m_iNbArc++; } if(iPointDebut2 > 0) { //--- bout initial if(m_iNbArc >= NB_MAX_ARC)return iNbArcSupprimes; m_ptabArc[m_iNbArc]=new CArcMygale(iPointDebut2+1); if(m_ptabArc[m_iNbArc] == NULL)return iNbArcSupprimes; j=0; for(i=0;i <= iPointDebut2;i++) { pArc2->GetPoint(i,dX,dY); point.Set(dX,dY); m_ptabArc[m_iNbArc]->SetPointGrow(j,point); j++; } m_ptabArc[m_iNbArc]->SetSens(iSens); m_ptabArc[m_iNbArc]->SetNbpt(j); m_ptabArc[m_iNbArc]->SetNoZone1(iNoZone3); m_ptabArc[m_iNbArc]->SetNoZone2(iNoZone4); m_ptabArc[m_iNbArc]->CalculFenetreSav(); m_iNbArc++; } SupprimerUnArc(iArc2); iNbArcSupprimes++; pArc1=NULL; pArc2=NULL; //--- on recommence InitUndo(); ASauver(); goto SUITE; } } iPointDebut2++; } iPointDebut1++; }

{ if(iNoZone3 >= 20) { pArc1->SetNoZone1(iNoZone3); pArc1->SetNoZone2(iNoZone1); } else { pArc1->SetNoZone1(iNoZone1); pArc1->SetNoZone2(2); } }

} } } iArc2++;

500

Annexe

} } } iArc1++; SUITE: i=0; } return iNbArcSupprimes; }

La mthode IsZoneFermee() teste la fermeture dune zone, en calculant loccurrence des extremits des arcs de la zone :
BOOL CSaveditDocument::IsZoneFermee(int iNoZone) { int i,j,iNoZone1,iNoZone2,iNbpt,iNbBout,itabNb[NB_MAX_SELECTION]; BOOL bTrouve; double dXGeo,dYGeo,dtabX[NB_MAX_SELECTION],dtabY[NB_MAX_SELECTION]; if(iNoZone < 20 || iNoZone > m_iNoZoneLibre)return FALSE; iNbBout=0; for(i=0;i < m_iNbArc;i++) { iNoZone1=m_ptabArc[i]->GetNoZone1(); iNoZone2=m_ptabArc[i]->GetNoZone2(); if(iNoZone1 == iNoZone || iNoZone2 == iNoZone) { iNbpt=m_ptabArc[i]->GetNbpt(); m_ptabArc[i]->GetPoint(0,dXGeo,dYGeo); bTrouve=FALSE; for(j=0;j < iNbBout;j++) { if(dtabX[j] == dXGeo && dtabY[j] == dYGeo) { itabNb[j]=1-itabNb[j]; bTrouve=TRUE; break; } } if(bTrouve == FALSE) { dtabX[iNbBout]=dXGeo; dtabY[iNbBout]=dYGeo; itabNb[iNbBout]=1; iNbBout++; } m_ptabArc[i]->GetPoint(iNbpt-1,dXGeo,dYGeo); bTrouve=FALSE; for(j=0;j < iNbBout;j++) { if(dtabX[j] == dXGeo && dtabY[j] == dYGeo) { itabNb[j]=1-itabNb[j]; bTrouve=TRUE; break; } } if(bTrouve == FALSE) { dtabX[iNbBout]=dXGeo; dtabY[iNbBout]=dYGeo; itabNb[iNbBout]=1; iNbBout++; } } } for(j=0;j < iNbBout;j++) { if(itabNb[j] != 0)return FALSE; } return TRUE; }

Structures et mthodes : implmentation 501 La mthode TestValeur() permet de mettre en vidence les erreurs de valeur numrique pour des courbes de niveaux (document de type Ligne, saisie par valeur numrique). On calcule pour cela les intersections de toutes les lignes saisies avec des lignes horizontales (y=constante), en testant ensuite les diffrences de valeur entre deux points dintersection conscutifs.
void CSaveditDocument::TestValeur(double dIntervalleMaximum,double dIntervalleMinimum) { if(IsOuvert() == FALSE)return; if(m_iTypeObjet != TYPE_LIGNE_MYGALE)return; if(m_iTypeSaisie != SAISIE_VALEUR && m_iTypeSaisie != SAISIE_CLEVALEUR)return; if(m_iNbObjet == 0)return; int i,j,iNbpt,iNoObjet1,iNoObjet2; double dValeur1,dValeur2,dDifference; double dFx1,dFy1,dFx2,dFy2; double dXMin,dYMin,dXMax,dYMax; double dX0,dY0,dX1,dY1,dXGeo,dYGeo; double dX,dY,dXa,dYa,dXb,dYb,dIntervalleLigne; for(i=0;i < NB_MAX_OBJET;i++)m_itabNoZone[i]=0; //-- calcul de la fentre du document, en coordonnes savane int iNbLignesRaster=500 ; FenetreSav(dFx1,dFy1,dFx2,dFy2); dIntervalleLigne=(dFy2-dFy1)/iNbLignesRaster; double dMarge=(dFy2-dFy1)/20.; dY=dFy1 + dMarge; while(dY <= dFy2 - dMarge) { //--- Pour chaque ligne raster, calcul des intersections CChaine chaine; for(i=0;i < NB_MAX_ARC;i++) { //--- intersections de l'arc avec la ligne if(m_ptabArc[i] != NULL) { m_ptabArc[i]->GetFenetreSav(dXMin,dYMin,dXMax,dYMax); if(dY >= dYMin && dY <= dYMax) { iNbpt=m_ptabArc[i]->GetNbpt(); m_ptabArc[i]->GetPoint(0,dXGeo,dYGeo); wind.GeoToSav(dXGeo,dYGeo,dX0,dY0); for(j=1;j < iNbpt;j++) { m_ptabArc[i]->GetPoint(j,dXGeo,dYGeo); wind.GeoToSav(dXGeo,dYGeo,dX1,dY1); //--- ordre sur Y if(dY1 > dY0) { dXa=dX0; dYa=dY0; dXb=dX1; dYb=dY1; } else { dXa=dX1; dYa=dY1; dXb=dX0; dYb=dY0; } //--- intersection if(dY >= dYa && dY <= dYb) { if(dYa == dYb)dX=dXa; else dX=((dXb-dXa)*(dY-dYa)/(dYb-dYa)) + dXa; chaine.InsererCellule(dX,i); } dX0=dX1; dY0=dY1; }

502

Annexe
} } } //--- test des diffrences CCellule* pCellule=chaine.m_ptrDebut; while(pCellule != NULL) { iNoObjet1=pCellule->m_iNoObjet; dValeur1=m_dtabValeur[iNoObjet1]; pCellule=pCellule->m_ptrSuivant; if(pCellule != NULL) { iNoObjet2=pCellule->m_iNoObjet; dValeur2=m_dtabValeur[iNoObjet2]; //--- tests if(dIntervalleMaximum > 0.) { dDifference=fabs(dValeur2-dValeur1); if(dDifference > dIntervalleMaximum) { m_itabNoZone[iNoObjet1]=1; m_itabNoZone[iNoObjet2]=1; } } if(dIntervalleMinimum > 0.) { dDifference=fabs(dValeur2-dValeur1); if(dDifference < dIntervalleMinimum) { m_itabNoZone[iNoObjet1]=1; m_itabNoZone[iNoObjet2]=1; } } } } dY+=dIntervalleLigne; }

Nous prsentons enfin des extraits des mthodes de lecture des documents SAVEDIT pour chaque type de document (point, ligne, zone), ce qui nous permet de montrer le format de stockage de ces documents. Format des documents de type point :
m_iNbObjet=0; while(fread(buffer,iTailleBuffer,1,FileObjets) == 1) { memcpy(&dLong,&buffer[0],8); memcpy(&dColat,&buffer[8],8); m_dtabPoint[iIndice]=dLong; iIndice++; m_dtabPoint[iIndice]=dColat; iIndice++; switch(m_iTypeSaisie) { case SAISIE_VALEUR: memcpy(&m_dtabValeur[m_iNbObjet],&buffer[16],8); break; case SAISIE_CLE: memcpy(&m_ctabCle[m_iNbObjet*m_iNbcharCle],&buffer[16],m_iNbcharCle); break; case SAISIE_CLEVALEUR: memcpy(&m_dtabValeur[m_iNbObjet],&buffer[16],8); memcpy(&m_ctabCle[m_iNbObjet*m_iNbcharCle],&buffer[24],m_iNbcharCle); break; default: break; } m_iNbObjet++;

Structures et mthodes : implmentation 503

}

Pour les lignes, la procdure de lecture est la suivante :

CPointMygale point; strcpy(chNomFichierObjets,m_chNomFichier); strcat(chNomFichierObjets,".lg"); FILE* FileObjets=fopen(chNomFichierObjets,"rb"); if(FileObjets == NULL) { ::ErreurDeFichier(chNomFichierObjets); if(m_ctabCle != NULL)free(m_ctabCle); if(m_dtabValeur != NULL)free(m_dtabValeur); m_ctabCle=NULL; m_dtabValeur=NULL; return FALSE; } int iTailleBuffer=8; //--- pour nbpt et sens if(m_iTypeSaisie == SAISIE_VALEUR || m_iTypeSaisie == SAISIE_CLEVALEUR)iTailleBuffer+=8; if(m_iTypeSaisie == SAISIE_CLE || m_iTypeSaisie == SAISIE_CLEVALEUR)iTailleBuffer+=m_iNbcharCle; int iIndice=0; int i,iNbpt,iSens;while(fread(buffer,iTailleBuffer,1,FileObjets) == 1) { memcpy(&iNbpt,&buffer[0],4); memcpy(&iSens,&buffer[4],4); switch(m_iTypeSaisie) { case SAISIE_VALEUR: memcpy(&m_dtabValeur[m_iNbObjet],&buffer[8],8); break; case SAISIE_CLE: memcpy(&m_ctabCle[m_iNbObjet*m_iNbcharCle],&buffer[8],m_iNbcharCle); break; case SAISIE_CLEVALEUR: memcpy(&m_dtabValeur[m_iNbObjet],&buffer[8],8); memcpy(&m_ctabCle[m_iNbObjet*m_iNbcharCle],&buffer[16],m_iNbcharCle); break; default: break; } //--- lecture de l'arc m_ptabArc[m_iNbArc]=new CArcMygale(iNbpt); if(m_ptabArc[m_iNbArc] == NULL) { ::ErreurDeMemoire(); fclose(FileObjets); if(m_ctabCle != NULL)free(m_ctabCle); if(m_dtabValeur != NULL)free(m_dtabValeur); m_ctabCle=NULL; m_dtabValeur=NULL; for(i=0;i < NB_MAX_ARC;i++) { if(m_ptabArc[i] != NULL)delete m_ptabArc[i]; m_ptabArc[i]=NULL; } return FALSE; } for(i=0;i < iNbpt;i++) { if(fread(buffer,16,1,FileObjets) != 1) { ::ErreurDeFichier(chNomFichierObjets); fclose(FileObjets); if(m_ctabCle != NULL)free(m_ctabCle); if(m_dtabValeur != NULL)free(m_dtabValeur); m_ctabCle=NULL; m_dtabValeur=NULL; for(int i=0;i < NB_MAX_ARC;i++) {

504

Annexe

if(m_ptabArc[i] != NULL)delete m_ptabArc[i]; m_ptabArc[i]=NULL; } return FALSE; } memcpy(&point.m_dX,&buffer[0],8); memcpy(&point.m_dY,&buffer[8],8); m_ptabArc[m_iNbArc]->SetPointGrow(i,point); } m_ptabArc[m_iNbArc]->SetNbpt(iNbpt); m_ptabArc[m_iNbArc]->SetSens(iSens); //--- calcul de la fentre de l'arc m_ptabArc[m_iNbArc]->CalculFenetreSav(); m_iNbArc++; m_iNbObjet++; } fclose(FileObjets);

Enfin, pour les zones, la procdure de lecture est la suivante :

FILE* FileObjets=fopen(chNomFichierObjets,"rb"); if(FileObjets == NULL) { ::ErreurDeFichier(chNomFichierObjets); free(m_dtabPoint); if(m_ctabCle != NULL)free(m_ctabCle); if(m_dtabValeur != NULL)free(m_dtabValeur); m_dtabPoint=NULL; m_ctabCle=NULL; m_dtabValeur=NULL; return FALSE; } int iTailleBuffer=20; if(m_iTypeSaisie == SAISIE_VALEUR || m_iTypeSaisie == SAISIE_CLEVALEUR)iTailleBuffer+=8; if(m_iTypeSaisie == SAISIE_CLE || m_iTypeSaisie == SAISIE_CLEVALEUR)iTailleBuffer+=m_iNbcharCle; int iNoZone,iIndice; double dLong,dColat; iIndice=0; while(fread(buffer,iTailleBuffer,1,FileObjets) == 1) { memcpy(&iNoZone,&buffer[0],4); memcpy(&dLong,&buffer[4],8); memcpy(&dColat,&buffer[12],8); m_itabNoZone[m_iNbObjet]=iNoZone; if(iNoZone >= m_iNoZoneLibre)m_iNoZoneLibre=iNoZone+1; m_dtabPoint[iIndice]=dLong; iIndice++; m_dtabPoint[iIndice]=dColat; iIndice++; switch(m_iTypeSaisie) { case SAISIE_VALEUR: memcpy(&m_dtabValeur[m_iNbObjet],&buffer[20],8); break; case SAISIE_CLE: memcpy(&m_ctabCle[m_iNbObjet*m_iNbcharCle],&buffer[20],m_iNbcharCle); break; case SAISIE_CLEVALEUR: memcpy(&m_dtabValeur[m_iNbObjet],&buffer[20],8); memcpy(&m_ctabCle[m_iNbObjet*m_iNbcharCle],&buffer[28],m_iNbcharCle); break; default: break; } m_iNbObjet++; } fclose(FileObjets);

Structures et mthodes : implmentation 505

//--- lecture des arcs FILE* FileArcs=fopen(chNomFichierArcs,"rb"); if(FileArcs == NULL) { ::ErreurDeFichier(chNomFichierArcs); free(m_dtabPoint); if(m_ctabCle != NULL)free(m_ctabCle); if(m_dtabValeur != NULL)free(m_dtabValeur); m_dtabPoint=NULL; m_ctabCle=NULL; m_dtabValeur=NULL; return FALSE; } iTailleBuffer=16; //--- pour nbpt,sens,iNz1,iNz2 int i,iNbpt,iSens,iNz1,iNz2; CPointMygale point; while(fread(buffer,iTailleBuffer,1,FileArcs) == 1) { memcpy(&iNbpt,&buffer[0],4); memcpy(&iSens,&buffer[4],4); memcpy(&iNz1,&buffer[8],4); memcpy(&iNz2,&buffer[12],4); //--- lecture de l'arc m_ptabArc[m_iNbArc]=new CArcMygale(iNbpt); if(m_ptabArc[m_iNbArc] == NULL) { ::ErreurDeMemoire(); fclose(FileArcs); free(m_dtabPoint); if(m_ctabCle != NULL)free(m_ctabCle); if(m_dtabValeur != NULL)free(m_dtabValeur); m_dtabPoint=NULL; m_ctabCle=NULL; m_dtabValeur=NULL; for(i=0;i < NB_MAX_ARC;i++) { if(m_ptabArc[i] != NULL)delete m_ptabArc[i]; m_ptabArc[i]=NULL; } return FALSE; } for(i=0;i < iNbpt;i++) { if(fread(buffer,16,1,FileArcs) != 1) { ::ErreurDeFichier(chNomFichierArcs); fclose(FileArcs); free(m_dtabPoint); if(m_ctabCle != NULL)free(m_ctabCle); if(m_dtabValeur != NULL)free(m_dtabValeur); m_dtabPoint=NULL; m_ctabCle=NULL; m_dtabValeur=NULL; for(int i=0;i < NB_MAX_ARC;i++) { if(m_ptabArc[i] != NULL)delete m_ptabArc[i]; m_ptabArc[i]=NULL; } return FALSE; } memcpy(&point.m_dX,&buffer[0],8); memcpy(&point.m_dY,&buffer[8],8); m_ptabArc[m_iNbArc]->SetPointGrow(i,point.m_dX,point.m_dY); } m_ptabArc[m_iNbArc]->SetNbpt(iNbpt); m_ptabArc[m_iNbArc]->SetSens(iSens); m_ptabArc[m_iNbArc]->SetNoZone1(iNz1); m_ptabArc[m_iNbArc]->SetNoZone2(iNz2); //--- calcul de la fentre de l'arc m_ptabArc[m_iNbArc]->CalculFenetreSav(); m_iNbArc++;

506

Annexe

} fclose(FileArcs);

RESUME
Cet ouvrage prsente un travail de recherche et de dveloppement informatique visant apporter une rponse concrte la question suivante : comment construire un systme dinformation gographique complet et oprationnel, en suivant les principes thoriques de la gestion de donnes et en les adaptant aux donnes gographiques ? . Le sujet principal de cet ouvrage est de montrer sur un exemple concret limplication des principes thoriques de la gestion de donnes dans la ralisation pratique dun logiciel de type SIG. Elle prsente l'architecture et la ralisation dun systme d'information gographique oprationnel le systme SAVANE - partir des nombreux concepts, techniques et algorithmes ncessaires cette ralisation. Ce travail de recherche a t effectu dans le cadre de lIRD (Institut de recherche pour le dveloppement). Louvrage expose lensemble des principes ncessaires la ralisation et la bonne utilisation dun SIG, en dcrivant chaque aspect ncessaire la construction du systme et en expliquant les choix effectus, selon la dmarche suivante : - exposer avec prcision tous les aspects concernant la dfinition et lutilisation de linformation gographique ; - exposer et dvelopper les principes de la gestion de donnes (modle relationnel et objet) pour les tendre aux donnes localises ; - dvelopper ou mettre en uvre les algorithmes ncessaires limplantation de ces principes dans un systme dinformation ; - construire un systme oprationnel, mettant en uvre les principes thoriques et rpondant un cahier des charges fonctionnel couvrant lensemble des besoins ncessaires lutilisation de ce systme dans le cadre de projets appliqus, notamment en gographie et dans le cadre de la recherche pour le dveloppement.. L'expos des mthodes est souvent suivi de la prsentation d'algorithmes et de leur ralisation concrte. Des rfrences renvoient frquemment le lecteur une annexe contenant limplantation effective des structures et des algorithmes.