Les Principes Des Système D'information Géographique

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.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.1. La restriction spatiale par fentre dtude
5.5.9.1.2. La restriction spatiale par domaine
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

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

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 :

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 :

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
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

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].

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.

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.

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

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
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

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

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

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.

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 :

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

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

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

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
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
Chapitre 3
Ville
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 h
P
P
b
O
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
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).

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
a (mtres)
Aplatissement (a-b)/a
Airy 1830
6377563.396
1/299.3249646
Australian National
6378160
1/298.25
Bessel 1841 (Ethiopie, Indonesie, Japon, Core)
6377397.155
1/299.1528128
Bessel 1841 (Namibie)
6377483.865
1/299.1528128
Clarke 1866
6378206.4
1/294.9786982
Clarke 1880
6378249.145
1/293.465
Everest
6377298.556
1/300.8017
6377276.345
1/300.8017
Everest India 1956
6377301.243
1/300.8017
Everest Malaisie occidentale, Singapour
6377304.063
1/300.8017
Brunei, Malaisie orientale (Sabah, Sarawak)

Everest India 1830

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

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

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

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

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 :

- 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

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

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

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;
Ellipsoide(6378249.2,0.00680348765);
Lambert III Sud (tangente) :

Ellipsoide(6378249.2,0.00680348765);
Lambert IV Corse (tangente) :

Ellipsoide(6378249.2,0.00680348765);
Coordonnes au point dorigine : 234.358,185361.369;
Eurolambert (tangente) :
Ellipsoide(6378388.2000,0.00672267002);
Lambert Etendu (tangente) :

Ellipsoide(6378249.0000,0.00680348765);
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);
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

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.

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

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,

- 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

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.

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

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.

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

(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

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

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.
P2
P1
P3
profils
Z1
Z3
potentialits
Z2
jointure
P1
P2
P3
couleur
rouge
jaune
ocre
Ph
7.5
5.8
6.5
Z1
Z2
Z3
pente
10-20
20-30
10-20
pierrosit
faible
moyenne
trs faible
salinit
faible
trs faible
moyenne
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
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.

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.

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

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
C
A
G
B
C
F
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

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.

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

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
Objets de type point
feuille i
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 :

- 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
feuille j
Objets de type ligne
x,y, ptrarc,v1,v2,...
x,y, ptrarc,v1,v2,...
....
x,y,ptrarc,v1,v2,...
x,y,ptrarc,v1,v2,...
....
Arcs gomtriques
iarc,isens,nbpt,ptr,xb,yb,xh,yh
x,y,.....,x,y
x,y,.....,x,y
x,y,.....,x,y
x,y,.....,x,y
.....
.....
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 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
nz,x,y,xb,yb,xh,yh,v1,v2,...
....
....
Arcs gomtriques
nz1,nz2,nbpt,ptr,xb,yb,xh,yh
x,y,.....,x,y
x,y,.....,x,y
x,y,.....,x,y
x,y,.....,x,y
.....
.....
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).

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

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

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

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

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

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

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

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)

{
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;
{
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_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

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
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

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

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.
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
et Sminaires, Traitement des donnes localises, 1986,Editions de lOrstom
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
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.
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
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 :
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.
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
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 ;
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
...
Valeurs des pixels, imagette j
imagette j
...
fig. 6.3 : structure interne des relations mosaques
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) ;
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
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.
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
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.
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
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.
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
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.
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
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
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).
arc simple
235
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.
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
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.
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
Le groupe Point / Point

Dfinition mathmatique
(P1 P2 = 0)
(P1 P2 = )
Nombre de
relations
1
1
Le groupe Point / Ligne

EXTREMITE
SUR
DISJOINT
(P L = 0)
(P L = 0)
(P L = )(P L = )
Le groupe Point / Polygone
1
1
1

DANS
SUR
DISJOINT
(P R = 0)
(P R = 0)
(P R = )(P R = )
Le groupe Ligne / Ligne
CROISE
(L1 L2 = 0)
11
JOINT
(L1 L2 = 0)
14
RENCONTRE
(L1 L2 = 0)
23
COUVRE
(L1 L2 = 1)
13
DISJOINT
(L1 L2 = )(L1 L2 = )
243
1
1
1
(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
9
10
12
11
13
1
CONTIENT-DANS
(R1 R2 = 2)(R1 R2 = )
DEHORS
(R1 R2 = )
(R1 R2 = 2)(R1 R2 = 1)
RECOUVRE
2
1
BORDE
(R1 R2 = 1)
(R1 R2 = )(R1 R2 = 0)
(R1 R2 = )(R1 R2 = 1)
DISJOINT
(R1 R2 = )(R1 R2 = )
RENCONTRE
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.
245
7.4.1. Les diffrentes mthodes de stockage

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
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).
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.
251
7.5.2. Les contraintes sur les objets gomtriques

7.5.2.1. Les classes CArc et CSaveditDocument
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.
253
7.5.2.6. Suppression darcs en double

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.
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.
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
259
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
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.
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
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
[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
263
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 :
n
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)
p1(v1)
v(Pk) d(Pij,Pm)
p3(v3)
p8(v8)
v(Pij) =
p4(v4)
p7(v7)
p5(v5)
p6(v6)
k=1
8
m=1
m=k
m=1
k=1 m=k
d(Pij,Pm)
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
[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
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
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.
logique de sa construction, cette

chapitres ne reflte pas toujours
techniques sinscrivent dans cette
approfondie, rflexion qui a elle-
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
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
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
[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
et Sminaires sur le Traitement des donnes localises, Paris, Editions de lORSTOM, 1986,
p. 29-87
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];
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;
}

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];
strcpy(chNomRelationLocal,chNomRelation);
strcpy(chNom2Local,chNom2);
if(strlen(chNom2Local) == 0)strcpy(chNom2Local,"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;
chNom3Local[8]=0;
chNom4Local[8]=0;
if(fseek(m_FileBase,adr,SEEK_SET) != 0)return FALSE;
{
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;
}
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(2,m_chNomFichierFeuille) == FALSE)return FALSE;
iPbl++;
iNbRelations++;
break;
case 2:
case 4:
if(base.NouveauFichier(2,m_chNomFichierFeuille) == FALSE)return FALSE;
if(base.NouveauFichier(3,m_chNomFichierArc) == FALSE)return FALSE;
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.

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

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);
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++;
}
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 g_irep1=24;

else
else
else
else

g_irep2=24;

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,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;

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(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);
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)
{
if(ftabCode != NULL)free(ftabCode);
if(ctabNewCle != NULL)free(ctabNewCle);
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);
{
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)

{
i=strlen(chCle);
memcpy(&ctabNewCle[iNbNewValeurs*iNbcarSavane],chCle,i);
iNbNewValeurs++;
iCode=iNbvalb + iNbNewValeurs;
}
}
ftabCode[iNoTuple]=(float) iCode;
iNoTuple++;
}
}
}
else
{
//--- pas de valeurs dj introduites, codification directe des cls
iNoTuple=0;
fseek(FileMygalePoint,0L,SEEK_SET);
{
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++;
}
//--- criture dans les tuples des relations

long fValUnix;
int iPtr=iSavanePtrTupleFeuille;
iNoTuple=0;
while(iNoTuple < iNbTupleFeuille)
{
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);
}
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();
int NbMaxObjetsParFeuille();
int NbMaxArcsParFeuille();
void MiseAJour(int iNoFichier);

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;
5)
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");
5)
if(FileFeuille != NULL)
{
int iNbObj;
while(fscanf(FileFeuille,"%*17c%8f%8f%8f%8f%8i%*25c",&fXb,&fYb,&fXh,&fYh,&iNbObj) ==
{
if(iNbMaxObjetsParFeuille < iNbObj)iNbMaxObjetsParFeuille=iNbObj;
}
}
break;
}
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 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;

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;
{
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;
{
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;

}
//--- 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;
{
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,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,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
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
if(strcmp(m_pRelations[iNoth]->m_chFichArc,chNomFichier) != 0)
{
strcpy(m_pRelations[iNoth]->m_chFichArc,chNomFichier);
bModifie=TRUE;
}
}
}
== 0)
== 0)
//--- 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
}
k++;
}
{
if(m_pRelations[iNoth]->m_pAttributs[iNoatt]->m_iNbvalb != iNbvalb)
{
bModifie=TRUE;
}
if(m_pRelations[iNoth]->m_pAttributs[iNoatt]->m_iPtrval != iPtrval)
{
bModifie=TRUE;
}
}
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--;

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)
{
{
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;
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_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)
{
{
case FRANCAIS:
default:
strcpy(chDescription,"sans description");
break;
case ESPAGNOL:
strcpy(chDescription,"sin descripcin");
break;
case ANGLAIS:
strcpy(chDescription,"without description");
break;
}
}
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;

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;
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;
m_iNbarcFeuille=0;
m_iPtrarcFeuille=0;
}
return -1;
}
break;
case 3:
{

m_iNb++;
xc=UnixToDos(xc);
yc=UnixToDos(yc);
if(xc >= m_fWindXb && xc <= m_fWindXh && yc >= m_fWindYb && yc <= m_fWindYh)
{
return 1;
}
return 0;
}
else
{
//--- positionne sur le premier lment d'une feuille
int iPtr,iPtrObj;
while(fscanf(m_FileFeuille,"%*17c%8f%8f%8f%8f%8i%8i%*8i%*8i%*c",&fXb,&fYb,&fXh,&fYh,&m_iNbOb
j,&iPtrObj) == 6)
{
{
iPtr=(iPtrObj-1)*(m_iSizeIdentifiantTuple + m_iNb0*SIZEVAL);
m_iNb=1;
return 2;
}
}
return -1;
}
break;
case 2:
{
int iPtr;
fread(&m_iArc,SIZEINT,1,m_FileDescriptif);
fread(&m_iPtrarc,SIZEINT,1,m_FileDescriptif);
m_iArc=UnixToDos(m_iArc);
m_iPtrarc=UnixToDos(m_iPtrarc);
xc=UnixToDos(xc);
yc=UnixToDos(yc);
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)
{
return 1;
}
return 0;
}
else
{
//--- positionne sur le premier lment d'une feuille
int iPtr,iPtrObj,iNbarc,iPtrarc;
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)
{
{
iPtr=(iPtrObj-1)*(m_iNb0*SIZEVAL + m_iSizeIdentifiantTuple);
m_iNb=1;
return 2;
}
}
m_iNbarcFeuille=0;
m_iPtrarcFeuille=0;
return -1;
}
break;
case 1:
if(!feof(m_FileDescriptif))
{
return 1;
}
else return -1;
break;
case 14:
case 24:
if(m_iNbObj)
{
//--- il reste des objets a lire
fread(&nz,SIZEINT,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)
{
}
if(iNbarc == 0)return -1;
m_iNbObj=1;
return 2;
}
break;
case 13:

if(!feof(m_FileDescriptif))return 1;
else return -1;
break;
case 12:
fread(&m_iArc,SIZEINT,1,m_FileDescriptif);
fread(&m_iPtrarc,SIZEINT,1,m_FileDescriptif);
else return -1;
break;
case 11:
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;
{
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:

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 '>':
if(caractere == '=')return m_SymboleCourant=SUPERIEUREGAL;
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;
while(isdigit(caractere) || caractere == '.')
{
*p++=caractere;
}
*p=0;
m_dValeurNombre=atof(m_NomNombre);
return m_SymboleCourant=NOMBRE;
}
break;
394
Annexe
case 'v': // variable
case 'V':
{
char* p=m_chNomIdentifiant;
while(isdigit(caractere))
{
*p++=caractere;
}
*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);
}
break;
default :
if(isalpha(caractere))
{
char* p=m_chNomIdentifiant;
*p++=(char ) tolower(caractere);
while(isalpha(caractere))
{
*p++=(char ) tolower(caractere);
}
*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;
}
else if(strcmp(m_chNomIdentifiant,"e") == 0)
{
m_dValeurNombre= E;
}
}
ErreurDeSyntaxe("Erreur de syntaxe : symbole inconnu !");

return m_SymboleCourant=FIN;
break;
double CCalculateur::ConditionExpression()
{
double dGauche = ConditionTerme();
for(;;)
{
switch (m_SymboleCourant)
}
}
{
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();
{
case EGAL :
{
LireSymbole();
double dDroit=Expression();
if(dGauche == dDroit)return 1.; else return 0.;
}
case DIFFERENT :
{
LireSymbole();
if(dGauche != dDroit)return 1.; else return 0.;
}
case INFERIEUR :
{
LireSymbole();
if(dGauche < dDroit)return 1.; else return 0.;
}
case INFERIEUREGAL :
{
LireSymbole();
if(dGauche <= dDroit)return 1.; else return 0.;
}
case SUPERIEUR :
{
LireSymbole();
if(dGauche > dDroit)return 1.; else return 0.;
}
case SUPERIEUREGAL :
{
LireSymbole();
if(dGauche >= dDroit)return 1.; else return 0.;
}
}
}
double CCalculateur::Expression()
{
double dGauche = Terme();
for(;;)
{
{
case PLUS :
LireSymbole();
dGauche+=Terme();
break;
case MOINS :
LireSymbole();
396
}
}
Annexe
dGauche-=Terme();
break;
}
double CCalculateur::Terme()
{
double dGauche = Primaire();
for(;;)
{
{
case MUL:
LireSymbole();
dGauche*=Primaire();
break;
case DIV:
{
LireSymbole();
double d=Primaire();
if(d == 0)return ErreurDeCalcul("division par zro");
dGauche/=d;
}
break;
}
}
}
double CCalculateur::Primaire()
{
{
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();
if(d<-1. || d>1.)return ErreurDeCalcul("acos : erreur de domaine");
return acos(d);
}
case SIN :
LireSymbole();
return sin(Primaire());
case ASIN :
{
LireSymbole();
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 :

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();
if(d<=0)return ErreurDeCalcul("ln : erreur de domaine");
return log10(d);
}
case SQRT :
{
LireSymbole();
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
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();
LireSymbole(); // virgule
if(d2 == 0)return ErreurDeCalcul("mod : division par zro");
return fmod(d1,d2);
}
case SI :
{
LireSymbole();
double dCondition= ConditionExpression();
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();

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;
{
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_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++;
}
}
}
}
i=lecture.Lire(v);
}
lecture.Close();
}
}
else
{
int iPtrarc;
CArc arc;
CLecture lecture;
{
lecture.SetFenetreLecture(fWindXbSav,fWindYbSav,fWindXhSav,fWindYhSav);
FILE* FileArc=lecture.GetFileArc();
i=lecture.Lire(v);
while(i != -1)
{
if(i == 1)
{
{

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_itabNombre[i] > 0)m_ctabData[i]=1;
}
}
iNoRelation++;
}
//--- calcul de la moyenne par pixel a partir de la somme
{
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;
{
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];
CLecture lecture;
{
i=lecture.LireSansTestFenetre(v);
while(i != -1 && m_iNbLecture < m_iNbmaxObjets)
{
if(i == 1)
{
{
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,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");

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;
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;
}
}
}
}
}
}
}
}
}
break;
fclose(FileImage);
}
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)
{
{
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
{
{
du=1./m_dtabDistance[k];
ds1+=du;
ds2+=((double)m_ftabValeurVoisin[k]*du);
}
}
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;
}

else
{
{
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);
}
}
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]);
{
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;
{
dDistance=sqrt((dXProj-m_dtabX[i])*(dXProj-m_dtabX[i]) + (dYProj-m_dtabY[i])*(dYProjm_dtabY[i]));
{
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.;
{
{
dSomme+=((double)m_ftabValeur[i]*(m_dDistanceMax - dDistance)/m_dDistanceMax);
iNb++;
}
406
Annexe
}
else fSomme=(float) dSomme;
return fSomme;
}
break;
case INTERPOLATION_MOYENNE:
{
int iNb=0;
float fSomme;
double dDistance;
fSomme=0.F;
{
{
fSomme+=m_ftabValeur[i];
iNb++;
}
}
else fSomme/=iNb;
return fSomme;
}
break;
case INTERPOLATION_MOYENNE_DECROISSANTE:
{
int iNb=0;
float fSomme;
double dSomme,dDistance;
dSomme=0.;
{
{
dSomme+=((double)m_ftabValeur[i]*(m_dDistanceMax - dDistance)/m_dDistanceMax);
iNb++;
}
}
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;

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)
{
}
}
}
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)
{
{
{
}
else
{
{
}
}
}
iXp=iX;
iYp=iY;
}
nb++;
}
iX=(int) dXb;
iY=(int) dYb;
if(iX != iXp || iY != iYp)
{
{
{
}
else
{
{
}
}
}
}
}
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));
}
i++;
}
InsererCellule(nolig,nocol,iCode1,iCode2);
nolig++;
fX+=fP;
}
}
ptr=ptrSuivant;
iNb++;
}
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;
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;
}
}
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;

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;
&& 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;
return iType;
}
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];

}
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;
}
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;
}
else if(iType == 6)
{
x0=col+1.F;
y0=lig+0.5F;
xc=col+0.5F;
yc=lig+1.F;
icote1=2;
ilig1++;
}
break;
case 26:
x0=col+0.5F;
y0=lig;
xc=col+0.5F;
yc=lig+0.5F;
fin1=1;
break;
case 27:
x0=col;
y0=lig+0.5F;
xc=col+0.5F;
yc=lig+0.5F;
fin1=1;
break;
default:
break;
}
iNza=19+iNz1;
iNzb=19+iNz2;
nbpt1=0;
lig1x[nbpt1]=x0;
lig1y[nbpt1]=y0;
416
etc.
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);
{
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)
{
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);
{
lig1x[nbpt1]=xc;
lig1y[nbpt1]=yc;
nbpt1++;
xc=col+0.5F;
yc=lig;
icote1=4;
ilig1--;
}
else if(iType == 8)
{
lig1x[nbpt1]=xc;
lig1y[nbpt1]=yc;
nbpt1++;
xc=col+0.5F;
yc=lig;
fin1=1;
}
else if(iType == 10)fin1=1;
break;
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.

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)
{
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)
{
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 == 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;
}
}

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;
dY3=-(dPx3-dPx1)*sinTeta+(dPy3-dPy1)*cosTeta;
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));

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 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);
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(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++;

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;
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;
iNbarcTache++;
dXFin=dtabX1[jArc];
dYFin=dtabY1[jArc];
jArc=iArc;
}
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 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
}
else
{
//--- on est sr que la tache 1 n'est pas incluse
}
}
else
{
//--- 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
}
else
{
//--- on est sr que la tache 0 n'est pas incluse
}
}
}
else
{
//--- zones de plusieurs taches
BOOL bIncluse;
int j,iIndice,iNoTache,iNoTacheBis,iSize,iNbTachesNonNulles;
double dSurface,dXInterieur,dYInterieur;
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)
{
if(ctabSurface != NULL)free(ctabSurface);
if(itabTri != NULL)free(itabTri);

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 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
{

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
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);

CProjection();
CProjection(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;
430
Annexe
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 < 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;
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;
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;
b=b+db;
b=b-db;
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;
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;
}
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(rl > 10800.)rl-=21600.;
}
{
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;
b=b-db;
b=b+db;
b=b-db;
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;
if(m_dParallele1 > 5400.)dPar=m_dParallele1-5400.;

else dPar=5400.-m_dParallele1;
if(m_dParallele2 > 5400.)dPar=m_dParallele2-5400.;
else dPar=5400.-m_dParallele2;
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;
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);
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(rl > 10800.)rl-=21600.;
}
{
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;
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);
//--- calcul de la colatitude
l=-(log(r/m_dC))/m_dN;
phibis=l;
v=exp(l);
phi=phibis;
i=1;
while(phibis != phi && i<50)
{
phi=phibis;
i++;
}
dLatitude=phi*m_dRadianToMinute;
if(m_iParalleleOrigineHem == NORD)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)

{
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
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
int
int
int
int
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);

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();
};

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);
}
}

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);
}
}
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 AjouterUneRelation(int iNoth);
void AjouterUnMasque(const char *chNomMasque);
void AjouterUnFond(const char *chNomFond);
void SupprimerUneEntree(int iIndex);
int GetNbEntree() {return m_iNbEntree;};
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);
};

void Tracer(CDC* pDC);
void TracerRaster(CDC* pDC);
void Exporter(const char* chNomFichierBmp);
BOOL MiseAJour();
class CDessinZone
{
//--- classe pour le dessin de zones et contours de zones
private:
CCadre* m_pCadre;
public:
//--- attributs gnraux
//--- 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 TracerRaster(CDC* pDC,int iModeSuperposition,CPerspective* pPerspective);
BOOL MiseAJour();
void ExporterParEstompage(const char* chNomFichier);
};
class CDessinLigne
{
//--- classe pour le dessin de ligne
private:
CCadre* m_pCadre;
public:
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];
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);
BOOL MiseAJour();
};
class CDessinSymbole
{
//--- classe pour le dessin de symboles et de valeurs

private:
CCadre* m_pCadre;
void TracerSymboles(CDC* pDC);
void TracerValeurs(CDC* pDC);
void TracerDiagrammes(CDC* pDC);
public:
//--- 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
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);
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:
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 Tracer(CDC *pDC);
void TracerPlage(CDC *pDC);
void ImprimerPlage(CDC *pDC);
void TracerRaster(CDC *pDC,int iModeSuperposition,CPerspective* pPerspective);
BOOL MiseAJour();
};
class CDessinFond
{
//--- classe pour le dessin de fond graphique
private:
CCadre* m_pCadre;
public:
char m_chNom[100];
int m_bNiveau[256];
public:
CDessinFond(CCadre* pCadre);
void Tracer(CDC *pDC);
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() :
void CDessinPixel::TracerIllum(CDC* pDC)

{
//--- paramtres
double dPI=acos(-1.);
int iPrint=config.IsPrinting(pDC);
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,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,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);
return;
}
if((iCadreXhVue-iCadreXbVue) == 0 || (iCadreYhVue-iCadreYbVue) == 0)
{
fclose(FileImage);
return;
}
//--- allocation memoire
iDatasize=1;
iTypeAttribut=pSchema->m_pRelations[iNoth]->m_pAttributs[iNoatt]->m_iType;
if(iTypeAttribut == 1 || iTypeAttribut == 5 || iTypeAttribut == 6)iDatasize=1;
bufima1=(unsigned char *) malloc(iMosaiqueNbcol*iDatasize);
bufima2=(unsigned char *) malloc(iMosaiqueNbcol*iDatasize);
if(bufima1 == NULL || bufima2 == NULL)
{
if(bufima1 != NULL)free(bufima1);
if(bufima2 != NULL)free(bufima2);
fclose(FileImage);
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);

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;
fread(bufima1,iNbcolALire,iDatasize,FileImage);
ptr=ptrdeb+(iImagetteXbImage+((iImageY+1)*nbcol))*iDatasize;
450
Annexe
}
else
{
ptr=ptrdeb+(iImagetteXbImage+((iImageY-1)*nbcol))*iDatasize;
ptr=ptrdeb+(iImagetteXbImage+(iImageY*nbcol))*iDatasize;
}
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;
}
}
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;
}
}
{
bInconnu=TRUE;
}
{
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.);

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);
}
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;
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)
{
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 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;
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;
{
//--- 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);

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
{
{
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;
{
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;
{
//--- attribut numrique
fValeur=v[iNovar];
if(fValeur > FINCONNU && fValeur >= m_fAPlage && fValeur <= m_fBPlage)
{
{
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;
}
}
}
{
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
{
{
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);
}
}
}
}
}
fclose(FileDescriptif);
fclose(FileArc);
}
else if(iTypeRelation == 14 || iTypeRelation == 24)
{
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++;
}
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;
{
//--- attribut numrique
fValeur=v[iNovar];
if(fValeur > FINCONNU && fValeur >= m_fAPlage && fValeur <= m_fBPlage)
{
456
Annexe
{
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;
}
}

{
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;
}
else
{
{
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);
}
}

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(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];
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];
iNbarcTache++;
dXFin=dtabX2[jArc];
dYFin=dtabY2[jArc];
jArc=iArc;
}
else if(dtabX2[jArc] == dXFin && dtabY2[jArc] == dYFin)
{
itabPtrTache[iNbarcTache]=itabPtrarc[jArc];
iNbarcTache++;
dXFin=dtabX1[jArc];
dYFin=dtabY1[jArc];
jArc=iArc;
}
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;
}

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_chTitre[80];
public:
CLegendeDegrade();
};
class CLegendeSymbole
{
private:
int m_iLargeurTexte;
int m_iHauteurTexte;
int m_iNoSymbole;
double m_dTailleSymbole;
char m_chTexte[100];
public:
CLegendeSymbole();
};
class CLegendeSymboleParTaille
{
private:
int m_iDisposition;
int m_iNoSymbole;
int m_iNbSymboles;
int m_iSizePoint;
LOGFONT m_logfont;
double m_dtabTailleSymbole[20];
char m_chTexte[20][100];
char m_chTitre[80];
public:
CLegendeSymboleParTaille();
void Init();
};
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];

int m_itabHauteurTexte[TAILLE_PALETTE_VALEUR];
char m_chTitre[80];
int m_iXbTitre;
int m_iYbTitre;
int m_iXhTitre;
int m_iYhTitre;
public:
CLegendeSymboleParValeur();
};
class CLegendeDiagrammeCaisson
{
private:
int m_iNbCaissons;
public:
CLegendeDiagrammeCaisson();
};
class CLegendeDiagrammeParTaille
{
private:
int m_iDisposition;
int m_iNbSymboles;
int m_iSizePoint;
LOGFONT m_logfont;
double m_dtabTailleSymbole[20];
char m_chtabTexte[20][100];
char m_chTitre[80];
public:
CLegendeDiagrammeParTaille();
void Init();
};
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
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];
int
int
int
int
int
int
int
int
int
int
int
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;

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)
{
//--- union
int
int
int
int
i,j,k,iNothEmetteur,iNothRecepteur;
iNoattCleEmetteur,iNoattCleRecepteur;
iNbAttributsEmetteur,itabNoattEmetteur[NB_MAX_ATTRIBUTS];
iJointure;

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

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
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);
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;
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);
return;
}
CLecture lecture2Emetteur;
if(lecture2Emetteur.Open(pCadre,iNothEmetteur) == FALSE)
{
free(ftabCle);
free(itabPtr);
return;
}
i=lectureRecepteur.Lire(vRecepteur);
while(i != -1)
{
if(i == 1)
{
//--- initialisation du tupe

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);
{
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;
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;
pSchema->m_pRelations[iNothRecepteur]->m_iNoFichDescriptif=iNoFichier;
}
//--- creation des nouveaux attributs dans le schema
int iNbcar,iNoatt,iNbvalb,iPtrval;
char chNom[20];
{
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);
}
}
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)

{
//--- equijointure gomtrique
int iNoth1,iNoth2,iIntersection;
char chNomRelation[_MAX_PATH];
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)
{
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)
{
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);

return;
}
int *itabImage1=(int *) malloc(config.m_iDefX*(sizeof(int)));
int *itabImage2=(int *) malloc(config.m_iDefX*(sizeof(int)));
if(itabImage1 == NULL || itabImage2 == NULL)
{
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);
return;
}
CTableauCode* pTableauCode=new CTableauCode();
iY=0;
while(iY < config.m_iDefY)
{
iX=0;
{
fscanf(FileImage1,"%d %d%*c",&iCode1,&iNbpt);
for(i=0;i < iNbpt;i++){itabImage1[iX]=iCode1;iX++;}
}
iX=0;
{
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;
{
{
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(&iPtrarc,SIZEINT,1,FileDescriptif3);
fclose(FileDescriptif1);

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];
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)
{
}
//--- calcul des centrodes et fentres de zones
pSchema->m_pRelations[iNoth3]->CalculDesCentroides();
}
}
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;
if(iNoFichier == -1)return;
CLecture lecture;
{
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++;
{
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
{
pSchema->m_pRelations[iNoth]->m_iType+=10;
for(i=1;i <= pSchema->m_pRelations[iNoth]->m_iNba;i++)pSchema->m_pRelations[iNoth]>m_pAttributs[i]->m_iNumero=i;
}
else
{
}
//--- 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

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
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)
{
{
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);
void ASauver() {m_bASauver=TRUE;};
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:
CAmers* m_pAmers;
CImage* m_pImage;
double
double
double
double
double
double
m_aPToI;
m_bPToI;
m_cPToI;
m_aprimPToI;
m_bprimPToI;
m_cprimPToI;
double
double
double
double
double
double
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);

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];
::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;
double dXp1=dX-dX0;
double dYp1=dY-dY0;
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);
ImageToProjection(0,m_pImage->m_iNblig,dX,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=((long)
dYb=((long)
dXh=((long)
dYh=((long)
(dXb/m_dResolution))*m_dResolution;
(dYb/m_dResolution))*m_dResolution;
(dXh/m_dResolution)+1)*m_dResolution;
(dYh/m_dResolution)+1)*m_dResolution;
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)
{

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;
{
icol=0;
{
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);
}
dX+=m_dResolution;
icol++;
}
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;
{
icol=0;
{
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)
{
alfa0=1.+alfa1;
alfa2=1.-alfa1;
alfa3=2.-alfa1;
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.;
CX3=alfa3*(-alfa3*alfa3 + 5*alfa3 - 8.) + 4.;
CY0=beta0*(-beta0*beta0 + 5*beta0 - 8.) + 4.;
CY1=beta1*beta1*(beta1 - 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];
iIndice=iY*m_pImage->m_iNbcol+iX;
iIndice=(iY+1)*m_pImage->m_iNbcol+iX;
dVal=CY0*(CX0*dVal00 + CX1*dVal01 + CX2*dVal02 + CX3*dVal03);
dVal+=CY1*(CX0*dVal10 + CX1*dVal11 + CX2*dVal12 + CX3*dVal13);
buffer[icol]=(int) dVal;
}
dX+=m_dResolution;
icol++;
}
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:
CAmers* m_pAmers;
CImage* m_pImage;

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];
&& (FileDepl=fopen(chNomFichierDepl,"wb")) !=
//--- 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)
{
if(alpha != NULL)free(alpha);

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)
{
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);
return;
}
bufferDiff=(unsigned char *) malloc(m_iNbcolDestination*sizeof(unsigned char));
itabImage=(int *) malloc(m_iNbcolDestination*sizeof(int));
if(bufferDiff == NULL || itabImage == NULL)
{
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);
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);
}
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);
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);
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)
{
free(bufferDiff);
free(itabImage);
free(alpha);

free(beta);
free(gamma);
free(alphaprim);
free(betaprim);
free(gammaprim);
fclose(FileBmp);
fclose(FileDepl);
fclose(FileImage);
return;
}
double dX,dY,dXProj,dYProj,dDistance;
int j,iX,iY,ilig,icol,iDiff;
int iNbpt;
//--- init du progressCtrl
char chTitreProgress[100];
{
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;
{
//--- lire la ligne triangle
for(icol=0;icol < m_iNbcolDestination;icol++)itabImage[icol]=0;
icol=0;
{
fscanf(FileImage,"%d %d%*c",&iCode,&iNbpt);
j=0;
while(j < iNbpt)
{
itabImage[icol]=iCode;
icol++;
j++;
}
}
icol=0;
{
//--- 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;
bufferDiff[icol]=255;
}
dX+=m_dResolution;
icol++;
}
if(config.m_bImageDifference)fwrite(bufferDiff,1,m_iNbcolDestination,FileDepl);
dY+=m_dResolution;
ilig++;
iCount++;
if(iCount > iStep)
{
iCount=0;
}
}
else if(iModeRecalage == 1)
{
//--- recalage bilineaire
double dXImage,dYImage;
double alfa0,alfa1,beta0,beta1;
double dVal00,dVal01,dVal10,dVal11;
ilig=0;
{
icol=0;
{
j=0;
while(j < iNbpt)
{
icol++;
j++;
}
}
icol=0;
{
if(iCode > 0)
{
if(m_iRecalageInitial == SIMILITUDE)m_pSimilitude>ProjectionToImage(dXProj,dYProj,dXImage,dYImage);
else m_pSysteme1->ProjectionToImage(dXProj,dYProj,dXImage,dYImage);
alfa1=1.-alfa0;

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;
}
dX+=m_dResolution;
icol++;
}
dY+=m_dResolution;
ilig++;
iCount++;
if(iCount > iStep)
{
iCount=0;
}
}
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 dVal;
ilig=0;
{
icol=0;
{
j=0;
while(j < iNbpt)
{
icol++;
j++;
}
}
icol=0;
{
if(iCode > 0)
488
Annexe
{
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{
alfa0=1.+alfa1;
alfa2=1.-alfa1;
alfa3=2.-alfa1;
beta0=1.+beta1;
beta2=1.-beta1;
beta3=2.-beta1;
CX0=alfa0*(-alfa0*alfa0 + 5.*alfa0 - 8.) + 4.;
CX3=alfa3*(-alfa3*alfa3 + 5*alfa3 - 8.) + 4.;
CY0=beta0*(-beta0*beta0 + 5*beta0 - 8.) + 4.;
CY3=beta3*(-beta3*beta3 + 5.*beta3 - 8.) + 4.;
iIndice=(iY-1)*m_pImage->m_iNbcol+iX;
iIndice=iY*m_pImage->m_iNbcol+iX;
dVal=CY0*(CX0*dVal00 + CX1*dVal01 + CX2*dVal02 + CX3*dVal03);
buffer[icol]=(int) dVal;
}
}
else
{
buffer[icol]=0;
}
dX+=m_dResolution;
icol++;
}

dY+=m_dResolution;
ilig++;
iCount++;
if(iCount > iStep)
{
iCount=0;
}
}
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);
}
//--- 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);

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++)
{
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

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++)
{
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();
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;};
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 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;

while(iArc1 < m_iNbArc)
{
pArc1=m_ptabArc[iArc1];
if(pArc1 != NULL)
{
iNoZone1=pArc1->GetNoZone1();
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)
{
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;
bOui=TRUE;
while(iPointFin1 < iNbpt1-1 && iPointFin2 < iNbpt2-1 && bOui)
{
pArc1->GetPoint(iPointFin1+1,dX1,dY1);
if(dX1 == dX2 && dY1 == dY2)
{
iNbCommuns++;
iPointFin1++;
iPointFin2++;
}
else bOui=FALSE;
}
if(iNbCommuns == 1)
{
//--- on essaye dans l'autre sens
bOui=TRUE;
while(iPointFin1 < iNbpt1-1 && iPointFin2 > 0 && bOui)
{
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]->CalculFenetreSav();
m_iNbArc++;
}
if(iPointDebut1 > 0)
{
//--- bout initial
m_ptabArc[m_iNbArc]=new CArcMygale(iPointDebut1+1);
j=0;
for(i=0;i <= iPointDebut1;i++)
{
point.Set(dX,dY);
j++;
}
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->SetPoint(j,dX,dY);
j++;
}
pArc1->SetNbpt(j);
if(iNoZone1 < 20)
{
if(iNoZone3 >= 20)
{
pArc1->SetNoZone1(iNoZone3);
pArc1->SetNoZone2(2);
}
else
{
}
}
else
{
if(iNoZone1 < iNoZone3)
{
}

else
{
if(iNoZone3 >= 20)
{
}
else
{
}
}
}
}
//--- arc 2
Ordonner(iPointDebut2,iPointFin2);
iSens=pArc2->GetSens();
if(iPointFin2 < iNbpt2-1)
{
//--- bout final
m_ptabArc[m_iNbArc]=new CArcMygale(iNbpt2-iPointFin2+1);
j=0;
for(i=iPointFin2;i < iNbpt2;i++)
{
point.Set(dX,dY);
j++;
}
m_iNbArc++;
}
if(iPointDebut2 > 0)
{
//--- bout initial
m_ptabArc[m_iNbArc]=new CArcMygale(iPointDebut2+1);
j=0;
for(i=0;i <= iPointDebut2;i++)
{
point.Set(dX,dY);
j++;
}
m_iNbArc++;
}
SupprimerUnArc(iArc2);
iNbArcSupprimes++;
pArc1=NULL;
pArc2=NULL;
//--- on recommence
InitUndo();
ASauver();
}
}
}
iArc2++;
goto SUITE;
}
}
iPointDebut2++;
}
iPointDebut1++;
}
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;
}
}
{
dtabX[iNbBout]=dXGeo;
dtabY[iNbBout]=dYGeo;
itabNb[iNbBout]=1;
iNbBout++;
}
m_ptabArc[i]->GetPoint(iNbpt-1,dXGeo,dYGeo);
bTrouve=FALSE;
{
if(dtabX[j] == dXGeo && dtabY[j] == dYGeo)
{
itabNb[j]=1-itabNb[j];
bTrouve=TRUE;
break;
}
}
{
dtabX[iNbBout]=dXGeo;
dtabY[iNbBout]=dYGeo;
itabNb[iNbBout]=1;
iNbBout++;
}
}
}
{
if(itabNb[j] != 0)return FALSE;
}
return TRUE;
}

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;
}
}
if(dIntervalleMinimum > 0.)
{
dDifference=fabs(dValeur2-dValeur1);
if(dDifference < dIntervalleMinimum)
{
}
}
}
}
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:
break;
default:
break;
}
m_iNbObjet++;

}
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;
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);
{
case SAISIE_VALEUR:
break;
case SAISIE_CLE:
break;
break;
default:
break;
}
//--- lecture de l'arc
m_ptabArc[m_iNbArc]=new CArcMygale(iNbpt);
if(m_ptabArc[m_iNbArc] == NULL)
{
fclose(FileObjets);
m_ctabCle=NULL;
m_dtabValeur=NULL;
{
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)
{
fclose(FileObjets);
m_ctabCle=NULL;
m_dtabValeur=NULL;
for(int i=0;i < NB_MAX_ARC;i++)
{
504
Annexe

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);
//--- calcul de la fentre de l'arc
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)
{
free(m_dtabPoint);
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;
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++;
{
case SAISIE_VALEUR:
break;
case SAISIE_CLE:
break;
break;
default:
break;
}
m_iNbObjet++;
}
fclose(FileObjets);
//--- lecture des arcs

FILE* FileArcs=fopen(chNomFichierArcs,"rb");
if(FileArcs == NULL)
{
::ErreurDeFichier(chNomFichierArcs);
free(m_dtabPoint);
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)
{
fclose(FileArcs);
free(m_dtabPoint);
m_dtabPoint=NULL;
m_ctabCle=NULL;
m_dtabValeur=NULL;
{
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);
m_dtabPoint=NULL;
m_ctabCle=NULL;
m_dtabValeur=NULL;
for(int i=0;i < NB_MAX_ARC;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]->SetNoZone1(iNz1);
m_ptabArc[m_iNbArc]->SetNoZone2(iNz2);
//--- calcul de la fentre de l'arc
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.

Les Principes Des Système D'information Géographique

Transféré par

Informations du document

Titre original

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

Les Principes Des Système D'information Géographique

Transféré par

Droits d'auteur :

Formats disponibles

Les principes des systmes dinformation

Premire partie : introduction et prsentation gnrale du systme

2. Prsentation du systme SAVANE.... 21

2.2.2. SAVAMER : gorfrencement dimages et constitution de mosaques

2.2.4. SAVANE : exploitation des bases de donnes et cartographie

2.2.5. SAVATLAS : consultation de cartes et de donnes

2.3. La constitution et lexploitation dune base de donnes avec SAVANE

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

Deuxime partie : Modliser et grer linformation gographique

4.2.4. Nouveaux instruments, nouvelles mesures, nouvelles prcisions

4.2.5. Prcision des mesures

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

5.2.4. Les modles hirarchique et rseau

5.2.6. Le modle objet

5.3. SGBDR et objets gographiques : lextension du modle relationnel

5.3.3. Les extensions de lalgbre relationnelle

5.3.4. Objets spatiaux et oprations relationnelles classiques

5.5.3. Intgration dobjets et de valeurs dattributs

5.5.4. SAVANE : requtes et tats temporaires

5.5.5. La classe CLecture

5.5.8. La ralisation des opration relationnelles classiques

5.5.9. La ralisation des opration relationnelles tendues

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

6. Gorfrencement et intgration dimages .. 195

6.3.5. Un cas particulier : les satellites dobservation de la Terre

6.5. Le module SAVAMER

6.5.3. Le redressement et le r-chantillonnage

6.5.4. Le mosaquage et lintgration dans une mosaque

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

7.3.4. Les contraintes relationnelles

7.3.5. Les contraintes de jointure

7.4. Modles gomtriques et mise en uvre des contraintes dintgrit spatiale

7.4.2. La vrification de la cohrence spatiale

7.5.2.Les contraintes sur les objets gomtriques

7.5.3.Les contraintes sur les objets gographiques

7.5.4. Quelques procdures automatiques : algorithmes

Troisime partie : analyse spatiale et reprsentation cartographique

8.6. La cration de relations temporaires

8.7.2. Vers la zone : vectorisation ou tesslation

8.7.3. Vers la ligne

8.7.4. Vers le point

9. Reprsenter ... 315

9.1.3. La reprsentation cartographique

10. Conclusion ....... 343

Bibliographie gnrale ... 351

Les systmes d'information gographique (SIG) regroupent diffrentes mthodes

ralisation dun systme d'information gographique oprationnel le systme

- la ncessit de conserver la meilleure prcision possible en fonction de la

Un systme dinformation gographique rpondant nos objectifs est la fois un

oprationnel - et implmenter ces fonctionnalits en tant que mthodes, soit

Premire partie : introduction et prsentation du systme

Les systmes dinformation gographique 9

Prsentation gnrale des systmes

Depuis plus de vingt ans, le dveloppement de l'informatique a entran des

de modlisation et de calcul, l'informatique et les SIG n'ont pas seulement permis

Les systmes dinformation gographique 11

Les systmes dinformation gographique 13

1.2.3. La diffusion : les annes 90

Saisie et stockage numrique de plans et de cartes :

Les systmes dinformation gographique 15

Calculs mtriques (distances, surfaces), calculs techniques (visibilit,

Gestion et traitement des collections d'objets :

Gestion administrative et partage de donnes entre utilisateurs :