APPLICATION DE LA METHODOLOGIE D’EVALUATION DE LA COHERENCE
Nous avons présenté dans les chapitres précédents (C et D) la méthodologie que nous proposons pour évaluer la cohérence inter-représentations. Afin d’étudier la faisabilité de notre approche, nous avons mis au point plusieurs expérimentations qui illustrent la mise en œuvre complète de MECO et MACO. Nous les présentons dans ce chapitre. La première application développée est décrite en section E.3. Il s’agit d’une étude sur la cohérence entre représentations de ronds-points de deux BD de l’IGN. La seconde application est présentée dans la section E.4. Elle est consacrée à l’évaluation de la cohérence entre bâtiments. Enfin, la dernière application fait l’objet de la section E.5. Son but est de montrer les possibilités d’utilisation de l’apprentissage automatique pour acquérir des règles de correspondance entre attributs de routes. Nous décrivons dans cette première partie l’architecture du système que nous avons mis au point pour mener nos expérimentations. Elle est constituée de trois éléments : la plate-forme OXYGENE, le système-expert développé à partir du moteur JESS, et un ensemble d’algorithmes d’apprentissage proposé par le logiciel WEKA. La plate-forme de travail OXYGENE est d’abord présentée. Nous détaillons les caractéristiques du noyau ainsi que les extensions que nous avons réalisées. Nous exposons ensuite le moteur du système-expert : JESS. Nous l’avons relié à la plate- forme OXYGENE. Finalement, le logiciel WEKA est présenté. Il nous a servi à la réalisation des tests d’apprentissage.
L’ensemble des développements menés dans le cadre de cette thèse a été réalisé dans la nouvelle plate-forme de travail du laboratoire COGIT de l’IGN : OXYGENE [Badard et Braun 2003, Braun 2004]. Cette plate-forme a pris naissance il y a environ 4 ans. Elle a été conçue au cours de notre thèse. Nous avons participé à sa mise au point grâce aux expérimentations réalisées. Elle fut conçue pour rassembler les différentes applications de recherche développées au sein du laboratoire et implémentées dans plusieurs systèmes (plate- formes PlaGe, StratèGe et GéO2), dont la dispersion favorisait la multiplication du code et limitait son utilisation. OXYGENE constitue aujourd’hui l’environnement de développement de plusieurs équipes de recherche du laboratoire COGIT et accompagne la plate-forme de généralisation cartographique automatique AGIT. La figure 89 représente l’architecture générale d’OXYGENE. La plate-forme est fondée sur un schéma objet prenant en compte l’aspect géométrique, topologique et sémantique des données géographiques. Ce schéma s’appuie sur les standards développés par l’ISO et l’OpenGIS (normes 19107, 19109) et a été entièrement implémenté en JAVA, langage orienté-objet. Il constitue le noyau de la plate-forme. Celui-ci est relié au SGBD relationnel ORACLE (version 9i avec l’extension spatiale) qui permet de gérer et stocker les données des différentes bases exploitées.
Le lien entre le SGBD choisi et le schéma objet, ce qu’on appelle le « mapping », se fait à l’aide d’une bibliothèque de fonctions écrites en JAVA, nommée OJB (« ObJect relational Bridge »29). Les correspondances entre les tables stockées dans ORACLE et les classes correspondantes définies en JAVA sont décrites dans des fichiers XML et gérées par OJB (figure 90). L’utilisateur de la plate-forme ne manipule pas directement les tables mais passe par l’intermédiaire des classes JAVA correspondantes. Aucune requête n’est faite directement au niveau du SGBD, elles sont masquées grâce à OJB qui ne traite que des objets Java. Cette solution offre l’avantage d’assurer une relative indépendance du noyau par rapport au SGBD utilisé. La sélection d’un autre SGBD n’implique que de faibles modifications du code JAVA. A cette structure vient se greffer une bibliothèque d’opérateurs géométriques permettant de manipuler les données des bases et d’effectuer des analyses sur celles- ci. Un module d’appariement est également disponible de même que plusieurs algorithmes permettant la construction et le traitement de modèles numériques de terrain (MNT). Ces outils ont été développés par les chercheurs du laboratoire, au fur et à mesure de leurs besoins. Certains opérateurs ont également été récupérés de travaux extérieurs. C’est le cas de la bibliothèque JTS Topology Suite30 par exemple qui offre une série de fonctions géométriques simples codées en JAVA (calcul de longueur, de superficie, d’intersection, de zone tampon,…). La liste des opérateurs continue de s’enrichir et les algorithmes que nous avons développés sont intégrés à celle-ci. Tout le code de la plate-forme est documenté à l’aide de la Javadoc, mécanisme qui permet de générer automatiquement de la documentation sur le code JAVA développé à partir de commentaires insérés dans celui-ci. Ce code est par ailleurs partagé à l’aide d’un CVS (« Concurrent Versionning System »). Ce système se charge de centraliser le code des multiples développeurs sur un seul serveur et de prendre en compte les mises à jour effectuées sur eux tout en gardant l’historique.