1. Integration of 3D Geoscientific Visualisation Tools with help of a Geo-Database Kernel
S. Shumilov, Dr. M. Breunig, Department of Computer Science III, University of Bonn, Germany

2. Presentation Overview
Motivation
Case Study
Approach
Evaluation
Summary

3. heterogeneous isolated tools
The Problem
tool 2
tool 3
tool 1
“closed” applications
proprietary data exchange formats
obscure data semantics
no reuse due to poor documentation
heterogeneous isolated tools

4. Requirements Heterogeneity Distribution
technical level (DBMS, hardware, operating systems, …)
logical level (data formats, standards, semantics, …)
Distribution
transparent network access to various information sources
location independent cooperative work
maintain advantages of decentralized data storage

5. Case Study
Geological
Geophysical
3D Model
GOCAD
IGMAS

6. ? The Differences GOCAD IGMAS Bonn, SGI IRIX, C++, Geological
Berlin, Sun Solaris, Fortran, Geophysical ?

7. Integration of Data Models
GOCAD
IGMAS
Concurrent access to the common spatial data
Geological
Geophysical
GeoStore
- an integrated geological-geophysical extension of 3D kernel
a geometric 3D kernel -
GeoToolKit

8. GeoToolKit Object Model
GeoToolKit Kernel
Space(S)
methods: insert(SO) remove(SO) retrieve(BB):S add_index(AM)
SpatialObject(SO)
methods: contains(SO):BOOL intersection(SO):SO distance(SO):REAL clone():SO
AccessMethod(AM)
methods: insert(SO) remove(SO) retrieve(BB):Set<SO>
BoundingBox(BB)
methods: contains(BB):BOOL intersection(BB):BB
SpatialObject Class Hierarchy
AccessMethod Class Hierarchy 0D 1D 2D 3D
Point
Segment
Triangle
Tetrahedron
R*Tree
OctTree
To facilitate the development of 3D/4D geo-applications we have developed a component-based software called GeoToolKit. The idea is to provide for the application developer a set of geo-oriented software building blocks involving DBMS-based spatial data maintenance, special support for efficient spatial retrieval, communication, visualization and graphical interfaces, which can be assembled in a ready-to-use application even by geo-scientists not experienced in programming. 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 applications.
Currently GeoToolKit includes classes for the representation of simple (point, segment, triangle, tetrahedron) and complex (curve, surface, solid) 3D spatial objects. Complex shapes are approximated and decomposed into a set of adjacent simple objects of the same dimension. Such representation turned out to be especially beneficial for the maintenance of non-regular shapes which are typical for the majority of geo-applications.
GeoToolKit class hierarchy is complete: any 3D-spatial object can be modeled either directly by one of the built-in spatial classes or as a composition of these classes within a group. Geometric operations are closed: operation results can be used in further operations. Spatial objects are maintained in special container classes - spaces - which are capable of efficient retrieval of elements according to their location in space. To provide an efficient retrieval a space utilizes specialized spatial indexes.
PolyLine
TriangNet
TetraNet
User-Defined Access Methods
inheritance
1:1 relationship
Curve
Surface
Volume
1:n relationship
Group
Line
Plane
Box
User-Defined Spatial Objects
representational data type

9. GeoStore Object Model Geometric GeoToolKit Kernel
getVolume()
Surface
ClosedSurf
Volume
getSurf()
{2+,}
{ time = const }
StratSurface
Stratum
{2+,}
{ property = const }
PropSurface
Domain
Solid
{ block = const }
attributes:
time
property
block
The integrated geological-geophysical data model is based upon GeoToolKit’s class hierarchy. This picture presents a part of the data model that inherited from two basic GeoToolKit’s classes: Surface and Volume. New geo-scientific classes define some additional thematic attributes (e.g. lithology, tectonics and density) and inherit the geometric functionality completely from GeoToolKit’s spatial classes. All geo-scientific classes can be subdivided into three sections:
a) Volume based spatial complex: Solid,
b) Volume based spatial compound objects: Stratum, Domain, Block,
c) Surface based spatial compound objects: StratSurface, PropSurface, FaultSurface.
Solid is a maximal volume that has constant thematic attributes. Solid’s objects are used as basic building blocks for compound objects. For example, groups of solids with the same lithology attributes build a Stratum. This solid representation is more preferable for geological modeling, because it allows an efficient derivation of stratigraphical values for arbitrary locations in space. In GOCAD a solid (referred to as Tsolid) can be modelled as a specialised tetrahedron container class, which is derived from a general simplicial complex class. Alternatively, a stratum can be modelled as a composition of bounding surfaces: faults and an upper and lower stratigraphic boundaries. IGMAS, on the contrary, exploits the bounding surface representation under assumption that bodies have no holes.
FaultSurface
Block
(to the Stratum)
GhostSurface
Geological - Geophysical extension
C++ class
inheritance
aggregation
1:1 relationship
1:n relationship
function relation

10. Integration of Platforms
GOCAD
IGMAS
Bonn, SGI IRIX, C++
Berlin, Sun Solaris, Fortran
Remote multiplatform access
CORBA
GeoStore
GeoToolKit
Common spatial data

11. ObjectStore/CORBA Integration
„proxy“ object
Geo-Applications
CORBA- Client
GOCAD
CORBA
Adapter
transient mediator
GeoStore
persistent object
GeoToolKit

12. XDA - An Integration Framework
CORBA
XDA
SODA
eXtensible Database Adapter - a framework for ObjectStore/ CORBA integration
Spatial
Object
Adapter - an extension of XDA for GeoStore/ GeoToolKit
transient mediator
GeoStore
GeoToolKit
persistent object

13. Functionality of eXtendable Database Adapter
remote interaction
Control of Binding
Object reference generation
Support for Up-Down Calls
Client’s IDL interface
Intelligent automatic
Mediator’s Activation and Deactivation
Transactions control
Clustering of database objects
ORB
BOA
XDA
SODA
MEDIATOR -
transient CORBA object
ObjectStore API
A database schema evolution may be extremely time-consuming, therefore the CORBA-compilance should be achievable without changing where and how the data are stored. It could be achieved only if the mediators are transient and an original database do not have any additional communication counterparts. The price of this is a responsibility to control the life circle of mediators – their creation and deletion. Care should be taken also to avoid the creation of multiple mediators tied with the same database object. Since standard CORBA object adapter – Basic Object Adapter (BOA) does not provide these features, we developed our own an eXtensible Database Adapter (XDA) an object adapter for objects stored in a database. The XDA does not completely replace the BOA, but represents its extension. Unlike the BOA, the XDA control the life circle of mediators and deal with typical database features, e.g. locks and transactions. The XDA provides for a CORBA client an IDL interface for the native ObjectStore functionality allowing the client to control the management of persistent objects. The interface includes methods for manipulation with usual ObjectStore objects such as databases, segments, objects and transactions.
ObjectStore
persistent ObjectStore objects

14. Usage of transactions XDA_Adapter_var xda;
XDA_Transaction_var tr1, tr2, tr3;
... // connect to the adapter and open a database
op1 (); // default mode - implicit transaction
op2 (); // management by the XDA
// explicit transaction management by the client
tr1 = xda->begin_transaction (XDA_Transaction::update);
op3 ();
op4 ();
tr1->commit_destory();
// nested transaction
tr2 = xda->begin_transaction(XDA_Transaction::update);
op5 ();
tr3 = xda->begin_transaction (XDA_Transaction::read_only);
op6 ();
op7 ();
tr3->abort_destroy (); // abort of transaction
op8 ();
tr2->commit_destroy ();
boundaries of open transactions ?

15. Advantages from CORBA/OODBMS integration
Independence from concrete platform, programming environment and concrete database system
makes the data accessible for arbitrary remote applications
manage complex object relations in understandable manner
Applications can manipulate with persistent objects directly in the database
reduces network traffic of data
keeps clients thin
makes data concurrently available
improves data consistency
Arbitrary CORBA-compatible applications can concurrently access a common data. These applications can run on different hardware and software platforms and have different data models. Different geo-applications can store, retrieve and also exchange data with each other. For example, updated parts of geometries (inside a box) from IGMAS can be stored in the database and retrieved for further processing in GOCAD.
Moreover CORBA allows to process spatial objects direct in the object-oriented database that reduces network data transfer and allows to keep clients relative thin.
The objects can be accessed at any time concurrently by other remote applications, that work on different computing environments and probably have different data models.
Application objects can be stored, retrieved and processed directly in the object-oriented database without transfer to the client side.
This keeps data consistent during data exchange between different applications.

16. Evaluation Application
Project Participants:
Geological 3D Modelling A. Siehl, R. Seidemann Dept. of Geology, University of Bonn
Gravity and Magnetic 3D Modelling H.-J. Götze, S. Schmidt Dept. of Geophysics, FU Berlin
Dataset:
Geotectonic Atlas of NW Germany (Kockel et al. 1996)
Sponsor agenda:
Deutsche Forschung Gemeinschaft (DFG) and BGR

17. Remote access to common spatial data model
The Goal
Geological
3D modeling and visualization tools
Geophysical
Remote access to common spatial data model
GOCAD
IGMAS
GeoStore
Construction of consistent geological 3D model during
iterative process of geoscientific 3D modeling in
different geological and geophysical tools

18. Developed 3D-GIS architecture
CORBA clients
IGMAS
Platforms: SGI / Solaris / Windows NT
IGMAS extension
GOCAD
C / Fortran interface
Fortran/CORBA Library
GOCAD extension
C++ interface
Object Request Broker (ORB)
IDL interface
SODA
XDA
GeoToolKit/GeoStore - was tacked as a start point Database for the development of the 3D/4D Geo-Database. Its object model was extended by the new types and a Wrapper around the Database was developed. Wrapper makes it accessible to the remote CORBA clients: GOCAD and IGMAS. Using the CORBA the clients receive access to the Database. The extensions to the clients provide a user interface for the database.
Basically our work was focused on the development of the Wrapper on the server part. Since standard CORBA object adapter – Basic Object Adapter (BOA) does not provide these features, we developed our own an eXtensible Database Adapter (XDA) - an object adapter for objects stored in a database. Through corresponding transient mediators XDA makes original ObjectStore classes (e.g. os_database, os_transaction) accessible for a CORBA client.
C++ interface
GeoToolKit/ GeoStore
CORBA servers
Platform: Solaris
ObjectStore

19. Geological 3D Model

20. GOCAD - CORBA export

21. 3D Solid Model In GeoStore

22. R*Tree access method in GeoStore

23. IGMAS 3D gravity model
W-E trending cross section of the IGMAS 3D gravity model, cutting through the study area with the geological 3D model included

24. CORBA - GOCAD import

25. Corrected Geological 3D modeljm
kru
Weser
su+sm ju
Bückeburg
Stadthagen
Salt dome k 5
so + m
10km

26. Consistency Control in GeoStore

27. Results
BGR
3D perspective view of the horizon “Buntsandstein”
Kockel, F. et al., Geotektonischer Atlas von Nordwest-Deutschland und dem deutschen Nordsee-Sektor - Digital, Hannover,

28. Advantages of Integration
Improves consistency of 3D Models
Allows working on parts of large 3D models
Extends the set of usable geo-scientific tools
Provides openness and reusability of the data and methods

29. Developed Technologies
GeoToolKit - a generic geometric 3D database kernel
GeoStore - an integrated geological-geophysical extension
eXtensible Database Adapter - a framework for ObjectStore/CORBA integration

30. Future Development
A distributed interoperable infrastructure is achievable in our opinion, but needs to be completely dynamic and extensible
Generic semantic models based on meta- information could improve flexibility of the system
Intelligent access and mediation methods to distributed persistent storages can speed-up system’s performance

31. Communication Infrastructure
VRML
Distributed Geoscientific Tools and Applications
Platform-independent
Extensible Client-Integrator
IGMAS
GOCAD
Communication Infrastructure
GeoClient
Bus
GeoServer
GeoStore
Intelligent Bus Management, Metadata Services, Pool of Client’s Components
GeoToolKit
3D/4D Database

32. Integration of Applications
VRML
Integrated Components
IGMAS
Dynamically Extensible Client
GOCAD
GeoClient
Bus
GeoServer
Pool of Client’s Components

33. Integration of Data Sources
GOCAD
Geoscientific Tools and Applications
GeoClient
Bus
Open Data Sources
Adapter
Mediators
3D/4D Database

34. 3D-GIS Integration Architecture
Geoscientific Tools and Applications ?
IGMAS
GOCAD
GeoClient
Bus
Adapter
Adapter
GeoServer ?
GeoStore
New Database
GeoToolKit
3D/4D Database

35. Contact information
Department of Computer Science III, University of Bonn, Germany
GeoToolKit
XDA
Sergey Shumilov