An Object-Oriented Data Model and a Query Language for Geographic 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

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 information systems and a corresponding extensible SQL-like query language. This model is intended to be a general base for the development of geographic information systems. Hence, our model supports both two- and three-dimensional data 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.

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, ofce 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 signicant 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 objectoriented data models and database systems have not yet been specialized to meet the requirements of GIS. The architectures of common GIS systems which are commercially available are based on relational 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 addition to the relational database system a le management system provides access to geometric and topological data. As a consequence of this xed 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 le 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 database systems supporting additional data types and access methods. Examples of such systems are System 9 [EcUf 89], Smallworld [CNT 90], GEO++ [ViOo 92], and GeoSabrina [LPV 93].

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 eld 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 cope with the structural deciencies 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 deciencies of the relational model. Unfortunately, [DRSM 93] and [ScVo 92] do not support the integration 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 dene 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-dened 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 benet 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 applications to be implemented on top of GOODAC. These implementations may dene appropriate subclasses of certain predened OOGDM-classes, inherit the predened operations and may even add special operations and access structures. The paper is organized as follows. Section 2 informally introduces our new model. We present the 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.

2
2.1

The structure of the OOGDM

Types, classes and objects

OOGDM objects have an identity, a state, and a behaviour. The possible states and the behaviour of an object are dened 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 denition 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 database 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 identiers corresponding to objects of that class. Similar to [ODMG 93], attribute denitions based on data types are marked by the keyword attribute, and denitions based on class names are marked by the keyword relationship. A relationship between two classes c1 and c2 which is established by an attribute of c1 and an attribute of c2 can 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 T can be constrained by the denition of a supertype S for the actual type parameter. This constraint is denoted by T -> S. Furthermore, we dene the use of a generic class c without a formal type parameter as a short notation for c <Void>. Since we use generic classes to allow the customization of our general class denitions, 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 class of 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_object class 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 inheritance hierarchy in a notation similar to [RBPE 91]. A denition of all classes and their attributes and methods is given in the appendix. spatial_object

feature

geographic_object

elementary_feature

feature_set

Figure 1: Top-levels of the inheritance tree.

2.3

Elementary features

Elementary features are atomic objects of the database describing a single geographic abstraction. An elementary feature contains a description of the geometry related to this abstraction. All concrete information which is required in a specic application area must be added by deriving further subclasses from the subclasses of elementary_feature predened 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, twodimensional 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-dimensional elementary features are either raster-based prole 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. A three-dimensional elementary feature is either a raster-based lattice or a vector-based polyhedral 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 corresponding subclasses of 0d_feature, prole, 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 denitions of the elementary feature classes describing the geometry. We use a notation similar to the data denition 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 dened. 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 an attribute geometry describing the geometry underlying the objects of the class. This geometry is dened based on the corresponding data types mentioned above. In addition: The geometry of a polyline is a list of points. The geometry of a prole is a line in 2-D or 3-D space. The geometry of a layer2d and a layer3d is a rectangle. The geometry of a lattice is a box. All concrete classes of elementary features are generic classes having a formal type parameter T which may be used to associate thematic data with the objects, i.e. all vector-based classes have an attribute data of type T and all raster-based classes have an attribute data which is an array of T having the appropriate dimension, i.e. each array element corresponds to a raster point.

elementary_feature

0d_feature

1d_feature

2d_feature

3d_feature

point2d

point3d profile

polyline

layer

region

lattice

solid

profile2d profile3d

polyline2d polyline3d

layer2d

layer3d region2d region3d

Figure 2: Child-classes of elementary features.

All classes describing raster-based objects have an appropriate number of frequency attributes describing the distance between the sampling points (e.g. a layer has two frequency attributes x-frequency and y-frequency). Examples Zero-dimensional elementary features are for example topographic or climatic information like the elevation of the surface at a coordinate value (x, y) or the temperature or general weather information at a specied 3-D coordinate value. A one-dimensional elementary feature of class prole2d or prole3d is a discrete set of data values ordered linearly (i.e. along a line segment) in space. Examples are elevationproles, 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 altitude values zi. A one-dimensional elementary feature of class polyline2d or polyline3d is 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 layer2d and layer3d contain 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 class region2d and region3d describe 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 oceanographic 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 center opera-

tion returning the center of an object, and a bounding_box operation returning the minimal bounding box of an object. The complete set of predened operations can be found in the denition 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 ve basic topological predicates: disjoint, touch, in, cross, overlap. Originally, these relations have been introduced in [CFO 93]. [CFO 93] show that these predicates are sufcient for representing all possible relationships. 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 denition of these predicates in 2-D space we refer to [CFO 93]. We do not discuss the adaption of the formal denitions to 3-D space in this paper. Based on these predicates corresponding topological functions touch, cross, and overlap can be dened 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 operation 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 redened in the subclasses to return appropriate values or to be implemented efciently. Due to space limitations we cannot show these redenitions in the appendix.

2.5

Feature sets

Elementary (geographic) features are not sufcient 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 of feature_set according to the 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 gure 3 we show the denitions for the class feature_set and its subclasses. It is obvious that 0-D elementary features can only be used to dene raster-based feature set objects. A set of 0-D features or a set of proles can describe a prole 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 gure 3. A set of polylines is a network in 2-D or 3-D space (part (2)). The classes of part (4) describe sets of regions. A set of layers can dene a layer in 2-D or 3-D space or a lattice (part (5)). A set of

solids is described by the class solid_set of part (6). A set of lattices can dene another lattice. Such feature sets are denoted by the class lattice_3d_set in part (7). All classes of feature sets which combine raster-based objects of class x basically inherit from feature_set<x> and from the class of elementary feature constructed by the set. The rst 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 dene new feature sets. For example, if we use a set of point2d to construct a layer2d_0d_set, we can use this set as an element of a layer2d_2d_set object. During the construction of objects of the raster-based set classes, we have to ensure that the geometry of the composed objects ts to the geometry dened for the elementary raster features, e.g. if we combine 0d_features to form a layer3d_0d_set all points must be located on a raster in a plane of 3-D space.

class feature_set <T -> feature> : feature { relationship Set <T> members; };

(1) Sets of 0-D features:

class profile2d_0d_set <T -> point2d> : feature_set <T>, profile2d; class profile3d_0d_set <T -> point3d> : feature_set <T>, profile3d; class layer2d_0d_set <T -> point2d> : feature_set <T>, layer2d; class layer3d_0d_set <T -> point3d> : feature_set <T>, layer3d; class lattice_0d_set <T -> point3d> : feature_set <T>, lattice;

(2) Sets of polylines

class network2d <T -> polyline2d> : feature_set <T>; class network3d <T -> polyline3d> : feature_set <T>;

(3) Sets of proles

class profile2d_1d_set <T -> profile2d> : feature_set <T>, profile2d; class profile3d_1d_set <T -> profile3d> : feature_set <T>, profile3d; class layer2d_1d_set <T -> profile2d> : feature_set <T>, layer2d; class layer3d_1d_set <T -> profile3d> : feature_set <T>, layer3d; class lattice_1d_set <T -> profile3d> : feature_set <T>, lattice;

(4) Sets of regions

class region2d_set <T -> region2d> : feature_set <T>; class region3d_set <T -> region3d> : feature_set <T>;

(5) Sets of layers

class layer2d_2d_set <T -> layer2d> : feature_set <T>, layer2d; class layer3d_2d_set <T -> layer3d> : feature_set <T>, layer3d; class lattice_2d_set <T -> layer3d> : feature_set <T>, lattice;

(6) Sets of solids

class solid_set <T -> solid> : feature_set <T>;

(7) Sets of lattices

class lattice_3d_set <T -> lattice> : feature_set <T>, lattice; Figure 3: Definition of feature_set and its subclasses (methods omitted).

class soil : region2d <Short>{ // geometry inherited from region2d // attribute Short data given by generic class}; class soil_map : region2d_set <soil>{ // geometry is inherited from region2d_set<soil> // relationship Set<soil> members is inherited from region2d_set<soil>}; Figure 4: A soil_map composed of objects of class soil.

All classes of feature sets which combine vector-based objects of class x inherit from feature_set<x> 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_set by building the union of the current and another feature_set object. Obviously, these methods are only successful, if the result is a valid feature_set object. Method make_elementarty_feature generates an elementary feature from the current feature_set object. The methods union and make_elementary_feature must be redened in all subclasses of feature_set to adapt the operand and the result type. Due to space limitations we omit these obvious redenitions. Examples Consider a set of elevation-values stored as independent objects in the database. Then, an elevation-prole, like those in the Digital Elevation Map (DEM) [ElCa 83], may be represented by a prole2d_0d_set composed of point2d objects. Hence, the DEM can be viewed as an object of class layer2d_1d_set<prole2d_0d_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 independent objects in the database is an example for a combination of a set of two-dimensional vector objects, i.e. regions, to a compound object (see example in gure 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 additional (non-spatial) data. As explained in section 2.1 attribute types can be dened using the type constructors set, list, bag, and array. Examples for such complex objects are cities, countries, rivers, roads, and even maps. The class geographic_object has a geometry attribute of class elementary_feature. This relationship can be redened in classes inherited from geographic_object to 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 specication 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 region2d for its spatial representation and additional features representing the road network, the buildings, and vegetation inside the city. Using a set constructor we can group a set of geographic objects representing the citys districts as an addi-

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.
class city : geographic_object { relationship region2d geometry; relationship feature streets; relationship feature vegetation; relationship Set<geographic_object> city_districts; attribute Long population; attribute String name; } Figure 5: The geographic object city.

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) dened in the ODMG standard [ODMG 93] for objectoriented 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 data types, and the query language has to be extensible by user-dened 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-dened 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

some kind of PICK-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, we cannot 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 select part of a query. Binary predicates are applied using an inx-operator syntax, e.g. river cross city, city in state. Other predicates are used in the functional prex notation. Except for vector-based feature sets, each class of an OOGDM-based application has a geometry attribute (see section 2). Hence, we may apply geometric or topological operations to complete objects, e.g. to check whether river r intersects city c we may use the predicate r intersect c instead of c.geometry intersect r.geometry. The rst version of the predicate claries that objects of OOGDM are viewed as spatial objects.

An application example

In this section we present an extended example application of OOGDM and its query language OOGQL. We rst derive classes from the class hierarchy of OOGDM modelling several types of features and geographic objects. This example is a simple presentation for integrating vectorand raster-based data in one database. Based on this database, we discuss some sample queries.

4.1

Class denitions

We consider classes for the geographic objects city, state, railroad, and river. The class denitions are shown in gure 6. A city has attributes name and population and belongs to a state. Furthermore, each city contains a vegetation map. The vegetation map is dened by a subclass vegetation_map of class layer2d. For this class we have dened 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 vegetation 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 of river_pollution objects, which are subclasses of class prole2d<int>, describe the water quality in each segment of the river. Note that we could describe this application by other class denitions. 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.

10

class vegetation_map : layer2d<String>{ Short coverage (String vegetation_type, region2d query_region) const; }; class elevation : point2d<Short> { } ; class elevation_map: layer2d_0d_set <elevation> { elevation min_height () const; elevation max_height () const; Double avg_height () const; }; class river_pollution : profile2d<int> { }; class river : geographic_object { relationship polyline2d geometry; attribute String name; relationship Set<river_pollution> 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<city> cities inverse city::belongs_to; relationship city capital; relationship Set<vegetation_map> land_use; relationship Set<elevation_map> topography; relationship Set<river> rivers; }; Figure 6: Class definitions for the example application.

To illustrate the implementation of methods of application dependant subclasses we sketch the denition of method coverage of class vegetation_map in gure 7. First the relevant part of the vegetation 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 redened in class layer2d<T> to return a Set<region2d<Set<point2d<T>>>> when called with an object of class region2d. Since the region parameter need not denote a rectangular region (gure 8), overlap cannot create a layer2d<T> object. Hence, the individual elements of the layer lying inside the region are transformed to objects of class point2d<T> and stored in a set. overlap must return a set of region2d objects since the overlap of the layer and the region can consist of several regions (gure 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 class Set<region2d<Set<point2d<String>>>> returned by the overlap for class vegetation_map we

11

iterate over the set of points of class Set<point2d<String>> associated with the region. For each point we may access the associated data which describes the type of vegetation for this data point.
Short vegetation_map::coverage(String type, region_2d query_region) const { Set<region2d<Set<point2d<String>>>> part; region2d<Set<point2d<String>>> region; point2d<String> point; iterator i, j; Long allPoints, matchingPoints; part = overlap(query_region); // determine the relevant part of the layer part.data.initializeIter(i); // initialize iterator for Set<region2d<>> while (part.data.nextIter(i)) { // iterate over all region2d<.> objects in part.data region = part.data.access (i); //access current region region.data.initializeIter(j); // initialize iterator for Set<point2d<String>> while (region.data.nextIter(j)) { //iterate over all points<String> in region.data point = region.data.access(j); //access the current point if (point.data == type) // point represents vegetation type matchingPoints ++; 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.

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 struct keyword in the selectpart combines the non-spatial attributes of the cities to tuples:
select struct (n : c.name, p : c.population) from c in city

12

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 nd the corresponding state via the belongs_to-relationship:
select c.name from c in city where 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 dened 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-dened function all_nearest_neighbours returning a set of pairs (g1, g2) of geographic objects where g2 is a nearest neighbours of g1 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 signicantly higher than the evaluation cost for the rst query. In the rst 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 single query the following two examples are given. At rst, we want to know the pollution of river

13

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 elevation 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 rst 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 insert operation calls a constructor for class elevation_map to initialize the inherited members attribute with the previous query result. This constructor is responsible for computing the geometry.

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 applications subclasses of these abstract classes must be derived. By using an object-oriented data model as a base for OOGDM we may benet 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-dened predicates 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 Ode object-oriented database system [AGGL 95]. The OOGDM class hierarchy discussed in section

14

2 constitutes the interface applications have to GOODAC. Hence, the implementation starts with representations for the classes of this interface. These representations include data structures for the representation of geometric data in main memory and access structures supporting efcient 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 requirements. 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. Since OOGQL can be extended by user dened functions and predicates written in C++, we only provide basic functions and predicates. Similar to [Gti 88] QL/G and OOGQL offer operations 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 (structured) values. So far we have focussed our attention on creating a sound class hierarchy, which takes into account the needs of geographic data modelling, and on the denition OOGQL. Clearly, much work has still to be done to nish 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.

15

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. D. Alves: A Data Model for Geographic Information Systems, Proc. Spatial Data Handling 1990, 879 - 887. R. Arlein, J. Gava, N. Gehani, D. Lieuwen: Ode 4.0 User Manual, AT&T Bell Laboratories, Murray Hill, 1995. L. Becker and R.H. Gting: Rule-Based Optimization and Query Processing in an Extensible Geometric Database System, ACM TODS 17 (1992), 247 - 303. 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. K. Bennis, B. David, I. Quilio, Y. Vimont: GoTropics Database Support Alternatives for Geographic Applications, Proc. Spatial Data Handling 1990, 599 - 610. T. Brinkhoff, H. P. Kriegel, R. Schneider, B. Seeger: Multi-Step Processing of Spatial Joins, Proc. ACM SIGMOD 1994. E. Clementini, P. Di Felice, P. van Oosterom: A Small Set of Formal Topological Relationships Suitable for End-User Interaction, Proc. Large Spatial Databases (SSD93), Springer, LNCS 692, 277 - 295. 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. A. Chance, R. Newel, D. Theriault: An object-oriented GIS - Issues and solutions, Proc. EGIS90, 179-188. 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. O. Deux: The Story of O2, IEEE Transactions on Knowledge and Data Engineering, 2(1), 91 108, 1990. J. W. van Eck, M. Uffer: A Presentation of System 9, Proc. Photogrammetry and Land Information Systems (1989), 139 - 178. M. J. Egenhofer: Spatial SQL: A Query and Presentation Language, IEEE Trans. on Knowledge and Data Engineering, 6 (1), 1994, 86 - 95. M. J. Egenhofer, R. D. Franzosa: Point-set topological spatial relations, Int. Journal of Geographic Information Systems, 5 (2), 1991, 161 - 174. M. J. Egenhofer, K. K. Al-Thaha: Reasoning about Gradual Changes of Topological Relationships, Int. Conference GIS, 1992, Springer, LNCS 639, 196 - 219. A. A. Elassal, V. M. Caruso: Digital Elevation Models, USGS Digital Cartographic Data Standards, Geological Survey Circular 895-B, 1983. M. Feuchtwanger: Towards a Geographic Semantic Database Model, Ph. D. Thesis, Simon Fraser University, Vancouver, 1993. M. Freeston: The BANG File: A New Kind of Grid File, Proc. ACM SIGMOD Conf. (1987), 260 - 268. M. F. Goodchild: A Spatial Analytical Perspective on Geographical Information Systems, International Journal of GIS, 1987, 1 (4), 327-334. M. F. Goodchild: Towards an Enumeration and Classication of GIS Functions, Proc. Int. GIS Symposium, 1987. G. Graefe, D. J. DeWitt: The EXODUS Optimizer Generator, Proc. ACM SIGMOD 1987. R. H. Gting: Geo-Relational Algebra: A Model and Query Language for Geometric Database Systems, Proc. Conf. on Extending Database Technology, 1988. R. H. Gting: Gral: An Extensible Relational Database System for Geometric Applications, Proc. VLDB 1989, 33 - 44. O. Gnther: Efcient Computation of Spatial Joins, Proc. Int. Conf. on Data Engineering (1993), 50 - 59. L. M. Haas, J. C. Freytag, G. M. Lohman H. Pirahesh: Extensible Query Processing in Starburst, Proc. ACM SIGMOD 1989. L. M. Haas et al.: Starburst Mid-Flight: As the Dust Clears, IEEE Transactions on Knowledge and Data Engineering, 2 (1), 1990.

[Alve 90] [AGGL 95] [BeG 92] [BHF 93] [BDQV 90] [BKSS 94] [CFO 93]

[ChZu 95] [CNT 90] [DRSM 93] [Deux 90] [EcUf 89] [Egen 94] [EgFr 91] [EgTh 92] [ElCa 83] [Feuc 93] [Free 87] [Good 87a] [Good 87b] [GrDe 87] [Gti 88] [Gti 89] [Gnt 93] [Haas 89] [Haas 90]

16

[HeLe 91] [Herr 87] [HLS 88] [InPh 87] [KPI 87] [LLOW 91] [LPV 93] [LoSa 89] [More 89] [Nyer 80] [ODMG 93] [ODD 89] [Pequ 84] [Rote 91] [RFS 88] [RBPE 91] [Same 89] [SRH 90] [ScKr 91]

[ScVo 92]

[ViOo 92] [VBH 95]

W. Hesse, F. J. Leahy: Authoritative Topographic Cartographic Information System (ATKIS), Department of Surveying and Land Information, University of Melbourne, 1991. J. Herring: TIGRIS: Topologically Integrated Geographic Information Systems, Proc. AutoCarto 8 (1987), 282 -291. J. Herring, R. Larsen, J. Shivakumar: Extensions to the SQL Language to Support Spatial Analysis in a Topological Data Base, Proc. GIS/LIS, 1988, 741 - 750. K. Ingram, W. Phillips: Geographic Information Processing using a SQL-based Query Language, Proc. Auto-Carto 8 (1987), 326 - 335. T. Keating, W. Phillips, K. Ingram: An Integrated Topologic Database Design For Geographic Information Systems, Photogrammetric Engineering & Remote Sensing, 53 (10), 1399 - 1402. C. Lamb, G. Landis, J. Orenstein, D. Weinreb: The ObjectStore Database System. Communications of the ACM, 34 (10), 50 - 63. T. Larue, D. Pastre, Y. Vimont: Strong Integration of Spatial Domains and Operators in Relational Database Systems, Proc. Advances in Spatial Databases 1993, LNCS 692, 53 - 72. D.B. Lomet, B. Salzberg: A Robust Multi-Attribute Search Structure, Proc. 5th Intern. Conf. on Data Engineering (1989), 296 - 304. S. Morehouse: The Architecture of ARC/INFO, Auto-Carto 9 Conf. (1989), 266-277. T. L. Nyerges: Modeling the Structure of Cartographic Information for Query Processing. Ph. D. Thesis, Ohio State University, OH, Ann Arbor, 1980. R. G. G. Cattell (ed.): The Object Database Standard: ODMG - 93, Morgan- Kaufmann Publishers, San Francisco, 1994. B. C. Ooi, R. S. Davis, K. J. McDonell: Extending a DBMS for Geographic Applications, 5th Intern. Conf. on Data Engineering (1989), 590 - 597. D. Peuquet: Data Structures for a Knowledge-based Geographic Information System, Proc. Spatial Data Handling 1984. D. Rotem: Spatial Join Indices, Proc. 7th Intern. Conf. on Data Engineering (1991), 500 - 509 N. Roussopolos, C. Faloutsos, T. Sellis: An Efcient Pictorial Database System for PSQL, IEEE Trans. Software Engineering, 14 (5). J. Rumbaugh, M. Blaha, W. Premerlani, F. Eddy, W. Lorensen: Object-Oriented Modeling and Design, Prentice-Hall, 1991. H. Samet: The Design and Analysis of Spatial Data Structures, Addison-Wesley, 1989. M. Stonebraker, L. A. Rowe, M. Hirohama: The Implementation of Postgres, IEEE Transactions on Knowledge and Data Engineering, Vol. 2 (1), 1990. 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. 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. T. Vijlbrief, P. van Oosterom: The GEO++ system: An Extensible GIS, Proc. Spatial Data Handling, 1992, 40 - 50. A. Voigtmann, L. Becker, K. Hinrichs: A Query Language for Geographic Applications, Internal Report, Institut fr num. Mathematik - Informatik, Westf. Wilhelms-Universitt Mnster, 1995.

17

Appendix

Class denitions for OOGDM

/* -------------------------------------------- */ /* abstract base classes */ /* -------------------------------------------- */ class spatial_object { Double distance(spatial_object other) const; spatial_object bounding_box() const; bool bool bool bool bool disjoint(spatial_object other) const; touch(spatial_object other) const; in(spatial_object other) const; overlap(spatial_object other) const; cross(spatial_object other) const;

/* ------------------------------------------ */ /* tydefs */ /* ------------------------------------------ */ Struct PointDesc{ Long x; Long y; }; Struct Long Long Long PointDesc3d{ x; y; 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<PointDesc> boundary_vertices; }; Struct PolygonDesc3d{ List<PointDesc3d> boundary_vertices; }; Struct RegionDesc2d{ PolygonDesc base_region; Set<PolygonDesc> holes; }; Struct RegionDesc3d{ PolygonDesc3d base_region; Set<PolygonDesc3d> holes; }; Struct BoxDesc{ RectangleDesc3d base; Long height; }; Struct PolyhedronDesc{ Set<PolygonDesc3d> boundary; }; Struct SolidDesc{ PolyhedronDesc base_polyhedron; Set<PolyhedronDesc> holes; };

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 <T -> feature> : feature { relationship Set<T> members; // compose members to an elementary feature elementary_feature make_elementary_feature() const; // add other_members to the current instance void add(Set<feature> other_members); // remove remove_members from current instance void remove(Set<feature> remove_members); // union current instance and feature_set other feature_set<T> union(feature_set<T> other) const; }; class elementary_feature : feature { attribute Scale scale; }; class 0d_feature <T> : elementary_feature { attribute T data; }; class 1d_feature : elementary_feature { Double length(); }; class 2d_feature : elementary_feature { Double area() const; Point center() const; Set<1d_feature> Boundary() const; }; class 3d_feature : elementary_feature { Double volume() const; Point3d center() const; Set<2d_feature> Boundary() const; };

18

/* ------------------------------------------- */ /* elementary feature classes */ /* ------------------------------------------- */ class point2d <T> : 0d_feature <T> { attribute PointDesc geometry; }; class point3d <T> : 0d_feature <T> { attribute PointDesc3d geometry; }; class profile <T> : 1d_feature { attribute Array<T> data; attribute Short frequency; }; class profile2d <T> : profile <T> { attribute LineDesc geometry; }; class profile3d <T> : profile <T> { attribute LineDesc3d geometry; }; class polyline <T> : 1d_feature { attribute T data; attribute Short NoOfNodes; }; class polyline2d <T> : polyline <T> { attribute List<PointDesc> geometry; }; class polyline3d <T> : polyline <T> { attribute List<PointDesc3d> geometry; }; class layer attribute attribute attribute <T> : 2d_feature { Array<Array<T>> data; Short x-frequency; Short y-frequency; };

/* ------------------------------------------- */ /* feature_set classes */ /* ------------------------------------------- */ class profile2d_0d_set <T -> point2d> : feature_set <T>, class profile3d_0d_set <T -> point3d> : feature_set <T>, class layer2d_0d_set <T -> point2d> : feature_set <T>, class layer3d_0d_set <T -> point3d> : feature_set <T>, class lattice_0d_set <T -> point3d> : feature_set <T>, class network2d <T -> polyline2d> : feature_set <T>; class network3d <T -> polyline3d> : feature_set <T>; class profile2d_1d_set <T -> profile2d> : feature_set <T>, class profile3d_1d_set <T -> profile3d> : feature_set <T>, class layer2d_1d_set <T -> profile2d> : feature_set <T>, class layer3d_1d_set <T -> profile3d> : feature_set <T>, class lattice_1d_set <T -> profile3d> : feature_set <T>, class region2d_set <T -> region2d> : feature_set <T>; class region3d_set <T -> region3d> : feature_set <T>; class layer2d_2d_set <T -> layer2d> : feature_set <T>, layer2d; class layer3d_2d_set <T -> layer3d> : feature_set <T>, layer3d; class lattice_2d_set <T -> layer3d> : feature_set <T>, lattice; class solid_set <T -> solid> : feature_set <T>; class lattice_3d_set <T -> lattice> : feature_set <T>, lattice;

profile2d; profile3d; layer2d; layer3d; lattice;

profile2d; profile3d; layer2d; layer3d; lattice;

class layer2d <T> : layer <T> { attribute RectangleDesc geometry;}; class layer3d <T> : layer <T> { attribute RectangleDesc3d geometry;}; class region <T> : 2d_feature { attribute T data; }; class region2d <T> : region <T> { attribute RegionDesc2d geometry;}; class region3d <T> : region <T> { attribute RegionDesc3d geometry; }; class lattice <T> : 3d_feature { attribute Array<Array<Array<T>>> data; attribute BoxDesc geometry; attribute Short x-frequency; attribute Short y-frequency; attribute Short z-frequency; }; class solid <T> : 3d_feature { attribute T data; attribute SolidDesc geometry; };

19