Projet de développement d`un SIG-3D géologique
Transcription
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/