- Email: [email protected]
New Internet tools to manage geological and geophysical data
Computers & Geosciences 27 (2001) 563–575
New Internet tools to manage geological and geophysical data$ A. Guillen*, Ch. Meunier, X. Renaud, Ph. Repusseau BRGM BP 6009-45060 Orleans Cedex 02, France Received 1 April 1999; received in revised form 4 May 2000; accepted 9 September 2000
Abstract Data access within the framework of a scientific program such as GeoFrance 3D is of primary importance } scientists must be able to download, store and retrieve data using only an Internet connection and a browser on their computer. Here we describe the data model developed for this purpose, along with the architecture and classes of the system designed using Java technologies. We then illustrate the uses of the system, currently accessible at the URL address http://gf3d.brgm.fr:8000, using data from the GeoFrance 3D Armor project. # 2001 Elsevier Science Ltd. All rights reserved. Keywords: Internet; Java; Geological and geophysical data; Databases
1. Introduction
*
Visualization of the downward 3D extension of geological structures and phenomena, in order to reduce uncertainties in the use of subsurface space for the installation of infrastructures or for mining, is a daily challenge to the Earth Science community. It is also the ultimate goal of the GeoFrance 3D program (Groupe de Recherche GeoFrance 3D, 1997), which is dedicated to enhancing knowledge of the Lithosphere. GeoFrance 3D is a framework research program implementing the most advanced methods in each discipline. It is targeted to become an archive program providing storage, access and 3D valorization of geological and geophysical data gathered or treated within the framework of its projects. It aims at creating a ‘‘3D observatory’’ of the Earth’s crust through:
*
$
Associated code available at http://gf3d.brgm.fr:8000. *Corresponding author. Tel.: +33-2-3864-3869; fax: +33-23864-3361. E-mail addresses: [email protected] (A. Guillen), c.meunier @brgm.fr (Ch. Meunier), [email protected] (X. Renaud), [email protected] (Ph. Repusseau).
*
*
*
collecting existing data concerning the surface and subsurface of France; carrying out new exploration by deploying the geophysical measuring instruments necessary for imaging the subsurface; compiling multisource databases and providing the means for implementing 3D models and generalized inversion methods; providing 2D and 3D visualization of subsurface objects; disseminating these data and tools as widely as possible.
In this paper, we describe how GeoFrance 3D stores geological and geophysical data and enables the scientific community to access the data. The initial step was to provide a 2D- and 3D-modeling and datamanagement environment that fulfils the requirements of professionals in geology and geophysics; requirements that are well described by Van Brakel and Pienaar (1997). The environment must also be accessible via the Internet and be suitably equipped to enable: * *
the input of new data; the consultation of catalogues of available data with geographical and thematic requests;
0098-3004/01/$ - see front matter # 2001 Elsevier Science Ltd. All rights reserved. PII: S 0 0 9 8 - 3 0 0 4 ( 0 0 ) 0 0 1 6 4 - 3
564
A. Guillen et al. / Computers & Geosciences 27 (2001) 563–575
the downloading of these data on workstations so that they can be used in 2D and 3D modeling applications.
*
A pilot application capable of processing geographical and thematic queries was developed in April 1997 using the geological and principal geophysical data of the GeoFrance 3D Armor project. The results obtained from this phase of development enabled the prototype application to be developed into a public one. We should also like to point out that a close link exists between our project and the European geological electronic information exchange system (GEIXS) project1 mounted by Eurogeosurveys, whose objective is to provide free access to public catalogues of digital data available in the 15 European Geological Surveys. After describing the set of the problems to be solved, we discuss the architectural choices using the latest dataprocessing techniques. We also address the problem, accompanied by examples, of such a system being able to evolve to deal with: the addition of new data, a more powerful administration.
* *
Lastly, we show how all these aspects are integrated into a concept of 3D geological object modeling.
2. Method To provide access to all the GeoFrance 3D geological and geophysical data via the Internet, it is necessary support distributed applications according to a traditional client–server schema. Each application is structured with the following components: a database management system (DBMS), a query server, a user interface.
* * *
Abel et al. (1998) describe two main themes in the use of the Internet by the spatial information systems (SIS) community. The first relates to spatial data distribution and the second to accessing specialist spatial data processing services. Here we focus on the spatial data distribution and on designing the set of applications to address the GeoFrance 3D data, i.e.:
the management of seismic-profile and regular-grid data (grid and image level), the management of raw data.
*
*
Wherever possible we chose European standards or geoscience standards for these different fields. 2.1. Management of geoscience meta-data ‘‘In data-processing meta-data is definitional data that provides information about or documentation of other data managed within an application or environment’’,2 its management requires the facility for storing it in a database, modifying it and removing it. Geological and geophysical information concerns objects and phenomena directly or indirectly related to a location on or near the Earth’s surface. Digital data from a wide variety of sources is being georeferenced for use in a diversity of applications including environment, geological cartography and 3D modeling. Consequently, there is an increasing need for information standards to enable universal usage of digital geoscience information, to enhance the ability to integrate geoscience information with other digital information and applications, and to incorporate geo-processing functionality into a broad spectrum of existing and emerging information technologies. In the present situation, the basic objective of standardization in this field is to enable GeoFrance 3D geological and geophysical information to be accessed by different users, applications and systems from different locations. This requires a standard way of defining and describing this information, a standard method for structuring and encoding it, and a standard way of accessing, transferring and updating it via geoinformation processing and communication functions, independent of any particular computer system. To achieve a geoscience meta-data standard model, we used the CEN/TC 287 geographic information prestandard3 developed under an EEC project. This prestandard comprises a structured set of definitions that specify principles to define and describe and transport representations of objects of the real world. It allows comprehension and use of numerical geoscience information in any reference system of the real world. The CEN/TC 287 model is very complete and quite complex. A given meta-data is described by 10 main headings: its identification (name f the meta-data), its subject matter (summary, usage, nature),
*
the management of geoscience meta-data (catalogue level), the management of vector-type geological data (map level), using a distributed geographical information system (DGIS),
*
*
1
GEIXS, http://eurogeosurveys.brgm.fr.
*
2
FOLDOC (free on-line dictionary of computing), http: //foldoc.doc.ic.ac.uk/foldoc.index.html. 3 CEN/TC 287 The Geographic Information European Prestandards, http://forum.afnor.fr/afnor/WORK/AFNOR/ GPN2/Z13C/index.htm.
A. Guillen et al. / Computers & Geosciences 27 (2001) 563–575 *
*
*
*
* * *
*
its administration (organizational implications, role of each organization), its points of contact (set of themes, techniques, commercial aspects), its dissemination rules (restriction, copyright, price, media, format, point of contact), its quality (process of acquisition, quality of localization, set of themes), its geographical system of reference, its space extension (limit of zone), its temporal extension (date of acquisition and/or modification, update frequency), its data description schema.
We determined the relevant data that had to be accessible through the interface and then attempted to obtain a compromise between a detailed description of the standard and convenience of use. The items retained in the user interface to describe a given meta-data are thus (Fig. 1): A Meta-data folder gathering the attributes describing a given meta-data, themselves gathered in various thematic file: * compulsory data: mandatory attributes of a given data; * dataset identification: attributes identifying a given data;
dataset overview: attributes the user intended for this data; * dataset quality elements; – sources: attributes giving the history of the data; – quality: attributes giving the quality of the data; * extent: attributes describing the spatial and temporal extent of the data; * administrative meta-data: attributes describing the administrative aspects and the distribution of the data; * classification: attributes describing the dictionary of a given data; – a Thesaurus card, gathering the attributes defining the dictionary of the data; * meta-data reference: attributes giving the coordinate system. An Organization folder, gathering the attributes describing an organization. A Contact folder, containing the role of a person to be contacted. * A Person file, containing the description of a person (address, e-mail, etc.). *
*
* *
565
One of the specifications for the data entry application of a given meta-data is to the ability manage Multiple languages for the descriptive attributes of the meta-data.
Fig. 1. Client interface to input, request, update or delete meta-data (Armor project).
566
A. Guillen et al. / Computers & Geosciences 27 (2001) 563–575
This means that the system must be able ‘‘to speak’’ all the European languages retained for the project, namely: English, French, Dutch, Portuguese, Italian, Spanish, Greek, Swedish, Danish and Finnish. As with the European GEIXS project (see footnote 1), users may be located in or from different countries working on world-wide objects or compiling results from different methods or some particular specific dataset. The adopted solution is to create three entities to manage this requirement: a Multi-language object made up of a compulsory English text and an optional Translation-type attribute; a Translated object having (a) a compulsory attribute ‘‘traduction’’ for the text corresponding to the translation of the English text, and (b) a Languagetype attribute; a Language object including/understanding an enumeration of the languages used for the translations.
*
*
*
English must always be used in addition to a local language. Initially, the aspect concerning languages with special alphabetic characters was not treated. Lastly, it was deliberately decided to remove the description of the space extension of a given meta-data from the schema and to store it in a more suitable application called the DGIS. 2.2. Management of vector-type geological data The management of vector-type geological data, such as geological maps, cross-sections and observation points, must be designed to: graphically display database query results whilst satisfying spatial and/or attribute criteria; build requests with a spatial constraint for a query to the database management system (DBMS); export geometries and attributes to 2D GIS and 3D modeling tools.
*
*
*
Since the objective is to manage spatial queries from a geographical information system, we chose the spatial data engine (SDE) tool produced by ESRI4 to handle this functionality and incorporated it as a spatial layer on top of our external relational database. SDE is delivered with a dynamic library, allowing the development of client applications. We then encapsulated this application programming interface (API) in Java classes so as to provide the different components of the architecture in platform-independent form.
The user interface includes three essential parts (Fig. 2): a visualization tool (window) in which the geometry of geological objects and the images are presented; a set of fields to display the geographic co-ordinates of the bounding box of the geological object(s), as well as the current position in the current co-ordinate system (which is described in a particular window); a box allowing the selection, request and handling of objects.
*
*
*
The box allows one to: select a geological entity and to display its attributes, display a geometry, erase the objects not required by the user of the visualization tool, formulate a query and submit it to the server.
* * *
*
A query to the database is formulated by selecting a geographical layer (SDE organizes the different type of data in layers), specifying the attribute conditions of the layer, and then defining the spatial condition. This spatial condition relates to the geometry defined by the user (e.g. a polygon representing a zone of interest) with the option of specifying different topological operations such as ‘‘surfaces intersect each other’’ and/or ‘‘the points of intersection are contained within to the zone under study’’. For the data exchange between user and system, we selected the version 12 DXF File Format from AutoDesk,5 which is in ASCII format that can be used by the main GIS users’ tools, such as MapINFO1, Arc/Info1 as well as 3D modeling tools (AutoCAD1, Euclid1, Catia1, etc.) As large volumes of data are exchanged between the server and the client, the speed of application is limited by the bandwidth of the network. 2.3. Management of the seismic-profile and regular-grid data The objective was to create an application to input, modify, query, visualize and download geophysical data. The database contains geophysical studies (regular grids or seismic profiles) stored with standard formats used by geophysicists. To handle the grids, we selected the grid exchange format (GXF) developed by Getech6 with which it is possible to store regular rectangular grids (compressed or uncompressed) with an ASCII format that is platform independent. Among other data types, these grids can contain: gravity data, magnetic data,
* *
5 4
ESRI France, http://www.esrifrance.fr/index.htm.
6
AutoDesk, http://www.autodesk.fr. GXF format, htpp://getech.com/page2.htm.
A. Guillen et al. / Computers & Geosciences 27 (2001) 563–575
567
Fig. 2. Client interface for DGIS application (Armor project).
* *
digital terrain models, remote sensing images, etc.
To manage the seismic profiles we selected the SEGY format (Barry et al., 1975), which is a binary format and, therefore, dependent on the data-processing platform. To enable a correct user/system exchange, the data is stored in the database as a table of bytes managed by Java, which enables the format to be made independent of the platform type. The user interface includes two essential components (Figs. 3 and 4): * *
a screen allowing the selection of studies, a visualization tool (window) that displays the regular grids or the seismic profiles.
2.4. Raw data A raw data management system is yet to be developed, but will be designed to deal with, for example, * * * *
gravity point data, aeromagnetic data, structural geology data, etc.
The infrastructure that we have already developed for GeoFrance 3D geological and geophysical data allows for building such a system, which will be included in the next system development stage.
3. Architecture Our choice of architecture in the design of the applications was guided by the current state of the art in the Internet field and its prospective developments (see Chen and Davidson, 1997). It is a distributed architecture allowing a separation between the database and the client application, and the only user requirement is an Internet connection and a browser. Moreover, the client applications must run independently of the physical location of the server. We, therefore, adopted Java technology, which frees us from the proprietary protocols of communication provided by the database management systems, and also frees us from the format of the binary files. Finally, Java technology it allows the applications to be used with existing Internet browsers (Netscape, Explorer, HotJava, etc.), as well as providing many other advantages such as interoperability, memory management and security: interoperability being essential because the applications must be accessible on any
568
A. Guillen et al. / Computers & Geosciences 27 (2001) 563–575
Fig. 3. Client interface to manage geophysical studies (Armor project).
Fig. 4. Visualization of magnetic fields reduced to pole (Armor project).
platform, and security being significant because the databases are public. The user interfaces are applets and their privileges are more restrictive than those of some of the applications (e.g. read/write operations disabled for some files, launch facility disabled for certain applications, etc.). This is deliberate in order to avoid
interference without specific authorization of the client. Java is an object-oriented language, with a standardized library including: * *
graphic components, an events management facility,
A. Guillen et al. / Computers & Geosciences 27 (2001) 563–575 * *
connection classes between a server and the DBMS, exceptions. The architecture is also conditioned by the fact that:
* *
the databases are managed by an Oracle system V7.3, spatial queries are processed by SDE Version 3.
The links between the servers and the databases are thus made using Java database connection (JDBC) for Oracle and a layer of Java native interfaces (JNI) for SDE. The communications protocol between the server and the client was developed using remote method invocation (RMI) which supports the distributed process between two virtual machines. To address the constraints and previous choices, the schema of the selected Java architecture is given in Fig. 5, and that of the basic RMI architecture is given in Fig. 6. On the client side, the invocation of a method on a class of the server operates like a simple standard local call thanks to a local procedure in remote procedure call (RPC) known as a stub. The stub masks the complexity of the call through the network by transforming the data
Fig. 5. Architecture of Java application.
569
into a neutral format and then encoding this data so that it can be transported through a path to create a connection with the target host. RMI treats a remote object differently from a nonremote object when the object is passed from one virtual machine to another. Rather than making a copy of the implementation object in the receiving machine, RMI passes a remote stub for a remote object; the stub then acts as the local representative, or proxy, for the remote object and basically is, for the caller, the remote reference. The caller invokes a method on the local stub, which is responsible for carrying out the method call on the remote object. A stub for a remote object implements the same set of remote interfaces that the remote object implements. This allows a stub to be cast to any of the interfaces that the remote object implements. However, this also means that only those methods defined in a remote interface are available to be called in the receiving machine. On the server side, the data is decoded, transformed from the neutral format to the type suitable for the platform and passed as information to skeletons that, like stubs, mask the complexity of the transit of information and treat it like a local call to the server. Once the code is executed by the class of the server, it simply turns the value over to the skeletons which require it. The process is now reversible if the value is required to be returned to the calling client. The interface describes the various methods that the client will be likely to call upon and which a distant server will handle. Coding of the user interface results in one or more Java interfaces according to the choice of the developer, but it must inherits from the remote interface for client/server exchange. All the applications are applets to be loaded via a browser. They start by making a connection to the server and loading the information for processing future queries to the database. The user can then navigate in the database, and also formulate and submit queries. 3.1. META interfaces The META application is client oriented and ensures the visualization of the results from meta-data queries formulated by the user. METASERVER is a server that assures the communication between the server SDE and Oracle and the various client applications. Note that during input, geographical information of the meta-data is stored in the database SDE and can be accessed using the DGIS application. 3.2. DGIS interfaces
Fig. 6. Architecture of RMI.
The DGIS application is client oriented and addresses the formulation of spatial queries by the user and ensures the visualization of the results. DGISSERVER
570
A. Guillen et al. / Computers & Geosciences 27 (2001) 563–575
is a server that assures the communication between server SDE and the various customer applications. It encapsulates the SDE library, which gives access to the resources of the server SDE to: * * *
* *
establish a connection; submit a query; carry out basic geometrical queries such as selection in a polygon, along a line or close to a line; change the system of co-ordinates; etc.
The Java native interface (JNI) is a means of encapsulating a library of C or C++ functions dependent on the platform on which it is carried out. An Oracle proprietary protocol supports the communication between the server SDE and Oracle. 3.3. The geophysical interfaces This client interface the realization of thematic queries on the geophysical data managed by GXF and SEGY formats and ensures graphic visualization of grid data and seismic profiles.
3.4. Administration of the system The system administration envisages certain user profiles to which rights can be selectively assigned. A user may have rights to: * * * * *
select data, update data, write new data in the database, delete old data, download data on a local computer.
These rights are allocated to a username, a password, and the IP-address of the client’s computer.
4. Visualization tool In order to facilitate geoscience browsing, one needs to have the ability to (a) display geometrical objects in a graphical environment, and (b) visualize all objects in such an environment (images, geometrical forms, mathematical functions, geophysical recordings, etc.) by positioning them on a virtually infinite georeferenced sheet. Consequently, we developed a visualization tool which sits on top of the class structure schematized in Fig. 7.
Fig. 7. Design of visualization classes.
A. Guillen et al. / Computers & Geosciences 27 (2001) 563–575
Any displayable object inherits from the Presentable class. It contains a reference to the visualization tool and the envelope of the object to be presented, and thus can be referred to geographically. The compute and computeEnvelope methods are abstract and are implemented within the classes that contain them; they compute both the presentation of the object and the object envelope. The viewer (Visu class) contains a set of Presentable objects and displays them by calling up each of the compute methods. Visu inherits first from Canvas, which is a standard class of Java whose canvases are sheets on which the objects of the Presentable type are drawn, and then from the Component class, which implements the methods for repainting the objects on the sheet. The Shape and Image classes determine the compute method(s) of the Presentable class. We applied this principle to visualize the geophysical grids and seismic profiles, but it is possible to extend this schema to any georeferenced object. The Shape class is the generalization of geometric forms such as the point, the polygon, a compound of these geometrical forms, etc. These are the classes that implement the abstract compute method. The viewer supports various operations: *
*
*
*
*
Paint: (overload the Paint method of Component): to repaint the presentable objects in the current envelope (on each operation defined below in particular), it calls up a dedicated compute method. FitAll: to define the envelope containing all the presentable objects in order to see all objects. Zoom: to enlarge the objects presented according to the user demands. Pan: to move within the viewer by keeping the same aspect ratio of visualization. Convert: to transform the co-ordinates of the objects using an affine function.
5. Development and discussion The following examples, taken from the GeoFrance 3D Armor project, enable us to illustrate the various possibilities of the system, namely: * *
*
the management of the geoscience meta-data, the management of the vector-type geological data, using a DGIS, the management of seismic-profile and regular-grid data.
5.1. Geoscience meta-data The Armor project being part of the GeoFrance 3D program, we created a meta-data describing the GeoFrance 3D program and, within this, a metadata describing the Armor project as illustrated in Fig. 1. Similarly, the Armor project contains several datasets (1 : 100,000-scale geological map, aeromagnetic maps, gravity maps, seismic profiles, etc.) for each of which we created a meta-data describing the various fields. Moreover, we created a hyperlink with the meta-data of the GeoFrance 3D program as a dataset. 5.2. Vector-type geological data The DGIS contains, in addition to the area of interest for each dataset (geological maps, geophysical maps, seismic profiles) the geological map of Armor at 1 : 100,000 scale. Fig. 8 shows some results and screens used in this application such as: *
* *
The viewer is implemented by carrying out a sequence of operations whose events are managed by using a mouse. In a package for two-dimensional geometry, the following classes are defined:
571
Fig. 8A: the area of interest on the 1 : 100,000-scale geological map, Fig. 8B: the different layers available currently, Fig. 8C: the Armor 1 : 100,000-scale geological map resulting from the Armor project and the information on a selected formation.
5.3. Seismic-profile and regular-grid data * * * * * * *
*
a point (Point), a compound of points (CompPoint), a line (Line), a polygon (Polygon), a compound of shapes (Compound), an envelope (Envelope), a vector (Vec): its construction is based on the Point and transformations such as geometric, homothetic, translation, displacement, etc, a graphic transformation (GTrsf2d): ensuring the two-way transformation between real and screen coordinates, various operations on matrices, etc.
The regular-grid geophysical data that was compiled for the Armor project, such as the areomagnetic data (Galdeano et al., 2001), were stored in the database so that they could be accessed for the Armor study as illustrated in Figs. 2 and 3. The seismic profile obtained in 1994 (Bitri et al., 2001) was similarly stored (Fig. 9); however, it should be noted that the quantity of information contained in a seismic profile implies significant document size, with the result that it takes several minutes to access the data on the server and provide an image to the user (10 min for a 60 MB file).
572
A. Guillen et al. / Computers & Geosciences 27 (2001) 563–575
Fig. 8. (A) Results of a spatial query on geological data (Armor project). (B) List of available layers and their attributes (Armor project). (C) Armor 1 : 100,000-geological map and information about different objects obtained after spatial query (Armor project).
A. Guillen et al. / Computers & Geosciences 27 (2001) 563–575
573
Fig. 8. Continued.
The development of the Armor project demonstrated that the choices were appropriate and that all the functionalities were successfully implemented.
In order to valorize existing 2D work (maps, crosssections, grids, DTM) we included a SDE client in our 3D solution. This integration allows us to: *
6. 3D modeling tools *
For several years, the BRGM has been developing 3D methods and modeling tools for geologists, based on CAS.CADE library from Matra Datavision.7 7 Matra Datavision, http://www.opencascade.com and http: //www.opencascade.org.
*
*
use existing 2D objects (maps, cross-sections, grids, DTM), build the meta-data of our 3D models by conforming to the CEN/TC 287 geographic information prestandard (see footnote 3), produce a virtual reality modeling language (VRML) document to be included in the meta-data, publish our meta-data in the catalogues of 3D models (Courrioux et al., 2001) as shown in Fig. 10.
574
A. Guillen et al. / Computers & Geosciences 27 (2001) 563–575
Fig. 9. Seismic profile (Armor project).
In order to realize this integration, we encapsulated the various functions of the client SDE in C++ and packaged the whole in the CAS.CADE environment.
*
7. Conclusions *
Using existing tools and protocols (RMI, JDBC, etc.), we have developed a client–server architecture in Java that satisfies our requirements. The main problem was in defining the right architecture. We now have: *
a graphical visualization environment using pure Java that allows us to visualize images in a virtually
infinite georeferenced sheet, and which can support extensions; a geological and geophysical data storage in an Oracle server that allows the data to be downloaded for possible modification, thus ensuring their permanence; the processing of spatial information (geographical storage and spatial query) with a suitable tool (SDE).
The object-oriented design of these applications ensures a high level of reusability and scalability. The libraries that we have developed could be reused in the near future to build other applications, such as a knowledge database for geology or geophysics.
A. Guillen et al. / Computers & Geosciences 27 (2001) 563–575
575
Fig. 10. 3D model (Armor project).
All the results can be viewed at the URL address http://gf3d.brgm.fr:8000/, where the user can access the different applications and study all the design, packages and classes documentation.
Acknowledgements The work described in this article was co-funded by the Geofrance 3D program and a BRGM research project. Patrick Skipwith, BRGM Translation Service, improved the English of the final version of the manuscript. We are grateful to Patrick Ledru and Anne Bourguignon for their involvement.
References Abel, D.J., Taylor, K., Ackland, R., Hungerford, S., 1998. An exploration of GIS architecture for Internet environments. Computers Environment and Urban Systems 22 (1), 7–23.
Barry, K.M., Cavers, D.A., Kneale, C.W., 1975. Special report: recommended standards for digital tape formats. Geophysics 40 (2), 344–352. Bitri, A., Brun, J.P., Truffert, C., Guennoc, P., 2001. Deep seismic imaging of the Cadomian thrust wedge of northern Brittany. Tectonophysics 331 (1–2), 65–80. Chen, E., Davidson, D., 1997. Moving beyond the current state of the Internet. Computers & Geosciences 23 (2), 497–502. Courrioux, G., Guillen, A., Boissonnat, J.D., Nullans, S., Repusseau, Ph., Renaud, X., Thibaud, M., 2001. 3D volumic modelling of Cadomian terranes (Northern Britanny, France): an automatic method using Voronoi diagrams. Tectonophysics 331 (1–2), 181–196. Galdeano, A., Azfirane, F., Truffert, C., Debeglia, N., 2001. Detailed aeromagnetic mapping and structures of the North Armorican Massif (Saint-Malo survey). Tectonophysics 33 (1–2), 99–122. Groupe de Recherche Ge´oFrance 3D, 1997. L’imagerie Ge´ologique et Ge´ophysique 3D du sous-sol de la France. Me´moire de la Socie´te´ Ge´ologique de France 172, 53–71. Van Brakel, P.A., Pienaar, M., 1997. Geographic information systems: how a World Wide Web presence can improve their availability. The Electronic Library 15 (2), 109–116.
New Internet tools to manage geological and geophysical data$ A. Guillen*, Ch. Meunier, X. Renaud, Ph. Repusseau BRGM BP 6009-45060 Orleans Cedex 02, France Received 1 April 1999; received in revised form 4 May 2000; accepted 9 September 2000
Abstract Data access within the framework of a scientific program such as GeoFrance 3D is of primary importance } scientists must be able to download, store and retrieve data using only an Internet connection and a browser on their computer. Here we describe the data model developed for this purpose, along with the architecture and classes of the system designed using Java technologies. We then illustrate the uses of the system, currently accessible at the URL address http://gf3d.brgm.fr:8000, using data from the GeoFrance 3D Armor project. # 2001 Elsevier Science Ltd. All rights reserved. Keywords: Internet; Java; Geological and geophysical data; Databases
1. Introduction
*
Visualization of the downward 3D extension of geological structures and phenomena, in order to reduce uncertainties in the use of subsurface space for the installation of infrastructures or for mining, is a daily challenge to the Earth Science community. It is also the ultimate goal of the GeoFrance 3D program (Groupe de Recherche GeoFrance 3D, 1997), which is dedicated to enhancing knowledge of the Lithosphere. GeoFrance 3D is a framework research program implementing the most advanced methods in each discipline. It is targeted to become an archive program providing storage, access and 3D valorization of geological and geophysical data gathered or treated within the framework of its projects. It aims at creating a ‘‘3D observatory’’ of the Earth’s crust through:
*
$
Associated code available at http://gf3d.brgm.fr:8000. *Corresponding author. Tel.: +33-2-3864-3869; fax: +33-23864-3361. E-mail addresses: [email protected] (A. Guillen), c.meunier @brgm.fr (Ch. Meunier), [email protected] (X. Renaud), [email protected] (Ph. Repusseau).
*
*
*
collecting existing data concerning the surface and subsurface of France; carrying out new exploration by deploying the geophysical measuring instruments necessary for imaging the subsurface; compiling multisource databases and providing the means for implementing 3D models and generalized inversion methods; providing 2D and 3D visualization of subsurface objects; disseminating these data and tools as widely as possible.
In this paper, we describe how GeoFrance 3D stores geological and geophysical data and enables the scientific community to access the data. The initial step was to provide a 2D- and 3D-modeling and datamanagement environment that fulfils the requirements of professionals in geology and geophysics; requirements that are well described by Van Brakel and Pienaar (1997). The environment must also be accessible via the Internet and be suitably equipped to enable: * *
the input of new data; the consultation of catalogues of available data with geographical and thematic requests;
0098-3004/01/$ - see front matter # 2001 Elsevier Science Ltd. All rights reserved. PII: S 0 0 9 8 - 3 0 0 4 ( 0 0 ) 0 0 1 6 4 - 3
564
A. Guillen et al. / Computers & Geosciences 27 (2001) 563–575
the downloading of these data on workstations so that they can be used in 2D and 3D modeling applications.
*
A pilot application capable of processing geographical and thematic queries was developed in April 1997 using the geological and principal geophysical data of the GeoFrance 3D Armor project. The results obtained from this phase of development enabled the prototype application to be developed into a public one. We should also like to point out that a close link exists between our project and the European geological electronic information exchange system (GEIXS) project1 mounted by Eurogeosurveys, whose objective is to provide free access to public catalogues of digital data available in the 15 European Geological Surveys. After describing the set of the problems to be solved, we discuss the architectural choices using the latest dataprocessing techniques. We also address the problem, accompanied by examples, of such a system being able to evolve to deal with: the addition of new data, a more powerful administration.
* *
Lastly, we show how all these aspects are integrated into a concept of 3D geological object modeling.
2. Method To provide access to all the GeoFrance 3D geological and geophysical data via the Internet, it is necessary support distributed applications according to a traditional client–server schema. Each application is structured with the following components: a database management system (DBMS), a query server, a user interface.
* * *
Abel et al. (1998) describe two main themes in the use of the Internet by the spatial information systems (SIS) community. The first relates to spatial data distribution and the second to accessing specialist spatial data processing services. Here we focus on the spatial data distribution and on designing the set of applications to address the GeoFrance 3D data, i.e.:
the management of seismic-profile and regular-grid data (grid and image level), the management of raw data.
*
*
Wherever possible we chose European standards or geoscience standards for these different fields. 2.1. Management of geoscience meta-data ‘‘In data-processing meta-data is definitional data that provides information about or documentation of other data managed within an application or environment’’,2 its management requires the facility for storing it in a database, modifying it and removing it. Geological and geophysical information concerns objects and phenomena directly or indirectly related to a location on or near the Earth’s surface. Digital data from a wide variety of sources is being georeferenced for use in a diversity of applications including environment, geological cartography and 3D modeling. Consequently, there is an increasing need for information standards to enable universal usage of digital geoscience information, to enhance the ability to integrate geoscience information with other digital information and applications, and to incorporate geo-processing functionality into a broad spectrum of existing and emerging information technologies. In the present situation, the basic objective of standardization in this field is to enable GeoFrance 3D geological and geophysical information to be accessed by different users, applications and systems from different locations. This requires a standard way of defining and describing this information, a standard method for structuring and encoding it, and a standard way of accessing, transferring and updating it via geoinformation processing and communication functions, independent of any particular computer system. To achieve a geoscience meta-data standard model, we used the CEN/TC 287 geographic information prestandard3 developed under an EEC project. This prestandard comprises a structured set of definitions that specify principles to define and describe and transport representations of objects of the real world. It allows comprehension and use of numerical geoscience information in any reference system of the real world. The CEN/TC 287 model is very complete and quite complex. A given meta-data is described by 10 main headings: its identification (name f the meta-data), its subject matter (summary, usage, nature),
*
the management of geoscience meta-data (catalogue level), the management of vector-type geological data (map level), using a distributed geographical information system (DGIS),
*
*
1
GEIXS, http://eurogeosurveys.brgm.fr.
*
2
FOLDOC (free on-line dictionary of computing), http: //foldoc.doc.ic.ac.uk/foldoc.index.html. 3 CEN/TC 287 The Geographic Information European Prestandards, http://forum.afnor.fr/afnor/WORK/AFNOR/ GPN2/Z13C/index.htm.
A. Guillen et al. / Computers & Geosciences 27 (2001) 563–575 *
*
*
*
* * *
*
its administration (organizational implications, role of each organization), its points of contact (set of themes, techniques, commercial aspects), its dissemination rules (restriction, copyright, price, media, format, point of contact), its quality (process of acquisition, quality of localization, set of themes), its geographical system of reference, its space extension (limit of zone), its temporal extension (date of acquisition and/or modification, update frequency), its data description schema.
We determined the relevant data that had to be accessible through the interface and then attempted to obtain a compromise between a detailed description of the standard and convenience of use. The items retained in the user interface to describe a given meta-data are thus (Fig. 1): A Meta-data folder gathering the attributes describing a given meta-data, themselves gathered in various thematic file: * compulsory data: mandatory attributes of a given data; * dataset identification: attributes identifying a given data;
dataset overview: attributes the user intended for this data; * dataset quality elements; – sources: attributes giving the history of the data; – quality: attributes giving the quality of the data; * extent: attributes describing the spatial and temporal extent of the data; * administrative meta-data: attributes describing the administrative aspects and the distribution of the data; * classification: attributes describing the dictionary of a given data; – a Thesaurus card, gathering the attributes defining the dictionary of the data; * meta-data reference: attributes giving the coordinate system. An Organization folder, gathering the attributes describing an organization. A Contact folder, containing the role of a person to be contacted. * A Person file, containing the description of a person (address, e-mail, etc.). *
*
* *
565
One of the specifications for the data entry application of a given meta-data is to the ability manage Multiple languages for the descriptive attributes of the meta-data.
Fig. 1. Client interface to input, request, update or delete meta-data (Armor project).
566
A. Guillen et al. / Computers & Geosciences 27 (2001) 563–575
This means that the system must be able ‘‘to speak’’ all the European languages retained for the project, namely: English, French, Dutch, Portuguese, Italian, Spanish, Greek, Swedish, Danish and Finnish. As with the European GEIXS project (see footnote 1), users may be located in or from different countries working on world-wide objects or compiling results from different methods or some particular specific dataset. The adopted solution is to create three entities to manage this requirement: a Multi-language object made up of a compulsory English text and an optional Translation-type attribute; a Translated object having (a) a compulsory attribute ‘‘traduction’’ for the text corresponding to the translation of the English text, and (b) a Languagetype attribute; a Language object including/understanding an enumeration of the languages used for the translations.
*
*
*
English must always be used in addition to a local language. Initially, the aspect concerning languages with special alphabetic characters was not treated. Lastly, it was deliberately decided to remove the description of the space extension of a given meta-data from the schema and to store it in a more suitable application called the DGIS. 2.2. Management of vector-type geological data The management of vector-type geological data, such as geological maps, cross-sections and observation points, must be designed to: graphically display database query results whilst satisfying spatial and/or attribute criteria; build requests with a spatial constraint for a query to the database management system (DBMS); export geometries and attributes to 2D GIS and 3D modeling tools.
*
*
*
Since the objective is to manage spatial queries from a geographical information system, we chose the spatial data engine (SDE) tool produced by ESRI4 to handle this functionality and incorporated it as a spatial layer on top of our external relational database. SDE is delivered with a dynamic library, allowing the development of client applications. We then encapsulated this application programming interface (API) in Java classes so as to provide the different components of the architecture in platform-independent form.
The user interface includes three essential parts (Fig. 2): a visualization tool (window) in which the geometry of geological objects and the images are presented; a set of fields to display the geographic co-ordinates of the bounding box of the geological object(s), as well as the current position in the current co-ordinate system (which is described in a particular window); a box allowing the selection, request and handling of objects.
*
*
*
The box allows one to: select a geological entity and to display its attributes, display a geometry, erase the objects not required by the user of the visualization tool, formulate a query and submit it to the server.
* * *
*
A query to the database is formulated by selecting a geographical layer (SDE organizes the different type of data in layers), specifying the attribute conditions of the layer, and then defining the spatial condition. This spatial condition relates to the geometry defined by the user (e.g. a polygon representing a zone of interest) with the option of specifying different topological operations such as ‘‘surfaces intersect each other’’ and/or ‘‘the points of intersection are contained within to the zone under study’’. For the data exchange between user and system, we selected the version 12 DXF File Format from AutoDesk,5 which is in ASCII format that can be used by the main GIS users’ tools, such as MapINFO1, Arc/Info1 as well as 3D modeling tools (AutoCAD1, Euclid1, Catia1, etc.) As large volumes of data are exchanged between the server and the client, the speed of application is limited by the bandwidth of the network. 2.3. Management of the seismic-profile and regular-grid data The objective was to create an application to input, modify, query, visualize and download geophysical data. The database contains geophysical studies (regular grids or seismic profiles) stored with standard formats used by geophysicists. To handle the grids, we selected the grid exchange format (GXF) developed by Getech6 with which it is possible to store regular rectangular grids (compressed or uncompressed) with an ASCII format that is platform independent. Among other data types, these grids can contain: gravity data, magnetic data,
* *
5 4
ESRI France, http://www.esrifrance.fr/index.htm.
6
AutoDesk, http://www.autodesk.fr. GXF format, htpp://getech.com/page2.htm.
A. Guillen et al. / Computers & Geosciences 27 (2001) 563–575
567
Fig. 2. Client interface for DGIS application (Armor project).
* *
digital terrain models, remote sensing images, etc.
To manage the seismic profiles we selected the SEGY format (Barry et al., 1975), which is a binary format and, therefore, dependent on the data-processing platform. To enable a correct user/system exchange, the data is stored in the database as a table of bytes managed by Java, which enables the format to be made independent of the platform type. The user interface includes two essential components (Figs. 3 and 4): * *
a screen allowing the selection of studies, a visualization tool (window) that displays the regular grids or the seismic profiles.
2.4. Raw data A raw data management system is yet to be developed, but will be designed to deal with, for example, * * * *
gravity point data, aeromagnetic data, structural geology data, etc.
The infrastructure that we have already developed for GeoFrance 3D geological and geophysical data allows for building such a system, which will be included in the next system development stage.
3. Architecture Our choice of architecture in the design of the applications was guided by the current state of the art in the Internet field and its prospective developments (see Chen and Davidson, 1997). It is a distributed architecture allowing a separation between the database and the client application, and the only user requirement is an Internet connection and a browser. Moreover, the client applications must run independently of the physical location of the server. We, therefore, adopted Java technology, which frees us from the proprietary protocols of communication provided by the database management systems, and also frees us from the format of the binary files. Finally, Java technology it allows the applications to be used with existing Internet browsers (Netscape, Explorer, HotJava, etc.), as well as providing many other advantages such as interoperability, memory management and security: interoperability being essential because the applications must be accessible on any
568
A. Guillen et al. / Computers & Geosciences 27 (2001) 563–575
Fig. 3. Client interface to manage geophysical studies (Armor project).
Fig. 4. Visualization of magnetic fields reduced to pole (Armor project).
platform, and security being significant because the databases are public. The user interfaces are applets and their privileges are more restrictive than those of some of the applications (e.g. read/write operations disabled for some files, launch facility disabled for certain applications, etc.). This is deliberate in order to avoid
interference without specific authorization of the client. Java is an object-oriented language, with a standardized library including: * *
graphic components, an events management facility,
A. Guillen et al. / Computers & Geosciences 27 (2001) 563–575 * *
connection classes between a server and the DBMS, exceptions. The architecture is also conditioned by the fact that:
* *
the databases are managed by an Oracle system V7.3, spatial queries are processed by SDE Version 3.
The links between the servers and the databases are thus made using Java database connection (JDBC) for Oracle and a layer of Java native interfaces (JNI) for SDE. The communications protocol between the server and the client was developed using remote method invocation (RMI) which supports the distributed process between two virtual machines. To address the constraints and previous choices, the schema of the selected Java architecture is given in Fig. 5, and that of the basic RMI architecture is given in Fig. 6. On the client side, the invocation of a method on a class of the server operates like a simple standard local call thanks to a local procedure in remote procedure call (RPC) known as a stub. The stub masks the complexity of the call through the network by transforming the data
Fig. 5. Architecture of Java application.
569
into a neutral format and then encoding this data so that it can be transported through a path to create a connection with the target host. RMI treats a remote object differently from a nonremote object when the object is passed from one virtual machine to another. Rather than making a copy of the implementation object in the receiving machine, RMI passes a remote stub for a remote object; the stub then acts as the local representative, or proxy, for the remote object and basically is, for the caller, the remote reference. The caller invokes a method on the local stub, which is responsible for carrying out the method call on the remote object. A stub for a remote object implements the same set of remote interfaces that the remote object implements. This allows a stub to be cast to any of the interfaces that the remote object implements. However, this also means that only those methods defined in a remote interface are available to be called in the receiving machine. On the server side, the data is decoded, transformed from the neutral format to the type suitable for the platform and passed as information to skeletons that, like stubs, mask the complexity of the transit of information and treat it like a local call to the server. Once the code is executed by the class of the server, it simply turns the value over to the skeletons which require it. The process is now reversible if the value is required to be returned to the calling client. The interface describes the various methods that the client will be likely to call upon and which a distant server will handle. Coding of the user interface results in one or more Java interfaces according to the choice of the developer, but it must inherits from the remote interface for client/server exchange. All the applications are applets to be loaded via a browser. They start by making a connection to the server and loading the information for processing future queries to the database. The user can then navigate in the database, and also formulate and submit queries. 3.1. META interfaces The META application is client oriented and ensures the visualization of the results from meta-data queries formulated by the user. METASERVER is a server that assures the communication between the server SDE and Oracle and the various client applications. Note that during input, geographical information of the meta-data is stored in the database SDE and can be accessed using the DGIS application. 3.2. DGIS interfaces
Fig. 6. Architecture of RMI.
The DGIS application is client oriented and addresses the formulation of spatial queries by the user and ensures the visualization of the results. DGISSERVER
570
A. Guillen et al. / Computers & Geosciences 27 (2001) 563–575
is a server that assures the communication between server SDE and the various customer applications. It encapsulates the SDE library, which gives access to the resources of the server SDE to: * * *
* *
establish a connection; submit a query; carry out basic geometrical queries such as selection in a polygon, along a line or close to a line; change the system of co-ordinates; etc.
The Java native interface (JNI) is a means of encapsulating a library of C or C++ functions dependent on the platform on which it is carried out. An Oracle proprietary protocol supports the communication between the server SDE and Oracle. 3.3. The geophysical interfaces This client interface the realization of thematic queries on the geophysical data managed by GXF and SEGY formats and ensures graphic visualization of grid data and seismic profiles.
3.4. Administration of the system The system administration envisages certain user profiles to which rights can be selectively assigned. A user may have rights to: * * * * *
select data, update data, write new data in the database, delete old data, download data on a local computer.
These rights are allocated to a username, a password, and the IP-address of the client’s computer.
4. Visualization tool In order to facilitate geoscience browsing, one needs to have the ability to (a) display geometrical objects in a graphical environment, and (b) visualize all objects in such an environment (images, geometrical forms, mathematical functions, geophysical recordings, etc.) by positioning them on a virtually infinite georeferenced sheet. Consequently, we developed a visualization tool which sits on top of the class structure schematized in Fig. 7.
Fig. 7. Design of visualization classes.
A. Guillen et al. / Computers & Geosciences 27 (2001) 563–575
Any displayable object inherits from the Presentable class. It contains a reference to the visualization tool and the envelope of the object to be presented, and thus can be referred to geographically. The compute and computeEnvelope methods are abstract and are implemented within the classes that contain them; they compute both the presentation of the object and the object envelope. The viewer (Visu class) contains a set of Presentable objects and displays them by calling up each of the compute methods. Visu inherits first from Canvas, which is a standard class of Java whose canvases are sheets on which the objects of the Presentable type are drawn, and then from the Component class, which implements the methods for repainting the objects on the sheet. The Shape and Image classes determine the compute method(s) of the Presentable class. We applied this principle to visualize the geophysical grids and seismic profiles, but it is possible to extend this schema to any georeferenced object. The Shape class is the generalization of geometric forms such as the point, the polygon, a compound of these geometrical forms, etc. These are the classes that implement the abstract compute method. The viewer supports various operations: *
*
*
*
*
Paint: (overload the Paint method of Component): to repaint the presentable objects in the current envelope (on each operation defined below in particular), it calls up a dedicated compute method. FitAll: to define the envelope containing all the presentable objects in order to see all objects. Zoom: to enlarge the objects presented according to the user demands. Pan: to move within the viewer by keeping the same aspect ratio of visualization. Convert: to transform the co-ordinates of the objects using an affine function.
5. Development and discussion The following examples, taken from the GeoFrance 3D Armor project, enable us to illustrate the various possibilities of the system, namely: * *
*
the management of the geoscience meta-data, the management of the vector-type geological data, using a DGIS, the management of seismic-profile and regular-grid data.
5.1. Geoscience meta-data The Armor project being part of the GeoFrance 3D program, we created a meta-data describing the GeoFrance 3D program and, within this, a metadata describing the Armor project as illustrated in Fig. 1. Similarly, the Armor project contains several datasets (1 : 100,000-scale geological map, aeromagnetic maps, gravity maps, seismic profiles, etc.) for each of which we created a meta-data describing the various fields. Moreover, we created a hyperlink with the meta-data of the GeoFrance 3D program as a dataset. 5.2. Vector-type geological data The DGIS contains, in addition to the area of interest for each dataset (geological maps, geophysical maps, seismic profiles) the geological map of Armor at 1 : 100,000 scale. Fig. 8 shows some results and screens used in this application such as: *
* *
The viewer is implemented by carrying out a sequence of operations whose events are managed by using a mouse. In a package for two-dimensional geometry, the following classes are defined:
571
Fig. 8A: the area of interest on the 1 : 100,000-scale geological map, Fig. 8B: the different layers available currently, Fig. 8C: the Armor 1 : 100,000-scale geological map resulting from the Armor project and the information on a selected formation.
5.3. Seismic-profile and regular-grid data * * * * * * *
*
a point (Point), a compound of points (CompPoint), a line (Line), a polygon (Polygon), a compound of shapes (Compound), an envelope (Envelope), a vector (Vec): its construction is based on the Point and transformations such as geometric, homothetic, translation, displacement, etc, a graphic transformation (GTrsf2d): ensuring the two-way transformation between real and screen coordinates, various operations on matrices, etc.
The regular-grid geophysical data that was compiled for the Armor project, such as the areomagnetic data (Galdeano et al., 2001), were stored in the database so that they could be accessed for the Armor study as illustrated in Figs. 2 and 3. The seismic profile obtained in 1994 (Bitri et al., 2001) was similarly stored (Fig. 9); however, it should be noted that the quantity of information contained in a seismic profile implies significant document size, with the result that it takes several minutes to access the data on the server and provide an image to the user (10 min for a 60 MB file).
572
A. Guillen et al. / Computers & Geosciences 27 (2001) 563–575
Fig. 8. (A) Results of a spatial query on geological data (Armor project). (B) List of available layers and their attributes (Armor project). (C) Armor 1 : 100,000-geological map and information about different objects obtained after spatial query (Armor project).
A. Guillen et al. / Computers & Geosciences 27 (2001) 563–575
573
Fig. 8. Continued.
The development of the Armor project demonstrated that the choices were appropriate and that all the functionalities were successfully implemented.
In order to valorize existing 2D work (maps, crosssections, grids, DTM) we included a SDE client in our 3D solution. This integration allows us to: *
6. 3D modeling tools *
For several years, the BRGM has been developing 3D methods and modeling tools for geologists, based on CAS.CADE library from Matra Datavision.7 7 Matra Datavision, http://www.opencascade.com and http: //www.opencascade.org.
*
*
use existing 2D objects (maps, cross-sections, grids, DTM), build the meta-data of our 3D models by conforming to the CEN/TC 287 geographic information prestandard (see footnote 3), produce a virtual reality modeling language (VRML) document to be included in the meta-data, publish our meta-data in the catalogues of 3D models (Courrioux et al., 2001) as shown in Fig. 10.
574
A. Guillen et al. / Computers & Geosciences 27 (2001) 563–575
Fig. 9. Seismic profile (Armor project).
In order to realize this integration, we encapsulated the various functions of the client SDE in C++ and packaged the whole in the CAS.CADE environment.
*
7. Conclusions *
Using existing tools and protocols (RMI, JDBC, etc.), we have developed a client–server architecture in Java that satisfies our requirements. The main problem was in defining the right architecture. We now have: *
a graphical visualization environment using pure Java that allows us to visualize images in a virtually
infinite georeferenced sheet, and which can support extensions; a geological and geophysical data storage in an Oracle server that allows the data to be downloaded for possible modification, thus ensuring their permanence; the processing of spatial information (geographical storage and spatial query) with a suitable tool (SDE).
The object-oriented design of these applications ensures a high level of reusability and scalability. The libraries that we have developed could be reused in the near future to build other applications, such as a knowledge database for geology or geophysics.
A. Guillen et al. / Computers & Geosciences 27 (2001) 563–575
575
Fig. 10. 3D model (Armor project).
All the results can be viewed at the URL address http://gf3d.brgm.fr:8000/, where the user can access the different applications and study all the design, packages and classes documentation.
Acknowledgements The work described in this article was co-funded by the Geofrance 3D program and a BRGM research project. Patrick Skipwith, BRGM Translation Service, improved the English of the final version of the manuscript. We are grateful to Patrick Ledru and Anne Bourguignon for their involvement.
References Abel, D.J., Taylor, K., Ackland, R., Hungerford, S., 1998. An exploration of GIS architecture for Internet environments. Computers Environment and Urban Systems 22 (1), 7–23.
Barry, K.M., Cavers, D.A., Kneale, C.W., 1975. Special report: recommended standards for digital tape formats. Geophysics 40 (2), 344–352. Bitri, A., Brun, J.P., Truffert, C., Guennoc, P., 2001. Deep seismic imaging of the Cadomian thrust wedge of northern Brittany. Tectonophysics 331 (1–2), 65–80. Chen, E., Davidson, D., 1997. Moving beyond the current state of the Internet. Computers & Geosciences 23 (2), 497–502. Courrioux, G., Guillen, A., Boissonnat, J.D., Nullans, S., Repusseau, Ph., Renaud, X., Thibaud, M., 2001. 3D volumic modelling of Cadomian terranes (Northern Britanny, France): an automatic method using Voronoi diagrams. Tectonophysics 331 (1–2), 181–196. Galdeano, A., Azfirane, F., Truffert, C., Debeglia, N., 2001. Detailed aeromagnetic mapping and structures of the North Armorican Massif (Saint-Malo survey). Tectonophysics 33 (1–2), 99–122. Groupe de Recherche Ge´oFrance 3D, 1997. L’imagerie Ge´ologique et Ge´ophysique 3D du sous-sol de la France. Me´moire de la Socie´te´ Ge´ologique de France 172, 53–71. Van Brakel, P.A., Pienaar, M., 1997. Geographic information systems: how a World Wide Web presence can improve their availability. The Electronic Library 15 (2), 109–116.