an object-oriented data model and a query language for geographic information systems
TRANSCRIPT
-
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
-
7/28/2019 An Object-Oriented Data Model and a Query Language for Geographic Information Systems
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].
-
7/28/2019 An Object-Oriented Data Model and a Query Language for Geographic Information Systems
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.
-
7/28/2019 An Object-Oriented Data Model and a Query Language for Geographic Information Systems
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.
-
7/28/2019 An Object-Oriented Data Model and a Query Language for Geographic Information Systems
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.
-
7/28/2019 An Object-Oriented Data Model and a Query Language for Geographic Information Systems
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/28/2019 An Object-Oriented Data Model and a Query Language for Geographic Information Systems
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
-
7/28/2019 An Object-Oriented Data Model and a Query Language for Geographic Information Systems
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).
-
7/28/2019 An Object-Oriented Data Model and a Query Language for Geographic Information Systems
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.
-
7/28/2019 An Object-Oriented Data Model and a Query Language for Geographic Information Systems
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.
-
7/28/2019 An Object-Oriented Data Model and a Query Language for Geographic Information Systems
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.
-
7/28/2019 An Object-Oriented Data Model and a Query Language for Geographic Information Systems
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.
-
7/28/2019 An Object-Oriented Data Model and a Query Language for Geographic Information Systems
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.
-
7/28/2019 An Object-Oriented Data Model and a Query Language for Geographic Information Systems
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
-
7/28/2019 An Object-Oriented Data Model and a Query Language for Geographic Information Systems
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
-
7/28/2019 An Object-Oriented Data Model and a Query Language for Geographic Information Systems
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.
-
7/28/2019 An Object-Oriented Data Model and a Query Language for Geographic Information Systems
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.
-
7/28/2019 An Object-Oriented Data Model and a Query Language for Geographic Information Systems
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.
-
7/28/2019 An Object-Oriented Data Model and a Query Language for Geographic Information Systems
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(); };
class 2d_feature : elementary_feature {
Double area() const;
Point center() const;
Set Boundary() const; };
class 3d_feature : elementary_feature {
Double volume() const;
Point3d center() const;
Set Boundary() const; };
-
7/28/2019 An Object-Oriented Data Model and a Query Language for Geographic Information Systems
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 Array data;
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 Array data;
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> :
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;
class network2d polyline2d> :
feature_set ;
class network3d polyline3d> :
feature_set ;
class 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;
class region2d_set region2d> :
feature_set ;
class region3d_set region3d> :
feature_set ;
class layer2d_2d_set layer2d> :
feature_set , layer2d;
class layer3d_2d_set layer3d> :
feature_set , layer3d;
class lattice_2d_set layer3d> :
feature_set , lattice;
class solid_set solid> :
feature_set ;
class lattice_3d_set lattice> :feature_set , lattice;