ISPRS, Vol.34, Part 2W2, “Dynamic and Multi-Dimensional GIS", Bangkok, May 23-25, 2001 
271 
ystem: the real 
cels; 
into parts that 
of objects with 
ject (e.g. a cable 
egistered under 
dant information 
surface will be 
al-world objects 
and can be 
representation of 
2 exchange and 
situation and a 
of the Kadaster 
on the tasks and 
tate objects; 
of real estate 
.irai land). In this 
led as a system, 
factual situation 
rant with respect 
hrough spatially 
surface as 3D 
n. Whether this 
id to the juridical 
îe scope of this 
cne geo-DBMS, 
ake the juridical 
ion into account 
Van Oosterom, 
-objects in the 
s will also be 
ither implicit or 
d) between the 
parcels on the 
objects in the 
m is translated 
ntations cover 
to a geo-DBMS 
and inserting 
the (2D) geo- 
trative, 2D, 3D 
ands’ Kadaster 
parcels (and 
andmeetkundig 
system for 
and other 
Automatisering 
Registration) 
al solutions to 
this, the geo- 
geo-DBMS 
Due to the complexity of spatial features, topology and geometry 
spatial features used to be handled outside standard DBMSs 
within middleware and frontend Geographical Information 
Systems. This is not the optimal approach since this causes: 
the re-implementation of the same functionality many times; 
that other direct DBMS users might corrupt the data 
structure; 
non-optimal query plans (DBMS knows only 'half of the 
characteristics of the data); 
overhead and data transfer between DBMS and 
middleware during query execution; 
non optimal management of the data, since GISs do not 
have the extended data-management functionalities 
DBMSs have. 
The need for using a DBMS to store and manage spatial data is 
further enforced with the growing amount of (digital) spatial data, 
the growing number of users and disciplines and the growing 
complexity of geo-data. A geo-DBMS for managing geo-data 
(geometry as well as attributes) enhances the accessibility, 
security, consistency and integrity of spatial data and spatially 
linked data. 
In conclusion, general and reusable tasks should be executed 
within the DBMS, other distinct tasks has to remain to the 
specific application (Van Oosterom et al., 2000). 
Nowadays, the architecture of GISs is changing: systems are 
increasingly based on the integrated architecture, that is also 
storing geometric data (metric as well as topology) in the DBMS 
together with administrative data. The first step was to have data 
types and operators for the geometric primitives: point, line and 
polygon. This has reached the level of standardisation and is 
now implemented in several commercial DBMSs (see the next 
subsection). In case of large data sets, spatial indexing and 
clustering are also required, but outside the scope of 
standardisation. A spatial index is a structure supporting the 
spatial range queries by efficiently providing the addresses of 
the requested features. Spatial clustering makes sure that these 
addresses are physically close on disk and in this way too many 
inefficient ‘jumping’ on the disk is avoided. The subsequent step 
is also having support for the topologically structured features in 
the DBMS, that is complex features. With this the DBMS can 
check and guarantee consistency and complex operations can 
be executed within the DBMS. The support of spatial data types 
in DBMSs include: 
spatial operators (or geometry functions); 
spatial indexing; 
spatial clustering; 
topology management. 
Based on these ingredients spatial queries can be stated (and 
answered efficiently). In case a spatial query involves two tables, 
each having at least one spatial attribute, which are used in a 
spatial operator in the where-clause, then this is called a spatial 
join. 
3.2 DBMS, SQL and spatial features 
Conventional DBMSs (Oracle, IBM DB2, Informix, Ingres) have 
implemented spatial data types and spatial functions more or 
less similar to the OpenGIS Consortium (OGC) Simple Features 
Specification for SQL (OGC, 1999). 
The purpose of this specification is to define a standard SQL that 
supports storage, retrieval, query and update of simple spatial 
features. A simple feature is defined by the OpenGIS 
Implementation Specification to have both spatial and non- 
spatial attributes. Simple features are based on 2D geometry 
with linear interpolation between vertices. 
Simple spatial feature collections are conceptually stored as 
tables (layers) with geometry valued columns in a relational 
DBMS: each feature is stored as a row in a table. The spatial 
attributes of features are columns whose SQL data types are 
based on the underlying concept of additional geometric data 
types for SQL. The specification describes a standard set of 
SQL Geometry Types based on the OpenGIS Geometry Model 
(OGC, 2001), together with the SQL functions of those types. 
The base Geometry class has subclasses for Point, Curve, 
Surface and Geometry Collection. The defined geometric 
collections classes in 0, 1 and 2D are: Multipoint, MultiLineString 
and MultiPolygon for modelling geometries corresponding to 
collections of Points, LineStrings and Polygons respectively. 
MultiCurve and MultiSurface are introduced as abstract 
superclasses that generalise the collection interfaces to handle 
Curves and Surfaces. The attributes, methods and assertions for 
each geometry class are described in the specification (OGC, 
1999). 
The object model for geometry with the supported spatial data 
types is shown in Figure 3. 
Figure 3:the geometry object model defined by OGC (1999) 
An example, not strictly following the geometry model of the 
OGC, of the implementation of spatial functionality is the object- 
relational model in Oracle 8/ spatial (Oracle, 1999). A geometry 
is stored as an object, in a single row, in a column of type 
MDSYS.SDOJ3EOMETRY Supported data types, besides 
point, line string and polygon are shown in Figure 4. 
Oracle 8i offers several types of spatial indices: fixed grids, 
quadtree-like tiling and r-trees. Besides the overlap query 
functionality, that is using the operator sdo_relate, Oracle has 
three other spatial operators: 
sdo_filter (find overlap only based on bounding boxes); 
sdo_within_distance (find objects within a given distance 
from the query geometry); 
sdo_nn (find the nearest neighbours from the query 
geometry). 
Note that spatial operators need a spatial index in order to work. 
Other spatial functionality in Oracle is available through several 
interesting geometry functions (not needing a spatial index) such 
as sdo_area and sdojength (to obtain characteristics from the 
query geometries), sdo_buffer (to compute a buffer around a 
query geometry) and sdojntersection (to clip spatial data from 
the source tables with the query geometries).