GeoToolKit: Opening the Access to Object-Oriented Geodata Stores

O. Balovnev, M. Breunig, A.B. Cremers, S. Shumilov

Dept. of Computer Science III, University of Bonn, Germany

Abstract

We report on our experience with GeoToolKit [BBC 1997] - a software which is intended to facilitate the development of 3D/4D geo-applications. It addresses primarily the efficient maintenance of 3D-spatial objects within a database. To achieve this GeoToolKit is tightly coupled with the object-oriented DBMS ObjectStore®. GeoToolKit is not a closed GIS-in-a-box package - it is rather a library of C++ classes that allows the incorporation of spatial functionality within an application under development. Thus it is primarily oriented on software engineers with the C++ experience involved in the development of special-purpose geo-applications which can be hardly modeled within standard GISs. Currently GeoToolKit offers classes for the representation and manipulation with simple (point, segment, triangle, tetrahedron) and complex (curve, surface, solid) spatial objects. Complex objects are approximated and represented as homogenous collections of topological simplexes of the same dimension (e.g. triangle networks). Following the object-oriented modeling technique, not only abstract geometric primitives, such as points, curves, and surfaces but real world entities such as drilling wells, geological sections and strata, can be modeled and maintained. Applications developed with GeoToolKit simply inherit geometric functionality from GeoToolKit, extending it with the application-specific semantics. Spatial objects are collected into a special container class, which provides an efficient spatial retrieval using multidimensional indexes supplied within GeoToolKit.

GeoToolKit was successfully used for the re-implementation of GeoStore, an information system for the management of geologically defined geometries [BBC 1994] as well as for the development of a range of new applications. Due to GeoToolKit an application developer could focus on the application semantics instead of such "creative" tasks as optimal assembling of spatial objects from multiple tables or the implementation of routine geometric algorithms. This resulted in the considerable reduction of the code written and made the sources more understandable. Data earlier hidden within a particular application became available for all other applications built on top of GeoToolKit, that encouraged a consistent and non-redundant maintenance of data.

However, a direct database client-server communication with GeoToolKit-based data was not always possible because of the extreme heterogeneity of already existing applications and hardware platforms we have to deal with. Apart from this a database communication level did not provide relevant network navigation facilities. To implement a remote access to data for an external application, intrinsically not compliant with GeoToolKit class hierarchy, we had to use low-level UNIX-sockets libraries. This approach turned out to be very efficient for the direct communication between two particular applications. However, it lacks generality. To make external applications aware of internal conventions we needed a kind of standard distributed object computing platform. Taking into account the object-oriented nature of data the most suitable solution is Object Management Architecture [OMG97] which promises to become a world-wide standard. Using this approach any other CORBA-compliant application can get an open access to GeoToolKit-based data.Following the standard way for the integrating an external library into a CORBA environment we developed a wrapper. It encapsulates access to all GeoToolKit classes, providing run-time control of their instances, e.g. objects creation, caching and garbage collection. We re-produced GeoToolKit^Òs class hierarchy in CORBA^Òs Interface Definition Language (IDL). The IDL specification of GeoToolKit classes conforms the representations of geometries proposed within the Object Geodata Model [OGIS96], thus enabling their convergence in future.

Clients interact with objects of the encapsulated classes through special stub and skeleton parts generated in the compile time from IDL specifications. However, this approach does not work for classes not included in the original IDL class hierarchy because it requires a complete code recompilation in the both the client and server sides. An incremental extension of the static core shared by different applications is the most challenging problem in the wrapper development. We propose a mechanism that provides a dynamic creation of new user-defined classes without server recompilation. Clients interact with instances of dynamic classes through a specialized Meta-Object Protocol (MOP) implemented with the use of the Dynamic Invocation Interface (DII) on the client side and Dynamic Skeleton Interface (DSI) on the server side. However, operating through MOP is extremely annoying for the user. Special mediator classes generated on the client side hide the MOP from the user and allow the interaction with the server according to the standard C++ interface.

To deal with persistency we use a method based on the substitution of the Basic Object Adapter (BOA) by a special Object Database Adapter (ODA). We chose Orbix® as an implementation platform because it provided a core functionality necessary for the ObjectStore ODA development. Connections between implementation objects and their proxies are organized according to the TIE binding technique, i.e. only implementation objects are stored in the database. All relationships between CORBA objects in a database are actually relationships between corresponding implementation objects. For the unique objects identification ODA maintains an internal table of associations between CORBA object references and implementation objects.

In the project started recently GeoToolKit is used as a platform for an open distributed environment that will provide an open access to the GeoStore database for various remote geo-services involving the 3D-modeling tool GOCAD® located in Bonn and the geophysical modeling tool IGMAS® resided in Berlin. A free data exchange via a common database gives for geo-scientists an opportunity to perform a cooperative adjustment of geophysical density and geological stratigraphic models.

This work is funded by the German Research Foundation (DFG) as part of the program of the research group 'Interoperable Geoscientific Information System (IOGIS)'.
We acknowledge the receipt of industry data from various german oil companies which are active in the southern part of the Northwest German Basin.