You are using an outdated browser that does not fully support the intranda viewer.
As a result, some pages may not be displayed correctly.

We recommend you use one of the following browsers:

Full text

The 3rd ISPRS Workshop on Dynamic and Multi-Dimensional GIS & the 10th Annual Conference of CPGIS on Geoinformatics
Chen, Jun

ISPRS, Vol.34, Part 2W2, “Dynamic and Multi-Dimensional GIS", Bangkok, May 23-25, 2001
ystem: the real
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
system for
and other
al solutions to
this, the geo-
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
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
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,
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
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).