• TABLE OF CONTENTS
HIDE
 Abstract
 Main






Group Title: Department of Computer and Information Science and Engineering Technical Reports
Title: Efficient implementation techniques for topological predicates on complex spatial objects : the exploration phase
CITATION PDF VIEWER THUMBNAILS PAGE IMAGE ZOOMABLE
Full Citation
STANDARD VIEW MARC VIEW
Permanent Link: http://ufdc.ufl.edu/UF00095645/00001
 Material Information
Title: Efficient implementation techniques for topological predicates on complex spatial objects : the exploration phase
Alternate Title: Department of Computer and Information Science and Engineering Technical Report
Physical Description: Book
Language: English
Creator: Schneider, Markus
Praing, Reasey
Publisher: Department of Computer and Information Science and Engineering, University of Florida
Place of Publication: Gainesville, Fla.
Copyright Date: 2007
 Record Information
Bibliographic ID: UF00095645
Volume ID: VID00001
Source Institution: University of Florida
Holding Location: University of Florida
Rights Management: All rights reserved by the source institution and holding location.

Downloads

This item has the following downloads:

2007294 ( PDF )


Table of Contents
    Abstract
        Abstract
    Main
        Page 1
        Page 2
        Page 3
        Page 4
        Page 5
        Page 6
        Page 7
        Page 8
        Page 9
        Page 10
        Page 11
        Page 12
        Page 13
        Page 14
        Page 15
        Page 16
        Page 17
        Page 18
        Page 19
        Page 20
        Page 21
        Page 22
        Page 23
        Page 24
        Page 25
        Page 26
        Page 27
        Page 28
        Page 29
        Page 30
        Page 31
        Page 32
Full Text







Efficient Implementation Techniques for

Topological Predicates on Complex Spatial Objects:

The Exploration Phase

Markus Schneider* & Reasey Praing

University of Florida
Department of Computer & Information Science & Engineering
Gainesville, FL 32611, USA
{mschneid, rpraing}@cise.ufl.edu



Abstract
Topological predicates between spatial objects have for a long time been a focus of research in a number
of disciplines like artificial intelligence, cognitive science, linguistics, robotics, and spatial reasoning.
Especially as predicates, they support the design of suitable query languages for spatial data retrieval
and analysis in spatial database systems and geographical information systems. While, to a large ex-
tent, conceptual aspects of topological predicates (like their definition and reasoning with them) as well
as strategies for avoiding unnecessary or repetitive predicate evaluations (like predicate migration and
spatial index structures) have been emphasized, the development of robust and efficient implementation
techniques for them has been rather neglected. Recently, the design of topological predicates for different
combinations of complex spatial data types has led to a large increase of their numbers and accentuated
the need for their efficient implementation. The goal of this article is to develop efficient implementa-
tion techniques of topological predicates for all combinations of the complex spatial data types point2D,
line2D, and region2D within the framework of the spatial algebra SPAL2D. Our solution is a two-phase
approach. In the exploration phase, for a given scene of two spatial objects, all topological events are
recorded in two precisely defined topological feature vectors (one for each argument of a topological
predicate) whose specifications are characteristic and unique for each combination of spatial data types.
These vectors serve as input for the evaluation phase which analyzes the topological events and deter-
mines the Boolean result of a topological predicate or the kind of topological predicate. This paper puts
an emphasis on the exploration phase and in addition presents a first, simple evaluation method.

*This work was partially supported by the National Science Foundation (NSF) under grant number NSF-CAREER-IIS-0347574.








1 Introduction


Topological predicates (like overlap, meet, inside) between spatial objects (like points, lines, regions) have
always been a main area of research on spatial data handling, reasoning, and query languages in a number
of disciplines like artificial intelligence, linguistics, robotics, and cognitive science. They characterize the
relative position between two (or more) objects in space, deliberately exclude any consideration of quanti-
tative, metric measures like distance or direction measures, and are associated with notions like adjacency,
coincidence, connectivity, inclusion, and continuity. In particular, they support the design of suitable query
languages for spatial data retrieval and analysis in geographical information systems and spatial database
systems. The focus of this research has been on the conceptual design of and reasoning with these predicates
as well as on strategies for avoiding unnecessary or repetitive predicate evaluations. The two central concep-
tual approaches, upon which almost all publications in this field have been based and which have produced
very similar results, are the 9-intersection model [17] and the RCC model [11]. Until recently, topological
predicates have only been defined for simple spatial objects. In this article, we are especially interested in
topological predicates for complex spatial objects, as they have been recently specified in [45] on the basis
of the 9-intersection model.
In contrast to the large amount of conceptual work, implementation issues for topological predicates
have been widely neglected. Since topological predicates are expensive predicates that cannot be evaluated
in constant time, the strategy in query plans has consequently been to avoid their computation. The exten-
sive work on spatial index structures as a filtering technique in query processing is an important example
of this strategy. It aims at identifying a hopefully small collection of candidate pairs of spatial objects that
could possibly fulfil the predicate of interest and at excluding a large collection of pairs of spatial objects
that definitely cannot satisfy the predicate. The main reason for neglecting the implementation issue of topo-
logical predicates in the literature is probably the simplifying view that some plane-sweep [38] algorithm
is sufficient to implement topological predicates. Certainly, the plane sweep paradigm plays an important
role for the implementation of these predicates, but there are at least three aspects that make such an imple-
mentation much more challenging. A first aspect refers to the details of the plane sweep itself. Issues are
whether each topological predicate implementation necessarily requires an own, tailored plane sweep algo-
rithm, how the plane sweep processes complex instead of simple spatial objects, whether spatial objects have
been preprocessed in the sense that their intersections have been computed in advance (e.g., by employing a
realm-based approach [27]), how intersections are handled, and what kind of information the plane sweep
must output so that this information can be leveraged for predicate evaluation. A second aspect is that the
number of topological predicates increases to a large extent with the transition from simple to complex spa-
tial objects [45]. The two implementation alternatives of a single, specialized algorithm for each predicate
or a single algorithm for all predicates with an exhaustive case analysis are error-prone, inappropriate, and
thus unacceptable options from a correctness and a performance point of view. A third aspect deals with the
kind of query posed. This has impact on the evaluation process. Given two objects A and B of any complex
spatial data type point2D, line2D, or region2D [41], we can pose at least two kinds of topological queries:
(1) "Do A and B satisfy the topological predicate p?" and (2) "What is the topological predicate p between
A and B?". Only query 1 yields a Boolean value, and we call it hence a verification query. Query 2 returns
a predicate (name), and we call it hence a determination query.
The goal of this (and a follow-up) article is to develop and present efficient implementation strategies
for topological predicates between all combinations of the three complex spatial data types point2D, line2D,
and region2D within the framework of the spatial algebra SPAL2D. We distinguish two phases of predicate
execution: In an exploration phase, a plane sweep scans a given configuration of two spatial objects, detects
all topological events (like intersections), and records them in so-called topological feature vectors. These
vectors serve as input for the evaluation phase which analyzes these topological data and determines the
Boolean result of a topological predicate (query 1) or the kind of topological predicate (query 2). This








paper puts an emphasis on the exploration phase and in addition presents a simple evaluation method. A
follow-up article [37] deals in detail with improved and efficient methods for the evaluation phase. The two-
phase approach provides a direct and sound interaction and synergy between conceptual work (9-intersection
model) and implementation (algorithmic design).
The special goals of the exploration phase explain the introduction of topological feature vectors. The
design of individualized, ad hoc algorithms for each topological predicate of each spatial data type com-
bination turns out to be very cumbersome and error-prone and raises correctness issues. To avoid these
problems, we propagate a systematic exploration approach which identifies all topological events that are
possible for a particular type combination. These possible topological events are stored in two precisely
defined topological feature vectors (one for each argument object of the topological predicate) whose spec-
ifications are characteristic and thus unique for each type combination. However, the specification of the
topological feature vector of a particular spatial data type is different in different type combinations. The
exploration approach leads to very reliable and robust predicate implementations and forms a sound basis
for the subsequent evaluation phase. Further goals of the exploration phase are the treatment of complex
and not only simple spatial objects and an integrated handling of general and realm-based spatial objects.
Section 2 discusses related work about spatial data types as well as available design and implementa-
tion concepts for topological predicates. In Section 3, we present the data structures used for all spatial
data types in SPAL2D. Section 4 sketches some basic algorithmic concepts needed for the exploration algo-
rithms. Section 5 deals with the exploration phase for collecting topological information on the basis of the
plane sweep paradigm. It introduces a collection of exploration clg. ,, ,iii\, one for each type combination.
The algorithms extract the needed topological information from a given scene of two spatial objects and
determine the topological feature vectors that are specific to each type combination. We also determine the
runtime complexity of each algorithm in Big-O notation. Section 6 gives a first, simple evaluation method
leveraging topological feature vectors. In Section 7, we provide a brief overview of the implementation en-
vironment and present our testing strategy of the topological feature vectors. Since we are not aware of any
other, published implementation description of topological predicates to compare with, we do not provide
an empirical performance analysis. Finally, Section 8 draws some conclusions and discusses future work.


2 Related Work

In this section we present related work on spatial objects as the operands of topological predicates (Sec-
tion 2.1), sketch briefly the essential conceptual models for topological predicates (Section 2.2), and discuss
implementation aspects of topological predicates (Section 2.3).

2.1 Spatial Objects

In the past, numerous data models and query languages for spatial data have been proposed with the aim of
formulating and processing spatial queries in databases and GIS (e.g., [15, 25, 27, 36, 40, 41]). Sp'l,,, l data
types (see [41] for a survey) like point, line, or region are the central concept of these approaches. They
provide fundamental abstractions for modeling the structure of geometric entities, their relationships, prop-
erties, and operations. Topological predicates operate on instances of these data types, called spatial objects.
Until recently, these predicates have only been defined for simple object structures like single points, contin-
uous lines, and simple regions (Figure 1(a)-(c)). However, it is broad consensus that these simple geometric
structures are inadequate abstractions for real spatial applications since they are insufficient to cope with
the variety and complexity of geographic reality. Consequently, universal and versatile type specifications
are needed for (more) complex spatial objects so that they are usable in many different applications. With
regard to complex points (Figure l(d)), we allow finite collections of single points as point objects (e.g., to
gather the positions of all lighthouses in the U.S.). With regard to complex lines (Figure l(e)), we permit











o

(a) (b) (c) (d) (e) (f)

Figure 1: Examples of a simple point object (a), a simple line object (b), a simple region object (c), a
complex point object (d), a complex line object (e), and a complex region object (f).

arbitrary, finite collections of one-dimensional curves, i.e., spatially embedded networks possibly consisting
of several disjoint connected components, as line objects (e.g., to model the ramifications of the Nile Delta).
With regard to complex regions (Figure l(f)), the two main extensions relate to separations of the exterior
(holes) and to separations of the interior (multiple components). For example, countries (like Italy) can be
made up of multiple components (like the mainland and the offshore islands) and can have holes (like the
Vatican). From a formal point of view, spatial data types should be closed under the geometric operations
union, :il/ L i, i,,, and difference. This is guaranteed for complex but not for simple spatial data types. Our
formal specification of complex spatial data types given in [45] generalizes the definitions that can be found
in the literature, rests on point set theory and point set topology [23], and is the basis of our spatial data type
implementation. We call this specification the abstract model of our spatial type system SPAL2D.
So far, only a few models have been developed for complex spatial objects. The works in [6, 26, 27, 46]
are the only formal approaches; they all share a number of structural features with our type specifications
in [45]. The OpenGIS Consortium (OGC) has proposed geometric structures called simple features in their
OGC Abstract Specification [33] and in their Geography Markup Language (GML) [34], which is an XML
encoding for the transport and storage of geographic information. These geometric structures are similar
to ours but only described informally and called MultiPoint, Mi il ,,i. Siring, and MultiPolygon. Another
spatial data type specification is provided by ESRI's Spatial Database Engine (ArcSDE) [22]. It is also
similar to ours but only informally described. Its importance comes from the fact that several database
vendors have more or less integrated ArcSDE functionality into their spatial extension packages through
extensibility mechanisms. Examples are the Informix Geodetic DataBlade [31], the Oracle Spatial Cartridge
[35], and DB2's Spatial Extender [12].
Our main interest regarding complex spatial data types in this article relates to the development of effec-
tive geometric data structures that are able to support the efficient implementation of topological predicates.
Descriptions of such data structures for spatial data types are rare. We partially borrow concepts from the
implementation of the ROSE algebra [28] but generalize these concepts in the sense that we accommodate
realm-based and general spatial objects. We describe our data structures in Section 3 and call this specifica-
tion the discrete model of SPAL2D.

2.2 Conceptual Models for Topological Relationships

The conceptual study and determination of topological relationships has been an interdisciplinary research
topic for a long time. Two fundamental approaches have turned out to be the starting point for a number
of extensions and variations; these are the 9-intersection model [17], which is based on point set theory
and point set topology, and the RCC model [11], which is based on spatial logic. Despite rather different
foundations, both approaches come to very similar results. The implementation strategy described in this
article relies heavily on the 9-intersection model. The reason is that we are able to create a direct link
between the concepts of this model and our implementation approach, as we will see later. This enables us
to prove the correctness of our implementation strategy.








An B'4 0 An Bf0 AOnB- f
MA nB 0 A naB~Bo0 nB- B 0
A- nB'0 Ar nB0 A nB- f

Figure 2: The 9-intersection matrix

Based on the 9-intersection model, a complete collection of mutually exclusive topological relationships
can be determined for each combination of simple and recently also complex spatial data types. The model
is based on the nine possible intersections of the boundary (aA), the interior (A'), and the exterior (A-) of
a spatial object A with the corresponding components of another object B. Each intersection is tested with
regard to the topologically invariant criteria of non-emptiness. The topological relationship between two
spatial objects A and B can be expressed by evaluating the 3 x 3-matrix in Figure 2.
For this matrix, 29 512 different configurations are possible from which only a certain subset makes
sense depending on the definition and combination of the types of the spatial objects considered. For each
combination of spatial types, this means that each of its predicates is associated with a unique intersection
matrix so that all predicates are mutually exclusive and complete with regard to the topologically invariant
criteria of emptiness and non-emptiness.
Topological relationships have been first investigated for simple spatial objects and especially for simple
regions [9, 13, 16, 17]. For two simple regions, eight meaningful configurations have been identified which
lead to the well known eight topological predicates called disjoint, meet, overlap, equal, inside, contains,
covers, and coveredBy. A total of 33 topological relationships have been found for two simple lines [7, 14,
18]. Topological predicates between simple points are trivial: either two simple points are disjoint or they
are equal. A simple point can be located on one of the endpoints of a simple line, in the interior of a simple
line, or be disjoint from a simple line. For a simple point and a simple region, we obtain the three predicates
disjoint, meet, and inside. For a simple line and a simple region, 19 topological relationships [19] can be
distinguished.
The two works in [8, 21] are the first but restricted attempts to a definition of topological relationships
on complex spatial objects. In [8] the so-called TRCR (Topological Relationships for Composite Regions)
model only allows sets of disjoint simple regions without holes. Topological relationships between these
composite regions are defined in an ad hoc manner and are not systematically derived from the underlying
model. The work in [21] only considers topological relationships of simple regions with holes; multi-part
regions are not permitted. A main problem of this approach is that it depends on the number of holes of the
operand objects. In [45] with two precursors in [2] and [44] we have given a thorough, systematic, and com-
plete specification of topological relationships for all combinations of complex spatial data types. Details
about the determination process and prototypical drawings of spatial scenarios visualizing all topological
relationships can be found in these papers. This approach, which is also based on the 9-intersection model,
is the basis of our implementation. Table 1(b) shows the increase of topological predicates for complex ob-
jects compared to simple objects (Table l(a)) and underpins the need for sophisticated and efficient predicate
execution techniques.

2.3 Implementation Aspects of Topological Predicates

In queries, topological predicates usually appear as filter conditions of spatial selections and spatial joins. At
least two main strategies can be distinguished for their processing. Either we attempt to avoid the execution
of topological predicates since they are expensive predicates and cannot be executed in constant time, or
we design sophisticated implementation methods for them. The latter strategy is always needed while the
former strategy is worthwhile to do.
Avoidance strategies for expensive predicate executions can be leveraged at the algebraic level and at








simple simple simple complex complex complex
point line region point line region
simple point 2 3 3 complex point 5 14 7
simple line 3 33 19 complex line 14 82 43
simple region 3 19 8 complex region 7 43 33

(a) (b)

Table 1: Numbers of topological predicates between two simple spatial objects (a) and between two complex
spatial objects (b)

the physical level. At the algebraic level, consistency checking procedures examine the collection of topo-
logical relationships contained in a query for topological consistency by employing topological reasoning
techniques [39]. Optimization minimizes the number of computations needed [10] and aims at eliminating
topological relationships that are implied uniquely by composition [20]. At the physical level, several meth-
ods pursue the concept of avoiding unnecessary or repetitive predicate evaluations in query access plans.
Examples of these methods are predicate migration [30], predicate placement [29], disjunctive query op-
timization [5], and approximation-based evaluation [4]. Another important method is the deployment of
spatial index structures [24] to identify those candidate pairs of spatial objects that could possibly fulfil the
predicate of interest. This is done by a filtering test on the basis of minimum bounding rectangles.
At some point, avoidance strategies are of no help anymore, and the application of physical predicate ex-
ecution algorithms is required. So far, there has been no published research on the efficient implementation
of topological predicates, their optimization, and their connection to the underlying theory. All three aspects
are objectives of our work. We leverage the well known plane sweep paradigm [3] and go far beyond our
own initial attempts in [42, 43]. These attempts extend the concept of the eight topological predicates for
two simple regions to a concept and implementation of these eight predicates for complex regions.
The spatial data management and analysis packages mentioned in Section 2.1 like the ESRI ArcSDE,
the Informix Geodetic DataBlade, the Oracle Spatial Cartridge, and DB2's Spatial Extender offer limited
sets of named topological predicates for simple and complex spatial objects. But their definitions are vague
and their implementations unpublished. The open source JTS Topology Suite [32] conforms to the sim-
ple features specification [33] of the Open GIS Consortium and implements topological predicates through
topology graphs. A topology graph stores topology explicitly and contains labeled nodes and edges corre-
sponding to the endpoints and segments of a spatial object's geometry. For each node and edge of a spatial
object, one determines whether it is located in the interior, in the exterior, or on the boundary of another
spatial object. Computing the topology graphs and deriving the 9-intersection matrix from them require
quadratic time and quadratic space in terms of the nodes and edges of the two operand objects; our solution
requires linearithmic (loglinear) time and linear space.


3 Data Structures

Our approach to the verification (query type 1) as well as the determination (query type 2) of a topological
relationship requires a two-phase algorithm consisting of the exploration phase and the evaluation phase.
Only the exploration phase makes use of the two spatial input objects. Each input object can be of type
point2D, line2D, or region2D. In this section, we describe their data structures. Our data structure design
and implementation is part of a new type system (i.e., algebra) for handling two-dimensional spatial data.
In Section 3.1 we give a brief overview of this algebra, explain its main components, and briefly discuss
some main requirements of data structure design in a database context. The following three sections de-
scribe several data structures needed for a topological predicate implementation. Section 3.2 introduces the








primitive types poi2D and seg2D. Section 3.3 explains the geometric component data type hlfLgrciL ,i2D
as the basis of the spatial data type implementation. Finally, the data structures for the spatial data types
point2D, line2D, and region2D (i.e., their discrete model) are presented in Section 3.4.

3.1 Data Structure Design in the Type System SPAL2D

Our implementation of topological predicates is embedded into the framework of a new type system for
two-dimensional spatial data, called Spatial Algebra 2D (SPAL2D for short). Some major design goals
of this algebra are high-level and general, complex spatial data types, sophisticated spatial operations and
predicates, numerically stable and topologically consistent algorithms, and usability in a database and query
language context. The algebra consists of four constituents, shown in Figure 3.
A central problem for the design of spatial data types is usually the underlying number system that
usually fails to ensure numerically stable and topologically consistent geometric algorithms. Numerical
stability incorporates the three aspects of correctness, robustness, and efficiency. Correctness means that
the implementation should always yield the right geometric or topological result compared to reality. Ro-
bustness implies that all cases occurring in a geometric operation should be handled correctly. Efficiency
emphasizes the requirement that the possible advantages of a stable algorithm should not be neutralized by
time-consuming numerical computations. Therefore, at the lowest level, our number system RATIO pro-
vides a numerically stable rational number implementation, which enables exact geometric computation.
The arithmetic RATIO provides a data type rat for rational numbers whose value representations can be of
arbitrary, finite length and are only limited by main memory. This enables exact computation but entails the
price of possibly longer number representations. From an implementation standpoint, the idea is to leverage
exislin'. fast computer number systems and the operations defined on them.
The next higher level incorporates two-dimensional robust geometric pi ,ini,,i L (RGP2D) that are based
on RATIO and that implement coordinates as rational numbers. These primitives serve as elementary build-
ing blocks for all higher-level structures and contribute significantly to their behavior, performance, and
robustness. RGP2D offers a primitive data type poi2D for single points, a data type seg2D for segments, and
a type mbb2D for minimum bounding boxes together with corresponding operations and predicates. Those
concepts that are needed for our predicate executions are described in Section 3.2.
The third level provides the two-dimensional geometric component data types (GCDT2D) face2D,
polygon2D, block2D, and hirf g, iin,2D. Objects of these types rest on objects from RGP types and rep-
resent the components from which spatial objects at the highest level are constructed. The first three data
types are pure user concepts. Apolygon is a closed areal figure given by its linear boundary representation.
A face consists of an outer polygon and possibly one or more edge-disjoint inner polygons called holes; it is
a constituent part of a complex region. A block is a finite collection of connected segments and a constituent


SPAL2D
SDT2D

GCDT2D

RGP2D

RATIO


Figure 3: Architecture of the Sp\i l, Algebra 2D (SPAL2D)








part of a complex line. The fourth data type is exclusively an implementation concept. For the exploration
phase, we are only interested in this concept; we describe halfsegments in Section 3.3.
The highest level SDT2D offers the three complex spatial data types point2D, line2D, and region2D (see
Section 2.1 for their intuitive description and [45] for their formal definition in the abstract model) together
with a comprehensive collection of spatial operations and predicates. For the construction of complex spatial
objects, SDT2D utilizes the three geometric component data types face2D, polygon2D, and block2D. The
internal representation of complex spatial objects is based on the types poi2D and h,a/if ilgi, ,'2D. Since it
is of particular interest for our predicate implementation, it is described in Section 3.4.
Since our goal is to plug our spatial algebra into a database system, the design and implementation of
data structures is subject to other criteria than in other application contexts. In a database context, data
structure design has to satisfy special requirements. A first aspect is that algorithms for different operations
processing the same kind of data usually prefer different internal data representations in order to be as
efficient as possible. In contrast to traditional work on algorithms, the focus here is not on finding the
most efficient algorithm for each single problem (operation) together with a corresponding sophisticated
data structure, but rather on considering the algebra as a whole and on reconciling the various requirements
posed by different algorithms within a single data structure for each data type. Otherwise, the consequence
would be considerable conversion costs between different data structures in main memory for the same
data type. A second aspect is that the intended use in a database system implies that representations for
data types should not employ pointer data structures in main memory but be embedded into compact storage
areas (arrays), which can be efficiently transferred between main memory and disk. This avoids unnecessary
and high costs for packing main memory data and unpacking external data.
In the following sections, we (only) introduce those data types and operations from RGP2D, GCDT2D,
and SDT2D that are needed for the implementation of topological predicates.

3.2 Robust Geometric Primitive Types

All objects of robust geometric primitive types are stored in records. The type poi2D incorporates all single,
two-dimensional points we can represent on the basis of our rational number system RATIO. That is, this
type is defined as

poi2D = {(x,y) Ix,y c rat} U {e}

The value e represents the empty object and is an element of all data types. The empty object is needed
to represent the case that an operation yields an "empty" result. Consider the case of a primitive operation
that computes the intersection of two segments in a point. If both segments do not intersect at all or they
intersect in a common segment, the result is empty and has to be represented.
Given two points p,q e poi2D, we assume a predicate "=" (p = q # p.x = q.x A p.y = q.y) and the
lexicographic order relation "<" (p < q = p.x < q.x V (p.x = q.x A p.y < q.y)).
The type seg2D includes all straight segments bounded by two endpoints. That is

seg2D ={(p,q) Ip,q epoi2D, p < q}U{e}

The order defined on the endpoints normalizes segments and provides for a unique representation. This
enables us to speak of a left endpoint and a right endpoint of a segment.
The predicates on, in : poi2D x seg2D -> bool check whether a point is located on a segment including
and excluding its endpoints respectively. The predicates poilntersect,seglntersect : seg2D x seg2D -- bool
test whether two segments intersect in a point or a segment respectively. The predicates collinear, equal,
disjoint, meet : seg2D x seg2D -> bool determine whether two segments lie on the same infinite line, are
identical, do not share any point, and touch each other in exactly one common endpoint respectively. The








function len : seg2D -- real computes the length of a segment. The type real is our own approximation type
for the real numbers and implemented on the basis of type rat. The operation poilntersection : seg2D x
seg2D -- poi2D returns the intersection point of two segments.
The type mbb2D comprises all minimum bounding boxes, i.e., axis-parallel rectangles. It is defined as

mbb2D = {(p,q) Ip,q Epoi,p.x < q.x,p.y < q.y}U{e}

Here, the predicate disjoint : mbb2D x mbb2D -* bool checks whether two minimum bounding boxes
are disjoint; otherwise, they interfere with each other.

3.3 The Geometric Component Data Type halfsegment2D

Halfsegments are the basic implementation components of objects of the spatial data types line2D and
region2D. A halfsegment, which is stored in a record, is a hybrid between a point and segment. That is, it
has features of both geometric structures; each feature can be inquired on demand. We define the set of all
halfsegments as the component data type

ih(Ilj giLgiiD = {(s,d) s e seg2D- {e}, d E bool}

For a halfsegment h = (s,d), the Boolean flag d emphasizes one of the segment's end points, which is
called the f ,i nimig,,i point of h. If d = true (d =false), the left (right) end point of s is the dominating
point of h, and h is called left (right) halfsegment. Hence, each segment s is mapped to two halfsegments
(s, true) and (s,false). Let dp be the function which yields the dominating point of a halfsegment.
The representation of line2D and region2D objects requires an order relation on halfsegments. For
two distinct halfsegments hi and h2 with a common end point p, let a be the enclosed angle such that
0 < a < 180'. Let a predicate rot be defined as follows: rot(h ,h2) is true if, and only if, hi can be rotated
around p through a to overlap h2 in counterclockwise direction. This enables us now to define a complete
order on halfsegments. For two halfsegments hi = (s ,di) and h2 = (2,d2) we obtain:

hi < h2 # dp(hi) < dp(h2) V (1)
(dp(h) = dp(h2) A ((-dl A d2) V (2a)
(dil =d2 A rot(hi,h2)) V (2b)
(dl = d2 A collinear(sl,s2) A len(s ) < len(s2)))) (3)

Examples of the order relation on halfsegments are given in Figure 4. Case 1 is exclusively based on
the (x,y)-lexicographical order on dominating points. In the other cases the dominating points of hi and h2
coincide. Case 2a deals with the situation that hi is a right halfsegment and h2 is a left halfsegment. Case 2b
handles the situation that hi and h2 are either both left halfsegments or both right halfsegments so that the
angle criterion is applied. Finally, case 3 treats the situation that hi and h2 are collinear. Two halfsegments
hi = (si,di) and h2 = (s2,d2) are equal if, and only if, si = s2 and dl = d2.
We will also need an order relation between a point v E poi2D and a halfsegment h e h1,,fL gILJ iL2D.
We define v < h # v < dp(h) and v =h h= v = dp(h). This shows the hybrid nature of halfsegments having
point and segment features.

3.4 Spatial Data Types

The general, internal representation structure for point2D, line2D, and region2D objects of the discrete
model is that of an information part of fixed length, followed by an ordered sequence of elements of vari-
able length. Information part and sequence are stored in a compact storage area, i.e., an array. Depending
on the type, the representations differ in the kind of elements and in the contents of the information parts.













2h h2





case 1 case 2a case 2b case 3


Figure 4: Examples of the order relation on halfsegments: hi < h2

The element type is poi2D for point2D objects, i-1f lgiri ,in2D for line2D objects, and attributed halfseg-
ments (see below) for region2D objects. Ordered sequences are selected as representation structures, since
they directly and efficiently support parallel traversals (Section 4.1) and the plane sweep paradigm (see
Section 4.3). The information part keeps the number of points for point2D objects, the number of halfseg-
ments, the total length of all segments, etc. for line2D objects, and the number of halfsegments, the area,
the perimeter, etc. for region2D objects. In general, the information part contains information that can be
easily computed during the construction of a spatial object. Corresponding operations can later benefit from
this information and answer in constant (instead of linear) time. In our context, the information part is not
needed so that we neglect it in the following. Another simplification relates to the sequence structure of
line2D and region2D objects. The sequence structures also support the block components of a line2D object
and the face components of a region2D object. For this purpose, halfsegments belonging to the same block
as well as attributed halfsegments belonging to the same face are linked with each other in the halfsegment
sequence by array indices. We will also neglect this aspect, since we do not need block and face components.
We now have a closer look at the type definitions. Let No : N U {0}. The spatial data type point2D is
defined as

point2D = {(p,...,pn) n E No,V
Since n = 0 is allowed, the empty sequence () represents the empty point2D object.
The spatial data type line2D is defined as

line2D {(hl,...,h2n) (i) n G No
(ii) V < i < 2n : hi EG hi1(LgoiU2D
(iii) Vhi = (si,di) E {hi,...,h2n} 3hj = (sj,dj) E {h,... ,h2n},
1 < i < j <2n: equal(si,sj) A d, dj
(iv) V < i < 2n: hi < hi+l
(v) Vhi (si,d,),hj (sj,d) E {hi,...,h2n},i ^ j: equal(si,sj) V
disjoint(si,sj) V meet(si,sj)}

The value n is equal to the number of segments of a line2D object. Since each segment is represented by
a left and a right halfsegment (condition (iii)), a line2D object has 2n halfsegments. Since n = 0 is allowed
(condition (i)), the empty sequence () represents the empty line2D object. Condition (iv) expresses that
a line2D object is given as an ordered halfsegment sequence. Condition (v) requires that the segments of
two distinct halfsegments are either equal (this only holds for the left and right halfsegments of a segment),
disjoint, or meet.









S9 S
S7 2 6
SS /S S5
4S
S3 S[
S6


L R

Figure 5: A line2D object L and a region2D object R

The internal representation of region2D objects is similar to that of line2D objects. But for each half-
segment, we also need the information whether the interior of the region is above/left or below/right of it.
We denote such a halfsegment as attributed halfsegment. Each element of the sequence consists of a half-
segment that is augmented by a Boolean flag ia (for "interior above"). If ia = true holds, the interior of the
region is above or, for vertical segments, left of the segment. The spatial data type region2D is defined as

region2D = {(hi,iai),...,(h2n,ia2n)) (i) n E No
(ii) VI < i < 2n : hi E h l1f Lgii ,u2D,iai E bool
(iii) Vhi= (si,di) E {hi,...,h2n}
3hj = (sj,dj) E {hl,...,h2n},1 < i < j < 2n:
si = sj A di = dj A iai = iaj
(iv) V < i <2n : hi (v) "additional topological constraints"}

Condition (v) refers to the additional topological constraints that all faces must be edge-disjoint from
each other and that for each face its holes must be located inside its outer polygon, be edge-disjoint to the
outer polygon, and be edge-disjoint among each other. These constraints are checked during the construction
of a region2D object. We mention them for reasons of completeness and assume their satisfaction.
As an example, Figure 5 shows a line2D object L (with two blocks) and a region2D object R (with a
single face containing a hole). Both objects are annotated with segment names si. We now determine the
halfsegment sequences of L and R and let h= (si, true) and h = (si,false) denote the left halfsegment and
right halfsegment of a segment si respectively. For L we obtain the ordered halfsegment sequence
L -(h ,h', h h, h' h h ,hi, h, h h If h, h, h, hr, hr)
1 4' 5 7' 1' 2' 7' 8' 5' 6 .- 9' 2' 3' 9' 3

For R we obtain the following ordered sequence of attributed halfsegments (t true, f -false):

R ((h t), (h f), (h f), (h t),(hr,t), (h t), (h ,f), (h' ,f), (hr, t), (hr,f), (h ,f), (h t))

Since inserting a halfsegment at an arbitrary position needs O(n) time, in our implementation we use
an AVL-tree embedded into an array whose elements are linked in halfsegment order. An insertion then
requires O(logn) time.
If we take into account that the segments of a line2D object as well as the segments of a region2D
object are not allowed to intersect each other or touch each other in their interiors according to their type
specifications, the definition of the order relation on halfsegments (Section 3.3) seems to be too intricate.
If, in Figure 4, we take away all subcases of case 1 except for the upper left subcase as well as case 3, the
restricted order relation can already be leveraged for complex lines and complex regions. In case that all








spatial objects of an application space are defined over the same realm1 [26, 41], the restricted order relation
can also be applied for a parallel traversal of the sequences of two (or more) realm-based line2D or region2D
objects. But only in the general case of intersecting spatial objects, the full order relation on halfsegments
is needed for a parallel traversal of the objects' halfsegment sequences.


4 Basic Algorithmic Concepts

In this section, we describe three algorithmic concepts that serve as the foundation of the exploration al-
g,, 1iui1,i in Section 5. These concepts are the parallel object traversal (Section 4.1), overlap numbers
(Section 4.2), and the plane sweep paradigm (Section 4.3). Parallel object traversal and overlap numbers
are employed during a plane sweep. We will not describe these concepts in full detail here, since they are
well known methods in Computational Geometry [3] and spatial databases [28]. Instead, we will focus on
the specialties of these concepts in our setting. This includes a smoothly integrated handling of general and
realm-based spatial objects. An objective of this section is also to introduce a number of auxiliary operations
and predicates that make the description of the exploration algorithms later much more comprehensible.

4.1 Parallel Object Traversal

For a plane sweep, the representation elements (points or segments) of the spatial operand objects have
usually to be merged together and sorted afterwards according to some order relation (e.g., the order on
x-coordinates). This initial merging and sorting is rather expensive and requires O(nlogn) time, if n is the
number of representation elements of both operand objects. Our approach avoids this initial sorting, since
the representation elements of point2D, line2D, and region2D objects are already stored in the order we
need (point order or halfsegment order). We also do not have to merge the object representations, since we
can deploy parallel object traversal that allows us to traverse the point or halfsegment sequences of both
operand objects in parallel. Hence, by employing a cursor on both sequences, it is sufficient to check the
point or halfsegment at the current cursor positions of both sequences and to take the lower one with respect
to the point order or halfsegment order for further computation.
If the operand objects have already been intersected with each other, like in the realm case [26], the
parallel object traversal has only to operate on two, i/tic point or halfsegment sequences. But in the general
case, intersections between both objects can exist and are detected during the plane sweep. A purely static
sequence structure is insufficient in this case, since detected intersections have to be stored and handled
later during the plane sweep. In order to avoid a change of the original object representations, which would
be very expensive and only temporarily needed, each object is associated with an additional and temporary
dynamic sequence, which stores newly detected points or halfsegments of interest. Hence, our parallel object
traversal has to handle a static and a dynamic sequence part for each operand object and thus four instead
of two point or halfsegment sequences. It returns the smallest point or halfsegment from the four current
cursor positions. We will give an example of the parallel object traversal when we discuss our plane sweep
approach (Section 4.3).
To simplify the description of this parallel scan, two operations are provided. Let 01 E U and 02 E 3
with a(, p3 {point2D,line2D,region2D}. The operation selectfirst(01, 02, object, status) selects the first
point or halfsegment of each of the operand objects 01 and 02 and positions a logical pointer on both of
them. The parameter object with a possible value out of the set {none, first, second, both} indicates which
of the two object representations contains the smaller point or halfsegment. If the value of object is none, no

1A realm provides a discrete geometric basis for the construction of spatial objects and consists of a finite set of points and non-
intersecting segments, called realm objects. That is, a segment inserted into the realm is intersected and split according to a special
strategy with all realm objects. All spatial objects like complex points, complex lines, and complex regions are then defined in
terms of these realm objects. Hence, all spatial objects defined over the same realm become aquainted with each other beforehand.








point or halfsegment is selected, since 01 and 02 are empty. If the value is first (second), the smaller point
or halfsegment belongs to 01 (02). If it is both, the first point or halfsegment of 01 and 02 are identical. The
parameter status with a possible value out of the set {end_ofnone, end_offirst, end_ofsecond, endof_both}
describes the state of both object representations. If the value of status is end_ofnone, both objects still have
points or halfsegments. If it is end_offirst (end_of"second), 01 (02) is exhausted. If it is end_of_both, both
object representations are exhausted.
The operation select_next(Oi, 02, object, status), which has the same parameters as selectfirst, searches
for the next smallest point or halfsegment of 01 and 02. Two points (halfsegments) are compared with
respect to the lexicographic (halfsegment) order. For the comparison between a point and a halfsegment, the
dominating point of the halfsegment and hence the lexicographic order is used (see Section 3.3). If before
this operation object was equal to both, select_next moves forward the logical pointers of both sequences;
otherwise, if object was equal to first (second), it only moves forward the logical pointer of the first (second)
sequence. In contrast to the first operation, which only has to consider the static sequence part of an object,
this operation also has to check the dynamic sequence part of each object. Both operations together allow
one to scan in linear time two object representations like one ordered sequence.

4.2 Overlap Numbers

The concept of overlap numbers is exclusively needed for the computation of the topological relationships
between two region2D objects. The reason is that we have to find out the degree of overlapping of region
parts. Overlap numbers serve as part of the "interface" between the discrete and abstract specifications of
complex regions. For a complex region F, we have to distinguish its discrete specification Fd as a sequence
of attributed halfsegments and its abstract specification Fa as an infinite point set. In the abstract model, a
point in the plane has overlap number k if k regions contain this point. For two regions Fa and Ga, a point
p obtains the overlap number 2, if, and only if, p E Fa and p E Ga. It obtains the overlap number 1, if, and
only if, either p E Fa and p E Ga, or p E Fa and p E Ga. Otherwise, its overlap number is 0. In the discrete
model, where we cannot explicitly represent infinite point sets, we employ finite boundary representations,
i.e., attributed halfsegments. Since a segment sh of an attributed halfsegment (h,iah) = ((sh,dh),iah) of a
region Fd separates space into two parts, an interior and an exterior one, during a plane sweep each such
segment is associated with a segment class which is a pair (m/n) of overlap numbers, a lower (or right)
one m and an upper (or left) one n (m,n E No). The lower (upper) overlap number indicates the number of
overlapping region2D objects below (above) the segment. In this way, we obtain a segment classification of
two region2D objects and speak about (m/n)-segments. Obviously, 0 < m,n < 2 holds. Of the nine possible
combinations only seven describe valid segment classes. This is because a (0/0)-segment contradicts the
definition of a complex region2D object, since then at least one of both regions would have two holes or an
outer cycle and a hole with a common border segment. Similarly, (2/2)-segments cannot exist, since then
at least one of the two regions would have a segment which is common to two outer cycles of the object.
Hence, possible (m/n)-segments are (0/1)-, (0/2)-, (1/0)-, (1/1)-, (1/2)-, (2/0)-, and (2/1)-segments.
Figure 6 gives an example.


1 2ii ""-,,

-o ----1 -'I
S


Figure 6: Example of the segment classification of two region2D objects








4.3 Plane Sweep


The plane sweep technique [3, 38] is a well known algorithmic scheme in Computational Geometry. Its
central idea is to reduce a two-dimensional geometric problem to a simpler one-dimensional geometric
problem. A vertical sweep line traversing the plane from left to right stops at special event points which are
stored in a queue called event point schedule. The event point schedule must allow one to insert new event
points discovered during processing; these are normally the initially unknown intersections of line segments.
The state of the intersection of the sweep line with the geometric structure being swept at the current sweep
line position is recorded in vertical order in a data structure called sweep line status. Whenever the sweep
line reaches an event point, the sweep line status is updated. Event points which are passed by the sweep
line are removed from the event point schedule. Note that, in general, an efficient and fully dynamic data
structure is needed to represent the event point schedule and that, in many plane-sweep algorithms, an initial
sorting step is needed to produce the sequence of event points in (x,y)-lexicographical order.
In our case, the event points are either the points of the static point sequences ofpoint2D objects or the
(attributed) halfsegments of the static halfsegment sequences of line2D (region2D) objects. This especially
holds and is sufficient for the realm case. In addition, in the general case, new event points are determined
during the plane sweep as intersections of line segments; they are stored as points or halfsegments in the
dynamic sequence parts of the operand objects and are needed only temporarily for the plane sweep. As
we have seen in Section 4.1, the concepts of point order, halfsegment order, and parallel object traversal
avoid an expensive initial sorting at the beginning of the plane sweep. We use the operation get_event to
provide the element to which the logical pointer of a point or halfsegment sequence is currently pointing.
The Boolean predicate look_ahead tests whether the dominating points of a given halfsegment and the next
halfsegment after the logical pointer of a given halfsegment sequence are equal.
Several operations are needed for managing the sweep line status. The operation newsweep creates
a new, empty sweep line status. If a left (right) halfsegment of a line2D or region2D object is reached
during a plane-sweep, the operation addleft delighth) stores (removes) its segment component into (from)
the segment sequence of the sweep line status. The predicate coincident checks whether the just inserted
segment partially coincides with a segment of the other object in the sweep line status. The operation set_attr
(get_attr) sets (gets) an attribute for (from) a segment in the sweep line status. This attribute can be either a
Boolean value indicating whether the interior of the region is above the segment or not (the "Interior Above"
flag), or it can be an assigned segment classification. The operation get_pred_attr yields the attribute from
the predecessor of a segment in the sweep line status. The operation pred_exists (commonpointexists)
checks whether for a segment in the sweep line status a predecessor according to the vertical y-order (a
neighbored segment of the other object with a common end point) exists. The operation predofp searches
the nearest segment below a given point in the sweep line status. The predicate current_exists tests whether
such a segment exists. The predicate poi_onseg (poi_inseg) checks whether a given point lies on (in) any
segment of the sweep line status.
Intersections of line segments stemming from two lines2D objects, two region2D objects, or a line2D
object and a region2D object are of special interest, since they indicate topological changes. If two segments
of two line2D objects intersect, this can, e.g., indicate a proper intersection, or a meeting situation between
both segments, or an overlapping of both segments. If a segment of a line2D object intersects a segment
of a region2D object, the former segment can, e.g., "enter" the region, "leave" the region, or overlap with
the latter segment. Overlap numbers can be employed here to determine entering and leaving situations. If
segments of two region2D objects intersect, this can, e.g., indicate that they share a common area and/or a
common boundary. In this case, intersecting line segments have especially an effect on the overlap numbers
of the segments of both region2D objects. In Section 4.2 we have tacitly assumed that any two segments
from both region2D objects are either disjoint, or equal, or meet solely in a common end point. Only if
these topological constraints are satisfied, we can use the concepts of overlap numbers and segment classes








for a plane sweep. But the general case in particular allows intersections. Figure 7 shows the problem of
segment classes for two intersecting segments. The segment class of sl [s2] left of the intersection point is
(0/1) [(1/2)]. The segment class of sl [s2] right of the intersection point is (1/2) [(0/1)]. That is, after the
intersection point, seen from left to right, sl and s2 exchange their segment classes. The reason is that the
topology of both segments changes. Whereas, to the left of the intersection, sl (s2) is outside (inside) the
region to which s2 (sl) belongs, to the right of the intersection, sl (S2) is inside (outside) the region to which
S2 (S1) belongs.

2 2


S1 0 0 s,

Figure 7: Changing overlap numbers after an intersection.

In order to be able to make the needed topological detections and to enable the use of overlap numbers
for two general regions, in case that two segments from two different regions intersect, partially coincide,
or touch each other within the interior of a segment, we pursue a splitting strategy that is executed during
the plane sweep "on the fly". If segments intersect, they are temporarily split at their common intersection
point so that each of them is replaced by two segments (i.e., four halfsegments) (Figure 8a). If two seg-
ments partially coincide, they are split each time the endpoint of one segment lies inside the interior of the
other segment. Depending on the topological situations, which can be described by Allen's thirteen basic
relations on intervals [1], each of the two segments either remains unchanged or is replaced by up to three
segments (i.e., six halfsegments). From the thirteen possible relations, eight relations (four pairs of symmet-
ric relations) are of interest here (Figure 8b). If an endpoint of one segment touches the interior of the other
segment, the latter segment is split and replaced by two segments (i.e., four halfsegments) (Figure 8c).
This splitting strategy is numerically stable and thus feasible from an implementation standpoint, since
RATIO ensures correctness, numerical robustness, and hence topological consistency of intersection opera-
tions. Intersecting and touching points can be exactly computed, lead to representable points with rational
coordinates provided by RATIO, and are thus precisely located on the intersecting or touching segments.
However, as indicated before, the splitting of segments entails some algorithmic effort. On the one
hand, we want to keep the halfsegment sequences of the line2D and region2D objects unchanged, since
their update is expensive and only temporarily needed for the plane sweep. On the other hand, the splitting
of halfsegments has an effect on these sequences. As a compromise, for each line2D or region2D object,
we maintain its "static" representation, and the halfsegments obtained by the splitting process are stored in
an additional "dynamic" halfsegment sequence. The dynamic part is also organized as an AVL tree which

1 2

S 2 1 2 3 2
2 2 1
1
1 2
----4
1 2
(a) (b) (c)

Figure 8: Splitting of two intersecting segments (a), two partially coinciding segments (without symmetric
counterparts) (b), and a segment whose interior is touched by another segment (c). Digits indicate part
numbers of segments after splitting.















(a) (b)


Figure 9: Sweep line status before the splitting (S4 to be inserted) (a) and after the splitting (b). The vertical
dashed line indicates the current position of the sweep line.

is embedded in an array and whose elements are linked in sequence order. Assuming that k splitting points
are detected during the plane sweep, we need O(k) additional space, and to insert them requires O(klogk)
time. After the plane sweep, this additional space is released.
To illustrate the splitting process in more detail, we consider two region2D objects R1 and R2. In general,
we have to deal with the three cases in Figure 8. We first consider the case that the plane sweep detects an
intersection. This leads to a situation like in Figure 9a. The two static and the two dynamic halfsegment
sequences ofR1 and R2 are shown in Table 2. Together they form the eventpoint schedule of the plane sweep
and are processed by a parallel object traversal. Before the current position of the sweep line (indicated
by the vertical dashed line in Figure 9), the parallel object traversal has already processed the attributed
halfsegments (h ,t), (h2,f), (h ,t), and (h2,f) in this order. At the current position of the sweep line,
the parallel object traversal encounters the halfsegments (h3 ,t) and (h4,f ). For each left halfsegment
visited, the corresponding segment is inserted into the sweep line status according to the y-coordinate of its
dominating point and checked for intersections with its direct upper and lower neighbors. In our example,
the insertion of S4 leads to an intersection with its upper neighbor vi. This requires segment splitting; we split
vi into the two segments vi1, and v1,2 and s4 into the two segments S4,1 and s4,2. In the sweep line status, we
have to replace vi by vl,1 and s4 by S4,1 (Figure 9b). The new halfsegments (h41 ,f), (f4,2 ,f), and (h2 ,f)
are inserted into the dynamic halfsegment sequence of R1. Into the dynamic halfsegment sequence of R2,
we insert the halfsegments (hr,, t), (h1,2, t), and (h1,2, t). We need not store the two halfsegments (h4,1,
and (h1, t) since they refer to the "past" and have already been processed.
On purpose we have accepted a little inconsistency in this procedure, which can fortunately be easily
controlled. Since, for the duration of the plane sweep, s4 (vi) has been replaced by s4,1 (vl,1) and s4,2 (V1,2),
the problem is that the static sequence part of R1 (R2) still includes the now invalid halfsegment (h4,f)
((hl ,t)), which we may not delete (see Figure 9b). However, this is not a problem due to the following
observation. If we find a right halfsegment in the dynamic sequence part of a region2D object, we know that
it stems from splitting a longer, collinear, right halfsegment that is stored in the static sequence part of this
object, has the same right end point, and has to be skipped during the parallel object traversal.

R1 dynamic sequence part (h 1 ,f) (h 42 f) (hr ,f)
R1 ,i,,,c sequence part (h1 ,t) (h2, f) (h, ,t) (h4, f) (h3 ,t)
(hr f) (h4, f) (hs,5, f) (h f) (h t
R2 ',',~i sequence part (h ,t) (h,,f) (h,, f) (hv.,f) (hi f)
(h^l ,t)
R2 dynamic sequence part (h1 1, t) (h(12 t) (hv 1, t)

Table 2: Static and dynamic halfsegment sequences of the regions R1 and R2 in Figure 9.








For the second and third case in Figure 8, the procedure is the same but more splits can occur. In case of
overlapping, collinear segments, we obtain up to six new halfsegments. In case of a touching situation, the
segment whose interior is touched is split. In all cases considered, each right halfsegment of a split segment
contained in the static sequence part gets a new counterpart in the dynamic sequence part pointing to it.


5 The Exploration Phase for Collecting Topological Information

For a given scene of two spatial objects, the goal of the exploration phase is to discover appropriate topo-
logical information that is characteristic and unique for this scene and that is suitable both for verification
queries (query type 1) and determination queries (query type 2). Our approach is to scan such a scene from
left to right by a plane sweep and to collect topological data during this traversal that later in the evaluation
phase helps us confirm, deny, or derive the topological relationship between both objects. From both phases,
the exploration phase is the computationally expensive one since topological information has to be explicitly
derived by geometric computation.
Our research shows that it is unfavorable to aim at designing a universal exploration algorithm that cov-
ers all combinations of spatial data types. This has three main reasons. First, each of the data types point2D,
line2D, and region2D has very type-specific, well known properties that are different from each other (like
different dimensionality). Second, for each combination of spatial data types, the topological information
we have to collect is very specific and especially different from all other type combinations. Third, the
topological information we collect about each spatial data type is different in different type combinations.
Therefore, using the basic algorithmic concepts of Section 4, in this section, we present exploration
algorithms for all combinations of complex spatial data types. Between two objects of types point2D,
line2D, or region2D, we have to distinguish six different cases, if we assume that the first operand has an
equal or lower dimension than the second operand2. All algorithms except for the point2D/point2D case
require the plane sweep technique. Depending on the types of spatial objects involved, a boolean vector vF
consisting of a special set of topologicall flags" is assigned to each object F. We call it a topological feature
vector. Its flags are all initialized to false. Once certain topological information about an object has been
discovered, the corresponding flag of its topological feature vector is set to true. For all type combinations,
we aim at minimizing the number of topological flags of both spatial argument objects. In symmetric cases,
only the first object gets the flag. The topological feature vectors are later used in the evaluation phase for
predicate matching. Hence, the selection of topological flags is highly motivated by the requirements of the
evaluation phase (Section 6, [37]).
Let P(F) be the set of all points of apoint2D object F, H(F) be the set of all (attributed) halfsegments
[including those resulting from our splitting strategy] of a line2D (region2D) object F, and B(F) be the set
of all boundary points of a line2D object F. For f E H(F), let f.s denote its segment component, and, if F
is a region2D object, letf.ia denote its attribute component. The definitions in the next subsections make
use of the operations on robust geometric primitives (Section 3.2) and halfsegments (Section 3.3).

5.1 The Exploration Algorithm for the point2D/point2D Case

The first and simplest case considers the exploration of topological information for two point2D objects F
and G. Here, the topological facts of interest are whether (i) both objects have a point in common and (ii) F
(G) contains a point that is not part of G (F). Hence, both topological feature vectors vF and vG get the flag
poidisjoint. But only vF in addition gets the flag poishared since the sharing of a point is symmetric. We
obtain (the symbol ":<" means "equivalent by definition"):
2If, in the determination query case, a predicate p(A,B) has to be processed, for which the dimension of object A is higher than
the dimension of object B, we process the converse predicate pCO"'(B,A) where pCO"' has the transpose of the 9-intersection matrix
(see Figure 2) of p.








01 algorithm ExplorePoint2DPoint2D
02 input: point2D objects F and G, topological feature
03 vectors vF and vG initialized ilii i.i/e
04 output: updated vectors vF and VG
05 begin
06 ,, 1,. ii i, aF, G, object, status);
07 while status = endof-none and not (vF- r' ..... ""],,
08 and VG[poidisjoint] and vF [poishared]) do
09 if object =first then vF '* .. -'. *1 ,. ".. ] : true
10 else if object = second then vGc [! ..* .. 1 .. ."1"'] : true


11 else /* object = both */
12 vF [poi_shared] := true;
13 endif
14 selectnext(F, G, object, status);
15 endwhile;
16 if status = e,,.i_. -i _r, ,'i Iln vG joiidioiiit] := true
17 else if status = endof second then
18 VF ['oi- Jinoiirt] : true
19 endif
20 end ExplorePoint2DPoint2D.


Figure 10: Algorithm for computing the topological feature vectors for twopoint2D objects

Definition 1 Let F, G E point2D, and let VF and vG be their topological feature vectors. Then


(i) vF[poishared]
(ii) VF [poi_disjoint]
(iii) G [poi_disjoint]


:3f fP(F) 3geP(G): f g
: 3f eP(F)VgeP(G): ff g
: 3ge P(G) V fP(F) : f g


For the computation of the topological feature vectors, a plane sweep is not needed in this case; a parallel
traversal suffices, as the algorithm in Figure 10 shows. The while-loop terminates if either the end of one of
the objects has been reached or all topological flags have been set to true (lines 7 and 8). In the worst case,
the loop has to be traversed / + m times where / (m) is the number of points of the first (second) point2D
object. Since the body of the while-loop requires constant time, the overall time complexity is O(1 +m).


5.2 The Exploration Algorithm for the point2D/line2D Case

In case of apoint2D object F and a line2D object G, at the lowest level of detail, we are interested in the
possible relative positions between the individual points of F and the halfsegments of G. This requires a
precise understanding of the definition of the boundary of a line2D object, as it has been given in [45]. It
follows from this definition that each boundary point of G is an endpoint of a (half)segment of G and that
this does not necessarily hold vice versa, as Figure 11(a) indicates. The black segment endpoints belong to
the boundary of G, since exactly one segment emanates from each of them. Intuitively, they "bound" G. In
contrast, the grey segment endpoints belong to the interior of G, since several segments emanate from each
of them. Intuitively, they are "connector points" between different segments of G.
The following argumentation leads to the needed topological flags for F and G. Seen from the perspec-
tive of F, we can distinguish three cases, since the boundary of F is empty [45] and the interior of F can
interact with the exterior, interior, or boundary of G. First, (the interior of) a point f of F can be disjoint
from G (flag poidisjoint). Second, a point f can lie in the interior of a segment of G (flag poi_on_interior).


F 0


G


G
F


Figure 11: Boundary points (in black) and connector points (in grey) of a line2D object (a), a scenario
where a boundary point of a line2D object exists that is unequal to all points of a point2D object (b), a
scenario where this is not the case (c).








01 algorithm ExplorePoint2DLine2D
02 input: point2D object F and line2D object G,
03 topological feature vectors vF and vG
04 initialized v i. i., l?
05 output: updated vectors vF and vG
06 begin
07 S:= new-sweep(); lastdp := ;
08 1,i _,, -i- F, G, object, status);
09 while status 7 end_of-second and status e e,,. 1. _-. .il and
10 not (vF [p,,iJdioirt] and vF [poion_interior] and
11 vF [poi_on_bound] and vG[bound_poidisjoint]) do
12 if object =first then p := get_event(F);
13 if poi_inseg(S, p) then vF [poi_on_interior] := true
14 else vF ..'. 1',,. *l. '] := true endif
15 else if object = second then
16 h := getevent(G); /* h = (s,d) */
17 ifd then o. ./_/, i,. \ s) else delj ',-,i \ s) endif;
18 if dp(h) lastdp then lastdp := dp(h);


19 if not lookahead(h, G) then
20 vG[bound poi-disjoint] := true
21 endif
22 endif
23 else /* object = both */
24 h := getevent(G); /* h= (s,d) */
25 if d then ao. I, s) else delj ,-I~,/1i s) endif;
26 lastdp := dp(h);
27 if lookahead(h,G) then
28 vF [poi_on_interior] := true
29 else vF [poi_on_bound] := true endif
30 endif
31 select-next(F, G, object, status);
32 endwhile;
33 if status = endof second then
34 vF [poi-dijoint] : true
35 endif
36 end ExplorePoint2DLine2D.


Figure 12: Algorithm for computing the topological feature vectors for apoint2D object and aline2D object

This includes an endpoint of such a segment, if the endpoint is a connector point of G. Third, a point f can
be equal to a boundary point of G (flag poi_onbound). Seen from the perspective of G, we can distinguish
four cases, since the boundary and the interior of G can interact with the interior and exterior of F. First,
G can contain a boundary point that is unequal to all points in F (flag boundpoi_disjoint). Second, G can
have a boundary point that is equal to a point in F. But the flag poi_on_bound already takes care of this
situation. Third, the interior of a segment of G (including connector points) can comprehend a point of F.
This situation is already covered by the flag poi_oninterior. Fourth, the interior of a segment of G can be
part of the exterior ofF. This is always true since a segment of G represents an infinite point set that cannot
be covered by the finite number of points in F. Hence, we need not handle this as a special situation. More
formally, we define the semantics of the topological flags as follows:

Definition 2 Let F E point2D, G E line2D, and vF and VG be their topological feature vectors. Then


(i) VF [poidisjoint]
(ii) v [poi_on_interior]
(iii) vF [poi_on_bound]
(iv) vG [bound poi_disjoint]


:. 3f E P(F) VgeH(G) : on(f,g.s)
:I 3f E P(F) 3g e H(G) Vb E B(G) : on(f,g.s) A f b
:I 3fEP(F) geB(G):f g
:= 3g B(G)VfeP(F):f g


Our algorithm for computing the topological information for this case is shown in Figure 12. The
while-loop is executed until the end of the line2D object (line 9) and as long as not all topological flags
have been set to true (lines 10 to 11). The operations selectfirst and selectnext compare a point and a
halfsegment according to the order relation defined in Section 3.3 in order to determine the next elements)
to be processed. If only a point has to be processed (line 12), we know that it does not coincide with an
endpoint of a segment of G and hence not with a boundary point of G. But we have to check whether the
point lies in the interior of a segment in the sweep line status structure S. This is done by the search operation
poiinseg on S (line 13). If this is not the case, the point must be located outside the segment (line 14). If
only a halfsegment h has to be processed (line 15), its segment component is inserted into (deleted from)
S if h is a left (right) halfsegment (line 17). We also have to test if the dominating point of h, say v, is a
boundary point of G. This is the case if v is unequal to the previous dominating point stored in the variable
last_dp (line 18) and if the operation lookahead finds out that v does also not coincide with the dominating
point of the next halfsegment (lines 19 to 20). In case that a point v of F is equal to a dominating point of









01 algorithm ExplorePoint2DRegion2D
02 input: point2D object F and region2D object G,
03 topological feature vectors vF and vG
04 initialized ilvi i., ie
05 output: updated vectors vF and vG
06 begin
07 S:= newsweep();
08 ,1 _iJ, iF, G, object, status);
09 while status = endof none and not (vF [poi_inside]
10 and vF[poi_on_bound] and vF [poi_outside]) do
11 if object =first then p := getevent(F);
12 ifpoionseg(S, p) then vF [poi-on.bound] : tr
13 else pred_ofp(S, p);
14 if current_exists(S) then ia := get_attr(S);
15 if ia then vF [poiinside] : true


16 else vF [poioutside] := true endif
17 else vF [poi_outside] := true
18 endif
19 endif
20 else h := get_event(G); ia := get_attr(G); /* h= (s,d) */
21 if d then o. I/_, I/ s); set_attr(S, ia)
22 else del_ ,,*i1,, s) endif;
23 if object = both then vF [poionbound] : true endif
24 endif
25 select-next(F, G, object, status);
26 endwhile;
ue 27 if status = endofsecond then
28 vF [poi_outside] : true
29 endif
30 end ExplorePoint2DRegion2D.


Figure 13: Algorithm for computing the topological feature vectors for a point2D object and a region2D
object

a halfsegment h in G (line 23), we know that v has never been visited before and that it is an end point of
the segment component of h. Besides the update of S (line 25), it remains to decide whether v is an interior
point (line 28) or a boundary point (line 29) of h. For this, we look ahead (line 27) to see whether the next
halfsegment's dominating point is equal to v or not.
If I is the number of points of F and m is the number of halfsegments of G, the while-loop is executed
at most / + m times. The insertion of a left halfsegment into and the removal of a right halfsegment from the
sweep line status needs O(logm) time. The check whether a point lies within or outside a segment (predicate
poiinseg) also requires O(logm) time. Altogether, the worst time complexity is O((l+ m)logm). The
while-loop has to be executed at least m times for processing the entire line2D object in order to find out
whether a boundary point exists that is unequal to all points of the point2D object (Figures 11(b) and (c)).


5.3 The Exploration Algorithm for the point2D/region2D Case

In case of a point2D object F and a region2D object G, the situation is simpler than in the previous case.
Seen from the perspective of F, we can again distinguish three cases between (the interior of) a point of F
and the exterior, interior, or boundary of G. First, a point of F lies either inside G (flag poiinside), on the
boundary of G (flag poi_onbound), or outside of region G (flag poioutside). Seen from the perspective of
G, we can distinguish four cases between the boundary and the interior of G with the interior and exterior of
F. The intersection of the boundary (interior) of G with the interior of F implies that a point of F is located
on the boundary (inside) of G. This situation is already covered by the flag poi_on_bound (poiinside). The
intersection of the boundary (interior) of G with the exterior of F is always true, since F as a finite point set
cannot cover G's boundary segments (interior) representing an infinite point set. More formally, we define
the semantics of the topological flags as follows (we assume poilnRegion to be a predicate which checks
whether a point lies inside a region2D object):

Definition 3 Let F E point2D, G E region2D, and vF and VG be their topological feature vectors. Then

(i) vF [poi_inside] : 3f e P(F) : poilnRegion (f, G)
(ii) vF [poionbound] : 3f e P(F) 3g E H(G) : on(f,g.s)
(iii) vF [poioutside] := f E P(F) Vg G H(G) : -poilnRegion (f, G) A -on(f,g.s)

We see that VG is not needed. The algorithm for this case is shown in Figure 13. The while-loop is
executed as long as none of the two objects has been processed (line 9) and as long as not all topological








flags have been set to true (lines 9 to 10). If only a point has to be processed (line 11), we must check
its location. The first case is that it lies on a boundary segment; this is checked by the sweep line status
predicate poion-eg (line 12). Otherwise, it must be located inside or outside of G. We use the operation
pred_ofp (line 13) to determine the nearest segment in the sweep line status whose intersection point with
the sweep line has a lower y-coordinate than the y-coordinate of the point. The predicate currentexists
checks whether such a segment exists (line 14). If this is not the case, the point must be outside of G (line
17). Otherwise, we ask for the information whether the interior of G is above the segment (line 14). We
can then derive whether the point is inside or outside the region (lines 15 to 16). If only a halfsegment h
has to be processed or a point v of F is equal to a dominating point of a halfsegment h in G (line 20), h's
segment component is inserted into (deleted from) S if h is a left (right) halfsegment (line 20 to 21). In case
of a left halfsegment, in addition, the information whether the interior of G is above the segment is stored in
the sweep line status (line 21). If v and the dominating point of h coincide, we know that the point is on the
boundary of G (line 23).
If I is the number of points of F and m is the number of halfsegments of G, the while-loop is executed
at most / + m times. Each of the sweep line status operations addleft, del_right, poi_onseg, predofp, cur-
rentexists, getattr, and setattr needs O(logm) time. The total worst time complexity is O((l +m)logm).

5.4 The Exploration Algorithm for the line2D/line2D Case

We now consider the exploration algorithm for two line2D objects F and G. Seen from the perspective of F,
we can differentiate six cases between the interior and boundary ofF and the interior, boundary, and exterior
of G. First, the interiors of two segments of F and G can partially or completely coincide (flag segshared).
Second, if a segment of F does not partially or completely coincide with any segment of G, we register this
in the flag segunshared. Third, we set the flag interiorpoishared if two segments intersect in a single point
that does not belong to the boundaries of F or G. Fourth, a boundary endpoint of a segment of F can be
located in the interior of a segment (including connector points) of G (flag boundoninterior). Fifth, both
objects F and G can share a boundary point (flag boundshared). Sixth, if a boundary endpoint of a segment
of F lies outside of all segments of G, we set the flag bounddisjoint. Seen from the perspective of G, we
can identify the same cases. But due to the symmetry of three of the six topological cases, we do not need
all flags for G. For example, if a segment ofF partially coincides with a segment of G, this also holds vice
versa. Hence, it is sufficient to introduce the flags segunshared, boundoninterior, and bounddisjoint for
G. More formally, we define the semantics of the topological flags as follows:

Definition 4 Let F, G E line2D, and let vF and VG be their topological feature vectors. Then
(i) vF[segshared] : I 3f e H(F) 3g e H(G) : seglntersect(f.s,g.s)
(ii) VF [interior poishared] : 3f e H(F) 3g e H(G) Vp e B(F) UB(G) :
poilntersect(f.s,g.s) A poilntersection(f.s,g.s) / p
(iii) vF [seg unshared] : f E H(F) Vg e H(G) : -seglntersect(f.s,g.s)
(iv) vF [boundoninteriorl : I 3f EH(F) 3g EH(G) p e B(F) \ B(G):
poilntersection (f.s, g.s) p
(v) vF[boundshared] : 3p EB(F) q e B(G) :p q
(vi) vF[bound disjoint] : 3p E B(F) Vg E H(G) : -on(p,g.s)
(vii) vG[segunshared] : I 3g e H(G) Vf e H(F) : -seglntersect(f.s,g.s)
(viii) vG[boundoninterior] : 3f e H(F) 3g e H(G) 3p e B(G) \ B(F) :
poilntersection (f.s,g.s) p
(ix) vG[bounddisjoint] : 3q E B(G) Vf E H(F) : -on(q,f.s)
The exploration algorithm for this case is given in Figure 14. The while-loop is executed until both
objects have been processed (line 9) and as long as not all topological flags have been set to true (lines 9 to









01 algorithm ExploreLine2DLine2D
02 input: line2D objects F and G, topological feature
03 vectors vF and vG initialized e ili i.i/e
04 output: updated vectors vF and VG
05 begin
06 S := new-sweep); lastdp_in7 := e; lastdp_in_G := e;
07 lastboundin-7 := e; lastboundinG := e;
08 1 ,i _J, F, G, object, status);
09 while status e e,,. 1.. *' .di and not (vF [segshared]
10 and vF [interiorpoi-shared] and vF [segunshared]
11 and vF [bound_on_interior] and vF [bound shared]
12 and vF [bounddisjoint] and v [bounddisjoint]
13 and vG[bound_on_interior] and vG [,, '""' ... ) do
14 if object =first then h := get_event(F); /* h= (s, d) */
15 ifd then o,1/_,/ t., 1 s)
16 else del ,/, s'i s); vF [segunshared] : true endif;
17 ifdp(h) 7 lastidpinF then lastdpinF7 : dp(h);
18 if not lookahead(h,F) then
19 lastbound_in-F : dp(h);
20 if lastboundin7 = last_boundinG then
21 vF [bound shared] : true
22 else if lastboundin-7 = lastdpin_G then
23 vF [boundon_interior] : true
24 else if not lookahead(h, G) then
25 VF [bounddisjoint] : true
26 endif
27 endif
28 endif;
29 if dp(h) lastboundinlF then
30 if dp(h) = lastboundin_G then
31 vG[boundon_interior] : true
32 else ifdp(h) = lastdpin_G then
33 vF [interiorpoi-shared] : true
34 endif
35 endif


36 else if object = second then h := get_event(G);
37 ... /* like lines 15 to 35 with F and G swapped */
38 else /* object = both */
39 h := getevent(F); vF [segshared] := true;
40 if d then o., l. / I/ \ s) else delj ,,m, 1\ s) endif;
41 if dp(h) lastdpin7 then lastpdpinl := dp(h);
42 if not look-ahead(h,F) then
43 lastboundin 7 : dp(h)
44 endif
45 endif;
46 ifdp(h) 7 lastdpin_G then lastdpinG : dp(h);
47 if not lookahead(h, G) then
48 lastboundinG : dp(h)
49 endif
50 endif;
51 if lastboundin-7 = lastboundin_G then
52 vF [bound-shared]: true
53 else
54 if lastboundin7 = lastdpin_G then
55 vF [boundoninterior] : true
56 endif;
57 if lastboundinG = lastidpin7 then
58 vG[boundoninterior] := true
59 endif
60 endif
61 endif;
62 if status= e *,.i_.- i i hlu-n
63 vG[seg-unshared] := true;
64 else if status = endof second then
65 vF [segunshared] := true;
66 endif
67 select-next(F, G, object, status);
68 endwhile;
69 end ExploreLine2DLine2D.


Figure 14: Algorithm for computing the topological feature vectors for two line2D objects


13). If a single left (right) halfsegment of F (line 14) has to be processed (the same for G (line 36)), we insert
it into (delete it from) the sweep line status (lines 15 and 16). The deletion of a single right halfsegment
further indicates that it is not shared by G (line 16). If the current dominating point, say v, is unequal to the
previous dominating point of F (line 17) and if the operation look_ahead finds out that v is also unequal to
the dominating point of the next halfsegment of F (line 18), v must be a boundary point of F (line 19). In
this case, we perform three checks. First, if v coincides with the current boundary point in G, both objects
share a part of their boundary (lines 20 to 21). Second, otherwise, if v is equal to the current dominating
point, say w, in G, w must be an interior point of G, and the boundary of F and the interior of G share a
point (lines 22 to 23). Third, otherwise, if v is different from the dominating point of the next halfsegment
in G, F contains a boundary point that is disjoint from G (lines 24 to 25). If v has not been identified as a
boundary point in the previous step (line 29), it must be an interior point ofF. In this case, we check whether
it coincides with the current boundary point in G (lines 30 to 31) or whether it is also an interior point in
G (lines 32 to 33). If a halfsegment belongs to both objects (line 38), we can conclude that it is shared by
them (line 39). Depending on whether it is a left or right halfsegment, it is inserted into or deleted from the
sweepline status (line 40). Lines 41 to 45 (46 to 50) test whether the dominating point v of the halfsegment









01 algorithm ExploreLine2DRegion2D
02 input: line2D object F and region2D object G,
03 topological feature vectors vF and vG
04 initialized il1 i.,le
05 output: updated vectors vF and vG
06 begin
07 S := newsweep(); last_dp_in_ := E; lastdp_in_G := E;
08 lastboundin F := E;
09 ,i _,, iF, G, object, status);
10 while status 7 endoffirst and status e en,. 1_. 4*- il
11 and not (vF [seginside] and vF [segshared]
12 and vF [seg-outside] and vF [poishared]
13 and vF [boundinside] and vF [boundshared]
14 and vG[bounddisjoint] and vG[seg-unshared]) do
15 if object =first then h := getevent(F); /* h= (s, d) */
16 if d then o,l /_I, i. \ s)
17 else
18 ifpredexists(S,s) then
19 (m p/np) := getpred_attr(S, s);
20 if np 1 then vF [seginside] : true
21 else vF [segoutside] : true endif
22 else vF [segoutside] : true endif;
23 deli ,,-,,. s);
24 endif;
25 ifdp(h) 7 lastdpin-F then lastdpin l=: dp(h);
26 if not lookahead(h,F) then
27 lastboundin F : dp(h);
28 if last_boundin = lastdp_in_G
29 or lookahead(h,G) then
30 vF [boundshared] : true
31 else
32 if predexists(S,s) then
33 (mp/np) := getpredattr(S, s);
34 if np 1= then vF [bound inside] : true


Figure
object


35 else vF[boundoutside] := true endif
36 else vF [boundoutside] := true endif
37 endif
38 endif
39 endif;
40 ifdp(h) 7 lastboundinF and
41 (dp(h) = lastdp_in_G or lookahead(h, G)) then
42 vF [poishared] :true
43 endif
44 else if object = second then
45 h := get_event(G); ia := get_attr(G);
46 if d then I/ /. 1, l, s); setattr(S, ia)
47 else delj X,/ i G' s); vG[segunshared] := true endif;
48 if dp(h) lastdp_in_G then
49 lastip_inG : dp(h) endif;
50 else /* object = both */ vF [segshared] := true;
51 h := get_event(G); ia := get_attr(G);
52 if d then o, /., / i' 1 s); set_attr(S, ia)
53 else delj ,l-m,i,, s) endif;
54 if dp(h) 7 lastdp_inp F then lastdpinl := dp(h);
55 if not look_ahead(h,F) then
56 vF [boundshared] : true
57 else vF [poishared] : true endif
58 endif;
59 ifdp(h) 7 lastdp_inG then
60 lastdp_inG : dp(h) endif;
61 endif;
62 if status = endof second then
63 vF [segoutside] : true endif;
64 select-next(F, G, object, status);
65 endwhile;
66 if status = endoffirst then
67 vG[segunshared] : true endif
68 end ExploreLine2DRegion2D.


15: Algorithm for computing the topological feature vectors for a line2D object and a region2D


is a boundary point of F (G). Afterwards, we check whether v is a boundary point of both objects (lines
51 to 52). If this is not the case, we examine whether one of them is a boundary point and the other one
is an interior point (lines 54 to 59). Lines 62 to 66 handle the case that exactly one of the two halfsegment
sequences is exhausted.
Let / (m) be the number of halfsegments of F (G). Segments of both objects can intersect or par-
tially coincide (Figure 8), and we handle these topological situations with the splitting strategy described
in Section 4.3. If, due to splitting, k is the total number of additional halfsegments stored in the dynamic
halfsegment sequences of both objects, the while-loop is executed at most / +m + k times. The only opera-
tions needed on the sweep line status are addleft and del_right for inserting and deleting halfsegments; they
require O(log(l+ m + k)) time each. No special predicates have to be deployed for discovering topological
information. Due to the splitting strategy, all dominating end points either are already endpoints of existing
segments or become endpoints of newly created segments. The operation lookahead needs constant time.
In total, the algorithm requires O((l + m +k)log( + m + k)) time and 0( + m + k) space.








5.5 The Exploration Algorithm for the line2D/region2D Case


Next, we describe the exploration algorithm for a line2D object F and a region2D object G. Seen from
the perspective of F, we can distinguish six cases between the interior and boundary of F and the interior,
boundary, and exterior of G. First, the intersection of the interiors of F and G means that a segment of
F lies in G (flag seg_inside). Second, the interior of a segment of F intersects with a boundary segment
of G if either both segments partially or fully coincide (flag segshared), or if they properly intersect in a
single point (flag poishared). Third, the interior of a segment of F intersects with the exterior of G if the
segment is disjoint from G (flag seg_outside). Fourth, a boundary point ofF intersects the interior of G if
the boundary point lies inside of G (flag boundinside). Fifth, if it lies on the boundary of G, we set the flag
bound_shared. Sixth, if it lies outside of G, we set the flag bound_disjoint.
Seen from the perspective of G, we can differentiate the same six cases as before and obtain most of the
topological flags as before. First, if the interiors of G and F intersect, a segment of F must partially or totally
lie in G (already covered by flag seg_inside). Second, if the interior of G and the boundary of F intersect,
the boundary point of a segment of F must be located in G (already covered by flag bound_inside). Third,
the case that the interior of G intersects the exterior of F is always true due to the different dimensionality
of both objects; hence, we do not need a flag. Fourth, if the boundary of G intersects the interior of F,
a segment of F must partially or fully coincide with a boundary segment of G (already covered by flag
seg_shared). Fifth, if the boundary of G intersects the boundary of F, a boundary point of a segment of
F must lie on a boundary segment of G (already covered by flag bound_shared). Sixth, if the boundary of
G intersects the exterior of F, a boundary segment of G must be disjoint from F (new flag seg_unshared).
More formally, we define the semantics of the topological flags as follows:

Definition 5 Let F E line2D, G E region2D, and vF and vG be their topological feature vectors. Then

(i) vF[seg_inside] : f eH(F) Vg H(G):
-seglntersect(f.s,g.s) A seglnRegion (f.s, G)
(ii) vF[seg_shared] : I 3f E H(F) 3g E H(G) : seglntersect(f.s,g.s)
(iii) vF[segoutside] : f H(F) Vg G H(G):
-seglntersect (f.s,g.s) A -seglnRegion(f.s,G)
(iv) vF[poi_shared] : I 3f E H(F) 3g E H(G) : poilntersect(f.s,g.s) A
poilntersection(f.s,g.s) B B(F)
(v) F [bound_inside] : 3 f H(F) : poilnRegion(dp(f),G) A dp(f) E B(F)
(vi) vF[bound shared] : I 3f E H(F) 3g E H(G) : poilntersect(f.s,g.s) A
poilntersection (f.s,g.s) E B(F)
(vii) vF[bounddisjoint] : I 3f e H(F) Vg E H(G) : -poilnRegion(dp(f), G) A
dp(f)E B(F) A -on(dp(f),g.s)
(viii) vG[seg_unshared] :< 3g E H(G) Vf E H(F) : -seglntersect(f.s,g.s)
The operation seglnRegion is assumed to check whether a segment is located inside a region; it is an
imaginary predicate and not implemented as a robust geometric primitive.
The exploration algorithm for this case is given in Figure 15. The while-loop is executed until at least the
first object has been processed (line 10) and as long as not all topological flags have been set to true (lines
11 to 14). In case that we only encounter a halfsegment h ofF (line 15), we insert its segment component s
into the sweep line status if it is a left halfsegment (line 16). If it is a right halfsegment, we find out whether
h is located inside or outside of G (lines 18 to 23). We know that it cannot coincide with a boundary segment
of G, since this is another case. The predicate pred_exists checks whether s has a predecessor in the sweep
line status (line 18); it ignores segments in the sweep line status that stem from F. If this is not the case (line
22), s must lie outside of G. Otherwise, we check the upper overlap number of s's predecessor (line 19).








The overlap number 1 indicates that s lies inside G (line 20); otherwise, it is outside of G (line 21). After
this check, we remove s from the sweep line status (line 23). Next we test whether the dominating point
of h is a boundary point of F (line 26) by using the predicate look_ahead. If this is the case, we determine
whether this point is shared by G (lines 28 to 30) or whether this point is located inside or outside of G (lines
31 to 38). Last, if the dominating point turns out not to be a boundary point of F, we check whether it is an
interior point that shares a boundary point with G (lines 40 to 43). In case that we only obtain a halfsegment
h of G (line 44), we insert its segment component s into the sweep line status and attach the Boolean flag
ia indicating whether the interior of G is above s or not (line 46). Otherwise, we delete a right halfsegment
h from the sweep line status and know that it is not shared by F (line 47). In case that both F and G share
a halfsegment, we know that they also share their segment components (line 50). The sweep line status is
then modified depending on the status of h (lines 52 to 53). If we encounter a new dominating point of F,
we have to check whether F shares a boundary point (lines 55 to 56) or an interior point (line 57) with the
boundary of G. If the halfsegment sequence of G should be exhausted (line 62), we know that F must have a
segment whose interior is outside of G (line 63). If after the while-loop only F is exhausted but not G (line
66), G must have a boundary segment that is disjoint from F (line 67).
Let I be the number of halfsegments of F, m be the number of attributed halfsegments of G, and k be
the total number of new halfsegments created due to our splitting strategy. The while-loop is then executed
at most / + m + k times. All operations needed on the sweep line status require O(log(l + m + k)) time each.
Due to the splitting strategy, all dominating end points are already endpoints of existing segments or become
endpoints of newly created segments. The operation look_ahead needs constant time. In total, the algorithm
requires O((l + m + k) log(l + m + k)) time and O(l + m + k) space.

5.6 The Exploration Algorithm for the region2D/region2D Case
The exploration algorithm for the region2D/region2D case is quite different from the preceding five cases,
since it has to take into account the areal extent of both objects. The indices of the vector fields, with one
exception described below, are not flags as before but segment classes. The fields of the vectors again contain
Boolean values that are initialized withfalse. The main goal of the exploration algorithm is to determine the
existing segment classes in each region2D object. Hence, the topological feature vector for each object is a
segment classification vector. Each vector contains afield for the segment classes (0/1), (1/0), (0/2), (2/0),
(1/2), (2/1), and (1/1). The following definition makes a connection between representational concepts
and point set topological concepts as it is later needed in the evaluation phase. For a segment s = (p, q) E
seg2D, the function pts yields the infinite point set of s as pts(s) {= r E2 r p + X(q p), X c R, O < X <
1}. Further, for F E region2D, we define c)F UfJH(F)pts(f.s), F {p cE R2 IpoilnRegion(p,F) }, and
F R2 _F -F. We can now define the semantics of this vector as follows:

Definition 6 Let F, G E region2D and vF be the segment classification vector ofF. Then
(i) vF[(O/1)] 3fe H(F):f.ia A pts(f.s) C G-
(ii) vF[(1/0)] : f EH(F) : -f.ia A pts(f.s) C G
(iii) vF[(1/2)] : f E H(F):f.ia A pts(f.s) C G
(iv) vF[(2/1)] : f EH(F) : -f.ia A pts(f.s) C G
(v) vF[(0/2)] : f E H(F) 3ge H(G) : f.s = g.s A f.ia A g.ia
(vi) vF[(2/0)] 3f e H(F) 3g H(G) : f.s = g.s A -f.ia A -g.ia
(vii) vF[(1/1)] : 3f EH(F) 3g H(G): f.s g.s A
((f.ia A -g.ia) V (-f.ia A g.ia))
(viii) vF[boundpoishared] : 3f E H(F) 3g E H(G) : f.s f g.s A dp(f) = dp(g)
The segment classification vector VG of G includes the cases (i) to (iv) with F and G swapped; we
omit the flags for the cases (v) to (viii) due to their symmetry (or equivalence) to flags of F. The flag









s S4 S 4
F G G



Figure 16: Special case of the plane sweep.

bound_poishared indicates whether any two unequal boundary segments of both objects share a common
point. Before the splitting, such a point may have been a segment endpoint or a proper segment intersection
point for each object. The determination of the boolean value of this flag also includes the treatment of a
special case illustrated in Figure 16. If two regions F and G meet in a point like in the example, such a
topological meeting situation cannot be detected by a usual plane sweep. The reason is that the plane sweep
forgets completely about the already visited segments (right halfsegments) left of the sweep line. In our
example, after sl and s2 have been removed from the sweep line status, any information about them is lost.
When s3 is inserted into the status sweep line, its meeting with s2 cannot be detected. Our solution is to
look ahead in object G for a next halfsegment with the same dominating point before s2 is removed from the
sweep line status.
The segment classification is computed by the algorithm in Figure 17. The while-loop is executed as
long as none of the two objects has been processed (line 8) and as long as not all topological flags have been
set to true (lines 8 to 12). Then, according to the halfsegment order, the next halfsegment h is obtained,
which belongs to one or both objects, and the variables for the last considered dominating points in F and/or
G are updated (lines 13 to 20). Next, we check for a possible common boundary point in F and G (lines 21 to
25). This is the case if the last dominating points ofF and G are equal, or the last dominating point in F (G)
coincides with the next dominating point in G (F). The latter algorithmic step, in particular, helps us solve
the special situation in Figure 16. If h is a right halfsegment (line 26), we update the topological feature
vectors ofF and/or G correspondingly (lines 27 to 32) and remove its segment component s from the sweep
line status (line 33). In case that h is a left halfsegment, we insert its segment component s into the sweep
line status (line 34) according to the y-order of its dominating point and the y-coordinates of the intersection
points of the current sweep line with the segments momentarily in the sweep line status. If h's segment
component s either belongs to F or to G, but not to both objects, and partially coincides with a segment
from the other object in the sweep lines status, our splitting strategy is applied. Its effect is that the segment
we currently consider suddenly belongs to both objects. Therefore, we modify the object variable in line 35
correspondingly. Next, we compute the segment class of s. For this purpose, we determine the lower and
upper overlap numbers mp and np of the predecessor p of s (lines 36 to 37). If there is no predecessor, mp
gets the 'undefined' value '*'. The segment classification of the predecessor p is important since the lower
overlap number m, of s is assigned the upper overlap number np of p, and the upper overlap number n, of s
is assigned its incremented or decremented lower overlap number, depending on whether the Boolean flag



ns 1 2 1 2 1 2 0 1 2 0 1 2 0 1 2 0 1 0 1
ms 0 0 0 0 0 0 1 1 1 1 1 1 1 1 1 2 2 2 2
p 0 0 0 0 1 1 1 1 1 1 1 1 1 2 2 2 2
mp 1 1 2 2 0 0 0 1 1 1 2 2 2 0 0 1 1



Table 3: Possible segment class constellations between two consecutive segments in the sweep line status.









01 algorithm ExploreRegion2DRegion2D
02 input: region2D objects F and G, topological feature
03 vectors vF and vG initialized A ili i i, e
04 output: updated vectors vF and vG
05 begin
06 S:= new-sweep); lastdp_in_ := E; lastdp_in_G := E;
07 . _il, '"F, G, object, status);
08 while status = endof-none and not (vF[(0/1)] and vF[(1,
09 andvF[(1/2)] andvF[(2/1)] andvF[(0/2)] and
10 VF[(2/0)] and vF[(1/1)] and vF[bound_poishared]
11 and vG[(0/1)] andvG[(1/0)] and vG[(1/2)] and
12 VG[(2/1)])do
13 if object =first then /* h = (s,d) */
14 h := get_event(F); lastdp_inF := dp(h)
15 else if object = second then
16 h := get_event(G); lastdpinG := dp(h)
17 else /* object = both */
18 h := get_event(F);
19 lastdp_in_ := dp(h); lastdpinG := dp(h)
20 endif;
21 if lastidpin- = lastdpin_G
22 or last-dpinF = look_ahead(h, G)
23 or lastdpinG = look_ahead(h, F) then
24 vF [bound_poishared] := true
25 endif;
26 if d = right then
27 {(ms/n,)} := get_attr(S);
28 if object -first then vF[(ms/ns)] := true


29 else if object = second then vG[(ms/ns)] := true
30 else if object = both then
31 vF [(ms/ns) := true; vG[(ms/ns) := true
32 endif;
33 del, ,s,. s)
34 else O, 4l., s);
35 if coincident(S, s) then object := both endif;
'0)] 36 if not predexists(S, s) then (mp/np) : (*/0)
37 else {(mp/np)} := getpredattr(S) endif;
38 ms : np; ns : p;
39 if object =first or object = both then
40 ifgetattr(F) then ns : ns + 1
41 else ns : ns -1 endif
42 endif;
43 if object = second or object = both then
44 if get_attr(G) then ns := n + 1
45 else ns : ns -1 endif
46 endif;
47 setattr(S, {(ms/ns)});
48 endif;
49 select-next(F, G, object, status);
50 endwhile;
51 if status = endoffirst then
52 VG[(0/1)] : true; vG[(1/0)] : true
53 else if status = endof-second then
54 vF[(0/1)] : true;vF[(1/0)] : true
55 endif
56 end ExploreRegion2DRegion2D.


Figure 17: Algorithm for computing the topological feature vectors for two region2D objects


'Interior Above' obtained by the predicate get_attr is true or false respectively (lines 39 to 46). The newly
computed segment classification is then attached to s (line 47). The possible 19 segment class constellations
between two consecutive segments in the sweep line status are shown in Table 3. The table shows which
segment classes (ms/ns) a new segment s just inserted into the sweep line status can get, given a certain
segment class (mp/np) of a predecessor segment p. The first two columns show the special case that at
the beginning the sweep line status is empty and the first segment is inserted. This segment can either be
shared by both region objects ((0/2)-segment) or stems from one of them ((0/1)-segment). In all these
cases (except the first two cases), np = ms must hold.
Let I be the number of attributed halfsegments of F, m be the number of attributed halfsegments of
G, and k be the total number of new halfsegments created due to our splitting strategy. The while-loop
is then executed at most l+ m +k times. All operations needed on the sweep line status require at most
O(log(l + m + k)) time each. The operations on the halfsegment sequences ofF and G need constant time.
In total, the algorithm requires O((l + m +k)log(l + m + k)) time and O(l +m + k) space.


6 Direct Predicate Characterization as a Simple Evaluation Method

In the previous section we have developed sophisticated and efficient algorithms for the computation of the
topological feature vectors vF and VG of two complex spatial objects F, G {point2D, line2D, region2D}.
The vectors vF and vG contain specific topological feature flags for each type combination. The flags capture
all topological situations between F and G and are different for different type combinations. Consequently,
each type combination has led to a different exploration algorithm.








0 0 1 1 0 0
0 1 1 1 0 0


(a) (b)

Figure 18: The 9-intersection matrix number 8 for the predicate meet between two line2D objects (a) and
the 9-intersection matrix number 7 for the predicate inside between two region2D objects (b)

In this section, we present a first method for the evaluation phase whose objective it is to uniquely
characterize the topological relationship of two given spatial objects of any type combination. Our general
evaluation strategy is to leverage the information kept in the topological feature vectors and accommodate
the objects' mutual topological features with an existing topological predicate for both predicate verification
and predicate determination. The method presented here provides a direct predicate characterization of
all s topological predicates of each type combination (see Table l(b) for the different values of s) that is
based on the feature values of vF and vG of the two spatial argument objects F and G. For example, for
the line2D/line2D case, we have to determine which topological flags of vF and VG must be turned on and
which flags must be turned off so that a given topological predicate (verification query) or a predicate to be
found (determination query) is fulfilled. For the region2D/region2D case, the central question is to which
segment classes the segments of both objects must belong so that a given topological predicate or a predicate
to be found is satisfied. The direct predicate characterization gives an answer for each individual predicate
of each individual type combination. This means that we obtain 184 individual predicate characterizations
without converse predicates and 248 individual predicate characterizations with converse predicates. In
general, each characterization is a Boolean expression in conjunctive normal form and expressed in terms
of the topological feature vectors vF and vG.
We give two examples of direct predicate characterizations. As a first example, we consider the topo-
logical predicate number 8 (meet) between two line2D objects F and G (Figure 18(a) and [45]) and see how
the flags of the topological feature vectors (Definition 4) are used.

P8 (F, G) : -_vF [seg_shared] A -VF [interiorpoi_shared] A vF [seg_unshared] A
-VF[bound_oninterior] A vF[boundshared] A vF[bound_disjoint] A
vG[seg_unshared] A -vG [bound_on_interior] A v [bound_disjoint]
If we take into account the semantics of the topological feature flags, the right side of the equivalence
means that both objects may only and must share boundary parts. More precisely and by considering the
matrix in Figure 18(a), intersections between both interiors (-vF[seg_shared], -vF [interiorpoi_shared])
as well as between the boundary of one object and the interior of the other object (-vF [bound_on_interior],
-VG [bound_on_interior]) are not allowed; besides intersections between both boundaries (vF [bound_shared),
each component of one object must interact with the exterior of the other object (vF[seg_unshared],
vG[seg_unshared], vF[bound disjoint], vG[bound disjoint]).
Next, we view the topological predicate number 7 (inside) between two region2D objects F and G
(Figure 18(b) and [45]) and see how the segment classes kept in the topological feature vectors (Definition 6)
are used.

p7(F,G) : -vFF[(O/1)] A -vF[(1/O)] A -vF[(0/2)] A -vF[(2/0)] A -vF[(1/1)] A
-vF[boundpoishared] A (vF[(1/2)] V vF[(2/1)]) A
fvG[(1/2)] A -vG[(2/1)] A (vG[(0/1)] V vG[(1/0)])
For the inside predicate, the segments of F must be located inside of G since the interior and boundary
of F must be located in the interior of G; hence they must all have the segment classes (1/2) or (2/1). This






















(a) (b)


Figure 19: Predicate verification (a) and predicate determination (b) based on the direct predicate charac-
terization method

"for all" quantification is tested by checking whether vF [(1/2)] or vF [(2/1)] are true and whether all other
vector fields are false. The fact that all other vector fields are false means that the interior and boundary
of F do not interact with the boundary and exterior of G. That is, the segments of G must be situated
outside of F, and thus they all must have the segment classes (0/1) or (1/0); other segment classes are
forbidden for G. Further, we must ensure that no segment of F shares a common point with any segment of
G (-vF [boundpoi_shared]).
The predicate characterizations can be read in both directions. If we are interested in predicate verifica-
tion, i.e., in evaluating a specific topological predicate, we look from left to right and check the respective
right side of the predicate's direct characterization (Figure 19(a)). This corresponds to an explicit imple-
mentation of each individual predicate. If we are interested in predicate determination, i.e., in deriving the
topological relationship from a given spatial configuration of two spatial objects, we have to look from right
to left. That is, consecutively we evaluate the right sides of the predicate characterizations by applying them
to the given topological feature vectors vF and vG. For the characterization that matches we look on its left
side to obtain the name or number of the predicate (Figure 19(b)).
The direct predicate characterization demonstrates how we can leverage the concept of topological fea-
ture vectors. However, this particular evaluation method has three main drawbacks. First, the method
depends on the number of topological predicates. That is, each of the 184 (248) topological predicates be-
tween complex spatial objects requires an own specification. Second, in the worst case, all direct predicate
characterizations with respect to a particular type combination have to be checked for predicate determina-
tion. Third, the direct predicate characterization is error-prone. It is difficult to ensure that each predicate
characterization is correct and unique and that all predicate characterizations together are mutually exclusive
and cover all topological predicates. From this standpoint, this solution is an ad hoc approach. In [37] we
present a sophisticated approach that avoids these shortcomings and has a formal foundation.


7 Implementation and Testing of the Approach

To verify the feasibility, practicality, and correctness of the concepts presented, we have implemented and
tested our approach. The system implementation of the algebra package SPAL2D (Section 3.1) for handling
two-dimensional spatial data includes the implementation of all six exploration algorithms from Section 5.
These algorithms are implemented at the highest level SDT2D (Figure 3). The implementation makes use








of the complex spatial data types point2D, line2D, and region2D, as they have been specified in Section 3.4.
Since performance is one of the goals of this implementation, C++ is our employed programming language.
A universal interface method TopPredExploration is provided to explore the topological events of two
interacting spatial objects. This interface is overloaded to accept two spatial objects of any type combination
as input. The output consists of two topological feature vectors which hold the topological information for
both argument objects. This information is then used to identify the corresponding topological predicate.
Since the direct predicate characterization method has proved to be an ad hoc, error-prone, and inefficient
solution for this purpose, we have not fully implemented this method (i.e., all 184 characterizations). Instead,
an efficient, well-founded, and systematical method described in [37] has been implemented for this purpose.
Our implementation incorporating the data structures for the spatial data types and the exploration al-
gorithms underwent various tests in order to verify the correctness of the concepts. We use a mixture of
black-box3 and white-box4 testing techniques known as gray-box5 testing. The black-box testing part ar-
ranges for well defined input and output objects. Each input object is a correct element of one of our spatial
data types. Each output is guaranteed to be a topological feature vector and is tailored to the respective type
combination. This enables us to test the functional behavior of our implementation by designing a collec-
tion of test cases to cover all type combinations of spatial objects as input and all possible values (true and
false) of all topological feature flags as output. The white-box testing part considers every single execution
path and guarantees that each statement is executed at least once. This ensures that all special cases that
are specified and handled by the algorithms are properly tested. Our collection of test cases consists of 184
different scenes corresponding to the total number of topological predicates between spatial objects. They
have been successfully tested and verified and indicate the correctness of our concepts and the ability of our
algorithms to correctly discover the needed topological information from any given scene.
A special test case generation technique has been leveraged to check the functionality of the exploration
algorithms and the correctness of the resulting values of the topological feature vectors. The vector values
have to be independent of the location of the two spatial objects involved. In order to check this, this
technique is able to generate arbitrarily many different orientations of a topologically identical scene of two
spatial objects with respect to the same sweep line and coordinate system. The idea is to rotate such a scene
by a random, rational angle around a central reference point. Special test cases including vertical segments
or a meeting situation like in Figure 16 are considered too. For this rotation scenario, we especially take
care of maintaining the robustness of geometric computation and preserving the topological consistency of a
scene. We ensure that segment end points are rotated to end points with rational coordinates (and not floating
point coordinates) by involving the Newton Method for approximating the results of numerical computations
by rational numbers from our special rational number system RATIO (Section 3.1). Intersecting segments
are broken up into four segments in advance.
Starting with a set of 184 explicitly constructed base cases (one for each topological predicate) which
cover the special test cases if possible, we have generated at least 20,000 test cases for the topological
predicates of each of the six type combinations by our random scene rotation technique. In total, more than
120,000 test cases have been successfully generated, tested, and checked in the exploration phase. All test
cases have been checked for predicate verification and predicate determination.

3Black box testing takes an external perspective of the test object to derive test cases and does not consider the internal structure
of the test object. The test designer selects valid and invalid input, determines the correct output, and checks the correctness of the
functional behavior of the test object.
4White box testing takes an internal perspective of the test object and designs test cases based on its internal structure. The tester
chooses test case inputs to exercise all paths through the software and determines the appropriate outputs. It requires programming
skills to identify all paths through the software.
5Gray box testing maintains the advantages of black-box and white-box testing and is not impeded by the limitations of each
particular one.








8 Conclusions and Future Work


While, from a conceptual perspective, topological predicates have been investigated to a large extent, the
design of efficient implementation methods for them has been widely neglected. Especially due to the
introduction of complex spatial data types, the resulting increase of topological predicates between them
asks for efficient and correct implementation concepts. Our approach has been implemented as part of our
SPAL2D software library which is a sophisticated spatial type system currently under development and
determined for an integration into extensible databases. We propose a two-phase approach which consists
of an exploration phase and an evaluation phase and which can be applied to both predicate verification
and predicate determination. The goal of the exploration phase is to traverse a given scene of two objects in
space, collect any topological information of importance, and store it in topological feature vectors. The goal
of the evaluation phase is to interpret the gained topological information and match it against the topological
predicates. In this article, we have focused on the exploration phase and in detail developed exploration
algorithms for all type combinations.
Future work refers to the design of efficient and correct evaluation methods that interpret and match the
information provided by the topological feature vectors against the topological predicates. In this article,
we have presented the direct characterization method as a first solution. However, we have also pointed out
its shortcomings. In [37] we propose evaluation methods that are robust, correct, and independent of the
number of topological predicates of a particular type combination and that have a formal basis.


References

[1] J. F. Allen. Maintaining Knowledge about Temporal Intervals. C,,i,,,iioaoii,,,rin oftheACM, 26:832-
843, 1983.
[2] T Behr and M. Schneider. Topological Relationships of Complex Points and Complex Regions. Int.
Conf on Conceptual Modeling, pp. 56-69, 2001.
[3] M. de Berg, M. van Krefeld, M. Overmars, and O. Schwarzkopf. Computational Geometry: A'!g il\,
andApplll i~,h' Springer-Verlag, 2nd edition, 2000.
[4] A. Brodsky and X. S. Wang. On Approximation-based Query Evaluation, Expensive Predicates and
Constraint Objects. Int. Workshop on Constraints, Databases, and Logic Programming, 1995.
[5] J. Claussen, A. Kemper, G. Moerkotte, K. Peithner, and M. Steinbrunn. Optimization and Evaluation
of Disjunctive Queries. IEEE Trans. on Knowledge and Data Engineering, 12(2):238-260, 2000.
[6] E. Clementini and P. Di Felice. A Model for Representing Topological Relationships between Complex
Geometric Features in Spatial Databases. Information Systems, 90(1-4):121-136, 1996.
[7] E. Clementini and P Di Felice. Topological Invariants for Lines. IEEE Trans. on Knowledge and Data
Engineering, 10(1), 1998.
[8] E. Clementini, P. Di Felice, and G. Califano. Composite Regions in Topological Queries. Information
Systems, 20(7):579-594, 1995.
[9] E. Clementini, P. Di Felice, and P. van Oosterom. A Small Set of Formal Topological Relationships
Suitable for End-User Interaction. 3rd Int. Symp. on Advances in Spatial Databases, LNCS 692, pp.
277-295, 1993.
[10] E. Clementini, J. Sharma, and M.J. Egenhofer. Modeling Topological Spatial Relations: Strategies for
Query Processing. Computers and Graphics, 18(6):815-822, 1994.
[11] Z. Cui, A. G. Cohn, and D. A. Randell. Qualitative and Topological Relationships. 3rd Int. Symp. on
Advances in S\Il,,,l/ Databases, LNCS 692, pp. 296-315, 1993.








[12] J.R. Davis. IBM's DB2 Spatial Extender: Managing Geo-Spatial Information within the DBMS.
Technical report, IBM Corporation, 1998.
[13] M. J. Egenhofer. A Formal Definition of Binary Topological Relationships. 3rdInt. Conf on Founda-
tions of Data Ogoiil:riii, andAlg.', ill1i, LNCS 367, pp. 457-472. Springer-Verlag, 1989.
[14] M. J. Egenhofer. Definitions of Line-Line Relations for Geographic Databases. 16th Int. Conf on
Data Engineering, pp. 40-46, 1993.
[15] M. J. Egenhofer. Spatial SQL: A Query and Presentation Language. IEEE Trans. on Knowledge and
Data Engineering, 6(1):86-94, 1994.
[16] M. J. Egenhofer and R. D. Franzosa. Point-Set Topological Spatial Relations. Int. Journal of Geo-
graphical Information Systems, 5(2):161-174, 1991.
[17] M. J. Egenhofer and J. Herring. A Mathematical Framework for the Definition of Topological Rela-
tionships. 4th Int. Symp. on Spatial Data Handling, pp. 803-813, 1990.
[18] M. J. Egenhofer and J. Herring. Categorizing Binary Topological Relations Between Regions, Lines,
and Points in Geographic Databases. Technical Report 90-12, National Center for Geographic Infor-
mation and Analysis, University of California, Santa Barbara, 1990.
[19] M. J. Egenhofer and D. Mark. Modeling Conceptual Neighborhoods of Topological Line-Region
Relations. Int. Journal of Geographical Information Systems, 9(5):555-565, 1995.
[20] M.J. Egenhofer. Deriving the Composition of Binary Topological Relations. Journal of Vi,,% Lan-
guages and Computing, 2(2): 133-149, 1994.
[21] M.J. Egenhofer, E. Clementini, and P. Di Felice. Topological Relations between Regions with Holes.
Int. Journal of Geographical Information Systems, 8(2):128-142, 1994.
[22] ESRI Spatial Database Engine (SDE). Environmental Systems Research Institute, Inc., 1995.
[23] S. Gaal. Point Set Topology. Academic Press, 1964.
[24] V. Gaede and O. Gunther. Multidimensional Access Methods. ACM Computing Surveys, 30(2):170-
231, 1998.
[25] R. H. Guting. Geo-Relational Algebra: A Model and Query Language for Geometric Database Sys-
tems. Int. Conf on Extending Database Technology, pp. 506-527, 1988.
[26] R. H. Guting and M. Schneider. Realms: A Foundation for Spatial Data Types in Database Systems.
3rdlnt. Symp. on Advances in Spatial Databases, LNCS 692, pp. 14-35. Springer-Verlag, 1993.
[27] R. H. Guting and M. Schneider. Realm-Based Spatial Data Types: The ROSE Algebra. VLDB Journal,
4:100-143, 1995.
[28] R.H. Guting, T. de Ridder, and M. Schneider. Implementation of the ROSE Algebra: Efficient Algo-
rithms for Realm-Based Spatial Data Types. Int. Symp. on Advances in Spatial Databases, 1995.
[29] J. M. Hellerstein. Practical Predicate Placement. ACMSIGMOD Int. Conf on Management of Data,
pp. 325-335.
[30] J. M. Hellerstein and M. Stonebraker. Predicate Migration: Optimizing Queries with Expensive Pred-
icates. ACM SIGMOD Int. Conf on Management ofData, pp. 267-276, 1993.
[31] Informix Geodetic DataBlade Module: User's Guide. Informix Press, 1997.
[32] JTS Topology Suite. Vivid Solutions. URL: http://www.vividsolutions.com/JTS/JTSHome.htm.
[33] OGC Abstract Specification. OpenGIS Consortium (OGC), 1999. URL:
http://www.opengis.org/techno/specs.htm.








[34] OGC Geography Markup Language (GML) 2.0. OpenGIS Consortium (OGC), 2001. URL:
http://www.opengis.net/gml/01-029/GML2.html.
[35] Oracle8: Spatial Cartridge. An Oracle Technical White Paper. Oracle Corporation, 1997.
[36] J. A. Orenstein and F. A. Manola. PROBE Spatial Data Modeling and Query Processing in an Image
Database Application. IEEE Trans. on Software Engineering, 14:611-629, 1988.
[37] R. Praing and M. Schneider. Efficient Implementation Techniques for Topological Predicates on Com-
plex Spatial Objects: The Evaluation Phase. Technical report, University of Florida, Department of
Computer & Information Science & Engineering, 2006.
[38] F. P. Preparata and M. I. Shamos. Computational Geometry. Springer Verlag, 1985.
[39] M. A. Rodriguez, M. J. Egenhofer, and A. D.Blaser. Query Pre-Processing of Topological Constraints:
Comparing a Composition-Based with Neighborhood-Based Approach. Int. Symp. on .S/l,,ld and
Temporal Databases, LNCS 2750, pp. 362-379. Springer-Verlag, 2003.
[40] N. Roussopoulos, C. Faloutsos, and T Sellis. An Efficient Pictorial Database System for PSQL. IEEE
Trans. on Software Engineering, 14:639-650, 1988.
[41] M. Schneider. .S~pill Data Types for Database Systems Finite Resolution Geometry for Geographic
Information Systems, volume LNCS 1288. Springer-Verlag, Berlin Heidelberg, 1997.
[42] M. Schneider. Implementing Topological Predicates for Complex Regions. Int. Symp. on Spatial Data
Handling, pp. 313-328, 2002.
[43] M. Schneider. Computing the Topological Relationship of Complex Regions. 15th Int. Conf on
Database and Expert Systems A1ppli ,,I, i pp. 844-853, 2004.
[44] M. Schneider and T. Behr. Topological Relationships between Complex Lines and Complex Regions.
Int. Conf on Conceptual Modeling, 2005.
[45] M. Schneider and T Behr. Topological Relationships between Complex Spatial Objects. ACM Trans.
on Database Systems, 31(1):39-81, 2006.
[46] M.F. Worboys and P. Bofakos. A Canonical Model for a Class of Areal Spatial Objects. 3rdlnt. Symp.
on Advances in Spatial Databases, LNCS 692, pp. 36-52. Springer-Verlag, 1993.




University of Florida Home Page
© 2004 - 2010 University of Florida George A. Smathers Libraries.
All rights reserved.

Acceptable Use, Copyright, and Disclaimer Statement
Last updated October 10, 2010 - - mvs