Projet de développement d`un SIG-3D géologique

Projet de développement d’un SIG-3D géologique
Avancement des travaux
Par : Etienne Desgagné
Directrice : Jacynthe Pouliot
Département des sciences géomatiques
Codirection : Donna Kirkwood
Département de génie géologique et géologie
Codirection : Thierry Badard
Département des sciences géomatiques
DÉPARTEMENT DES SCIENCES GÉOMATIQUES
FACULTÉ DE FORESTERIE ET DE GÉOMATIQUE
UNIVERSITÉ LAVAL
QUÉBEC
2006
Table des matières
Objectifs ........................................................................................................................................................................................................... 2
Problématique................................................................................................................................................................................................ 3
Méthodologie .................................................................................................................................................................................................. 4
Description du système ............................................................................................................................................................................. 5
Références....................................................................................................................................................................................................... 9
Normes ............................................................................................................................................................................................................. 9
Sites Web......................................................................................................................................................................................................... 9
Objectifs
L’objectif général de ce projet de maîtrise est de coupler de manière bidirectionnelle un modèle
3D et une base de données spatiale tout en permettant le requêtage tridimensionnel d’objets
géométriques. Ce type d’architecture pourrait être communément nommé un SIG-3D pour faire
référence à un système d’information géographique (SIG) apte à gérer les données à référence
spatiale et plus explicitement la 3e dimension de celles-ci. Ce type d’architecture sera adapté au
contexte de modélisation géologique tout en respectant les normes et spécifications du domaine
des sciences de l’information géographique. D’une manière plus spécifique, il s’agit donc de
coupler un outil de modélisation 3D utilisé en géologie, soit Gocad, avec un système de gestion
de base de données (SGBD) tout en permettant d’effectuer des requêtes autant spatiales
(tridimensionnelles) que descriptives.
Cette stratégie cherche ainsi entre autres à élargir les capacités de gestion de donnés descriptives1
des outils de modélisation 3D. On remarque en effet, que le logiciel Gocad, comme la plupart
des outils de modélisation 3D, utilise des fichiers comme format de stockage des modèles et de
leurs entités géométriques. L’utilisation des SGBD pour le stockage des objets géométriques 3D
serait un atout très intéressant pour ce genre d’application et ce projet se veut une des premières
tentatives d’élaboration d’un tel système. L’intérêt de ce type de couplage est de rendre
accessible les données 3D d’une organisation à un plus grand nombre de personnes, de faciliter
leur gestion en plus d’en assurer la sécurité, l’intégrité et donc la pérennité.
Ce projet devrait permettre à un utilisateur de Gocad de pouvoir importer les données qu’il désire
à partir d’une base de données sur un serveur, d’effectuer des mise-à-jour sur son modèle, et de
retourner les données modifiées dans la base de données sur le serveur. Il devrait aussi pouvoir
effectuer de l’analyse spatiale sur ses objets en 3D (comme par exemple une intersection entre
deux surfaces ou solides) ainsi qu’obtenir de l’information sur leurs propriétés descriptives.
La stratégie choisie cherche aussi, et surtout, à produire un système dit interopérable2 et basé sur
des composants ouverts3. L’interopérabilité permettra de simplifier et de renforcer le partage, la
réutilisation et l’intégration des données spatiales. L'une des conditions fondamentales
permettant l’interopérabilité est l'utilisation de langages et de protocoles communs d’où l’intérêt
d’exploiter les normes, le web et ses standards et les ressources open-source.
1
Les données descriptives concernent les propriétés thématiques d’un phénomène, autres que celles reliées aux
propriétés géométriques et topologiques. Exemples : la porosité, la conductivité hydraulique, la durée.
2
Faculté que possèdent des ensembles informatiques hétérogènes de fonctionner conjointement et de donner accès à
leurs ressources de façon réciproque (OQLF, 2004).
3
Système à libre redistribution et rendant disponible son code source.
Problématique
Les outils de type CAD (Conception Assistée par Ordinateur) dont fait partie Gocad, permettent
d’effectuer de la modélisation géométrique bidimensionnelle et tridimensionnelle mais sont
souvent limités au niveau des méthodes de stockage et de requêtage des données géométriques
(Pouliot et al, 2003). Afin de pouvoir réaliser nos objectifs, nous avons besoin de technologies
permettant la gestion, le traitement, le stockage et le requêtage de données géométriques. Le
problème est que présentement, la majorité des outils commerciaux ou libres pouvant répondre à
ces besoins tels que les systèmes d’information géographique (SIG) et les systèmes de gestion de
base de données spatiale (Geo-SGBD), ne sont pas conçues pour gérer efficacement la troisième
dimension (Stoter et Zlatanova, 2003; Zlatanova, Rahman et Pilouk, 2002; Pouliot et al. 2003).
Les principaux fournisseurs de SGBD (Oracle, IBM DB2, Informix, Ingres ainsi que MySql et
PostgreSql du côté Open Source) ont implanté dans leur système des types de données spatiales
et des opérateurs spatiaux en se basant sur le "Simple Features Specification for SQL" (SFS) de
l’Open GeoSpatial Consortium (OGC, 1999). Cette implantation consiste en une extension du
langage SQL qui permet de stocker, questionner et mettre à jour des primitives spatiales simples
comme les points, lignes et polygones. Par contre, ces Geo-SGBDs ne sont pas conçus pour
stocker des données spatiales 3D comme des solides, nécessaires à la modélisation 3D. Bien que
les Geo-SGBDs permettent de stocker les coordonnées x, y et aussi le z des objets géométriques
(points, lignes, polygones), les types de données spatiales reconnus sont en 2D et les résultats
d’analyses spatiales ne tiennent pas compte de la 3e dimension.
D’une manière semblable, les systèmes d’information géographique (SIG) commerciaux qui sont
utilisés pour stocker, traiter et requêter des données spatiales et descriptives, sont des outils
essentiellement 2D. Ils ne supportent pas les structures de données spatiale 3D et leurs opérateurs
spatiaux ne tiennent pas compte de la 3e dimension. « L’approche utilisée par les SIGs pour
gérer la troisième dimension consiste en l’ajout d’un attribut stockant l’altitude de chacun des
points des bases de données en deux dimensions. La principale limitation de ce type de démarche
est de ne permettre qu'une seule altitude z en tout point de la scène géographique modélisée,
c'est à dire pour tout couple (x,y) du plan. De ce fait, il devient impossible, contrairement à ce
qui peut se faire avec un CAD par exemple, d'intégrer dans ces logiciels des objets
géographiques aux formes concaves. Les SIGs se placent donc inconfortablement à mi-chemin
entre la 2D et la 3D, ils sont souvent qualifiés d'applications 2,5D. » (Ramos, 2004).
Du côté de l’ISO et de l’OGC, des normes et des spécifications plus complètes tenant compte de
la troisième dimension des objets géométriques ont été récemment publiés. Entre autre, on
retrouve le schéma spatial ISO 19107 qui définit un modèle de représentation pour les données
géométriques 3D, un format standard d’échange et de stockage basé sur ce schéma (GML 3),
ainsi que différentes interfaces de services Web (WMS4, WFS5, WTS6, WCS7 …) pour la
diffusion de données. Par contre, bien qu’il existe plusieurs projets implémentant ces normes et
spécifications, (Geoserver, Deegree, RedSpider, GeoOxygene, etc...) aucun d’entre eux ne les
implémentent totalement et plus particulièrement, tout ce qui touche le 3D a été laissé de côté.
4
Web Map Service
Web Feature Service
6
Web Terrain Service
7
Web Coverage Service
5
Méthodologie
Notre système sera développé suivant une architecture trois-tiers (client, serveur d’application,
base de données). Ce type d’architecture permet à plusieurs utilisateurs d’accéder en même
temps aux mêmes informations par la centralisation des données au sein d'une base de données.
Chacun des usagers peut accéder aux données à l’aide d’une application-cliente installée sur une
machine distante reliée au serveur via un réseau (Internet ou local). Le serveur d’application sert
d’intermédiaire entre les deux autres tiers et regroupe l’ensemble des composantes formant la
logique applicative du système où les traitements sur les données sont effectués. En utilisant une
telle architecture, nous pensons faciliter grandement le déploiement et le maintient du système
puisque le cœur de celui-ci (logique applicative) n’a pas à être installé sur chacun des postesclients. La seule chose dont le client à besoin est d’installer un simple plugin Gocad.
L’idée principale derrière ce projet est d’utiliser le concept de services Web pour donner accès à
des données ainsi qu’à des traitements à un groupe d’utilisateurs. Les services web permettent la
mise à disposition d’applications (appelées services) via le Web sans contrainte de plate-forme
de développement notamment par l’utilisation du langage XML. Dans ce projet, les services sont
mis à disposition des clients à l’aide du serveur d’application abritant un ensemble d’applications
destinées à recevoir les requêtes, récupérer les données, effectuer leur traitement et leur
conversion de format et de renvoyer des réponses. Le contrat de service que ce verra offrir le
client par notre système inclura la possibilité:
• d’extraire l’ensemble ou une partie d’un modèle géologique 3D
• d’extraire les propriétés géologiques attachées aux objets
• d’appliquer des opérateurs spatiaux aux données
• de retourner l’ensemble ou une partie du modèle mise-à-jour vers la base de données
Au niveau du stockage des données, comme les objets géométriques 3D ne sont pas reconnus par
les Geo-SGBD, nous devions trouver une alternative. Deux choix on été retenus. Nous avons
choisi d’éventuellement stocker nos modèles dans une structure de données topologiques 3D
adaptée au contexte géologique soit la structure GeoTEN (Lachance 2005). Cette structure de
données peut être déployée dans n’importe quel SGBD relationnel puisqu’elle ne repose pas sur
le modèle SFS implémenté dans les extensions spatiales des principaux SGBD. Pour les besoins
du projet à court terme, nous allons stocker nos données directement en format GML sous forme
de texte dans un SGBD standard, c’est-à-dire sans extension spatiale. Cette façon de faire nous
permettra d’implanter rapidement nos données dans la base de données ce qui nous permettra de
valider le fonctionnement du système.
Bien que les services de ce système sont destinés aux usagers de Gocad, et que les données
seront stockées dans un SGBD particulier, nous voulons bâtir un système qui favorise les
communications et l’interopérabilité entre différents services tout en étant le plus ouvert et le
plus générique possible afin d’être réutilisable. Cela signifie que notre développement pourrait
être utilisé dans le cadre d’un autre projet impliquant une application-cliente ou une source de
stockage différente. C’est dans ce but que nous avons décidé d’adopter plusieurs standards et
spécifications tels que définit par l’International Organisation for Standardization (ISO/TC 211)
(ISO Technical Committee 211 -- Geographic Information/Geomatics) et l’Open Geospatial
Consortium (OGC). Plus particulièrement, l’adoption dans nos travaux des interfaces standards
de services Web proposés par ces deux groupes nous permettrait d’offrir des services qui
pourraient éventuellement être reconnus par d’autres systèmes implémentant ces interfaces. Cela
permettrait aussi à notre système de pouvoir profiter des services offerts par d’autres applications
standardisées.
Pour permettre aux usagers de notre système d’effectuer de l’analyse spatiale sur les données,
nous allons entreprendre le développement d’une librairie Java d’algorithmes d’opérateur
spatiaux 3D. Cette librairie devrait à terme fournir l’ensemble des opérateurs spatiaux définit par
l’ISO soit Equals, Disjoint, Touches, Within, Overlaps, Crosses, Intersects, Contains, DWithin et
Beyond. Étant données les contraintes de temps, seulement l’opérateur Intersects sera implanté
dans ce projet comme preuve de concept.
Description du système
Le schéma suivant illustre l’architecture du système que nous proposons. Les sections suivantes
présentent chacune des composantes de cette architecture.
Figure 1: Architecture du système
Client
La partie cliente de cette architecture trois-tiers est constituée de plusieurs composantes. Le
logiciel Gocad est l’outil qui est utilisé pour la modélisation géologique 3D. Gocad permet la
construction, la visualisation et l’interrogation de modèle 3D. Il permet la représentation des
objets volumiques de différentes façons. Afin de montrer la faisabilité du système, un seul
modèle géométrique sera testé dans le prototype soit le modèle tétraédrique. Celui-ci, compatible
avec le modèle GeoTEN, a été jugé représentatif des récentes modélisations géologiques 3d (voir
Gocad meeting, June 2006).
Afin de permettre aux usagers de Gocad de construire, d’envoyer des requêtes et de recevoir des
réponses du serveur, un Plugin Gocad doit être développé. Ce plugin devrait fournir une interface
permettant de choisir les données à importer ainsi que les traitements à appliquer et génère une
requête GetFeature qui est envoyée au serveur. Au préalable, des requêtes getCapabilities et
DescribeFeatureType, permettent de connaître les données et les traitements rendus disponibles
par le serveur. Une fois la requête envoyée et traitée, le serveur renvoie vers le client les données
géométriques et descriptives demandées en format XML dont la géométrie est structurées selon
la norme ISO 19136 (GML 3). Ce mécanisme de « transaction » entre le client et le serveur est
implanté d’une manière standard en suivant la spécification WFS de l’OGC. Les filtres inclus
dans les requêtes envoyées au serveur (l’équivalent des clauses WHERE du langage de requête
SQL) sont construites suivant le Filter Encoding Specification de l’OGC.
Voici un exemple de requête GetFeature dans lequel on demande de retourner à l’aide d’un
filtre, un objet géométrique disposant de trois attributs descriptifs associés :
<?xml version="1.0" ?>
- <wfs:GetFeature service="WFS" version="1.1.0" xmlns:wfs="http://www.opengis.net/wfs"
xmlns:ogc="http://www.opengis.net/ogc" xmlns:gml="http://www.opengis.net/gml"
xmlns:myns="http://www.someserver.com/myns" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://www.opengis.net/wfs ../wfs/1.1.0/WFS.xsd">
- <wfs:Query typeName="myns:duparquet_unit_geol">
<wfs:PropertyName>myns:type_geom</wfs:PropertyName>
<wfs:PropertyName>myns:Id_unite_geol</wfs:PropertyName>
<wfs:PropertyName>myns:lithologie</wfs:PropertyName>
- <ogc:Filter>
<ogc:GmlObjectId gml:id="duparquet_unit_geol.1013" />
</ogc:Filter>
</wfs:Query>
</wfs:GetFeature>
Dans cet exemple, pour obtenir nos données, on spécifie l’identifiant de l’objet dans le filtre
(structure <ogc:Filter>…</ogc:Filter>). Toutefois, on pourrait tout aussi bien utiliser un
« parallélépipède englobant » (bbox 3d) et récupérer son contenu. Par contre, il va falloir
déterminer si le système renvoie tous les objets complets inclus ou intersectant ce parallélépipède
ou bien seulement les parties d’objets intersectées par cette enveloppe.
Comme Gocad ne permet pas de lire des données en format GML, le plugin devra contenir un
traducteur de données qui permettra de créer des objets Gocad à partir de documents GML 3.
Pour ce faire, un parseur XML de type SAX est utilisé pour parcourir le document GML reçu du
serveur et y récupérer l’information nécessaire pour recréer les objets Gocad.
Comme le parseur XML et le reste du système sont développés en langage Java et que Gocad est
développé en C++, le Java Native Interface (JNI) est utilisé pour faire le pont entre les deux
langages. Afin d’éviter d’échanger des objets complexes entre les deux langages, les objets
géométriques du format GML sont convertis en un format intermédiaire inspiré du Well Know
Text (WKT) de L’OGC. Le format WKT est une manière simple de stocker de l’information
géographique par la représentation des objets géométriques sous forme textuelle. Cette
transformation nous permet de limiter la transaction au transfert d’une simple chaîne de
caractère. Par exemple, deux triangles (dans un espace 3D) pourraient être stockés de la façon
suivante :
[(0 0 0,1 1 1,2 2 2) (0 1 0,1 2 1,3 2 1)]
Serveur
La partie serveur est le cœur de ce système 3-tiers et est responsable de la majorité des
traitements.
Le serveur d’application Apache Tomcat, développé en Java, est le moteur de notre système.
C’est en fait un conteneur de servlet dans lequel sont déployées les autres composantes de ce
tiers. Il contient aussi un serveur Web qui permet de recevoir des requêtes et d’envoyer des
réponses à destination des clients suivant plusieurs protocoles dont le HTTP qui nous est utile
pour pouvoir effectuer ces échanges sur Internet.
La principale composante de notre serveur s’appuie sur le projet open source Deegree, un
« Framework » Java qui sert de support principal pour la construction d’applications spatiales
distribuées et standardisées. Deegree fournit entre autres une implémentation, sous la forme
d’une servlet déployable dans Tomcat, de la spécification WFS de l’OGC. Cette implémentation
utilise les structures géométriques et les opérateurs spatiaux de la Java Topology Suite (JTS).
Bien que très réputée, la JTS n’est pas assez complète pour notre système puisqu’elle
implémente seulement la Simple Feature Specification for SQL (SFS) de L’OGC qui est une
spécification pour les objets géométriques simples en 2D. C’est pourquoi nous devons étendre le
modèle géométrique de Deegree au niveau tridimensionnel pour pouvoir servir et traiter des
objets 3D dans notre système. Pour ce faire, la composante GeoAPI fournit une interface dérivée
du schéma spatiale de l’ISO 19107 qui décrit l’ensemble des géométries simples et complexes
1D, 2D et 3D tel que défini par l’ISO. Une fois rendu 3D-compatible, Deegree va pouvoir
récupérer la requête GetFeatures du client, déterminer le datastore nécessaire pour récupérer la
donnée demandée, créer et lancer une requête SQL pour récupérer les données demandées en
prenant soin d’ajouter une clause WHERE respectant la contrainte du filtre contenu dans la
requête du client, récupérer les données et créer les objets géométriques dans la structure de
Deegree selon le schéma spatial ISO 19107 (en se basant sur les règles de mapping décrites dans
le datastore) et traduire ces objets en format GML 3 pour les envoyer au client.
La librairie d’algorithmes d’opérateurs spatiaux 3D qui sera intégrée dans Deegree va aussi
permettre à notre système de réaliser de l’analyse spatiale sur les données. Les opérateurs
spatiaux à appliquer sur les données seront mentionnés par le client dans sa requête. Deegree
effectuera donc ces traitements sur les objets géométriques en format ISO 19107 avant de
convertir les résultats en format GML 3 pour le retour au client. Voici un exemple de requête
XML impliquant l’opérateur spatial Within et l’opérateur de comparaison Between:
(GEOMETRY INSIDE unité géologique id :1013 ) AND (DENSITE between 13 and 21)
<?xml version="1.0" ?>
- <wfs:GetFeature service="WFS" version="1.1.0" xmlns:wfs="http://www.opengis.net/wfs"
xmlns:ogc="http://www.opengis.net/ogc" xmlns:gml="http://www.opengis.net/gml"
xmlns:myns="http://www.someserver.com/myns" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://www.opengis.net/wfs ../wfs/1.1.0/WFS.xsd">
- <wfs:Query typeName="myns:duparquet_unit_geol">
- <Filter>
- <And>
- <Within>
<PropertyName>myns:GEOMETRY</PropertyName>
<ogc:GmlObjectId gml:id="duparquet_unit_geol.1013" />
</Within>
- <PropertyIsBetween>
<PropertyName>DENSITE</PropertyName>
- <LowerBoundary>
<Literal>13</Literal>
</LowerBoundary>
- <UpperBoundary>
<Literal>21</Literal>
</UpperBoundary>
</PropertyIsBetween>
</And>
</Filter>
</wfs:Query>
</wfs:GetFeature>
La base de données
Pour ce qui est du branchement à des sources de données, Deegree fournit une interface standard
(appelée Datastore) qui cache à l’utilisateur l’ensemble de la mécanique et des spécificités
propres à chaque format de données. De cette façon, il suffit de développer un nouveau datastore
pour permettre à notre système de reconnaître un nouveau format de données par
l’implémentation de cette interface standard sans avoir à apporter trop de modification aux autres
composantes du système.
Dans ce projet, nous planifions développer éventuellement un nouveau datastore pour permettre
le branchement à une structure de données 3D topologique implantée dans le SGBD Oracle soit
la structure GeoTEN (Lachance 2005). De plus, nous planifions coupler à cette structure
géométrique des données de SIGEOM du MRNFP afin de relier aux objets géométriques de
notre modèle 3D de l’information relative aux unités géologiques. De cette façon, les usagers de
Gocad pourront lors de requête WFS, obtenir les propriétés géologiques des objets géométriques
ou utiliser ces propriétés pour restreindre leur sélection à l’aide d’un filtre (ex : Tous les solides
dont le type de minerais=or). Pour l’instant, les données seront stockées sous forme de texte dans
un SGBD standard en format GML. Bien que nous avons planifié d’implanter cette structure de
données dans Oracle, nous pourrions tout aussi bien utiliser un autre SGBD comme PostgreSQL,
MySql ou SqlServer par exemple.
Les données test
Dans le cadre de ce projet, un modèle 3D géo-intégré d’un segment de la faille de PorcupineDestor dans le secteur de Duparquet sera utilisé pour tester et démontrer le bon fonctionnement
du système. Ces données en format Gocad, proviennent du Ministère des ressources naturelles,
de la faune et des parcs du Québec. Certain travaux devront être réalisés sur ce modèle afin
d’obtenir des solides tétraédriques nécessaires au projet.
Références
Lachance, B. (2005) Développement d'une structure topologique de données 3D pour l'analyse de modèles
géologiques. Mémoire de maîtrise, Université Laval
Pouliot, J., B. Lachance, A. Brisebois, O. Rabaud, D. Kirkwood (2003) 3D geological modeling: Are GIS or CAD
appropriates? ISPRS Workshop, WG II/5, II/6, IV/1 and IV/2 Joint Workshop on "Spatial, Temporal and
Multi-Dimensional Data Modelling and Analysis", October, 2-3, 2003, Québec, Canada.
Ramos, F. (2003) Modélisation et Validation d'un Système d'Information Géographique 3D opérationnel, Thèse de
doctorat en Informatique, spécialité Sciences de l'Information Géographique, Université de Marne la
Vallée. Soutenue le 5 mai 2003.
Stoter, J.E., Zlatanova, S. (2003a) Visualising and editing of 3D objects organised in a DBMS. In: Proceedings
EUROSDR Workshop: Rendering and Visualisation, (January 2003), Enschede, The Netherlands, 14p.
Zlatanova, S., Rahman, A.A. et Pilouk, M. (2002) Trends in 3D GIS development. In: Journal of Geospatial
Engineering, Vol.4, No.2, pp. 1-10
Normes
ISO TC 211-19107 (2000). "Geographic information - Spatial schema." No924, ISO/CD 19107.3, ISO TC 211/WG
2, Secretariat: NSF, 2000-05-25.
ISO TC 211-19136 (2004) "Geography Markup language" v3.1
ISO TC 211-19142 "Web Feature Service" v1.1 ISO TC 211/WG4
ISO TC 211-19143 "Filter incoding" ISO TC 211/WG4
Sites Web
Deegree : http://www.deegree.org/
GeoAPI : http://geoapi.sourceforge.net
Apache Tomcat : http://tomcat.apache.org/
Gocad : http://www.earthdecision.com/