An Object-Oriented Data Model and a Query Language for Geographic Information Systems

7/28/2019 An Object-Oriented Data Model and a Query Language for Geographic Information Systems

1/20

An Object-Oriented Data Model

and a Query Language forGeographic Information Systems

Andreas Voigtmann, Ludger Becker and Klaus Hinrichs

Westflische Wilhelms-Universitt, Institut fr numerische Mathematik - Informatik

Einsteinstr. 62, D-48149 Mnster, Germany

email: {avoigt,beckelu,khh}@math.uni-muenster.de

Bericht Nr. 15/95-I


2/20

1

An Object-Oriented Data Model and a Query Language for

Geographic Information Systems

Andreas Voigtmann, Ludger Becker and Klaus H. Hinrichs

FB15, Informatik, Westflische Wilhelms-Universitt

Einsteinstr. 62, D-48149 Mnster, Germany

e-mail: {avoigt,beckelu,khh}@math.uni-muenster.de

Abstract

We present a new extensible, object-oriented data model for geographic infor-

mation systems and a corresponding extensible SQL-like query language. This

model is intended to be a general base for the development of geographic infor-

mation systems. Hence, our model supports both two- and three-dimensionaldata as well as raster- and vector-based data. In addition, the objects may have

several thematic and geometric attributes. Basically we propose a hierarchy of

classes describing so called spatial objects. Classes required to describe a

concrete application are modelled as subclasses of these abstract classes. The

presented query language generalizes earlier proposals of SQL-like query

languages for geographic information systems.

1 Introduction

The study of extensible and object-oriented database systems started almost a decade ago. This

research aimed at the support of advanced applications, e.g. CAD, office information systems

and geographic information systems (GIS). Several extensible and object-oriented systems

have been built (e.g. [AHS 91], [Deux 90], [Gti 89], [LLOW 91]), and there was a significant

progress on the engineering side (e.g. [GrDe 87], [Haas 89], [Haas 90], [SRH 90]) of these

systems. However, the new technology has been applied to GIS in part only. Especially object-

oriented data models and database systems have not yet been specialized to meet the require-

ments of GIS.

The architectures of common GIS systems which are commercially available are based on rela-tional database technology. Early systems used a classical relational database system to store

thematic information based on the standard data types provided by the database system. In addi-

tion to the relational database system a file management system provides access to geometric

and topological data. As a consequence of this fixed structure extensions and adaptations can

hardly be performed, and information describing a single object of the real world is distributed

in the system. Moreover, due to the two module architecture and the file manager, multi-user

access is usually not supported, and there is a considerable mismatch between the two modules

and the two query languages. ARC/INFO is a prominent example for such a GIS [More 89].

The next generation of geographic information systems was based on extended relational data-

base systems supporting additional data types and access methods. Examples of such systemsare System 9 [EcUf 89], Smallworld [CNT 90], GEO++ [ViOo 92], and GeoSabrina [LPV 93].


3/20

2

Since extensible relational database systems (e.g. [Gti 89], [SRH 90]) can be extended by data

types and access methods, such systems are a good base for realizing geographic information

systems. For example, GEO++ [ViOo 92] has been implemented on top of POSTGRES

[SRH 90]. The development of extensible relational database systems triggered research in the

field of access methods and spatial query processing (e.g. [BeG 92], [BHF 93], [BKSS 94],

[Free 87], [Gnt 93], [LoSa 89], [Rote 91], [Same 89]). But all this research could not copewith the structural deficiencies of the relational paradigm in the representation of geographic

data.

A completely new approach is the development of geographic information systems based on

object-oriented database systems (e.g. [AHS 91], [Deux 90], [LLOW 91], [AGGL 95]). Such

work is for example presented in [DRSM 93] and in [ScVo 92]. Building a GIS based on an

object-oriented data model is very promising since such models avoid the structural deficien-

cies of the relational model. Unfortunately, [DRSM 93] and [ScVo 92] do not support the inte-

gration of raster and vector data and do not support handling of 3-D information.

In this paper we present a new Object-Oriented Geographic Data Model (OOGDM). This data

model is intended to serve as a base for implementing geographic information systems. We use

the modelling concepts developed for object-oriented data models to define a set of abstract

classes which are organized in a hierarchy. Objects of these classes may have several thematic

and geometric attributes. We support modelling of geometric data in 2-D and 3-D and in raster

and vector representation. Furthermore, we present an Object-Oriented Geographic Query

Language (OOGQL) for querying databases based on OOGDM. This SQL-like query language

supports spatial data types and can be extended by user-defined predicates and operations.

Since the class-hierarchy of OOGDM is based on the properties of current object-oriented data

models OOGDM may be implemented on top of an object-oriented database system. The

advantages of this approach are twofold. First, GIS which are developed based on OOGDM

benefit from the properties of current database technology (e.g. support for long transactions,

new access methods). Second, the system can easily be extended by additional components;

e.g. if a given application requires a specialized visualization method, this method can be added

due to the object-oriented concepts underlying the system.

Currently we are implementing a Geographic Object-Oriented DAtabase Core (GOODAC)

which realizes the basic class hierarchy of OOGDM. We expect GIS systems for concrete appli-

cations to be implemented on top of GOODAC. These implementations may define appropriate

subclasses of certain predefined OOGDM-classes, inherit the predefined operations and may

even add special operations and access structures.

The paper is organized as follows. Section 2 informally introduces our new model. We presentthe basic hierarchies of OOGDM. Examples show how the proposed abstract classes can be

used to design classes which are useful for various concrete geographic applications. In section

3 we sketch the query language OOGQL. The features of the language are presented by some

queries of a sample application in section 4. Section 5 concludes this paper by comparing

OOGDM and OOGQL to other approaches and gives an overview of future work.


4/20

3

2 The structure of the OOGDM

2.1 Types, classes and objects

OOGDM objects have an identity, a state, and a behaviour. The possible states and the behav-

iour of an object are defined by attributes and the set of methods corresponding to the class of

the object. Attributes are described by attribute names and corresponding attribute types. The

definition of types is based on either (atomic) data types or class names. In addition, they may

be structured using the type constructors set, list, bag, and array proposed in the object data-

base standard [ODMG 93]. The extension of a data type is a set of values and the extension of

a class name is the set of object identifiers corresponding to objects of that class. Similar to

[ODMG 93], attribute definitions based on data types are marked by the keyword attribute,

and definitions based on class names are marked by the keyword relationship. A relationship

between two classes c1 and c2 which is established by an attribute ofc1 and an attribute ofc2can be maintained by the system if one attribute is declared to be the inverse of the other

attribute.

We further support generic classes having formal type parameters T. Each type parameter Tcan

be constrained by the definition of a supertype Sfor the actual type parameter. This constraint

is denoted by T-> S. Furthermore, we define the use of a generic class c without a formal type

parameter as a short notation for c . Since we use generic classes to allow the customi-

zation of our general class definitions, this is a useful abbreviation if no customization is

required.

2.2 Basic structure

The core of OOGDM is a hierarchy of classes. The top-level and therefore most abstract classof our data model is the spatial_object. It represents a set of attributes and operations common

to all instances which are stored in the GIS-database. The class spatial_object is specialized

into two different subclasses feature and geographic_object. Geographic objects are used to

describe complex objects of the real world. Geographic objects represent tuples of objects and

values, i.e. they are composed of features, other geographic_objects , and atomic values. We

describe the characteristics of the geographic_objectclass below. A feature represents a single

geographic abstraction. It is either elementary or composed of several features (feature_set).

Figure 1 gives a representation of the class hierarchy described so far. We present the inherit-

ance hierarchy in a notation similar to [RBPE 91]. A definition of all classes and their attributes

and methods is given in the appendix.spatial_object

elementary_feature feature_set

geographic_objectfeature

Figure 1: Top-levels of the inheritance tree.


5/20

4

2.3 Elementary features

Elementary features are atomic objects of the database describing a single geographic abstrac-

tion. An elementary feature contains a description of the geometry related to this abstraction.

All concrete information which is required in a specific application area must be added by

deriving further subclasses from the subclasses ofelementary_feature predefined in OOGDM.Based on the geometry of the objects methods for basic operations can be provided which are

useful in all GIS application areas.

We distinguish the elementary features by their spatial dimensionality, i.e. there are classes of

elementary geographic features for zero-dimensional objects, one-dimensional objects, two-

dimensional objects, and three-dimensional objects.

Except for the zero-dimensional elementary features which are described by the class

0d_feature we distinguish between vector-based and raster-based representations. One-dimen-

sional elementary features are either raster-based profile objects or vector-based polylines.

Two-dimensional elementary features are specialized into layer objects which are used for

storing raster-based data or into region features which are used to store vector-based data. Athree-dimensional elementary feature is either a raster-based lattice or a vector-based polyhe-

dral feature (solid). We assume that all vector-based representations describe a contiguous part

p of the data space, i.e. the information associated with these features is known for all points in

p whereas the raster-based representation obviously describes a discrete part of the data space.

To support both 2-D and 3-D GIS-applications we have to distinguish whether an elementary

feature is used in a two- or in a three-dimensional data space. Hence, we introduce corre-

sponding subclasses of0d_feature, profile, polyline, layer, and region. Figure 2 introduces the

names of these classes and presents the complete hierarchy of classes for elementary features.

In the appendix we show the definitions of the elementary feature classes describing the geom-etry. We use a notation similar to the data definition language proposed in the object database

standard [ODMG 93].

First data types for 2-D and 3-D points, lines, rectangles, polygons, regions, polyhedrons, and

solids describing the geometry of the corresponding elementary features are defined. A polygon

is described by a list of points. A region is a simple polygon with holes. Each hole is again

described by a simple polygon. Similarly, a polyhedron is represented by a set of 3-D polygons

describing its boundary. A solid consists of a polyhedron with holes. Again, each hole is given

by a polyhedron. Note that these types describe the view a user of OOGDM has of the geometry

of the objects. For the implementation of OOGDM we might choose to represent regions by a

decomposition into trapezoids [ScKr 91]. Each concrete class of elementary features has anattribute geometry describing the geometry underlying the objects of the class. This geometry

is defined based on the corresponding data types mentioned above. In addition:

The geometry of a polyline is a list of points.

The geometry of a profile is a line in 2-D or 3-D space.

The geometry of a layer2dand a layer3dis a rectangle.

The geometry of a lattice is a box.

All concrete classes of elementary features are generic classes having a formal type parameter

Twhich may be used to associate thematic data with the objects, i.e. all vector-based classes

have an attribute data of type Tand all raster-based classes have an attribute data which is an

array ofThaving the appropriate dimension, i.e. each array element corresponds to a rasterpoint.


6/20

5

All classes describing raster-based objects have an appropriate number offrequency attributes

describing the distance between the sampling points (e.g. a layerhas two frequency attributes

x-frequency and y-frequency).

Examples

Zero-dimensional elementary features are for example topographic or climatic informa-

tion like the elevation of the surface at a coordinate value (x, y) or the temperature or

general weather information at a specified 3-D coordinate value.

A one-dimensional elementary feature of class profile2dor profile3dis a discrete set ofdata values ordered linearly (i.e. along a line segment) in space. Examples are elevation-

profiles, i.e. a set of tuples (yi, zi) representing the elevation at coordinate position (x, yi)

for constant x-coordinate (in the given coordinate system) or (in vertical direction) a set

of tuples (zi, ti) representing air temperatures at coordinate position (x, y) at different alti-

tude values zi.

A one-dimensional elementary feature of class polyline2dor polyline3dis a continuous

linear object connecting points in space, for example segments of a road, a river, or a

ridge line.

Examples for two- and three-dimensional elementary features are straightforward:

Objects of class layer2dand layer3dcontain raster-based data for a rectangular region in

2-D or 3-D space, e.g. a matrix of elevation or vegetation information. Objects of classregion2dand region3ddescribe areas of 2-D and 3-D space by giving a vector-based

description of its boundary, e.g. a lake or a polygon containing the same type of soil. The

three-dimensional objects may be used to store geological, meteorological, or oceano-

graphic information.

2.4 Geometric and topological operations

The basic classes of OOGDM introduced above and the classes which are derived for concrete

applications represent spatial data. To support processing of this data, a set of geometric and

topological operations is required. Geometric operations include a distance operation, length,area, or volume operations for one-, two-, or three-dimensional spatial objects, a centeropera-

elementary_feature

1d_feature0d_feature 2d_feature 3d_feature

profile polyline layer region lattice solidpoint2d point3d

profile2d profile3d polyline2d polyline3d layer2d layer3d region2d region3dFigure 2: Child-classes of elementary features.


7/20

6

tion returning the center of an object, and a bounding_box operation returning the minimal

bounding box of an object. The complete set of predefined operations can be found in the defi-

nition of classes given in the appendix.

Topological predicates have been discussed in the literature intensively, e.g. [EgFr 91],

[EgTh 92], [CFO 93]. For our purposes, we use the following set of five basic topological pred-

icates: disjoint, touch, in, cross, overlap. Originally, these relations have been introduced in

[CFO 93]. [CFO 93] show that these predicates are sufficient for representing all possible rela-

tionships. The predicates can easily be adapted to support 3-dimensional data.

The disjoint predicate checks whether two spatial objects are disjoint. touch implies that two

objects touch along their boundaries but have no interior points in common. Object_1 in

Object_2 denotes that Object_1 is completely contained in Object_2. Finally, cross and overlap

are two different forms of intersection. Both imply that the objects intersect in their interior. The

relationship overlap is only applicable to objects of the same spatial dimensionality, e.g.

between two areas. cross denotes a sub-dimensional intersection between two objects, i.e. two

lines crossing in a point or an area crossing a three-dimensional solid object. For a formal defi-

nition of these predicates in 2-D space we refer to [CFO 93]. We do not discuss the adaption of

the formal definitions to 3-D space in this paper.

Based on these predicates corresponding topological functions touch, cross, and overlap can be

defined which construct for each pair of objects satisfying the topological relationship the

resulting intersection object.

All operations and predicates (except the dimension-dependant operations length, area, and

volume) introduced in this section are declared in class spatial_object. The bounding_box oper-

ation is also declared in class spatial_object since a bounding box can be obtained for every

spatial object. It is obvious that some operations have to be redefined in the subclasses to return

appropriate values or to be implemented efficiently. Due to space limitations we cannot showthese redefinitions in the appendix.

2.5 Feature sets

Elementary (geographic) features are not sufficient to describe the objects used by a GIS. There

is often the need to model compound features, e.g. a river consisting of many segments, a

network of rivers, or a layer of information composed of a set of data values which are stored

as atomic elements in the database. The class feature_set is used to represent these types of

features.

Similar to the class elementary_feature, we perform a subdivision offeature_set according tothe spatial dimensionality, the kind of the resulting object and the kind of the elementary

features being composed. Since objects consisting of components of different types are

described by geographic objects, we only consider homogeneous sets. It is obvious that a

feature set combining objects of 2-D space belongs to 2-D space and a feature set combining

objects of 3-D space belongs to 3-D space.

In figure 3 we show the definitions for the class feature_setand its subclasses. It is obvious that

0-D elementary features can only be used to define raster-based feature set objects. A set of 0-D

features or a set of profiles can describe a profile in 2-D or 3-D space, a layer in 2-D or 3-D

space, or a lattice. The corresponding classes are given in part (1) and (3) of figure 3. A set of

polylines is a network in 2-D or 3-D space (part (2)). The classes of part (4) describe sets ofregions. A set of layers can define a layer in 2-D or 3-D space or a lattice (part (5)). A set of


8/20

7

solids is described by the class solid_setof part (6). A set of lattices can define another lattice.

Such feature sets are denoted by the class lattice_3d_setin part (7).

All classes of feature sets which combine raster-based objects of class x basically inherit from

feature_set and from the class of elementary feature constructed by the set. The first class

provides the methods for processing sets and the second class describes the methods and the

geometry for the resulting feature. Due to multiple inheritance the feature sets are subclasses of

an elementary feature class. Hence, we may also use feature sets to define new feature sets. For

example, if we use a set ofpoint2d to construct a layer2d_0d_set, we can use this set as an

element of a layer2d_2d_setobject.

During the construction of objects of the raster-based set classes, we have to ensure that the

geometry of the composed objects fits to the geometry defined for the elementary raster

features, e.g. if we combine 0d_features to form a layer3d_0d_setall points must be located on

a raster in a plane of 3-D space.

class feature_set feature> : feature { relationship Set members; };

(1) Sets of 0-D features:class profile2d_0d_set point2d> : feature_set , profile2d;class profile3d_0d_set point3d> : feature_set , profile3d;class layer2d_0d_set point2d> : feature_set , layer2d;class layer3d_0d_set point3d> : feature_set , layer3d;class lattice_0d_set point3d> : feature_set , lattice;

(2) Sets of polylines

class network2d polyline2d> : feature_set ;class network3d polyline3d> : feature_set ;

(3) Sets of profilesclass profile2d_1d_set profile2d> : feature_set , profile2d;class profile3d_1d_set profile3d> : feature_set , profile3d;class layer2d_1d_set profile2d> : feature_set , layer2d;class layer3d_1d_set profile3d> : feature_set , layer3d;class lattice_1d_set profile3d> : feature_set , lattice;

(4) Sets of regionsclass region2d_set region2d> : feature_set ;

class region3d_set region3d> : feature_set ;

(5) Sets of layersclass layer2d_2d_set layer2d> : feature_set , layer2d;class layer3d_2d_set layer3d> : feature_set , layer3d;class lattice_2d_set layer3d> : feature_set , lattice;

(6) Sets of solidsclass solid_set solid> : feature_set ;

(7) Sets of latticesclass lattice_3d_set lattice> : feature_set , lattice;

Figure 3: Definition of feature_set and its subclasses (methods omitted).


9/20

8

All classes of feature sets which combine vector-based objects of class x inherit from

feature_set only, since these sets cannot be related to the elementary features. Hence, these

classes have no geometry attribute.

Class feature_set provides special methods for composing feature sets: add takes a set of

(elementary) features and adds them to the current feature_set object. The method remove

deletes objects from the feature_set. Finally, union creates a new feature_setby building the

union of the current and another feature_set object. Obviously, these methods are only

successful, if the result is a valid feature_setobject. Method make_elementarty_feature gener-

ates an elementary feature from the current feature_set object. The methods union and

make_elementary_feature must be redefined in all subclasses of feature_set to adapt the

operand and the result type. Due to space limitations we omit these obvious redefinitions.

Examples

Consider a set of elevation-values stored as independent objects in the database. Then, an

elevation-profile, like those in the Digital Elevation Map (DEM) [ElCa 83], may be

represented by a profile2d_0d_setcomposed ofpoint2dobjects. Hence, the DEM can be

viewed as an object of class layer2d_1d_set , i.e. the DEM is an

example for a feature set consisting of feature sets.

A map of soil composed of single regions of soil information, which are stored as inde-

pendent objects in the database is an example for a combination of a set of two-dimen-

sional vector objects, i.e. regions, to a compound object (see example in figure 4).

2.6 Geographic objects

Geographic objects are complex entities of the real world. We can describe a geographic object

as a tuple containing various information based on elementary features or feature sets and addi-

tional (non-spatial) data. As explained in section 2.1 attribute types can be defined using the

type constructors set, list, bag, and array. Examples for such complex objects are cities, coun-

tries, rivers, roads, and even maps.

The class geographic_object has a geometry attribute of class elementary_feature. This rela-

tionship can be redefined in classes inherited from geographic_objectto adapt the geometry for

the purposes of the new class. Due to inheritance, each object of a class derived from

geographic_object has an attribute geometry. Hence, geometric operations can be applied to

any object, and no specification of the attribute describing the geometry of an object is required.

This is an important issue for the query language discussed in section 4.

For example, a city can be modelled by a geographic_object. An object of class city refers to

an elementary feature of class region2dfor its spatial representation and additional features

representing the road network, the buildings, and vegetation inside the city. Using a setconstructor we can group a set of geographic objects representing the citys districts as an addi-

class soil : region2d {// geometry inherited from region2d// attribute Short data given by generic class};

class soil_map : region2d_set {// geometry is inherited from region2d_set

// relationship Set members is inherited from region2d_set};

Figure 4: A soil_map composed of objects of class soil.


10/20

9

tional element of the object. Finally, the object contains non-spatial attributes for the name of

a city and its population count. Figure 5 gives a formal description of the class city. In a real

application the basic classes of OOGDM which are used to describe streets, vegetation, and

city_districts should be replaced by appropriate subclasses. We discuss an extended example in

section 4.

3 Query Language

SQL has become the standard query language for most relational database systems. Currently,

enhanced versions of SQL for object-oriented database systems are developed. One proposal is

the Object Query Language (OQL) defined in the ODMG standard [ODMG 93] for object-

oriented databases. Our query language OOGQL for OOGDM is based on OQL. OQL has a

SQL-like syntax and supports the underlying object-oriented data model, i.e. besides tuples and

sets of tuples queries return objects and collections of objects.

To meet our requirements we have to extend OQL. We have to add support for spatial datatypes, and the query language has to be extensible by user-defined functions, methods, and

predicates.

In [Egen 94] Egenhofer describes requirements for spatial query languages. Most of these

requirements only make sense in the context of graphical user interfaces. Since our query

language is intended to serve as an application independent interface to OOGDM, we do not

try to meet these requirements explicitly. We expect GUI-based GISs to be implemented based

on GOODAC, the database kernel implementing OOGDM. The required new functionality of

such GISs is added to OOGQL via the extension mechanism and embedding the query

language into a graphical representation language like GPL introduced in [Egen 94].

3.1 Support for spatial data types

The basic classes of OOGDM introduced in section 2 and the classes which are derived for

concrete applications represent spatial data. In order to access these data a set of geometric and

topological operations and predicates as described in section 2.4 is required. Operations may

be implemented as methods or as functions which are not assigned to a class.

Since OOGQL can be extended by user-defined predicates and operations, one can add other

topological predicates like intersect, equal, etc. The extensibility of the query language also

enables the user to add methods from computational geometry or graph theory to the query

language. In an interactive GIS-environment, the query language may even be extended by

class city : geographic_object {relationship region2d geometry;relationship feature streets;relationship feature vegetation;relationship Set city_districts;attribute Long population;attribute String name; }

Figure 5: The geographic object city.


11/20

10

some kind ofPICK-operation [Egen 94] to enable interactive manipulation of query objects in

a map displayed by the GIS.

3.2 Query syntax

OOGQL is SQL-like and consists of select from where parts. Due to space limitations, wecannot give a complete description of the query language. Details can be found in [VBH 95].

The syntax for operations and predicates is different. Operations may be used in a functional

notation, e.g. area(city), length(river), or if they are implemented as methods in the usual notation

for methods city.area(), river.length(). If the operations are implemented as functions, only the

functional notation is allowed. Operations can be used in the where and in the selectpart of a

query. Binary predicates are applied using an infix-operator syntax, e.g. river cross city, city in

state. Other predicates are used in the functional prefix notation.

Except for vector-based feature sets, each class of an OOGDM-based application has a geom-

etry attribute (see section 2). Hence, we may apply geometric or topological operations tocomplete objects, e.g. to check whether river rintersects city c we may use the predicate r inter-

sect c instead ofc.geometry intersect r.geometry. The first version of the predicate clarifies that

objects of OOGDM are viewed as spatial objects.

4 An application example

In this section we present an extended example application of OOGDM and its query language

OOGQL. We first derive classes from the class hierarchy of OOGDM modelling several typesof features and geographic objects. This example is a simple presentation for integrating vector-

and raster-based data in one database. Based on this database, we discuss some sample queries.

4.1 Class definitions

We consider classes for the geographic objects city, state, railroad, and river. The class defini-

tions are shown in figure 6. A city has attributes name and population and belongs to a state.

Furthermore, each city contains a vegetation map. The vegetation map is defined by a subclass

vegetation_map of class layer2d. For this class we have defined a method coverage which

returns the percentage of a certain vegetation_type in a given query_region. A state is described

by its name, its population, the set of cities belonging to the state, and by its capital. Each state

has an associated set of elevation maps describing its topography and an associated set of vege-

tation maps describing the land use. The elevation maps are represented by feature sets

composing a layer object from a set of points representing single elevation points. A set of

rivers is associated with each state, too. A river is a geographic object having a polyline-like

geometry. It is characterized by its name. A set ofriver_pollution objects, which are subclasses

of class profile2d, describe the water quality in each segment of the river.

Note that we could describe this application by other class definitions. For example, it might be

reasonable to describe the vegetation information by a region instead of a layer or the elevation

information by a layer instead of a set of points.


12/20

11

To illustrate the implementation of methods of application dependant subclasses we sketch the

definition of method coverage of class vegetation_map in figure 7. First the relevant part of thevegetation layer must be determined. This is done by the overlap operation which is a method

of class spatial_object and due to inheritance a method of vegetation_map. The operation

overlap is redefined in class layer2d to return a Set when

called with an object of class region2d. Since the region parameter need not denote a rectan-

gular region (figure 8), overlap cannot create a layer2d object. Hence, the individual

elements of the layer lying inside the region are transformed to objects of class point2d and

stored in a set. overlap must return a set ofregion2dobjects since the overlap of the layer and

the region can consist of several regions (figure 8).

For each Set of objects there are methods intializeIter, nextIter, and access which allow to

iterate over all objects of the set. For each element of the set of regions of classSet returned by the overlap for class vegetation_map we

class vegetation_map : layer2d{Short coverage (String vegetation_type, region2d query_region) const; };

class elevation : point2d { } ;

class elevation_map: layer2d_0d_set {

elevation min_height () const;elevation max_height () const;Double avg_height () const; };

class river_pollution : profile2d { };

class river : geographic_object {relationship polyline2d geometry;attribute String name;relationship Set pollution; };

class railroad : geographic_object {

relationship polyline2d geometry;attribute Short no_of_tracks;attribute Short max_speed; };

class city : geographic_object {relationship region2d geometry;attribute String name;attribute Long population;relationship state belongs_to inverse state::cities;relationship vegetation_map vegetation; };

class state : geographic_object {relationship region2d geometry;attribute String name;attribute Long population;relationship Set cities inverse city::belongs_to;relationship city capital;relationship Set land_use;relationship Set topography;relationship Set rivers; };

Figure 6: Class definitions for the example application.


13/20

12

iterate over the set of points of class Set associated with the region. For

each point we may access the associated data which describes the type of vegetation for this

data point.

4.2 Query examples

The query language can be used similar to SQL to retrieve and access non-spatial data. In the

following query, retrieving the population counts of all cities, the structkeyword in the select-

part combines the non-spatial attributes of the cities to tuples:select struct (n : c.name, p : c.population)from c in city

Short vegetation_map::coverage(String type, region_2d query_region) const {Set part;

region2d region;point2d point;iterator i, j;Long allPoints, matchingPoints;

part = overlap(query_region); // determine the relevant part of the layerpart.data.initializeIter(i); // initialize iterator for Setwhile (part.data.nextIter(i)) { // iterate over all region2d objects in part.data

region = part.data.access (i); //access current regionregion.data.initializeIter(j); // initialize iterator for Setwhile (region.data.nextIter(j)) { //iterate over all points in region.data

point = region.data.access(j); //access the current point

if (point.data == type)// point represents vegetation typematchingPoints ++;

allPoints ++;};

};return (Short) 100*matchingPoints/allPoints;

}

Figure 7:Definition of method coverage.

geometry of layer

geometry of region

geometry of result

Figure 8: Overlap of a layer2d and a region2d.


14/20

13

If we want to retrieve the names of all cities belonging to Germany, there is no need to use a

spatial query checking whether the geometry of a city is inside the geometry of a state since we

can use the relationship between city and state objects. For each city we easily find the corre-

sponding state via the belongs_to-relationship:

select c.name

from c in citywhere c.belongs_to.name = Germany

However, there is no relationship between railroads and states. If we consider the query Which

railroads in Germany allow a maximum speed of more than 180 km/h?, we have to perform

a spatial query:select r

from r in railroad, s in state

where s.name = Germany and (r in s or r cross s) and r.max_speed > 180

Using the basic topological predicates we have to simulate the intersection condition by the

predicates in and cross. Assume there is a user defined topological predicate intersect. Then we

can write the where-part of the query as:where s.name = Germany and (r intersect s) and r.max_speed > 180

Queries may also return a single list (or a single set) of objects instead of several single objects

as in the previous queries. To retrieve a list of all cities which are within less than 50km from

the capital of Germany, we use the following query:select list (c)

from c in city, s in state

where distance (c, s.capital) < 50 and s.name = Germany

A further example shows a query using the vegetation layer of the city objects. Using the

method coverage of class vegetation_map we retrieve all cities covered with forest by at least

50 percent:select c.name

from c in city

where c.vegetation.coverage(forest, c) >= 50

Assume there is a user-defined function all_nearest_neighbours returning a set of pairs (g1, g2)

of geographic objects where g2 is a nearest neighbours ofg1 for the given database. To retrieve

all pairs of nearest neighbours of cities in the database, we use the this function:select all_nearest_neighbours(set (c))

from c in city

This result can also be obtained by the following query:

select struct (city1 : c1; city2 : c2)from c1, c2 in city

where distance (c1, c2) =

select min (distance (c3, c4))

from c3, c4 in city

where c1 = c3 and c1 c4

Probably, the query optimizer cannot detect that the semantics of the two queries are identical.

Hence, the optimizer does not choose the all nearest neighbour algorithm to evaluate the second

query and the evaluation cost for the second query are significantly higher than the evaluation

cost for the first query. In the first query set(c) is a set containing all objects of class cities.

To demonstrate the retrieval of information from both raster- and vector-based data in a singlequery the following two examples are given. At first, we want to know the pollution of river


15/20

14

Rhine within Germany:select p

from s in state, r in state.river, p in r.pollution

where s.name = Germany and r.name = Rhine and (p intersect s)

In the second example, we determine the name of german cities in the highlands (i.e. the eleva-

tion inside the city is at least 500m) having a railroad connection:select name: c.name

from c in city, r in railroad

where c.belongs_to.name = Germany and r cross c

and for all e_m in c.belongs_to.topography:for all elev in e_m.members: elev.data > 500 or not (elev in c)

Finally, we want to show an update of the database. Assume, we want to create a new digital

elevation map for the city of Frankfurt and the surrounding region (having a distance of less

than 25 kilometers to Frankfurt):A := select e

from e in elevation, c in city

where c.name = Frankfurt and distance (c, e) < 25;

insert elevation_map (members: select set(*) from A);

The first query selects the required elevation data from the database and references the query

result by a temporary variable A. The second statement performs the update of the database.

Basically the insertoperation calls a constructor for class elevation_map to initialize the inher-

ited members attribute with the previous query result. This constructor is responsible for

computing the geometry.

5 Discussion and future work

We have presented our object-oriented data model OOGDM for geographic information

systems. This model basically consists of a hierarchy of abstract classes. For concrete applica-

tions subclasses of these abstract classes must be derived. By using an object-oriented data

model as a base for OOGDM we may benefit from current database technology and avoid the

drawbacks of current GIS architectures and models.

OOGDM is intended to be a general data model which subsumes other data models proposed

for GISs (e.g. [AHS 91], [Alve 90], [BDQV 90], [CNT 90], [ChZu 95], [Deux 90],

[DRSM 93], [EcUf 89], [Feuc 93], [Good 87a], [Good 87b], [Gti 88], [HeLe 91], [Herr 87],[KPI 87], [LLOW 91], [LPV 93], [More 89], [Nyer 80], [ODD 89], [Pequ 84], [ScVo 92],

[ViOo 92]). Hence,

OOGDM supports handling of raster and vector-based data in 2-D and 3-D space.

OOGDM can be extended by new application dependant classes and types which are

derived from the class hierarchy of OOGDM.

The query language OOGQL for OOGDM can be extended by new user-defined predi-

cates and functions.

Due to this general data model, we feel that most GIS-applications can be built based on

GOODAC, an implementation of OOGDM which we currently develop on top of the Odeobject-oriented database system [AGGL 95]. The OOGDM class hierarchy discussed in section


16/20

15

2 constitutes the interface applications have to GOODAC. Hence, the implementation starts

with representations for the classes of this interface. These representations include data struc-

tures for the representation of geometric data in main memory and access structures supporting

efficient query processing on sets of geometric data (e.g. [ScKr 91], [Free 87], [LoSa 89],

[Same 89]).

The OOGDM is intended to serve as a base for various GIS-applications, but not as a base for

a single GIS. Hence, we do not provide a general graphical user interface meeting all require-

ments. However, the SQL-like interface OOGQL for OOGDM is an application independent

interface to all systems which may be built based on GOODAC. Hence, our SQL extension

integrates handling of vector and raster-based data in 2-D and 3-D space. Since other data

models only support a restricted set of data types, the corresponding SQL-like query languages

(e.g. [BDQV 90], [ChZu 95], [Egen 94], [HLS 88], [InPh 87], [ODD 89], [RFS 88],

[ScVo 92]) only support this restricted set of data types. In contrast to our approach, [Egen 94]

considers the use of SQL in connection with a graphical user interface. QL/G [ChZu 95] is a

query language to support general 2-D GIS applications. Since QL/G can only be extended by

operations written in QL/G, the authors provide a large set of operations and predicates. SinceOOGQL can be extended by user defined functions and predicates written in C++, we only

provide basic functions and predicates. Similar to [Gti 88] QL/G and OOGQL offer opera-

tions to construct new geometric entities based on (topological) properties of objects stored in

the database (e.g. the all_nearest_neighbours operation). Most query languages mentioned are

based on a relational data model with additional geometric attribute types. The QL/G approach

is based on a NF2 data model. Queries of the SQL-extensions based on relational data models

return relations as result. The SQL-extension presented in [ScVo 92] and OOGQL are based on

object-oriented data models. Hence, the result of a query is a set of objects or a set of (struc-

tured) values.

So far we have focussed our attention on creating a sound class hierarchy, which takes intoaccount the needs of geographic data modelling, and on the definition OOGQL. Clearly, much

work has still to be done to finish this research. We have to extend our work on querying and

query processing. During the implementation appropriate algorithms and access structures

must be chosen to realize the proposed predicates and functions. An optimizer must be designed

to map queries of OOGQL to these algorithms and data structures. Another important extension

to OOGDM is to incorporate time-varying data.


17/20

16

Literature

[AHS 91] T. Andrews, C. Harris, K. Sinkel: ONTOS: A persistent database for C++, in: R. Gupta and E.

Horowitz (eds.): Object-Oriented Databases with Applications to CASE, Networks and VLSI

Design, Series in Data and Knowledge Base Systems, Prentice Hall, 1991.

[Alve 90] D. Alves: A Data Model for Geographic Information Systems, Proc. Spatial Data Handling1990, 879 - 887.

[AGGL 95] R. Arlein, J. Gava, N. Gehani, D. Lieuwen: Ode 4.0 User Manual, AT&T Bell Laboratories,

Murray Hill, 1995.

[BeG 92] L. Becker and R.H. Gting:Rule-Based Optimization and Query Processing in an Extensible

Geometric Database System, ACM TODS 17 (1992), 247 - 303.

[BHF 93] L. Becker, K. Hinrichs, U. Finke:A New Algorithm for Computing Joins with Grid Files, Proc.

9th Intern. Conf. on Data Engineering (1993), 190 - 197.

[BDQV 90] K. Bennis, B. David, I. Quilio, Y. Vimont: GoTropics Database Support Alternatives for

Geographic Applications, Proc. Spatial Data Handling 1990, 599 - 610.

[BKSS 94] T. Brinkhoff, H. P. Kriegel, R. Schneider, B. Seeger:Multi-Step Processing of Spatial Joins,

Proc. ACM SIGMOD 1994.

[CFO 93] E. Clementini, P. Di Felice, P. van Oosterom:A Small Set of Formal Topological RelationshipsSuitable for End-User Interaction, Proc. Large Spatial Databases (SSD93), Springer, LNCS

692, 277 - 295.

[ChZu 95] E. P. F. Chan, R. Zhu: QL / G - A Query Language for Geometric Data Bases, Technical Report,

Department of Computer Science, University of Waterloo, 1995.

[CNT 90] A. Chance, R. Newel, D. Theriault: An object-oriented GIS - Issues and solutions, Proc.

EGIS90, 179-188.

[DRSM 93] B. David, L. Raynal, G. Schroter, V. Mansart: GeO2: Why objects in a geographical DBMS,

Proc. Advances in Spatial Databases 1993, LNCS 692, 264 - 276.

[Deux 90] O. Deux: The Story of O2, IEEE Transactions on Knowledge and Data Engineering, 2(1), 91 -

108, 1990.

[EcUf 89] J. W. van Eck, M. Uffer:A Presentation of System 9, Proc. Photogrammetry and Land Informa-

tion Systems (1989), 139 - 178.

[Egen 94] M. J. Egenhofer: Spatial SQL: A Query and Presentation Language, IEEE Trans. on Knowledge

and Data Engineering, 6 (1), 1994, 86 - 95.

[EgFr 91] M. J. Egenhofer, R. D. Franzosa: Point-set topological spatial relations, Int. Journal of

Geographic Information Systems, 5 (2), 1991, 161 - 174.

[EgTh 92] M. J. Egenhofer, K. K. Al-Thaha:Reasoning about Gradual Changes of Topological Relation-

ships, Int. Conference GIS, 1992, Springer, LNCS 639, 196 - 219.

[ElCa 83] A. A. Elassal, V. M. Caruso:Digital Elevation Models, USGS Digital Cartographic Data Stan-

dards, Geological Survey Circular 895-B, 1983.

[Feuc 93] M. Feuchtwanger: Towards a Geographic Semantic Database Model, Ph. D. Thesis, Simon

Fraser University, Vancouver, 1993.

[Free 87] M. Freeston: The BANG File: A New Kind of Grid File, Proc. ACM SIGMOD Conf. (1987), 260

- 268.

[Good 87a] M. F. Goodchild:A Spatial Analytical Perspective on Geographical Information Systems, Inter-national Journal of GIS, 1987, 1 (4), 327-334.

[Good 87b] M. F. Goodchild: Towards an Enumeration and Classification of GIS Functions, Proc. Int. GIS

Symposium, 1987.

[GrDe 87] G. Graefe, D. J. DeWitt: The EXODUS Optimizer Generator, Proc. ACM SIGMOD 1987.

[Gti 88] R. H. Gting: Geo-Relational Algebra: A Model and Query Language for Geometric Database

Systems, Proc. Conf. on Extending Database Technology, 1988.

[Gti 89] R. H. Gting: Gral: An Extensible Relational Database System for Geometric Applications,

Proc. VLDB 1989, 33 - 44.

[Gnt 93] O. Gnther:Efficient Computation of Spatial Joins, Proc. Int. Conf. on Data Engineering (1993),

50 - 59.

[Haas 89] L. M. Haas, J. C. Freytag, G. M. Lohman H. Pirahesh:Extensible Query Processing in Starburst,

Proc. ACM SIGMOD 1989.[Haas 90] L. M. Haas et al.: Starburst Mid-Flight: As the Dust Clears, IEEE Transactions on Knowledge

and Data Engineering, 2 (1), 1990.


18/20

17

[HeLe 91] W. Hesse, F. J. Leahy:Authoritative Topographic Cartographic Information System (ATKIS),

Department of Surveying and Land Information, University of Melbourne, 1991.

[Herr 87] J. Herring: TIGRIS: Topologically Integrated Geographic Information Systems, Proc. Auto-

Carto 8 (1987), 282 -291.

[HLS 88] J. Herring, R. Larsen, J. Shivakumar:Extensions to the SQL Language to Support Spatial Anal-

ysis in a Topological Data Base, Proc. GIS/LIS, 1988, 741 - 750.

[InPh 87] K. Ingram, W. Phillips: Geographic Information Processing using a SQL-based QueryLanguage, Proc. Auto-Carto 8 (1987), 326 - 335.

[KPI 87] T. Keating, W. Phillips, K. Ingram:An Integrated Topologic Database Design For Geographic

Information Systems, Photogrammetric Engineering & Remote Sensing, 53 (10), 1399 - 1402.

[LLOW 91] C. Lamb, G. Landis, J. Orenstein, D. Weinreb: The ObjectStore Database System. Communica-

tions of the ACM, 34 (10), 50 - 63.

[LPV 93] T. Larue, D. Pastre, Y. Vimont: Strong Integration of Spatial Domains and Operators in Rela-

tional Database Systems, Proc. Advances in Spatial Databases 1993, LNCS 692, 53 - 72.

[LoSa 89] D.B. Lomet, B. Salzberg:A Robust Multi-Attribute Search Structure, Proc. 5th Intern. Conf. on

Data Engineering (1989), 296 - 304.

[More 89] S. Morehouse: The Architecture of ARC/INFO, Auto-Carto 9 Conf. (1989), 266-277.

[Nyer 80] T. L. Nyerges:Modeling the Structure of Cartographic Information for Query Processing. Ph.

D. Thesis, Ohio State University, OH, Ann Arbor, 1980.

[ODMG 93] R. G. G. Cattell (ed.): The Object Database Standard: ODMG - 93, Morgan- Kaufmann

Publishers, San Francisco, 1994.

[ODD 89] B. C. Ooi, R. S. Davis, K. J. McDonell:Extending a DBMS for Geographic Applications, 5th

Intern. Conf. on Data Engineering (1989), 590 - 597.

[Pequ 84] D. Peuquet: Data Structures for a Knowledge-based Geographic Information System, Proc.

Spatial Data Handling 1984.

[Rote 91] D. Rotem: Spatial Join Indices, Proc. 7th Intern. Conf. on Data Engineering (1991), 500 - 509

[RFS 88] N. Roussopolos, C. Faloutsos, T. Sellis:An Efficient Pictorial Database System for PSQL, IEEE

Trans. Software Engineering, 14 (5).

[RBPE 91] J. Rumbaugh, M. Blaha, W. Premerlani, F. Eddy, W. Lorensen: Object-Oriented Modeling and

Design, Prentice-Hall, 1991.

[Same 89] H. Samet: The Design and Analysis of Spatial Data Structures, Addison-Wesley, 1989.

[SRH 90] M. Stonebraker, L. A. Rowe, M. Hirohama: The Implementation of Postgres, IEEE Transactionson Knowledge and Data Engineering, Vol. 2 (1), 1990.

[ScKr 91] R. Schneider, H. P. Kriegel: The TR*-tree: A new Representation of Polygonal Objects

Supporting Spatial Queries and Operations, Proc. Int. Workshop on Computational Geometry

(CG 91), Springer, LNCS 553, 249 - 263.

[ScVo 92] M. Scholl, A. Voisard: Geographic Applications: An Experience with O2: In F. Bancilhon, C.

Delobel, P. Kanellakis (eds): Building an Object-Oriented Data-base System: The Story Of O2.

Morgan Kaufman Pub. 585 - 618.

[ViOo 92] T. Vijlbrief, P. van Oosterom: The GEO++ system: An Extensible GIS, Proc. Spatial Data

Handling, 1992, 40 - 50.

[VBH 95] A. Voigtmann, L. Becker, K. Hinrichs:A Query Language for Geographic Applications, Internal

Report, Institut fr num. Mathematik - Informatik, Westf. Wilhelms-Universitt Mnster, 1995.


19/20

18

Appendix Class definitions for OOGDM

/* ------------------------------------------ */

/* tydefs */

/* ------------------------------------------ */

Struct PointDesc{

Long x;Long y; };

Struct PointDesc3d{

Long x;

Long y;

Long z; };

Struct LineDesc{

PointDesc start;

PointDesc end; };

Struct LineDesc3d{

PointDesc3d start;

PointDesc3d end; };

Struct RectangleDesc{

PointDesc lower_left;

PointDesc upper_right; };

Struct RectangleDesc3d{

PointDesc3d lower_left;

PointDesc3d upper_right;

PointDesc3d surface_normal; };

Struct PolygonDesc{

List boundary_vertices; };

Struct PolygonDesc3d{

List boundary_vertices; };

Struct RegionDesc2d{

PolygonDesc base_region;

Set holes; };

Struct RegionDesc3d{

PolygonDesc3d base_region;

Set holes; };

Struct BoxDesc{

RectangleDesc3d base;

Long height; };

Struct PolyhedronDesc{

Set boundary; };

Struct SolidDesc{

PolyhedronDesc base_polyhedron;

Set holes; };

/* -------------------------------------------- */

/* abstract base classes */

/* -------------------------------------------- */

class spatial_object {Double distance(spatial_object other) const;

spatial_object bounding_box() const;

bool disjoint(spatial_object other) const;

bool touch(spatial_object other) const;

bool in(spatial_object other) const;

bool overlap(spatial_object other) const;

bool cross(spatial_object other) const;

feature touch(spatial_object other) const;

feature overlap(spatial_object other) const;

feature cross(spatial_object other) const; };

class geographic_object {

relationship feature geometry; };

class feature : spatial_object { };

class feature_set feature> : feature {

relationship Set members;

// compose members to an elementary feature

elementary_feature make_elementary_feature() const;

// add other_members to the current instance

void add(Set other_members);

// remove remove_members from current instance

void remove(Set remove_members);

// union current instance and feature_set other

feature_set union(feature_set other) const; };

class elementary_feature : feature {

attribute Scale scale; };

class 0d_feature : elementary_feature {

attribute T data; };

class 1d_feature : elementary_feature {Double length(); };


Double area() const;

Point center() const;

Set Boundary() const; };


Double volume() const;

Point3d center() const;

Set Boundary() const; };


20/20

/* ------------------------------------------- */

/* elementary feature classes */

/* ------------------------------------------- */

class point2d : 0d_feature {

attribute PointDesc geometry; };

class point3d : 0d_feature {

attribute PointDesc3d geometry; };

class profile : 1d_feature {

attribute Array data;

attribute Short frequency; };

class profile2d : profile {

attribute LineDesc geometry; };

class profile3d : profile {

attribute LineDesc3d geometry; };

class polyline : 1d_feature {

attribute T data;

attribute Short NoOfNodes; };

class polyline2d : polyline {

attribute List geometry; };

class polyline3d : polyline {

attribute List geometry; };

class layer : 2d_feature {


attribute Short x-frequency;

attribute Short y-frequency; };

class layer2d : layer {

attribute RectangleDesc geometry;};

class layer3d : layer {

attribute RectangleDesc3d geometry;};

class region : 2d_feature {

attribute T data; };

class region2d : region {

attribute RegionDesc2d geometry;};

class region3d : region {

attribute RegionDesc3d geometry; };

class lattice : 3d_feature {


attribute BoxDesc geometry;

attribute Short x-frequency;

attribute Short y-frequency;

attribute Short z-frequency; };

class solid : 3d_feature {

attribute T data;

attribute SolidDesc geometry; };

/* ------------------------------------------- */

/* feature_set classes */

/* ------------------------------------------- */

class profile2d_0d_set point2d> :

feature_set , profile2d;

class profile3d_0d_set point3d> :


class layer2d_0d_set point2d> :

feature_set , layer2d;class layer3d_0d_set point3d> :

feature_set , layer3d;

class lattice_0d_set point3d> :

feature_set , lattice;

class network2d polyline2d> :

feature_set ;

class network3d polyline3d> :

feature_set ;

class profile2d_1d_set profile2d> :


class profile3d_1d_set profile3d> :


class layer2d_1d_set profile2d> :


class layer3d_1d_set profile3d> :


class lattice_1d_set profile3d> :feature_set , lattice;

class region2d_set region2d> :

feature_set ;

class region3d_set region3d> :

feature_set ;

class layer2d_2d_set layer2d> :


class layer3d_2d_set layer3d> :


class lattice_2d_set layer3d> :

feature_set , lattice;

class solid_set solid> :

feature_set ;

class lattice_3d_set lattice> :feature_set , lattice;

Documents

An Object-Oriented Data Model and a Query Language for Geographic Information Systems