Spatial Object Structure for Handling 3D Geodata in GRIFINOR

Abstract

This paper discusses the use of spatial objects in general and in relation to the GRIFINOR software platform (Bodum, Kjems et al. 2005). Here, objects have been created in a way that focuses on the overall demand of fast data retrieval, dynamic object structure and level of detail (LOD) (Dollner and Buchholz 2005).

Objects can be conceived as many different things. Though objects in the GRIFINOR1 system are used primarily as a spatial representation of real world features they are not limited to it. The objects can contain geometric information as well as all other kinds of information which can be described in a digital form.

Objects in GRIFINOR are implemented as Java objects, and a hierarchical structure has been maintained for the physical object structure like a building and its sub-parts. Therefore, there are no limitations to the extension of the objects, which in relation to the real world means that the representation of the features can be extended with more and more detail and information. Since the geodata used in GRIFINOR are stored as individual objects and not as one large model file it is easy to handle very large data-sets distributed on several databases. The paper will discuss advantages and disadvantages of this object- oriented approach and present examples of use.

Objects in GRIFINOR are not restricted to representing buildings or other geometrical well-defined features. (Stoter and Zlatanova 2003), (Zlatanova 1998). Every part of the world represented in the GRIFINOR container is defined as an object. From a computer science point of view creating objects even like terrain features is not difficult, but from a representational point of view terrain or other big surface areas are hard to define. So in terms of representing the real world, the ontology used in the system is of importance and influences the object structure significantly, but with regards to storing data in objects the ontology is of less importance and merely a question of applications.

When focusing narrowly on the creation of objects regarding the demands of the GRIFINOR system, you might experience some drawbacks in other fields; e.g. in the field of data exchange. But the approach chosen in the GRIFINOR system makes it almost easy exchanging data since the data model in the Java object is highly generalized and not dependent on any format like XML. This paper will discuss the questions of data exchange in relation to handling objects and in particular, in connection with the GRIFINOR system. Interoperability is a key-feature for almost every application.