56453-An Introduction To Spatial Database PDF

VLDBJournal,3,357-399(1994), Invited contribution,Hans-J.
Schek, Editor 357

QVLDB
An Introduction to Spatial Database Systems
Ralf Hartmut GQting
Received July 25, 1994; accepted August 18, 1994.
Abstract. We propose a definition of a spatial database system as a database sys-

tem that offers spatial data types in its data model and query language, and sup-
ports spatial data types in its implementation, providing at least spatial indexing
and spatial join methods. Spatial database systems offer the underlying database
technology for geographic information systems and other applications. We survey
data modeling, querying, data structures and algorithms, and system architecture
for such systems. The emphasis is on describing known technology in a coherent
manner, rather than listing open problems.
1. What is a Spatial Database System?

In various fields, there is a need to manage geometric, geographic, or spatial data
(i.e., data related to space). The space of interest can be, for example, the 2-
D abstraction of (parts of) the earth's surface (i.e., geographic space, the most
prominent example). Other examples are a man-made space (e.g., the layout of a
VLSI design), a volume containing a model of the human brain, or another 3-D
space representing the arrangement of chains of protein molecules. At least since
the advent of relational database systems, there have been attempts to manage such
data in database systems. Characteristic for the technology emerging to address
these needs is the capability to deal with large collections of relatively simple geometric
objects, for example, a set of 100,000 polygons. This is somewhat different from CAD
databases (e.g., solid modeling) where geometric entities are composed hierarchically
into complex structures, although the issues are certainly related.
Several terms have been used to describe database systems offering such support,
including pictorial, image, geometric, geographic, and spatial. The terms "pictorial
database system" and "image database system" arise from the fact that the data to
be managed are often initially captured in the form of digital raster images (e.g.,
remote sensing by satellites, or computer tomography in medical applications). The
term "spatial database system" has become popular during the last few years, to
some extent through the Symposium on Large Spatial Databases, which has been
Ralf Hartmut Gating, Dr.rer.nat, is Professor,Praktische InformatikIV, FernUniversit/itHagen, D-58084

Hagen, Germany.
358
held biannually since 1989 (Buchmann et al., 1989; Gtinther and Schek, 1991; Abel
and Ooi, 1993). This term is associated with a view of a database as containing
sets of objects in space rather than images or pictures of a space. Indeed, the
requirements and techniques for dealing with objects in space that have identity
and well-defined extents, locations, and relationships are rather different from those
for dealing with raster images. It has therefore been suggested that two classes of
systems, spatial database systems and image database systems, be clearly distinguished
(Gfinther and Buchmann, 1990; Frank, 1991). Image database systems may include
analysis techniques to extract objects in space from images, and offer some spatial
database functionality, but they are also prepared to store, manipulate, and retrieve
raster images as discrete entities. In this survey, we discuss only spatial database
systems in the restricted sense. Several articles in this special issue address image
database problems, and so complement the survey.
What is a spatial database system? We are not aware of a generally accepted
definition. The following reflects the author's personal view:
1. A spatial database system is a database system.
2. It offers spatial data types (SDTs) in its data model and query language.
3. It supports spatial data types in its implementation, providing at least spatial
indexing and effcient algorithms for spatial join.
Let us briefly justify these requirements. The first sounds trivial, but emphasizes
the fact that spatial, or geometric, information is in practice always connected
with "non-spatial" (e.g., alphanumeric) data. It is not sufficient to have a special
purpose system that cannot handle all the standard data modeling and querying
tasks. Hence, a spatial database system is a full-fledged database system with
additional capabilities for handling spatial data. The second requirement, SDTs
(e.g., POINT, LINE, REGION), provide a fundamental abstraction for modeling the
structure of geometric entities in space, as well as their relationships (l intersects r),
properties (area(r) > 1,000), and operations (intersection(l, r)--the part of l lying
within r). Which types are used may, of course, depend on a class of applications
to be supported (e.g., rectangles in VLSI design; surfaces and volumes in 3-D).
Without spatial data types, a system does not offer adequate support in modeling.
The third requirement is that a system must at least be able to retrieve from a
large collection of objects in some space those lying within a particular area without
scanning the whole set. Therefore, spatial indexing is mandatory. It should also
support connecting objects from different classes through some spatial relationship
in a better way than by filtering the cartesian product (at least for those relationships
that are important for the application).
The purpose of this survey is to coherently present some of the fundamental
problems and their solutions in spatial database systems. The focus is on describing
solutions that have been found, rather than on listing many open problems. We
consider spatial DBMSs to provide the underlying database technology for geographic
information systems (GIS) and other applications. As such, they can offer only
VLDB Journal 3 (4) Giiting: An Introduction to Spatial Database Systems 359
some basic capabilities; we do not claim that a spatial DBMS is directly usable as
an application-oriented GIS.
In the following four sections we consider modeling, querying, tools for im-
plementation (data structures and algorithms), and system architecture for spatial
database systems.
2. Modeling
2.1 What needs to be represented?
The main application that is driving research in spatial database systems is the
technology for GISs. Hence, we consider some modeling needs in this area that are
also typical for other applications. Examples are given for 2-D space but, almost
everywhere, extension to the three- or more-dimensional case is possible. There
are two important alternative views of what needs to be represented:
1. Objects in space: We are interested in distinct entities arranged in space, each
of which has its own geometric description.
2. Space: We wish to describe space itself, that is, to say something about every
point in space.
The first view allows one to model, for example, cities, forests, or rivers. The second
view is the one of thematic maps describing, for example, land use or the partition
of a country into districts. Since raster images reveal something about every point
in space, they are also closely related to the second view. We can reconcile both
views to some extent by offering concepts for modeling single objects, and spatially
related collections of objects.
For modeling single objects, the fundamental abstractions are point, line, and
region. A point represents (the geometric aspect of) an object for which only its
location in space, but not its extent, is relevant. For example, a city may be modeled
as a point in a model describing a large geographic area (a large scale map). A line
(in this context always understood to mean a curve in space, usually represented
by a polyline, a sequence of line segments) is the basic abstraction for facilities for
moving through space, or connections in space (e.g., roads, rivers, cables for phone,
electricity). A region is the abstraction for something having an extent in 2-D space
(e.g., a country, a lake, or a national park). A region may have holes and may also
consist of several disjoint pieces. Figure 1 shows the three basic abstractions for
single objects.
The two most important instances of spatially related collections of objects are
partitions (of the plane) and networks (Figure 2). A partition can be viewed as a
set of region objects that are required to be disjoint. The adjacency relationship is
of particular interest, that is, there are often pairs of region objects with a common
boundary. Partitions can be used to represent thematic maps. A network can be
viewed as a graph embedded in the plane, consisting of a set of point objects,
360
Figure 1. Three basic abstractions: point, line, and region
I AO
Figure 2. Partitions and networks
forming its nodes, and a set of line objects describing the geometry of the edges.
Networks are ubiquitous in geography (e.g., highways, rivers, public transport, or
power supply lines).
Obviously, we have mentioned only the most fundamental abstractions to be
supported in a spatial DBMS (for GIS, in this case). Other interesting spatially
related collections of objects include nested partitions (e.g., a country partitioned
into provinces partitioned into districts) and a digital terrain (elevation) model. For
a deeper discussion of modeling requirements for GIS see Smith et al. (1987) and
Frank (1991). In the sequel, we shall consider how the basic abstractions mentioned
above can be embedded into a DBMS data model.
2.2 Organizing the Underlying Space: Discrete Geometric Bases

As a basis for geometric modeling, Euclidean space very often is used or implicitly
assumed. Essentially, this means that a point in the plane is given by a pair of real
numbers. Unfortunately, there are no real numbers in computers, but only finite
and rather limited approximations. This leads to a lot of problems in geometric
computation (Greene and Yao, 1986; Franklin, 1984). For example, the intersection
point of two lines will be rounded to the nearest grid (i.e., representable) point;
a subsequent test to determine whether the intersection point is on one of the
lines yields a false result. If the fact that finite representations are used is ignored
Figure 3. Two simplicial complexes
in modeling, these problems are left to the implementor of a spatial DBMS,

Which will almost certainly lead to errors in query processing. Some authors have
therefore suggested introducing a discrete geometric basis for modeling as well
as implementation (Frank and Kuhn, 1986; Egenhofer et al., 1989; G/iting and
Schneider, 1993a).
The approach of Frank and Kuhn (1986) and Egenhofer et al. (1989) is based on
combinatorial topology. Simplex and simplicialcomplex are basic concepts. For each
dimension d, a d-simplex is a minimal object in that dimension, hence, a 0-simplex
is a point, a 1-simplex is a line segment, a 2-simplex is a triangle, a 3-simplex is
a tetrahedron, etc. Any d-simplex is composed of ( d + l ) simplices of dimension
d--1. For example, a triangle (a 2-simplex) is composed of three 1-simplices (line
segments), and a line segment as a 1-simplex is composed of two 0-simplices (points).
The components used in a simplex are called its faces (the edges and vertices in
the case of a triangle). A simplicialcomplex is a finite set of simplices such that the
intersection of any two simplices in the set is a face. Figure 3 shows a 1-complex
and a 2-complex.
An alternative proposal of a discrete geometric basis is the concept of a realm
(G/iting and Schneider, 1993a). A realm conceptually represents the complete un-
derlying geometry of one particular application space (in two dimensions). Formally,
a realm is a finite set of points and line segments over a discrete grid such that
(1) each point or end point of a line segment is a grid point, (2) each end point
of a line segment is also a point of the realm, (3) no realm point lies within a
line segment (i.e., on the line segment without being an end point) and (4) no two
realm segments intersect except at their end points. Figure 4 illustrates a realm.
With both approaches, the idea now is to form the geometries of application
objects by composing the primitives of the underlying geometric base. One can
easily see how the point, line, or region objects of Section 2.1 can be described in
terms of simplices or of the elements of a realm. Furthermore, if spatially related
collections of objects such as partitions or networks are represented on top of such
a geometric base, then the consistency of shared geometries and to some extent
the relationships between objects are automatically provided by this base layer.
362
Figure 4. A realm
Numeric robustness problems can be treated within the geometric base layer so
that spatial data types or algebras defined on top enjoy nice closure properties not
only in theory but also in an implementation (G~ting and Schneider, 1993a).
2.3 Spatial Data Types
Systems of spatial data types, or spatial algebras, can capture the fundamental ab-
stractions for point, line, and region, together with relationships between them and
operations for composition (e.g., forming the intersection of regions). In Section 1
we stated that they are a mandatory part of the data model for a spatial DBMS, so
that all proposals for models and query languages, as well as prototype systems (Sec-
tion 5) offer them in some form. Spatial types and operations have been described
(e.g., Chang and Fu, 1980; Lipeck and Neumann, 1987; Gfiting, 1988; Joseph and
Cardenas, 1988; Orenstein and Manola, 1988; Roussopoulos et al., 1988; Svensson
and Huang, 1991). Dedicated work towards a formal definition has been reported
by Scholl and Voisard (1989), Gargano et al. (1991), and Gfiting and Schneider
(1993b). As an example of spatial algebra, we briefly consider the ROSE algebra
(Gfiting and Schneider, 1993b).
The ROSE algebra offers three data types called points, lines, and regions, whose
values are realm-based (i.e., composed from elements of a realm). To describe these
values, one needs intermediate notions of an R-block and an R-face. For a given
realm R, an R-block is a connected set of line segments of R. An R-face is essentially
a polygon with holes that can be defined over realm segments. Then, a value of
type points is a set of R-points, a value of type lines is a set of disjoint R-blocks,
and a value of type regions is a set of edge-disjoint R-faces (edge-disjoint means
that two faces may have a common vertex, but no common edge).
The type system of the ROSE algebra is based on a second-order signature
(GiJting, 1993), which allows one to describe polymorphic operations by quantification
over //k/nds (which here can be viewed as type sets). Two such sets are EXT
= (lines, regions} and GEO = {points, lines, regions}. There are four classes of
VLDB Journal 3 (4) GOting:An Introduction to Spatial Database Systems 363
operations; for each of them we show a few examples:
(1) Spatial predicates expressing topological relationships:

V geo in GEO. V eextl, ext2 in EXT. V area in regions area-disjint.
geo regions ~ bool inside

extl ext2 --~ bool intersects, meets
area x area ~ bool adjacent, encloses
Here the type variable geo ranges over the three types in kind GEO, so that the
inside operation can compare a points, a lines, or a regions value with a regions
value. The intersects operation can be applied to two values of the same or
different types within kind EXT. The notation regions area-disjint is an attempt
to capture the structure of partitions in the type system. It describes a kind
for all partitions; each particular partition (thematic map) is a type within this
kind whose values are the regions within this partition. Hence, the type variable
area will pick one partition and the operation adjacent be applicable to any two
regions of that partition.
(2) Operations returning atomic spatial data type values:
V geo in GEO.
lines x lines ~ points intersection
regions x regions---* regions intersection
geo x geo ~ geo plus, minus
regions ~ lines contour
Here plus and minus form the union and difference, respectively, of two values
of the same type.
(3) Spatial operators returning numbers:
V geol x geo2 in GEO.
geol geo2 --~ real dist
regions --~ real perimeter, area
(4) Spatial operations on sets of objects:

V obj in OBJ. V geo, geol, geo2 in GEO.
set(obj) X (obj ---+geo) --+ geo sum
set(obj) X ( o b j - - ~ g e o l ) x geo2 ~ set(obj) closest
Here sum is a spatial aggregate function. It takes a set of objects together with a
spatial attribute of the objects of type geo (given as a function mapping each object
into its attribute value) and returns the geometric union of all attribute values.
For example, one might form the union of a set of provinces to determine the
364
area of a country. The closest operator determines within a set of objects those
whose spatial attribute value has minimal distance from some other geometric
(query) object.
These examples may show the kinds of operations that are available in a spatial
algebra. Formal definitions of the semantics of these types and operations can be
found in Giiting and Schneider (1993b). Some of the important issues related to
spatial data types or algebras are the following:
Extensibility. There is general agreement that the definition of types and, in
particular, the definition of operations is application-dependent. Hence, it
must be possible to define additional or alternative types and operations later,
which leads to the requirement of extensibility for the system architecture
(Section 5).
Completeness. Nevertheless, the question is whether there are any formal
criteria to say that a particular collection of operations is complete in some
respect. Some limited success in this direction has been obtained in the study
of topologicalrelationships (Section 2.4).
One or more types? Is it really necessary to have several different types to
distinguish, for example, points, lines, and regions? Some authors suggest
offering only a single type geometry whose instances can be any of these or
even mixed collections of them (e.g., Gargano et al., 1991; Larue et al., 1993).
This is analogous to the question of whether a system should offer different
types integer and real, or just a single type number. One advantage of a single
type may be that closure under operations is easier to achieve. On the other
hand, several types are more expressive and allow a more precise application
of operations.
Set Operations. A spatial algebra should offer not only operations on "atomic"
SDT values (a region value is considered to be atomic, even if it has a very
large description) but also on spatially related sets of objects, for example,
a partition (thematic map, tesselation) (G(iting, 1988; Scholl and Voisard,
1989; Tomlin, 1990; Svensson and Huang, 1991). Example operations are
the overlay of two partitions, fusion (merging adjacent areas in a partition
if other attributes are equal), or finding in a set of objects the one closest
to a query object. This kind of operation requires a much more intricate
interface with the DBMS data model than in the case of atomic operations
(G/iting and Schneider, 1993b).
2.4 Spatial Relationships

Among the operations offered by spatial algebras, spatial relationships are the most
important. For example, they make it possible to ask for all objects in a given
relationship with a query object (e.g., all objects within a window). One can
distinguish several classes (Pullar and Egenhofer, 1988; Egenhofer, 1989; Worboys,
1992):
Topological relationships, such as adjacent, inside, and disjoint, are invariant

under topological transformations like translation, scaling, and rotation.
Direction relationships, for example, above, below, or north_of southwest_of
Metric relationships, for example, "distance < 100."
Among these, topological relationships are the most fundamental and have been
studied in some depth. A basic question is whether we can somehow enumerate
all possible relationships. A method for this was proposed by Egenhofer (1989)
and Egenhofer and Herring (1990). It was originally formulated for simple regions
(connected, no holes), called area in the sequel, and is based on comparing the
intersections of their boundaries and interiors (denoted 0 A and A , respectively).
For two objects there are four intersection sets; each of them may be empty or
non-empty, which leads to 24 = 16 combinations (Table 1). Eight of these are not
valid, and two of them are symmetric so that six different relationships result, called
disjoint, in, touch, equal, cover, and overlap.
This approach has been extended in various ways. For example, point and
line features have been added (Egenhofer and Herring, 1992; de Hoop and van
Oosterom, 1992). Egenhofer extended the original four-intersection method to a
nine-intersection method by also considering intersections with the complement A-1
(Egenhofer, 1991b). Clementini et al. (1993) also considered the dimension of the
intersection (called the dimension-extended method): in 2-D space the intersection
can be empty, 0-D (point), 1-D (line), or 2-D (area). This results, in principle, in
44 = 256 combinations. Again, many of these are not valid, so that in total 52
relationships among point, line, and area features remain.
Since these are far too many to be named and remembered by a user, an
alternative is suggested. Five basic relationship names are introduced (touch, in,
cross, overlap, and disjoint), whose meaning is formally defined in terms of the
dimension extended method, for example:
The touch relationship applies to area/area, line/line, line/area, point/area,
and point/line, but not point/point situations. For two features A1 and A2,
it is defined by:
< A1 touch A2 >::-~. (A'~ A A~ = 0) A (A1 A A2 -~ 0)
In addition to the five relationships, three operators are offered to obtain the
boundaries of features: operator b applied to area A yields the boundary line 0A;
operators f and t return the end points of a line. It was proven by Clementini
et al. (1993) that the five relationships are mutually exclusive (no two different
relationships can hold between any two features) and that all situations described
by the dimension-extended method can be distinguished using the relationships and
the three boundary operators. Other work on spatial relationships includes Freksa
(1991), Frank (1992), and Cui et al. (1993). The article by Papadias and Sellis in
this special issue investigates the subject in more depth; further references can be
found there (Papadias and Sellis, 1994).
366
Table 1. Enumerating topological relationships by intersections

of boundaries and interiors
0A1 n 0A2 0Alf'lA~ A~ f-1 0A2 A~FI A~ relationship name
0 0 0 O A1 disjoint A2
0 0 0 #:O
0 0 #0 O
0 0 #0 #:O A2 in A1
0 #0 0
0 #0 0 4:0 A1 in A2
0 #0 #0 O
0 #0 #0 #O
#0 0 0 O A1 touch A2
#0 0 0 #0 A1 equal A2
#0 0 #0 0
#0 0 #0 #0 A1 cover A2
#0 #0 0
#0 0 #0 A 2 cover A 1
#0 #0 #0 0
#0 #0 #0 #0 A1 overlap A2
2.5 Integrating Geometry into the DBMS Data Model

The central idea for integrating geometric modeling into a DBMS data model is to
represent "spatial objects" (in the sense of application objects such as river, country,
or city) by objects (in the sense of the DBMS data model) that have at least one
attribute of a spatial data type. Hence, the DBMS data model must be extended
by SDTs at the level of atomic data types (such as integer and string), or had better
be generally open for user-defined types ("abstract data type support," Stonebraker
et al., 1983). So far, the relational model has been used most often as a basis (e.g.,
Chang and Fu, 1980; Gfiting, 1988; Roussopoulos et al., 1988; Ooi et al., 1989;
Egenhofer, 1994), but the approach can be used as well with any other data model
(e.g., an object-oriented one). In the relational case, an object is represented by a
tuple, so we can define example relations (of course, real GISs deal with less trivial
application objects):
relation states (sname: STRING; area: REGION; spop: INTEGER)
relation cities (cname: STRING; center: POINT; ext: REGION;
cpop : INTEGER)
relation rivers (rname: STRING; route: LINE)
VLDB Journal 3 (4) G0ting: An Introduction to Spatial Database Systems 367
Lipeck and Neumann (1987) integrated SDTs into an extended ER model;

Scholl and Voisard (1989) integrated them into a complex object model. Handling
partitions and networks is more difficult (Section 2.1). Partitions can be viewed
simply as sets of objects with region attributes, but then information is lost: regions
should be disjoint and adjacency relationships are particularly important within this
class (e.g., for establishing adjacency join indexes, Section 4.3). The importance of
modeling and manipulating partitions has been emphasized (Mantey and Carlson,
1980; Frank, 1988; Gtiting, 1988; Scholl and Voisard, 1989; Tomlin, 1990). In
Giiting (1988) a special AREA data type was suggested; creating a relation with
an attribute of type A R E A would imply that all regions occurring as values of this
relation had to be disjoint. But this is not clean, because it abuses the concept of
a data type to describe what should really be an integrity constraint on a relation.
Modeling of spatially embedded networks has not received much attention in
the research literature, although quite a bit of work has been done for graphs
in databases in general (Rosenthal et al., 1986; Agrawal, 1987; Cruz et al., 1987;
Gyssens et al., 1990). Usually, the assumption is that graphs are represented by the
given facilities of a data model. A disadvantage is that the graph structure is not
visible to the user, and cannot be supported very well in system implementation.
In Giiting (1994), the GraphDB model is proposed, which emphasizes an explicit
modeling of graphs together with a clean integration into a "standard" object-oriented
model. GraphDB offers object classes with inheritance, like other OO models, but
additionally distinguishes three kinds of object classes called simple classes, link
classes, and path classes, whose elements correspond to nodes, edges, and explicitly
stored paths of a graph. For example, in GraphDB we can model a highway network
whose nodes are highway junctions and exits with an associated POINT attribute,
whose edges are highway sections with an associated LINE attribute, and whose
explicitly stored paths are highways, as follows:
class v e r t e x = pos: POINT;
v e r t e x class j u n c t i o n = name: STRING;
v e r t e x class exit = nr: INTEGER;
linkclass s e c t i o n = route: LINE, no_lanes: INTEGER, top_speed:
I N T E G E R from v e r t e x to vertex;
path class h i g h w a y = name: STRING as section+;
Here the junction and exit subclasses inherit the pos attibute from the vertex class. A
highway is a path over a non-empty sequence of section edges. For further details,
see G6ting (1994). Another spatial data model with explicit graphs is described by
Erwig and G0ting (1991).
3. Querying
From one point of view, the problem of querying is to connect the operations of a
spatial algebra (including predicates to express spatial relationships) to the facilities
368
of a DBMS query language. But there are also other aspects that mainly have to do
with the fact that spatial data require a graphical presentation of results as well as
graphical input of queries or at least SDT values used in queries. In the following
three subsections, we consider the fundamental operations needed at the level of
manipulating sets of database objects, graphical input and output, and techniques
and requirements for extending query languages.
3.1 Fundamental Operations (Algebra)

We now consider from an algebraic point of view operations for manipulating sets
of database objects with spatial attributes. They can be classified as spatialselection,
spatial join, spatial function application, and other set operations.
Spatial Selection. Strictly speaking, there is no such thing as a spatial selection.
A selection is an operation that returns from a set of objects those that fulfill a
predicate. However, the term is used in the literature to describe a selection based
on a spatial predicate (e.g., Aref and Samet, 1991a). Some examples:
"Find all cities in Bavaria" (assuming that Bavaria exists as a R E G I O N value, and
inside is available in the spatial algebra).
cities select[center inside Bavaria]
"Find all rivers intersecting a query window."
rivers select[route intersects Window]
"Find all big cities no more than 100 kms from Hagen" (Hagen being a POINT value).
cities select[dist(center, Hagen) < i00 and pop > 500000]
The last example illustrates that selection conditions can also be based on metric
relationships, and can occur in conjunction with other predicates. Query optimization
should be able to compare access plans using spatial indexes with plans using a
standard index. This will be discussed further in Section 5.
Spatial Join. Similar to a spatial selection, a spatial join is a join that compares
any two objects with a predicate according to their spatial attribute values. Some
examples:
"Combine cities with their states."
cities states join[center inside area]
"For each river, find all cities within less than 50 kms."
cities rivers join[dist(center, route) < 50]
As mentioned in Section 1, spatial selection and spatial join are so important that it
is mandatory to support them with spatial indexing and with special join algorithms,
at least for the most important spatial predicates.
Spatial Function Application. How can operations of a spatial algebra that compute
new SDT values (class 2 in Section 2.3) be used in a query? In a set-oriented query,
VLDB Journal 3 (4) GiJting: An Introduction to Spatial Database Systems 369
a new SDT value is computed for each object in a set. Various object algebra
operators allow such an embedding of a function application, for example, the filter
operator of FAD (Bancilhon et al., 1987), the replace operator (Abiteboul and Beeri,
1988), or the A or extend operator (Giiting et al., 1989). The extend operator takes
an expression to be evaluated for each object and a (new) attribute name; it appends
the resulting value as a new attribute to the object. For example:
"For each river going through Bavaria, return the name, the part of its geometry lying inside
Bavaria, and the length of that part. "
rivers select[route intersects Bavaria]
extend [intersect ion (route, Bavaria) {part}]
extend[length(part) {plength}] project[rname, part, plength]
Other Set Operations. Such operations manipulate whole sets of spatial objects in a
special way; they lie at the interface between a spatial algebra and the DBMS object
algebra (Section 2.3). Of particular importance are operations that manipulate
partitions (thematic maps); a collection of such operations is described by Scholl
and Voisard (1989). Closely related is the map algebra by Tomlin (1990). Some
suggested operations are the following:
Overlay. Computes the elementary regions resulting from overlaying two
partitions. It can be viewed as a special kind of spatial join (Frank, 1988;
G~ting, 1988; Scholl and Voisard, 1989).
Fusion. This is a special kind of grouping. Objects are grouped by some
arbitrary attribute values. For each resulting group of objects, the union of
all values of a spatial attribute is formed. For example, given a set of region
objects with a "land-use" attribute, one can group by land-use to obtain one
object for land-use "wheat" with the associated union region, etc. (Scholl
and Voisard, 1989; Gargano et al., 1991).
Voronoi. From a set S of point objects, computes a corresponding set of
region objects (the Voronoi diagram). For each point p, the region consists
of the points of the plane closer to p than to any other point in S (Giiting,
1988).
3.2 Graphical Input and Output

Traditional database systems deal with alphanumeric data types whose values can
easily be entered through a keybord and represented textually within a query result
(e.g., a table). For a spatial database system, at least when it is to be used interactively,
graphical presentation of SDT values in query results is essential. It is also important
to enter SDT values to be used as "constants" in queries via a graphical input device.
Besides graphical representation of SDT values, another distinctive characteristic
of querying a spatial database is that the goal of querying is, in general, to obtain
a "tailored" picture of the space represented in the database. This means that the
370
information to be retrieved is often not the result of a single query but rather a
combination of several queries. For example, for (;IS applications, the user wants
to see a map built by graphically overlaying the results of several queries.
Requirements for spatial querying have been analyzed by Frank (1982), Egen-
hofer and Frank (1988), and Egenhofer (1994). In Egenhofer (1994), the following
list is given:
1. Spatial data types.
2. Graphical display of query results.
3. Graphical combination (overlay) of several query results. It should be possible
to start a new picture, to add a layer, or to remove a layer from the current
display. (Some systems also allow the order of layers to be changed; Voisard,
1991; Vijlbrief and van Oosterom, 1992).
4. Display of context. To interpret the result of a query, for example, a point
describing the location of a city, it is necessary to show some background,
such as the boundary of a state containing it (Frank, 1982). A raster image
of the area can also nicely serve as a background.
5. A facility for checking the content of a display. When a picture (a map) has
been composed by several queries, one should be able to check which queries
have built it.
6. Extended dialog. It should be possible to use pointing devices to select objects
within a picture or subareas (zooming in), for example, by dragging a rectangle
over the picture.
7. Varying graphical representations. It should be possible to assign different
graphical representations (colors, patterns, intensity, symbols) to different
object classes in a picture, or even to distinguish objects within one class
(e.g., by using different symbols to distinguish cities by population).
8. A legend should explain the assignment of graphical representations to object
classes.
9. Label placement. It should be possible to select object attributes to be
used as labels within a graphical representation. Sophisticated ("nice") label
placement for a map is a difficult problem, however (Freeman and Alan,
1987).
10. Scale selection. At least for GIS applications, selecting subareas should be
based on commonly used map scales. The scale determines not only the size of
the graphical representation, but it also could determine what kind of symbol
is used or whether an object is shown at all (cartographic generalization).
11. Subarea for queries. It should be possible to restrict attention to a particular
area of the space for several following queries.
These requirements, in general, can be fulfilled by offering textual commands in

the query language or within the design of a graphical user interface (GUI). A
GUI will probably have at least three subwindows: (1) a text window for displaying
the textual representation of a collection of objects, containing the alphanumeric

attributes of each object, (2) a graphics window containing the overlay of the
graphical representations of spatial attributes of several object classes or query
results, and (3) a text window for entering queries and perhaps displaying system
messages. One possible design was shown by Egenhofer and Frank (1988). Some
systems implement a text-graphic interaction: clicking at an object representation
in the text or graphic window selects and highlights the object representations in
both windows (Vijlbrief and van Oosterom, 1992).
Egenhofer (1994) suggested to view a query as consisting of three parts:
1. Describing the set of objects to be retrieved, as in traditional querying,
2. Partitioning the query result into subsets to be displayed in different formats
by a number of display queries,
3. Describing for each subset how to render its spatial attributes.
For part (1), the language SQL, extended by spatial types and operations, was used
by Egenhofer (1994). For parts (2) and (3), a special graphicalpresentation language
(GPL; Egenhofer, 1991a) was introduced, which provides specifications for most of
the requirements listed above.
3.3 Integrating Geometry into a Query Language

Integrating geometry into a query language has three main aspects:
Denoting SDT values as constants in a query, and graphical input of such
constants.
Expressing thefourclasses of fundamental operations (Section 3.1) for an em-
bedded spatial algebra.
Describingthepresentationofresults.
Denoting SDT values~graphical input. In traditional query languages, constants in

queries (needed in particular to formulate selection conditions, such as name =
"Smith") belong to an alphanumeric data type and are therefore textually repre-
sentable (i.e., they can simply be entered through the keyboard). This is not feasible
for SDT constants. Such a constant may be entered through a graphical input device
or it could have been computed in a previous query, for example, by extracting
the attribute value of some object from the database. In Section 3.1 we assume
that it is possible to introduce names for such values (Bavaria, Window, Hagen).
This is not the case in classical relational query languages. In the geo-relational
algebra (Giiting, 1988), atomic values are "first class citizens," so one can introduce
a named REGION value Bavaria as follows:
states extract [sname= "Bavaria"; area] {Bavaria}
Object-oriented query languages usually allow one single object to be identified;
one can then denote any attribute value (and, therefore, an SDT value) by dot
notation (e.g., determine an object "Bavaria," and then refer to "Bavaria.area"). If
372
it is possible to denote such values, then one can nicely decouple graphical input
and querying; the user interface allows one to draw the value and assign a name
to it, which can then be used in queries. If it is. not possible, then a suggested
technique (Chang and Fu, 1980; Frank, 1982; Egenhofer, 1994) is to use a special
keyword within a query such as PICK; parsing the query will lead to an interaction
that allows the user to graphically enter the value:, for example:
SELECT sname FROM cities WHERE center inside PICK
Expressing the four classes of fundamental operations. Obviously, expressing spatial

selection or spatial join is no problem at all, because selection and join are provided
by all query languages. Spatial function application, although not possible in classical
relational algebra, is also in practice provided by query languages (e.g., SQL allows
expressions in the SELECT clause). Hence, we can express the example queries
of Section 3.1 in SQL or other languages (assuming that it is possible to denote
constants):
SELECT * FROM rivers WHERE route intersects Window
SELECT cname, shame FROM cities, states
WHERE center inside area
SELECT rname, intersection(route, Bavaria),
length(intersection(route, Bavaria) )
FROM rivers
WHERE route intersects Bavaria
In contrast, the expression of other set operations of a spatial algebra does not fit
into the select.., from.., where (SFW) paradigm, because these are algebra operations
at the same level as projection, cartesian product, and selection, as captured by
SFW. Some syntactic facilities required in a query language to accomodate a spatial
algebra completely were described by Giiting and Schneider (1993b) where a general
"object model interface" is developed.
Describing the presentation of results. It is arguable whether this should be part of a

query language, be described by a separate language, or be defined by user interface
manipulation. An interesting observation is that a presentation language also needs
some embedded general querying capabilities to determine subsets of answers to
be shown in specific formats (Egenhofer, 1991a, 1994).
Proposals for spatial query languages have been described (e.g., Chang and Fu,
1980; Frank, 1982; Keating et al., 1987; Lipeck and Neumann, 1987; Gtiting, 1988;
Herring et al., 1988; Joseph and Cardenas, 1988; Roussopoulos et al., 1988; Ooi et
al., 1989; Scholl and Voisard, 1989; Svensson and Huang, 1991; Egenhofer, 1994).
Problems with SQL-based extensions were discussed by Egenhofer (1992). Other
directions in spatial querying include a deductive database approach (Abdelmoty
et al., 1993) and visual querying (i.e., drawing a sketch of the spatial situations to
be retrieved; Maingenaud and Portier, 1990; Meyer, 1992).
4. Tools for Spatial DBMS Implementation

We now consider system implementation bottom up. In this section, we first describe
data structures and algorithms that can be used as tools or building blocks within
different system architectures. System architectures themselves are discussed in the
next section. The general problem to be solved is implementation of a spatial
algebra in such a way that it can be integrated into a database system's query
processing. This means, first of all, that we have to provide representations for the
algebra's types as well as algorithms/procedures for its operations. However, it does
not suffice just to implement atomic operations efficiently such as a test whether
two regions intersect. It is also necessary to consider the use of such predicates
within set-oriented query processing (i.e., when they occur within a spatial selection
or a spatial join). Here spatial access methods and spatial join algorithms come
into play. Last but not least, other set operations of a spatial algebra need their
special implementations. In the following subsections, we discuss the representation
of spatial data types and implementation of atomic operations, spatial indexing to
support spatial selection, and support of spatial join.
4.1 Representing SDT Values/Implementing Atomic SDT Operations

The representation of a value of a spatial data type (e.g., a region) has to be
simultaneously compatible with two different views, namely, the view of the database
system, and the view of the spatial algebra. From the DBMS perspective, the
representation
is the same as that of attribute values of other types with respect to generic
operations,
can have varying and possibly very large size,
resides permanently on disk and is stored in one page or a set of pages,
can efficiently be loaded into main memory, where it is given as a value of
some variable (typically, a pointer variable) to the procedures that implement
operations of the spatial algebra,
offers a number of type-specific implementations of generic operations needed
by the DBMS.
From the point of view of the spatial algebra implementation, which is done in
some programming language (most likely the DBMS implementation language), the
representation
is a value of some programming language data type (e.g., region),
is some arbitrary data structure that is possibly quite complex,
supports efficient computational geometry algorithms for spatial algebra op-
erations,
is not geared to only one particular algorithm, but is balanced to adequately
support many operations.
374
To fulfill the DBMS requirements, the representation must be a paged data structure
compatible with the DBMS support for long fields or large attribute values. To
support efficient loading and storing on disk, it should consist of a single contiguous
byte block, as long as it is small enough to fit into one page. Otherwise, it can be
a large byte block cut into page-sized pieces. The DBMS then either may allocate
enough internal space to hold the whole value (and map pages into the right positions
of this buffer), or it may implement a more complex paging strategy to access the
value. When a value representation happens to be large, a good strategy is to split
it into a small infopart, which will contain often-used summary information about
the value, and an exact geometlypart, representing, for example, the long sequence
of vertices, so that it is possible to load only the info part into a DBMS buffer.
The info part might be contained in the DBMS object representation and contain
a logical pointer to a separate page sequence holding the exact geometry part. The
generic operations needed by the DBMS may concern, for example, transforming
from/to a textual or graphic representation for input/output at the user interface, or
transforming from/to an ASCII format for bulk loading or external data exchange.
More specifically, for spatial data types, generic approximations may be needed to
interface with spatial access methods: For example, each data type must provide
access to a bounding box (also called the minimum bounding rectangle (MBR)).
From both the spatial algebra and the programming language point of view,
the representation should be such that it is mapped by the compiler into a single or
perhaps a few contiguous areas (to support the DBMS loading). For example, it can
be defined as a pointer to a record with several fixed-size components and a very
large array (for the exact geometry) at the end; then one can dynamically allocate
the right amount of space for a given value. Apart from that, the representation
can support operations as follows:
Plane sweep sequence. Very often, algorithms on the exact geometry use
a plane-sweep. The sweep needs the components of the object (e.g., the
vertices) in some fixed order (e.g., x-order). It is highly advantageous to
store this order explicitly in the object so that not every sweep needs to sort
vertices first.
Approximations. The implementation of many operations starts with a rough
test on an approximation of the object. Usually this is the bounding box, but
there can also be other approximations. Hence, these should be part of the
representation.
Stored unary function values. Some operations of the spatial algebra compute
properties of a spatial value (e.g., the area or perimeter of a region). Since
these can be expensive to compute, they may be computed once after the
creation of the value and then be stored with it.
The representation strategy described above does assume, in fact, a particular DBMS
architecture, namely, that of an extensible DBMS. Hence, some of the remarks may
not be valid for an architecture that, for example, stores its SDT values separately
in files, outside of the DBMS storage management. However, there seems to be

growing agreement that the extensible approach (Section 5) is the right basis for
spatial database systems (e.g., Haas and Cody, 1991; Vijlbrief and van Oosterom,
1992; Larue et al., 1993).
The representation of data type values in extensible DBMSs ("abstract data type
support") has been discussed (e.g., Stonebraker et al., 1983; Osborn and Heaven,
1986; Wilms et al., 1988; Wolf, 1989; Dr6ge et al., 1990). The DASDBS Geo-Kernel
(Wolf, 1989; Dr6ge et al., 1990) makes somewhat special assumptions about the
interface to a generic spatial access method by requiring that each data type offer
generic operations for clipping at a rectangle and composing two clipped pieces of
an SDT value. The Gral system (Gfiting, 1989; Becker and Gfiting, 1992) is an
example of a system that implements the strategy described above.
Concerning the implementation of SDT operations, some important ideas have
already been mentioned, including prechecking approximations, looking up stored
function values, and using plane-sweep. Generally, efficient algorithms from compu-
tational geometry should be used (Preparata and Shamos, 1985; Mehlhorn, 1984).
For some operations, a simple scan of the vertices or edges is sufficient (e.g., to
compute the perimeter or area of a region, or the center of a set of points). For
more complex questions, plane-sweep is most often the appropriate technique (e.g.,
to compute the intersection of two polygons).
The implementation of many operations is simplified if the spatial algebra has a
discrete basis (e.g., is realm-based; Section 2.2). Basically, this means that in query
processing there are never any new intersection points computed; all intersection
points of SDT values over the realm are known within the realm and occur in both
objects. For example, to compute the intersection of two lines values (which is a
points value) in the ROSE algebra (Section 2.3), it is sufficient to do a parallel scan
on the two values' halfsegment sequences. (Each line segment occurring within a lines
value is represented twice, once for the left end point, and once for the right end
point so that each half-segment has a dominating point. The half-segment sequence
is ordered xy-lexicographically by dominating points. Hence, a parallel scan will
determine the intersection points in linear time.) Without the realm basis, a much
more complex plane-sweep algorithm is needed. Plane-sweep algorithms are also
simplified with a realm-basis, because the sweep-event structure (Nievergelt and
Preparata, 1982) now can be a static data structure, since no new intersection points
are discovered during the sweep. Such techniques are used in the implementation
of the ROSE algebra (de Ridder, 1994).
4.2 Spatial IndexingmSupporting Spatial Selection

The main purpose of spatial indexing is to support spatial selection, that is, to
retrieve from a large set of spatial objects (objects with an SDT attribute) those
objects in some particular relationship with a query SDT value. A spatial indexing
method organizes space and the objects in it so that only parts of the space and a
subset of the objects need to be considered. There are two ways to provide spatial
376
Figure 5. Bounding box and grid approximations of SDT value
indexing: (1) dedicated external spatial data structures are added to the system,
offering for spatial attributes what a B-tree does for standard attributes, and (2)
spatial objects are mapped into a 1-D space so that they can be stored within a
standard 1-D index such as a B-tree. Apart from spatial selection, spatial indexing
supports also other operations such as spatial join, finding the object closest to a
query value, etc.
A fundamental idea for spatial indexing and, in fact, for all spatial query
processing, is the use of approximations. This allows index structures to manage
an object in terms of one or more spatial keys, which are much simpler geometric
objects than the SDT value itself. A continuous approximation is based on the
coordinates of the SDT value itself. The prime example is the bounding box (the
smallest axis-parallel rectangle enclosing the SDT value). For grid approximations,
space is divided into cells by a regular grid, and the SDT value is represented by the
set of cells that it intersects. Figure 5 illustrates the two kinds of approximations.
The use of approximations leads to a filter and refine strategy for query processing
(Frank, 1981; Orenstein and Manola, 1988): First, based on the approximations,
a filtering step is executed; it returns a set of candidates that is a superset of the
objects fulfilling a predicate. Second, for each candidate (or pair of candidates
in case of spatial join) in a refinement step the exact geometry is checked. This
strategy has more recently been extended to include a second filtering step where
more precise approximations of the candidate objects are checked (Brinkhoff et al.,
1993a).
Due to the use of bounding boxes, most spatial data structures are designed to
store either a set of points (for point values) or a set of rectangles (for line or region
values). The operations offered by such structures are insert, delete, and member
(find a stored rectangle or point) to manage the set as such. Apart from that, one
or more query operations are supported. For stored points, some important types
of queries are:
Range query: Find all points within a query rectangle.
Figure 6. A kd-tree partitioning of a 2-D space
Nearest neighbor: Find the point closest to a query point.

Distance scan: Enumerate points in increasing distance from a query point.
For rectangles:
Intersection query: Find all rectangles intersecting a query rectangle.
Containment query: Find all rectangles completely within a query rectangle.
A spatial index structure organizes objects within a set of buckets (which normally
correspond to pages of secondary memory--some special approaches use varying size
buckets with many pages; Drdge and Schek, 1993). Each bucket has an associated
bucket region, a part of space containing all objects stored in the bucket. Bucket
regions are usually rectangles. For point data structures, these regions are normally
disjoint and they partition the space so that each point belongs to precisely one
bucket. For some rectangle data structures, bucket regions may overlap. Figure 6
shows a partition where each bucket can hold up to 3 points.
Like index structures for standard attributes, the structure can be a clustering
or a secondaJy index. A clustering index stores the actual spatial objects. An entry
in a secondary index is just a spatial key (e.g., point or rectangle) together with a
logical pointer to the object in the database.
In the following three subsections, we first consider 1-D embeddings that allow
the use of standard index structures such as the B-tree. We then discuss dedicated
spatial data structures for points and for rectangles.
4.2.1 1-D Embedding of Grid Approximations. The basic idea for this is (1) to find
a linear order for the cells of the grid such that cells close together in space are also
(as far as possible) close to each other in the linear order, and (2) to define this
order recursively for a grid that is obtained by a hierarchical subdivision of space.
Figure 7 shows the most popular such order, bit interleaving, proposed by Morton
(1966) and later rediscovered several times (e.g., Abel and Smith, 1983; Gargantini,
1982). Orenstein (1986) used it as a general basis for query processing in the
378
Figure 7. z-order enumeration of cells of hierarchical partition
01\
0
00 10
0
PROBE system (Orenstein and Manola, 1988), and called it z-order. In Figure 7,
the left diagram shows the ordering imposed on the four quadrants of the top level
of a regular hierarchical partition. On the right side, this is continued to the next
level: within each quadrant, cells are connected in z-order, and then the groups of
cells of the four quadrants are again connected in z-order. Each cell at each level
of the hierarchy has an associated bit string whose length corresponds to the level
to which the cell belongs. For example, the top-right cell in the left diagram has bit
string 11, on the right-side cell 1110 is shown. The bit string 1110 is obtained by
choosing 11 at the top level, and then 10 within the top level quadrant. One can
also think of it as being composed of a 11 x-coordinate (used for the first and third
bit) and a 10 y-coordinate (used for the second and fourth bit) which has led to the
name bit interleaving. The order that is so imposed on all cells of a hierarchical
subdivision is given by the lexicographical order of the bit strings.
Any shape (set of cells) over the grid can now be decomposed into a minimal
number of cells at different levels, always using the highest possible level. It can
therefore be represented by a set of bit strings (Figure 8), called z-elements by
Orenstein (1986).
For a given spatial object, one can therefore use its corresponding set of z-
elements as a set of spatial keys. To build an index for a set of objects, one can
just form the union of all these spatial keys and put them in lexicographical order
into a B-tree. Because of the proximity-preserving property of this embedding,
various types of queries can now be answered relatively efficiently through B-tree
access. For example, to answer a containment or range query with a rectangle r, this
rectangle is itself decomposed into a number of z-elements. For each z-element,
one portion of the leaf sequence of the B-tree is scanned containing all entries
having that z-element as a prefix. This returns a set of candidates which then can
be checked in the refine step whether containment is actually true.
Figure 8. A set of z-elements approximating an SDT value
10010 100110
II 1,(
110ca
Figure 9. Structure of the grid file

directory
Y3
Y2 i
Yl
Iq
I
scales ~.... buckets
I I I I
Xl x2 x3x4
4.2.2 Spatial Index Structures for Points. Data structures for representing points in
a k-dimensional space have a much longer tradition than spatial database systems.
This is because a tuple consisting of n attributes, t = ( x 1 . . . . . Xk) , can be viewed as
a point in k dimensions and, therefore, such data structures can be used to support
multi-attribute retrieval. On the other hand, they also can store points with a
geometrical interpretation. Two well-known representatives of such data structures
are the gridfile (Nievergelt et al., 1984) and the kd-tree (Bentley, 1975). The latter
is an internal data structure, but also has been used as a basis for external index
structures.
The grid file (Figure 9) partitions the data space into cells by an irregular
grid. It is characteristic for this partition that split lines extend through the whole
space. The split line positions are kept in scales, using one scale per dimension.
380
The directoly is a k-dimensional array whose entries are logical pointers to buckets.
Each cell of the data space corresponds to one element of the directory array, and
all points lying within a cell are stored in the bucket pointed to by the corresponding
directory entry. Several cells may be mapped into the same bucket so that bucket
regions, in general, consist of more than one cell.
The scales are relatively small structures and can be kept in memory; the
directory resides in a set of pages on disk. To find the bucket that contains a
particular point, one would determine with the help of the scales the address of the
page containing the directory entry for the cell containing it. The second page access
already retrieves this bucket. Range queries can be answered by determining from
the directory the set of buckets containing cells intersected by the query rectangle,
and then by examining the points in these buckets. For the treatment of bucket
overflows or underflows see Nievergelt et al. (1984).
The kd-tree is a binary tree where each internal node contains a key drawn from
one of the k dimensions; leaves contain the points to be stored. The key in the root
node (at level 0, counting from top to bottom) divides the data space with respect
to dimension 0, the keys in its sons, at level 1, divide the two subspaces with respect
to dimension 1, and so forth, up to dimension k-l, after which cycling through the
dimensions restarts. Figure 6 shows a kd-tree partitioning of the data space. For the
original kd-tree, the recursive splitting of space stops when each cell contains only a
single point. This has been transformed to an external data structure by letting each
cell of the partition correspond to a bucket and by also paging the binary tree itself
in the KDB-tree (Robinson, 1981), which is also a generalization of the B-tree (all
leaves are at the same level). Another variant is the LSD-tree (Henrich et al., 1989),
which abandons the strict cycling through the dimensions and makes it possible to
choose the dimension for splitting based on local criteria (therefore called local
split decision tree). The second important aspect of the LSD-tree is a clever paging
algorithm that keeps the external path length balanced, even for very unbalanced
binary trees. This allows the LSD-tree to deal rather well with skewed distributions
of points that particularly arise when extended spatial objects (k-dimensional boxes,
rectangles) are mapped into points through the transformation approach (Section
4.2.3). Other point data structures are, for example, EXCELL (Tamminen, 1982),
the buddy hash tree (Seeger and Kriegel, 1990), the BANG file (Freeston, 1987),
or the hB-tree (Lomet and Salzberg, 1989).
4.2.3 Spatial Index Structures for Rectangles. The management of rectangles in

external data structures is more difficult than that of points because rectangles,
unlike points, generally do not fall into a unique cell of a partition, but intersect
partition boundaries. There are three solutions for this problem:
The transformation approach: Instead of k-dimensional rectangles, we store
2k-dimensional points, using a point data structure.
Overlapping regions: Partitioning space is abandoned; bucket regions may
overlap.
Figure 10. Transformation approach, mapping intervals into 2-D points
A
ql n
y=i 2
I
I
I j
L
|
_
r
X=ll 12 ql q2
Clipping: Partitioning space is kept; if a rectangle intersects partition bound-

aries it is clipped into several pieces and represented within each cell that it
intersects.
The Transformation Approach. A rectangle, represented by four coordinates (xteft,
Xright, Ybottoma Ytop), can be regarded as a point in four dimensions. The various
types of queries then map to regions of the 4-D space. This approach is usually
illustrated by the case of intervals mapped into 2-D space.
In Figure 10, the interval to be stored, i = (il, i2), is mapped into a point (x, y).
An intersection query with an interval q = (ql, q2) translates to a condition: Find
all points (x~,J ) such that x' < q2 and ql < J . Hence, all intervals intersecting q
must lie as points in the shaded area of Figure 10.
The transformation approach (Hinrichs, 1985; Seeger and Kriegel, 1988), here
shown with the comer representation, generally leads to rather skewed distributions'
of points. For example, all points fall into the area above the diagonal x -- y. If all
intervals are small, all corresponding points lie very close to this diagonal. It is also
possible to use a center representation (using center and length of an interval), but
then the query regions become cone-shaped, and do not fit well with rectangular
partitions of the point set. The LSD-tree point data structure was designed to be
able to adapt to such skewed distributions (Henrich et al., 1989). A recent discussion
of the transformation approach and a comparison to methods storing rectangles
directly can be found in Pagel et al. (1993).
Overlapping Regions. The prime example of a structure using overlapping bucket
regions is the R-tree (Figure 11; Guttmann, 1984), It is a multiway tree, like the
B-tree, and stores a set of rectangles in each node. The leaves are the rectangles
of the set R to be represented. For an internal node, each rectangle is associated
with a pointer to a son p, and represents the bucket region of p, which is the
bounding box of all rectangles represented within p. For example, in Figure 11 the
382
Figure 11. Set of rectangles represented by R-tree
IAIBIClI
IDiEIFII IOIHllIIJIKLIMI
root node contains a rectangle A, which is the bounding box of the rectangles D,
E, and F, stored in the son associated with A. Rectangles may overlap; hence, a
rectangle can intersect several bucket regions but will be represented only in one
of them. An advantage is that a spatial object can be kept in just one bucket. A
problem is that now the search needs to branch and follow several paths whenever
one is interested in a region lying in the overlap of two son regions. To keep search
efficient, it is crucial to minimize the overlap of node regions. This is determined
by the split strategy on overflow. Several strategies based on different heuristics
have been studied (Guttman, 1984; Greene, 1989; Beckmann et al., 1990); the latter
study proposed the R*-tree, which appeared to perform best in experiments.
Clipping. A variant of the R-tree, called R+-tree, was proposed by Sellis et al.
(1987) and Faloutsos et al. (1987), and was used in the PSQL database system
(Roussopoulos et al., 1988). It completely avoids overlapping regions associated
with buckets or internal nodes of the same level by clipping data rectangles, if
necessary~ ' '
In Figure 12, an R+-tree is shown for the same set of data rectangles as in Figure
11. Here the rectangles A, B, and C in the root are chosen a bit differently to keep
them, and therefore the three sons' bucket regions, disjoint. Now it is necessary
to clip rectangles D and J so that each of them is represented in two buckets.
Experimental comparisons of spatial index structures including R-tree variants can
be found in Greene (1989), Smith and Gao (1990), and Beckmann et al. (1990).
There has been a tremendous amount of work on spatial index structures, and
it is not possible to cover it completely in this survey. Other directions include
quadtree variants (surveyed in Samet, 1990), which are closely related to the grid
approximation schemes of Section 4.2.1, or cell trees (Giinther, 1988; Gfinther and
Bilmes, 1989), which do not store rectangles, but work with polygonal subdivisions
of the plane directly. An excellent survey of spatial index structures can be found
in Widmayer (1991). The article by Lin et al. in this special issue introduces the
TI."-tree, a data structure for indexing sets of points in a high-dimensional space,
which is somewhat similar to an R-tree (Lin et al., 1994). It is a good example
VLDB Journal 3 (4) Gfiting: An Introduction to Spatial Database Systems 383
Figure 12. Set of rectangles represented by R+-tree
IAIBIcl I
for the design and analysis techniques needed in the development of spatial index
structures as described in this section.
It should be clear now that spatial index structures, offering a few fundamental
query operations, can support selection with many different spatial predicates through
the filter and refine strategy. For example, a query for all regions in a partition adjacent
to a given region can be answered by checking candidates from an intersection query;
to find all regions within a certain distance from a query point, one can also find
candidates with an intersection query that uses a suitable square around the point.
The filter and refine strategy was extended by Brinkhoff et al. (1993a) to
include a second filter step with finer approximations than the bounding box; they
compared, for example, bounding ellipses, convex hulls, and convex 5-corners. These
are conservative approximations, which means they include the actual SDT values.
Better conservative approximations are able to exclude some false hits from further
consideration. In the second filter step one can also use progressive approximations,
which are contained in the actual SDT value, such as a maximum enclosed circle or
a maximum enclosed rectangle (Brinkott et al., 1994). These allow one to identify
hits; if two progressive approximations intersect, their SDT values are guaranteed
to intersect. The goal is to avoid, as far as possible, the expensive loading and
comparison of the exact geometries. It also was suggested to decompose very large
SDT values into several components so that checking the exact geometry can for
most queries be restricted to one of the components (Kriegel et al., 1991).
4.3 Supporting Spatial Join

Spatial join (Section 3.1) determines for two sets of spatial objects all objects in a
relationship described by a spatial predicate. Classical join methods such as hash
join or sort/merge join are not applicable. Filtering the cartesian product is possible
but too expensive. Central ideas for computing spatial joins are, again, the filter and
refine strategy, and the use of spatial index structures. One can classify proposed
strategies along the following criteria:
Grid approximation/bounding box
None/one/both operands are represented in a spatial index structure.
384
For grid approximations, and for an overlap predicate, Orenstein (1986) and Orenstein
and Manola (1988) described join algorithms to determine pairs of candidates.
Essentially, a parallel scan of the two sets of z-elements corresponding to the two
sets of spatial objects is performed, similar to a merge join for a < predicate.
Note that overlay, a particularly important operation for GISs, is a special case
(Orenstein, 1991). A general problem with grid approximations is that choosing
too fine a grid leads to inefficiency because too :many z-elements per object are
created, whereas a too rough grid may deliver too many "false hits" in a spatial
join (Orenstein, 1989).
If the filter step is based on the use of bounding boxes, then the problem is
to determine for two sets of rectangles R, S, all pairs (r, s), r C R, s C S, such that
r intersects s. If none of the operands is represented in a spatial index, a good
technique is to use a rectangle intersection algorithm from computational geometry,
which solves this problem precisely. Such an algorithm, called bb_join, has been
used in the Gral system (G~ting, 1989; Becker and GiJting, 1992). The basis is
an external divide-and-conquer algorithm (Becker and Giiting, 1992; GiJting and
Schilling, 1987), somewhat similar to external merge sorting. Note that even when
base object sets are represented in a spatial index, such a method is needed in
query processing (e.g., when the two operand sets have been determined through
other indexes, or are themselves the result of geometric set operations). This also
was emphasized by Lo and Ravishankar (1994), who suggested building an index
for one of the operands on the fly, and who described a new tree structure, seeded
trees, particularly suitable for this method.
If one operand is represented in a spatial index, then an index join or repeated
search join can be used (Becker and Giiting, 1992; Lo and Ravishankar, 1994). This
is a classical technique, usually used with a B-tree index, which can be applied equally
well to spatial index structures. Hence, if the "inner" operand is represented in an
index supporting rectangle intersection queries, one can scan the "outer" operand
set; for each object, the bounding box of its SDT attribute is used as a search
argument on the index. As a result one again obtains a set of candidate pairs with
intersecting rectangles. Repeated search join is especially efficient if the outer set
is not too big (e.g., it is the result of a selection from a large set). If both sets are
large, bb_join may be more efficient. Such choices have to be made by the query
optimizer.
Recent research into spatial join methods has focused on the case where both
operands have a spatial index. The basic idea is to perform a synchronized traversal
of the two index structures so that pairs of ceils whose respective partitions cover
the same part of space are encountered together. A parallel traversal of two grid
files was examined by Rotem (1991), Becker et al. (1993); of R-trees by Brinkhoff
et al. (1993b). Giinther (1993) studied traversal of generalization trees, which
can represent nested polygonal partitions directly but can also be viewed as a
generalization of R-trees, for example. He also derived cost formulas for several
distributions, and compared the cost of nested-loop join (i.e., filtering the cartesian
VLDB Journal 3 (4) GOring: An Introduction to Spatial Database Systems 385
product), tree traversal, and the use of join indexes.

The use of join indices (Valduriez, 1987) also has been applied to spatial joins. A
join index contains all pairs of object identifiers for objects from two sets in a given
relationship of interest. Rotem (1991) described the computation of a join index
from two grid files, which combines the pairs of points within distance c from each
other, and also the maintenance of such an index under grid file reorganizations.
A problem is that the index is based on some fixed distance and does not support
well queries with other distances. Lu and Han (1992) suggested some variations to
accomodate different distances. Unfortunately, if all distances are to be supported,
the join index will have a quadratic number of entries which is not feasible for large
sets of objects.
After the filter step, as for spatial selection, one can insert a second filter step
with better approximations to determine hits and exclude false hits from further
checking (Brinkhoff et al., 1994).
5. System Architecture
5.1 Requirements
At the system architecture level, the problem is to integrate the tools described
in Section 4 to support spatial data types--and more. In principle, the following
extensions to a standard architecture need to be accommodated:
representations for the data types of a spatial algebra,
procedures for the atomic operations,
spatial index structures,
access operations for spatial indexes,
filter and refine techniques,
spatial join algorithms,
cost functions for all these operations,
statistics for estimating selectivity of spatial selection and spatial join,
extensions of the optimizer to map queries into the specialized query pro-
cessing methods,
spatial data types and operations within data definition and query language,
user interface extensions to handle graphical representation and input of
SDT values.
In our view, the only clean way to accomodate these extensions is an integrated
architecture based on the use of an eextensible DBMS. Nevertheless, GISs have been
constructed before extensible DBMS technology was available, and we shall first
review previous approaches to GIS architecture.
386
5.2 GIS ArchitecturesmUsing a Closed DBMS
The first generation of GIS was built directly on top of file systems, and did not
offer the benefits of DBMSs such as high-level data definition, flexible querying,
and transaction management. They are not further discussed here. When DBMS
technology and, in particular, relational systems, became available, attempts were
made to use them as a basis. The two main approaches are layered architecture and
dual architecture (following the terminology of Vijlbrief and Oosterom, 1992; see
also Larue et al., 1993).
Layered Architecture. Here spatial functionality is implemented on top of a given

DBMS, often a commercially available relational sTstem, as shown in Figure 13.
There are two possible strategies for representing SDT values. The first, used
in early work, is to let each tuple represent the coordinates of one point or line
segment, and to break the SDT value into pieces (e.g., represent a polygon as a
subset of a line segment relation; Berman and Stonebraker, 1977; Chang and Fu,
1980). The disadvantage is that, for the implementation of SDT operations in the
top layer, the SDT values first have to be reconstructed, which is far too expensive.
The second possibility is to represent SDT values in "long fields" of the DBMS (e.g.,
GEOVIEW, Waugh and Healey, 1987; SIRO-DBMS, Abel, 1989). This is better
than breaking SDT values into pieces, but it is still problematic because the DBMS
handles the geometries only in the form of uninterpreted byte strings; evaluation
of any predicate or operation on an exact geometry can be done only in the top
layer. Some limited form of spatial indexing can be provided by maintaining sets
of z-elements (Section 4.2.1) for the geometries in special relations, which in turn
can be indexed through a B-tree.
DualArchitecture. Here a top layer integrates two rather independent subsystems:
the DBMS, which handles non-spatial data, and a spatial subsystem, which stores
and manipulates geometries (Figure 14).
With this approach, the representation of each spatial object (an object with
an SDT attribute) is broken into two pieces. The first part contains the non-spatial
attributes, and is stored in the DBMS. The second part is the spatial attribute,
and is kept in data structures implemented directly on top of the file system. The
two pieces are connected by logical pointers. This approach is followed by most
commercial GISs (e.g., ARC/INFO, Morehouse, 1989; SICAD, Schilcher, 1985) as
well as some research prototypes (e.g., Ooi et al., 1989).
An advantage is that one is free to use adequate representations of SDT values,
as well as efficient data structures and algorithms for indexing and query processing
within the spatial subsystem. For example, in Ooi et al. (1989) a spatial kd-tree (Ooi
et al., 1987) is used as an index structure. A problem is that a query now has to be
decomposed into a non-spatial part and a spatial part, to be handled by the DBMS
and the spatial subsystem, respectively. This complicates query processing and leads
to overhead. Perhaps the main problem is that no global query optimization is
Figure 13. Layered architecture
Spatial Tools
Standard DBMS
Figure 14. Dual architecture
Integration Layer
Standard DBMS Spatial Subsystem
possible. For example, if a query can be processed by using either an index on a

standard attribute or one on a spatial attribute, the integration layer cannot compare
the two plans since estimated costs from the standard DBMS are not available.
Query optimization under the dual architecture was studied by Ooi et al. (1989).
A different view of a dual architecture was taken by Aref and Samet (1991a).
Again, spatial and non-spatial parts of an object are stored in separate structures
and linked by logical pointers. However, the intention is not to use a standard
DBMS, but to be able to use specialized storage structures for the geometries,
and to implement the concept within one new database system. The consequences
of dealing in query processing with relations represented by two separate storage
structures were studied by Aref and Samet (1991b). The PSQL system (Roussopoulos
et al., 1988) has a similar dual architecture within an extended relational prototype.
5.3 Integrated Spatial DBMS Architecture--Using an Extensible DBMS
Research into extensible database systems (e.g., POSTGRES, Stonebraker and Rowe,
1986; Probe, Dayal et al., 1987; EXODUS, Graefe and DeWitt, 1987; GENESIS,
Batory et al., 1988; Gral, G/iting, 1989; Sabrina, Gardarin et al., 1989; Starburst,
Haas et al., 1989; DASDBS, Schek et al., 1990) was aimed at making precisely the
kinds of extensions required in Section 5.1 possible. The use of an extensible system
388
Figure 15. Integrated, extensible architecture
Extensible DBMS optimization rules

query processing methods
!i i
index structures
leads to an integrated architecture which takes the following view:

1. There is no difference in principle between a "standard" data type such as
STRING and a spatial data type such as REGION. This includes operations;
for example, there is no difference in principle between concatenating two
strings or forming the intersection of two regions. System architecture should
treat them in the same way.
2. There is no difference in principle between a clustering or secondary index
for standard attributes (e.g., a B-tree) and for spatial attributes (e.g., an
R-tree).
3. Similarly, a sort/merge join, and a bounding-box join, are basically the same.
4. The mechanisms for query optimization should not distinguish spatial or other
operations (of course, differences may be reflected in the cost functions).
Such an integrated architecture, in principle, also can be obtained by implementing

a new database system from scratch or by making appropriate extensions to the
code of a given DBMS. Using an extensible DBMS just vastly reduces the effort.
Furthermore, a spatial DBMS based on an extensible DBMS is open for extensions,
and so allows one to add missing functionality at any time. This is particularly
important because it is not known how to determine a closed, complete set of
operations of a spatial algebra, as discussed in Section 2.3.
The architecture of an extensible DBMS essentially offers slots and registration
facilities for nearly all the kinds of extensions listed in Section 5.1. An attempt to
illustrate this is given in Figure 15, where spatial components are shaded and only
a few of the places for extension are shown.
Several spatial DBMS prototypes based on extensible systems have been built,
examples are Probe (Orenstein, 1986; Orenstein and Manola, 1988), the DASDBS
VLDB Journal 3 (4) Gtiting: An Introduction to Spatial Database Systems 389
GEO-Kernel (Schek et al., 1990; Wolf, 1989), and Gral (G/.iting, 1989; Becker
and Gtiting, 1992). Possible uses of extensibility, in particular in the context of
the Starburst system, for spatial database applications were discussed by Haas and
Cody, 1991). More recent prototypes are G E O + + (van Oosterom and Vijlbrief,
1991; Vijlbrief and van Oosterom, 1992), based on POSTGRES, and G6oSabrina
(Larue et al., 1993), based on Sabrina.
In the Probe system (Orenstein, 1986; Orenstein and Manola, 1988), spatial data
types can be introduced as refinements (within an object-oriented class hierarchy)
of a general POINT-SET data type. For all such types, the system provides built-in
support in the form of approximate geometry processing. This means that SDT
values are represented by sets of z-elements (Section 4.2.1) and that the filter step
for spatial selections (i.e., spatial indexing) and spatial joins is offered in the system
kernel. Recall that this work was a major proponent of the filter and refine strategy
for spatial query processing (Orenstein and Manola, 1988).
Work in the DASDBS project (Schek et al., 1990; Wolf, 1989) has focused on
external data type (EDT) support and on interfacing to generic spatial access methods.
The EDT concept is a variant of data type extensibility assuming that data structures
for an EDT and procedures working on these data structures are probably not coded
specifically for the DBMS but rather have existed in an application environment long
before. The DBMS should be able to work with these given programming language
representations by using appropriate conversion functions. This has recently been
extended to let the DBMS cooperate with a "geometric computation service" (as
an implementation of a spatial algebra) over a network within different run-time
environments (Schek and Wolf, 1993). For spatial indexing, generic access methods
partitioning the data space into cells such as the grid file or the R+-tree are assumed;
to interface with such an access method, each SDT implementation has to offer a
clip and a compose function to determine the piece of the geometry falling into
one cell and to put pieces together again, respectively.
The Gral system (Giiting, 1989; Becker and G/Jting, 1992) emphasizes many-
sorted algebra as a formal basis for its extensible system architecture; it uses
such algebras to describe application-specific query languages and query processing
systems, and provides a rule-based optimizer which transforms a query algebra
expression to an executable expression by applying transformation rules. For spatial
indexing, LSD-trees (Section 4.2.2) are available; spatial joins are supported by
repeated search on LSD-trees or a bounding-box-join algorithm (Section 4.3). The
bounding box is the generic interface between any spatial data type and access
or join methods. The system treats spatial and non-spatial data quite uniformly;
Becker and Gtiting (1992) demonstrated completely integrated query optimization
and processing, as well as how filter and refine techniques are actually implemented
in the optimizer.
Note that extensibility of a system architecture is rather orthogonal to the data
model implemented by that architecture. For example, Probe offers an object-
oriented or functional data model, DASDBS offers a nested relational model, and
390
POSTGRES, Starburst, and Gral offer extended relational models. Object-oriented

systems have been considered as an implementation platform (e.g., David et al.,
1993). Such systems are extensible at the data type level. However, they generally
lack extensibility at the level of index structures, query processing methods (e.g. join
algorithms), or query optimization, which is crucial for spatial DBMS implementation.
Experiments with an object-oriented system and some of the arising problems have
been described by Scholl and Voisard (1991).
6. Final Remarks
In this survey, we have tried to coherently present the major technical concepts for
spatial database systems. To keep the task manageable, we treated spatial database
systems only in a restricted sense; image database systems have been excluded. Some
interesting work on image databases includes Joseph and Cardenas (1988), Chang
et al. (1991), and Gupta et al. (1991). Fortunately, several articles in this special
issue are related to image databases and therefore help to close the gap: Baumann
describes basic DBMS support for the management of raster data (Baumann, 1994);
Chu et al. show modeling and querying requirements and techniques for images
in medical applications (Chu et al., 1994); and Papadias and Sellis focus on the
management of abstractions of spatial relationships occurring in images (Papadias
and Sellis, 1994).
Another omission, perhaps, is that not much has been said about the various
kinds of applications. A good general source for case studies of GIS applications and
their requirements is the International Journal of Geographical Information Systems.
Such issues also are discussed at the biannual Symposia on Spatial Data Handling.
The SEQUOIA 2000 project (Stonebraker et al., 1993b) addressed the needs of
global change researchers, in particular the need to deal with terabytes of raster
data. Some idea of the requirements of medical applications can be gained from
the paper by Chu et al. in this issue.
There are two recent surveys related to spatial database systems that may
augment the one given here. Giinther and Buchmann (1990) focus more on open
research questions. The survey by Bauzer-Medeiros and Pires (1994) is closer to
GIS applications.
Many interesting issues related to spatial database systems could not be included
in this survey, for example:
spatio-temporal modeling,
spatial objects with imprecise boundaries,
multi-scale modeling/cartographic generalization,
data lineage (maintaining information about precision, collection method,
etc. of data),
spatial reasoning/deductive spatial databases,
performance benchmarks for spatial DBMS (Stonebraker et al., 1993a).
VLDB Journal 3 (4) G/iting: An Introduction to Spatial Database Systems 391
Integrating solutions to such problems with the spatial database technology described
here will remain a fascinating challenge for database researchers for quite some
time.
Acknowledgments
I thank Max Egenhofer, Andre Frank, Hans-J6rg Schek, and Timos Sellis, who
carefully read a draft version of this survey and provided many interesting and
useful comments.
References
Abdelmoty, A.I., Williams, M.H., and Paton, N.W. Deduction and deductive data-
bases for geographic data handling. Proceedings of the Third International Sympo-
sium on Large Spatial Databases, Singapore, 1993.
Abel, D.J. SIRO-DBMS: A database tool kit for geographical information systems.
International Journal of Geographical Information Systems, 3:103-116, 1989.
Abel, D.J. and Ooi, B.C., eds. Proceedings of the Third lnternational Symposium on
Large Spatial Databases, Singapore, 1993.
Abel, D.J. and Smith, J.L. A data structure and algorithm based on a linear key for
a rectangle retrieval problem. Computer Vision, Graphics, and Image Processing,
24:1-13, 1983.
Abiteboul, S. and Beeri, C. On the power of languages for the manipulation of
complex objects. Technical Report 846, Paris: INRIA, 1988.
Agrawal, R. ALPHA: An extension of relational algebra to express a class of recursive
queries. Proceedings of the IEEE Data Engineering Conference, Los Angeles, 1987.
Aref, W. and Samet, H. Extending a DBMS with spatial operations. Proceedings of
the Second International Symposium on Large Spatial Databases, Zfirich, 1991a.
Aref, W. and Samet, H. Optimization strategies for spatial query processing. Proceed-
ings of the Seventeenth International Conference on l~ry Large Data Bases, Barcelona,
1991b.
Bancilhon, E, Briggs, T., Khoshafian, S., and Valduriez, E FAD, a powerful and
simple database language. Proceedings of the Thirteenth International Conference
on l~ry Large Data Bases, Brighton, 1987.
Batory, D.S., Barnett, J.R., Garza, J.E, Smith, K.P., Tsukuda, K., Twichell, B.C.,
and Wise, T.E. GENESIS: An extensible database management system. 1EEE
Transactions on Software Engineering 14:1711-1730, 1988.
Baumann, P. Management of multidimensional discrete data. VLDB Journal, 3(4):401-
444, 1994.
Bauzer-Medeiros, C. and Pires, E Databases for GIS.ACMSIGMODRecord, 23:107-
115, 1994.
392
Becker, L. and Giiting, R.H. Rule-based optimization and query processing in an

extensible geometric database system. ACM Transactions on Database Systems,
17:247-303, 1992.
Becker, L., Hinrichs, K., and Finke, U. A new algorithm for computing joins with
grid files. Proceedings of the Ninth International Conference on Data Engineering,
Vienna, 1993.
Beckmann, N., Kriegel, H.P., Schneider, R., and Seeger, B. The R*-tree: An
efficient and robust access method for points and rectangles. Proceedings of the
ACMSIGMOD Conference, Atlantic City, NJ, 1990.
Bentley, J.L. Multidimensional binary search trees used for associative searching.
Communications of the ACM, 18:509-517, 1975.
Berman, R.R. and Stonebraker, M. GEO-QUEL: A system for the manipulation
and display of geographic data. Computer Graphics, 11:186-191, 1977.
Brinkhoff, T., Kriegel, H.P., and Schneider, R. Comparison of approximations of
complex objects used for approximation-based query processing in spatial database
systems. Proceedings of the Ninth International Conference on Data Engineering,
Vienna, 1993a.
Brinkhoff, T., Kriegel, H.P., and Seeger, B. Efficient processing of spatial joins using
R-trees. Proceedings of the ACM SIGMOD Conference, Washington, DC, 1993b.
Brinkhoff, T., Kriegel, H.P., Schneider, R., and Seeger, B. Multi-step processing of
spatial joins. Proceedings of the ACM SIGMOD Conference, Minneapolis, 1994.
Buchmann, A., Gfinther, O., Smith, T.R., and Wang, Y.E, eds. Proceedings of the
First International Symposium on Large Spatial Databases, Santa Barbara, 1989.
Chang, N.S., and Fu, K.S. A relational database system for images. In: Chang,
S.K. and Fu, K.S., eds., Pictorial Information Systems, Berlin: Springer, 1980, pp.
288-321.
Chang, S.K., Jungert, E., and Li, Y. The design of pictorial databases based upon the
theory of symbolic projections. Proceedings of the First International Symposium
on Large Spatial Databases, Santa Barbara, 1991.
Chu, WW, Ieong, I.T., and Taira, R.K. A semantic modeling approach for image
retrieval by content. VLDB Journal, 3(4):445-477, 1994.
Clementini, E., Di Felice, P., and van Oosterom, E A small set of formal topo-
logical relationships suitable for end-user interaction. Proceedings of the Third
International Symposium on Large Spatial Databases, Singapore, 1993.
Cruz, I.E, Mendelzon, A.O., and Wood, ET. A graphical query language supporting
recursion. Proceedings of the ACM SIGMOD Conference, 1987.
Cui, Z., Cohn, A.G., and Randell, D.A. Qualitative and topological relationships
in spatial databases. Proceedings of the Third International Symposium on Large
Spatial Databases, Singapore, 1993.
David, B., Raynal, L., Schorter, G., and Mansart, V. GeO2: Why objects in a
geographical DBMS? Proceedings of the Third International Symposium on Large
Spatial Databases, Singapore, 1993.
VLDB Journal 3 (4) G/iting: An Introduction to Spatial Database Systems 393
Dayal, U., Manola, E, Buchmann, A., Chakravarthy, U., Goldhirsch, D., Heiler, S.,
Orenstein, J., and Rosenthal, A. Simplifying complex objects: The PROBE ap-
proach to modelling and querying them. In: Schek, H.-J. and Schlageter, G., eds.,
Proceedings GI-Fachtagung Datenbanksysteme in Biiro, Technilg und Wissenschaft,
Darmstadt, 1987.
Dr6ge, G. and Schek, H.-J. Query-adaptive data space partitioning using variable-
size storage clusters. Proceedings of the Third International Symposium on Large
SpatiaI Databases, Singapore, 1993.
Dr6ge, G., Schek, H.-J., and Wolf, m. Erweiterbarkeit in DASDBS (Extensibility
in DASDBS). Informatik Forschung und Entwicklung, 5:162-176, 1990.
Egenhofer, M. A formal definition of binary topological relationships. Proceedings
of the Third International Conference on the Foundations of Data Organization and
Algorithms, Paris, 1989.
Egenhofer, M. Extending SQL for cartographic display. Cartographyand Geographic
Information Systems, 18:230-245, 1991a.
Egenhofer, M. Reasoning about binary topological relations. Proceedings of the
Second International Symposium on Large Spatial Databases, Zfirich, 1991b.
Egenhofer, M. Why not SQL! International Journal of Geographical Information Sys-
tems, 6:71-85, 1992.
Egenhofer, M. Spatial SQL: A query and presentation language. IEEE Transactions
on Knowledge and Data Engineering, 6:86-95, 1994.
Egenhofer, M. and Frank, A. Towards a spatial query language: User interface con-
siderations. Proceedings of the Fourteenth International Conference on l,~ryLarge
Data Bases, Los Angeles, 1988.
Egenhofer, M., Frank, A., and Jackson, J.P. A topological data model for spa-
tial databases. Proceedings of the First International Symposium on Large Spatial
Databases, Santa Barbara, 1989.
Egenhofer, M. and Herring, J. A mathematical framework for the definition of
topological relationships. Fourth International Symposium on Spatial Data Han-
dling, Zfirich, 1990.
Egenhofer, M. and Herring, J. Categorizing binary topological relationships between
regions, lines, and points in geographic databases. Technical Report. Department
of Surveying Engineering, University of Maine, Orono, ME, 1992.
Erwig, M. and G/iting, R.H. Explicit graphs in a functional model for spatial
databases. FernUniversitfit Hagen, Informatik-Report 110, 1991. To appear in
IEEE Transactions on Knowledge and Data Engineering.
Faloutsos, C., Sellis, T., and Roussopoulos, N. Analysis of object-oriented spatial
access methods. Proceedings of the ACM SIGMOD Conference, San Francisco,
1987.
Frank, A. Application of DBMS to land information systems. Proceedings of the
Seventh International Conference on VeryLarge Data Bases, Cannes, 1981.
Frank, A. MAPQUERY: Data base query language for retrieval of geometric data
and their graphical representation. Computer Graphics, 16:199-207, 1982.
394
Frank, A. Overlay processing in spatial information systems. Proceedings of the

Eighth International Symposium on Computer-Assisted Cartography (Auto-Carto 8),
Baltimore, MD, 1988.
Frank, A. Properties of geographic data: Requirements for spatial access meth-
ods. Proceedings of the Second International Symposium on Large Spatial Databases,
Z/.irich, 1991.
Frank, A. Qualitative spatial reasoning about distances and directions in geographic
space. Journal of Visual Languages and Computing; 3:343-371, 1992.
Frank, A. and Kuhn, W. Cell graphs: A provable ,correct method for the storage
of geometry. Proceedings of the Second International Symposium on Spatial Data
Handling, Seattle, 1986.
Franklin, W.R. Cartographic errors symptomatic of underlying algebra problems.
Proceedings of the First International Symposium on Spatial Data Handling; Zfirich,
1984.
Freeman, H. and Ahn, J. On the problem of placing names in a geographic map.
International Journal on Pattern Recognition and Artificial Intelligence, 1:121-140,
1987.
Freeston, M.W. The BANG file: A new kind of grid file. Proceedings oftheACM
SIGMOD Conference, San Francisco, 1987.
Freksa, C. Qualitative spatial reasoning. In: Mark, D.M. and Frank, A., eds,
Cognitive and Linguistic Aspects of Geographic Space, Dordrecht: Kluwer, 1991.
Gardarin, G., Cheiney, J.E, Kiernan, G., Pastre, D., and Stora, H. Managing complex
objects in an extensible relational DBMS. Proceedings of the Fifteenth International
Conference on VeryLarge Data Bases, Amsterdam, 1989.
Gargano, M., Nardelli, E., and Talamo, M. Abstract data types for the logical
modeling of complex data. Information Systems, 16:565-584, 1991.
Gargantini, I. An effective way to represent quadtrees. Communications oftheACM,
25:905-910, 1982.
Graefe, G. and DeWitt, D.J. The EXODUS optimizer generator. Proceedings of the
ACMSIGMOD Conference, San Francisco, 1987.
Greene, D. An implementation and performance analysis of spatial data access
methods. Proceedings of the Fifth International Conference on Data Engineering;
Los Angeles, 1989.
Greene, D. and Yao, E Finite-resolution computational geometry. Proceedings of
the Twenty-Seventh IEEE Symposium on Foundations of Computer Science, Toronto,
1986.
Gfinther, O. Efficient structures for geometric data management. Lecture Notes in
Computer Science 337, Springer, 1988.
G/inther, O. Efficient computation of spatial joins. Proceedings of the Ninth Interna-
tional Conference on Data Engineering; Vienna, 1993.
Giinther, O. and Bilmes, J. The implementation of the cell tree: Design alternatives
and performance evaluation. Proceedings of the GI-Fachtagung Datenbanksysteme
in Biiro, Technik und Wissenschaft, Informatik-FacJ~berichte, 1989.
VLDB Journal 3 (4) Gfiting: An Introduction to Spatial Database Systems 395
Giinther, O. and Buchmann, A. Research issues in spatial databases. ACMSIGMOD

Record, 19:61-68, 1990.
Giinther, O. and Schek, H.-J., eds. Proceedingsof the Second International Symposium
on Large Spatial Databases, Z/irich, 1991.
Gtiting, R.H. Geo-relational algebra: A model and query language for geometric
database systems. In: Schmidt, J.W., Ceri, S., and Missikoff, M., eds., Proceedings
of the International Conference on Extending Database Technology, Venice, 1988.
Gfiting, R.H. Gral: An extensible relational database system for geometric appli-
cations. Proceedings of the Fifteenth International Conference on l.~ry Large Data
Bases, Amsterdam, 1989.
Gfiting, R.H. Second-order signature: A tool for specifying data models, query pro-
cessing, and optimization. Proceedings of the ACM SIGMOD Conference, Wash-
ington, DC, 1993.
Gfiting, R.H. GraphDB: A data model and query language for graphs in databases.
Fernuniversit/it Hagen, Informatik-Report 155, 1994 (submitted for publication).
Short version entitled "GraphDB: Modeling and querying graphs in databases,"
Proceedings of the TwentiethInternational Conference on VeryLarge Data Bases, San-
tiago, Chile, 1994.
Gfiting, R.H. and Schilling, W. A practical divide-and-conquer algorithm for the
rectangle intersection problem. Information Sciences, 42:95-112, 1987.
Gfiting, R.H. and Schneider, M. Realms: A foundation for spatial data types
in database systems. Proceedings of the Third International Symposium on Large
Spatial Databases, Singapore, 1993a.
Gfiting, R.H. and Schneider, M. Realm-based spatial data types: The ROSE algebra.
Fernuniversit/it Hagen, Report 141, 1993b.
G/iting, R.H., Zicari, R., and Choy, D.M. An algebra for structured office documents.
ACM Transactions on Information Systems, 7:123-157, 1989.
Gupta, A., Weymouth, T., and Jain, R. Semantic queries with pictures: The VIMSYS
model. Proceedings of the Seventeenth International Conference on l~ry Large Data
Bases, Barcelona, 1991.
Guttmann, R. R-trees: A dynamic index structure for spatial searching. Proceedings
oftheACMSIGMOD Conference, Boston, MA, 1984.
Gyssens, M., Paredaens, J., and van Gucht, D. A graph-oriented object data-
base model. Proceedings of the ACM Conference on Principles of Database Systems,
Nashville, TN, 1990.
Haas, L.M. and Cody, W.E Exploiting extensible DBMS in integrated geographic
information systems. Proceedings of the Second International Symposium on Large
SpatialDatabases, Ziirich, 1991.
Haas, L.M., Freytag, J.C., Lohman, G.M., and Pirahesh, H. Extensible query pro-
cessing in Starburst. Proceedings oftheACMSIGMOD, Portland, OR, 1989.
Henrich, A., Six, H.-W., and Widmayer, E The LSD-tree: Spatial access to multidi-
mensional point- and non-point-objects. Proceedings of the Fifteenth International
Conference on l~ry Large Data Bases, Amsterdam, 1989.
396
Herring, J., Larsen, R., and Shivakumar, J. Extensions to the SQL language to
support spatial analysis in a topological data base. Proceedings of GIS/LIS, San
Antonio, TX, 1988.
Hinrichs, K. The grid file system: Implementation and case studies of applications.
Doctoral thesis, ETH Zfirich, 1985.
de Hoop, S. and van Oosterom, P. Storage and manipulation of topology in Postgres.
Proceedings of the Third European Conference on Geographical Information Systems,
Miinchen, 1992.
Joseph, T. and Cardenas, A. PICQUERY: A high level query language for pictorial
database management. IEEE Transactions on Software Engineering~ 14:630-638,
1988.
Keating, T., Phillips, W., and Ingrain, K. An integrated topological database design
for geographic information systems. Photogrammetric Engineering and Remote
Sensing~ 53:1399-1402, 1987.
Kriegel, H.P., Horn, H., and Schiwietz, M. The performance of object decomposition
techniques for spatial query processing. Proceedings of the Second International
Symposium on Large Spatial Databases, Z/irich, 1991.
Larue, T., Pastre, D., and Vi6mont, Y. Strong integration of spatial domains and
operators in a relational database system. Proceedings of the Third International
Symposium on Large Spatial Databases, Singapore, 1993.
Lin, K.I., The TV-tree: An index structure for high-dimensional data. VLDBJournal,
3(4): 519-544, 1994.
Lipeck, U. and Neumann, K. Modelling and manipulating objects in geoscien-
tific databases. Proceedings of the Fifth International Conference on the Entity-
Relationship Approach, Dijon, France, 1987.
Lo, M.L. and Ravishankar, C.V. Spatial joins using seeded trees. Proceedings of the
ACM SIGMOD Conference, Minneapolis, MN, 1994.
Lomet, D.B. and Salzberg, B. A robust multi-attribute search structure. Proceedings
of the Fifth International Conference on Data Engineering, Los Angeles, 1989.
Lu, W. and Hun, J. Distance-associated join indices for spatial range search. Pro-
ceedings of the Ninth International Conference on Data Engineerin& Vienna, 1992.
Maingenaud, M. and Portier, M. Cigales: A graphical query language for geo-
graphical information systems. Proceedings of the Fourth International Symposium
on Spatial Data Handling, Ziirich, 1990.
Mantey, P.E. and Carlson, E.D. Integrated geographic data bases: The GADS
experience. In: Blaser, A., ed., Data Base Techniques for Pictorial Applications.
Berlin: Springer, 1980, pp. 173-198.
Mehlhorn, K. Data Structures and Algorithms 3: Multidimensional Searching and Com-
putational Geometry. Berlin: Springer, 1984.
Meyer, B. Beyond icons: Towards new metaphors for visual query languages for
spatial information systems. In: Cooper, R., ed. Interfaces to Database Systems.
Berlin: Springer, 1992.
Morehouse, S. The architecture of ARC/INFO. Proceedings of the Auto-Carto 9,

Baltimore, MD, 1989.
Morton, G.M. A Computer Oriented Geodetic Data Base and a New Technique in File
Sequencing. IBM Ltd., Ottawa, Canada, 1966.
Nievergelt, J., Hinterberger, H., and Sevcik, K.C. The grid file: An adaptable,
symmetric multikey file structure. A C M Transactions on Database Systems, 9:38-
71, 1984.
Nievergelt, J. and Preparata, EP. Plane-sweep algorithms for intersecting geometric
figures. Communications oftheACM, 25:739-747, 1982.
Ooi, B.C., McDonell, K.J., and Sacks-Davis, R. Spatial kd-tree: An indexing mecha-
nism for spatial databases. Proceedings of the IEEE COMPSAC Conference, Tokyo,
1987.
Ooi, B.C., Sacks-Davis, R., and McDonell, K.J. Extending a DBMS for geographic
applications. Proceedings of the Fifth International Conference on Data Engineering,
Los Angeles, 1989.
van Oosterom, E and Vijlbrief, T. Building a GIS on top of the open DBMS
POSTGRES. Proceedings of the Second European Conference on Geographical In-
formation Systems, Brussels, 1991.
Orenstein, J.A. Spatial query processing in an object-oriented database system.
Proceedings of the A C M SIGMOD Conference, Washington, DC, 1986.
Orenstein, J.A. Strategies for optimizing the use of redundancy in spatial databases.
Proceedings of the First International Symposium on Large Spatial Databases, Santa
Barbara, 1989.
Orenstein, J.A. An algorithm for computing the overlay of k-dimensional spaces. Pro-
ceedings of the Second lnternational Symposium on Large Spatial Databases, ZUrich,
1991.
Orenstein, J.A. and Manola, E PROBE spatial data modeling and query processing
in an image database application. IEEE Transactions on Software Engineering,
14:611-629, 1988.
Osborn, S.L. and Heaven, T.E. The design of a relational database system with
abstract data types for domains. A C M Transactions on Database Systems, 11:357-
373, 1986.
Pagel, B.U., Six, H.W., and Toben, H. The transformation technique for spatial
objects revisited. Proceedings of the Third lnternational Symposium on Large Spatial
Databases, Singapore, 1993.
Papadias, D. and Sellis, T. Qualitative representation of spatial knowledge in two-
dimensional space. VLDB Journal, 3(4):479-517, 1994.
Preparata, EP. and Shamos, M.I. Computational Geometry: An Introduction. Berlin:
Springer, 1985.
Pullar, D. and Egenhofer, M. Towards formal definitions of topological relations
among spatial objects. Proceedings of the Third International Symposium on Spatial
Data Handling; Sydney, 1988.
398
de Ridder, T Die ROSE-Algebra: Implementierung geometrischer Datentypen und

Operationen for erweiterbare Datenbanksysteme (The ROSE algebra: Imple-
mentation of geometric data types and operations for extensible database systems).
Fernuniversit/it Hagen, Fachbereich Informatik, Diplomarbeit (Master's Thesis),
1994.
Robinson, J.T The KDB-tree: A search structure for large multidimensional dynamic
indexes. Proceedings of the ACM SIGMOD Conj~rrence, Ann Arbor, MI, 1981.
Rosenthal, A., Heiler, S., Dayal, U., and Manola, E Traversal recursion: A practical
approach to supporting recursive applications. Proceedings oftheACMSIGMOD
Conference, Washington, DC, 1986.
Roussopoulos, N., Faloutsos, C., and Sellis, T An efficient pictorial database system
for PSQL. IEEE Transactions on Software Engineering; 14:639-650, 1988.
Rotem, D. Spatial Join indices. Proceedings of the Seventh International Conference
on Data Engineering; Kobe, Japan, 1991.
Samet, H. The Design andAnalysis of SpatiaI Data Structures. Reading, MA: Addison-
Wesley, 1990.
Schek, H.-J., Paul, H.B., Scholl, M.H., and Weikum, G. The DASDBS project:
Objectives, experiences, and future prospects. 1EEE Transactions on Knowledge
and Data Engineering, 2:25-43, 1990.
Schek, H.-J. and Wolf, A. From extensible databases to interoperability between
multiple databases and GIS applications. Proceedings of the Third International
Symposium on Large Spatial Databases, Singapore, 1993.
Schilcher, M. Interactive graphic data processing in cartography. Computers &
Graphics, 9:57-66, 1985.
Scholl, M. and Voisard, A. Thematic map modeling. Proceedings of the First Inter-
national Symposium on Large Spatial Databases, Santa Barbara, 1989.
Scholl, M. and Voisard, A. Object-oriented database systems for geographic ap-
plications: An experiment with 02. In: Gambosi, G., Six, H., and Scholl, M.,
eds., Proceedings of the International Workshop on Database Management Systems
for GeographicaIApplications, Capri, 1991.
Seeger, B. and Kriegel, H.E Techniques for design and implementation of efficient
spatial access methods. Proceedings of the Fourteenth International Conference on
l,~ty Large Data Bases, Los Angeles, 1988.
Seeger, B. and Kriegel, H.E The buddy-tree: An efficient and robust access method
for spatial database systems. Proceedings of the Sixteenth International Conference
on Vely Large Data Bases, Brisbane, Australia, 1990.
Sellis, T, Roussopoulos, N., and Faloutsos, C. The R+-tree: A dynamic index for
multi-dimensional objects. Proceedings of the Thirteenth International Conference
on VeryLarge Data Bases, Brighton, 1987.
VLDB Journal 3 (4) Gtiting: An Introduction to Spatial Database Systems 399
Smith, T.R. and Gao, R Experimental performance evaluations on spatial access

methods. Proceedings of the Fourth International Symposium on Spatial Data Han-
dling, Zfirich, 1990.
Smith, T.R., Menon, S., Star, J.L., and Estes, J.E. Requirements and principles
for the implementation and construction of large-scale geographic information
systems. InternationaI Journal of Geographical lnformation Systems, 1:13-31, 1987.
Stonebraker, M., Frew, J., Gardels, K., and Meredith, J. The Sequoia 2000 stor-
age benchmark. Proceedings of the ACM SIGMOD Conference, Washington, DC,
1993a.
Stonebraker, M., Frew, J., and Dozier, J. The SEQUOIA 2000 project. Proceedings
of the Third International Symposium on Large SpatiaI Databases, Singapore, 1993b.
Stonebraker, M. and Rowe, L.A. The design of POSTGRES. Proceedings of the
SIGMOD Conference, Washington, DC, 1986.
Stonebraker, M., Rubenstein, B., and Guttmann, A. Application of abstract data
types and abstract indices to CAD databases. Proceedings oftheACMEngineering
Design Applications Conference, San Jose, CA, 1983.
Svensson, E and Huang, Z. Geo-SAL: A query language for spatial data analy-
sis. Proceedings of the Second International Symposium on Large Spatial Databases,
Zfirich, 1991.
Tamminen, M. The extendible cell method for closest point problems. BIT, 22:27-41,
1982.
Tomlin, C.D. GeographicInformation Systems and Cartographic Modeling. Englewood
Cliffs, NJ: Prentice-Hall, 1990.
Valduriez, R Join indices. ACM Transactions on Database Systems, 12:218-246, 1987.
Vijlbrief, T. and van Oosterom, E The GEO+ + system: An extensible GIS. Pro-
ceedings of the Fifth International Symposium on Spatial Data Handling, Charleston,
SC, 1992.
Voisard, A. Towards a toolbox for geographic user interfaces. Proceedings of the
Second International Symposium on Large Spatial Databases, Zfirich, 1991.
Waugh, TC. and Healey, R.G. The GEOVIEW design: A relational data base
approach to geographical data handling. International Journal of Geographical
Information Systems, 1:101-118, 1987.
Widmayer, R Datenstrukturen f/Jr Geodatenbanken (data structures for spatial
databases). In: Vossen, G., ed. Entwicklungstendenzen bei Datenbanksystemen.
Mfinchen: Oldenbourg, 1991, pp. 317-361.
Wilms, RE, Schwarz, P.M., Schek, H.-J., and Haas, L.M. Incorporating data types
in an extensible database architecture. Proceedings of the Third International
Conference on Data and Knowledge Bases, Jerusalem, 1988.
Wolf, A. The DASDBS Geo-kernel: Concepts, experiences, and the second step.
Proceedings of the First International Symposium on Large Spatial Databases, Santa
Barbara, 1989.
Worboys, M.E A generic model for planar geographical objects. International Journal
of Geographical Information Systems, 6:353-372, 1992.

56453-An Introduction To Spatial Database PDF

Uploaded by

Copyright:

Available Formats

56453-An Introduction To Spatial Database PDF

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

56453-An Introduction To Spatial Database PDF

Uploaded by

Copyright:

Available Formats

VLDBJournal,3,357-399(1994), Invited contribution,Hans-J.

Schek, Editor 357

An Introduction to Spatial Database Systems

Ralf Hartmut GQting

Received July 25, 1994; accepted August 18, 1994.

Abstract. We propose a definition of a spatial database system as a database sys-

1. What is a Spatial Database System?

Ralf Hartmut Gating, Dr.rer.nat, is Professor,Praktische InformatikIV, FernUniversit/itHagen, D-58084

Figure 1. Three basic abstractions: point, line, and region

2.2 Organizing the Underlying Space: Discrete Geometric Bases

Figure 3. Two simplicial complexes

in modeling, these problems are left to the implementor of a spatial DBMS,

2.3 Spatial Data Types

operations; for each of them we show a few examples:

(1) Spatial predicates expressing topological relationships:

geo regions ~ bool inside

(4) Spatial operations on sets of objects:

set(obj) X ( o b j - - ~ g e o l ) x geo2 ~ set(obj) closest

2.4 Spatial Relationships

Topological relationships, such as adjacent, inside, and disjoint, are invariant

Table 1. Enumerating topological relationships by intersections

2.5 Integrating Geometry into the DBMS Data Model

Lipeck and Neumann (1987) integrated SDTs into an extended ER model;

3.1 Fundamental Operations (Algebra)

3.2 Graphical Input and Output

These requirements, in general, can be fulfilled by offering textual commands in

the textual representation of a collection of objects, containing the alphanumeric

3.3 Integrating Geometry into a Query Language

Denoting SDT values~graphical input. In traditional query languages, constants in

Expressing the four classes of fundamental operations. Obviously, expressing spatial

Describing the presentation of results. It is arguable whether this should be part of a

4. Tools for Spatial DBMS Implementation

4.1 Representing SDT Values/Implementing Atomic SDT Operations

in files, outside of the DBMS storage management. However, there seems to be

4.2 Spatial IndexingmSupporting Spatial Selection

Figure 5. Bounding box and grid approximations of SDT value

Figure 6. A kd-tree partitioning of a 2-D space

Nearest neighbor: Find the point closest to a query point.

Figure 7. z-order enumeration of cells of hierarchical partition

Figure 8. A set of z-elements approximating an SDT value

Figure 9. Structure of the grid file

4.2.3 Spatial Index Structures for Rectangles. The management of rectangles in

Figure 10. Transformation approach, mapping intervals into 2-D points

Clipping: Partitioning space is kept; if a rectangle intersects partition bound-

Figure 11. Set of rectangles represented by R-tree

Figure 12. Set of rectangles represented by R+-tree

4.3 Supporting Spatial Join

product), tree traversal, and the use of join indexes.

5.2 GIS ArchitecturesmUsing a Closed DBMS

Layered Architecture. Here spatial functionality is implemented on top of a given

Figure 13. Layered architecture

Figure 14. Dual architecture

Standard DBMS Spatial Subsystem

possible. For example, if a query can be processed by using either an index on a

5.3 Integrated Spatial DBMS Architecture--Using an Extensible DBMS

Figure 15. Integrated, extensible architecture

Extensible DBMS optimization rules

leads to an integrated architecture which takes the following view:

Such an integrated architecture, in principle, also can be obtained by implementing