le contexte d’un navigateur sur un poste distant. 
Pour l’implémentation du système GEOLIB, la technologie Active 
X de Microsoft a été adoptée. La raison principale de ce choix 
était l’orientation dominante pour cette plate-forme de clients 
potentiels 1 . Le système encapsulé et affichant l’interface avec un 
composant de type ActiveX garantissait à la fois le 
fonctionnement dans l’architecture Internet et l’intégration avec 
un grand nombre d’outils de développement d’applications 
Windows et de systèmes auteurs. La technologie Microsoft était 
plus simple à l’utilisation ainsi qu’au développement et nécessitait 
moins de ressources à l’exploitation que CORBA. Pour le choix 
entre Java et ActiveX, un des critères de sélection était la rapidité 
d’exécution du code binaire. 
3.2. Fonctionnalités GeoLib 
Le premier prototype du système GEOLIB devait supporter les 
fonctionnalités suivantes : 
• acquisition et conversion de données : 
import de données vecteur (spaghetti) et rasteur avec 
des données attributaires associées, 
création et modification des cartes à partir de plusieurs 
couches, 
• exploitation de données, requêtes spatiales et attributaires : 
requêtes sur des critères attributaires, 
requêtes spatiales basées sur la distance, l’adjacence, 
l’intersection et l’inclusion, 
• visualisation de données 2D : 
affichage et suppression visuelle de couches et de 
résultats de requêtes, 
zoom physique sur les couches rasteur et vecteur, 
fonctionnalité de déplacement (“pan”), 
• fonctions géographiques : 
calcul de la longueur et de la surface des objets, 
calcul de la distance entre deux objets, 
opérateurs d’adjacence, d’intersection et d’inclusion, 
• fonctionnalités système : 
gestion d’un tampon client et serveur pour 
l’optimisation de la lecture et du transfert des données, 
système “multi-threads” pour paralléliser l’exécution 
des requêtes, des tâches liées à la lecture sur disque 
et à la communication réseau, 
gestion de la couche de communication Internet. 
3.3. Contraintes architecturales 
Les données géographiques représentent généralement des 
volumes importants. Elles sont organisées en structures simples 
(■spaghetti) ou plus sophistiquées qui intègrent des notions de 
topologie entre objets [Laurini, Scholl], Le modèle spaghetti n’est 
pas adapté pour des opérations telles que le calcul de 
l’intersection entre deux polygones. Les structures topologiques 
le permettent, mais elles augmentent l’espace de stockage et la 
maintenance nécessaire après les mises à jours. Ces structures 
occupent en effet une place plus importante et peuvent même 
doubler l’espace nécessaire pour le stockage. En général, la 
1 Ce choix a été fait au début de l’année 1997. Le langage Java 
manquait des bibliothèques graphiques et était peu performant à 
l’exécution. Aujourd’hui l’évolution du langage Java permet 
d’envisager la migration du système GEOLIB sur une plate-forme 
Java. 
tendance sera la suivante : plus les fonctionnalités d'analyse 
géographique sont riches, plus le modèle de données 
correspondant est complexe, plus il occupe d’espace de 
stockage. 
Bien que les performances des réseaux évoluent sans cesse, 
Internet peut encore être caractérisé comme étant un réseau 
lent. En tenant compte du volume potentiel de données 
géographiques, le transfert de données est donc un des points 
critiques de notre système. 
Par ailleurs, dans une architecture Internet, l’applicatif du client 
est soumis aux règles de sécurité qui peuvent par exemple 
interdire le stockage des données temporaires sur le disque du 
client. Toutes les données que le client manipule doivent alors se 
trouver dans la mémoire vive du poste client. C'est également un 
point critique, car le rapport entre le volume de données et la 
taille mémoire disponible sur le poste client n’est pas toujours 
favorable. 
Le troisième point important concerne l’équilibrage des capacités 
de traitement des données géographiques entre les deux parties 
du système : le client et le serveur. D’une part, il n’est pas 
raisonnable de mettre un outil SIG généraliste sur la partie client 
si la plupart des fonctionnalités SIG ne sont pas utilisées. D’autre 
part, l’architecture serveur de données a aussi ses défauts. 
Supposons que tous les traitements (simples ou complexes) se 
fassent sur la partie serveur et que la partie client ne s’occupe 
que de la visualisation de l’information et de la construction des 
requêtes. Cela oblige à s’adresser au serveur même si le client 
dispose de toutes les données pour répondre à la requête, quelle 
que soit sa complexité et même dans le cas où l'on demande 
d’exécuter à nouveau la même requête. Cela signifie que les 
mêmes données vont transiter sur le réseau et que le serveur 
sera surchargé, faute d’exécuter les mêmes traitements. 
La conception du système dans un environnement Internet doit 
donc tenir compte de deux exigences : 
a) réduire le volume de données à transférer au minimum 
nécessaire pour permettre à l’utilisateur de travailler, 
b) équilibrer les traitements entre le client et le serveur, ce qui 
signifie avoir un client intelligent, capable de traiter certaines 
requêtes en local. 
La solution que propose GEOLIB consiste à laisser les 
traitements complexes s'effectuer sur le serveur de données. Le 
client conserve une partie allégée de la bibliothèque de fonctions 
pour pouvoir répondre à certaines requêtes sans s’adresser au 
serveur. Il est doté d’un tampon d'objets et de réponses qui 
permettra de disposer de certaines données sur le poste client 
afin d’anticiper les actions de l’utilisateur. 
3.4. Architecture générale 
Deux architectures de déploiement ont été étudiées : Internet et 
mono-poste. Ces deux architectures ont des différences 
significatives : 
• une application mono-poste n’a qu’un seul utilisateur, donc le 
système GEOLIB sera visible comme une seule unité et 
s’intégrera totalement dans l'applicatif final. 
• dans un environnement Internet, le système est utilisé par 
plusieurs utilisateurs. Il est composé d’au moins deux parties, 
la partie serveur et la partie client. Une couche de 
communication est nécessaire pour le fonctionnement de 
cette architecture. 
L’étude détaillée de deux types d’applications a permis de 
concevoir une architecture à partir de modules internes. Les 
principaux modules sont les mêmes pour les deux architectures. 
Ces modules s’accordent pour produire deux variantes du 
système GEOLIB : GEOLIB mono-poste (en tant que composant 
ActiveX pour l’intégration avec l’applicatif final), et GEOLIB Web 
(en tant qu'application serveur avec composant ActiveX pour le 
téléchargement et l’exécution dans le navigateur). Les figures 
suivantes (Figure 4 et Figure 5) illustrent ces architectures en