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
Figure 4: Geometry types supported by the object-relation
model in Oracle
more complex objects and concepts including curves and
surfaces in 2D and 3D, arcs and circle interpolations, conics,
polynomial splines, topology and solids. The interfaces will
cover creation, querying, modifying, translating, accessing,
fusing, and transferring geospatial information.
One of the aims of the use of geo-data is to capture the real
world into computer models to get a better understanding of the
world. The main part of this modelling process is to develop a
model based on (relevant) objects in the real world. The
Kadaster works with a data model for features in 2D (see Figure
5). This data model is maintained in a geo-DBMS.
The object-relational model in Oracle defines the object type
CREATE TYPE sdo_geometry AS OBJECT (
SDO_GTYPE indicates the type of the geometry (point,
linestring, polygon, multipoint, multilinestring, multipolygon).
SDO_SRID is a reference to the spatial reference system used
for the ordinates. SDO_ELEM_INFO is defined using a varying
length array of numbers. These attributes show how to interpret
the ordinates stored in the SDO_ORDINATES attribute. They
include type of element (point, linestring consisting of straight
lines, linestring consisting of circular arcs, polygon). A geometry
object is composed of elements.
A z-value can be used to define the geometry objects. However,
spatial index creation and geometry functions ignore the z-
values in the current version of Oracle (8.1.7).
An example of using the object-relational model to represent a
(9, 30)
SDO_GTYPE < 9 ' 21 >
SDO_ELEM_INFO = (1,1003,3)
SDO_ORDINATES = (6,21,9,30) )
In SDO_GTYPE, the 2 indicates two-dimensional and the 3
indicates a polygon. In SDO_ELEM_INFO, the final 3 in
1,1003,3 indicates that this is a rectangle. Because it is a
rectangle, only two co-ordinates are specified (lower-left 12,15
and upper-right 15,24).
Besides, the tables representing the geometry objects, metadata
is maintained, describing the dimension, lower and upper
bounds and tolerance in each dimension. This metadata is
stored in a global table.
Curves and surfaces are not yet implemented in the commercial
DBMSs. Specifications for complex features as well as for 3D
geometry objects are currently being developed by OGC (OGC,
1998) in co-operation with ISO (ISO TC211, 2001). On the OGC
meeting in April 2001, Liège, a request for proposal on this topic
was issued (OGC (2), 2001). The request aims to extend the
interfaces in the OpenGIS Simple Features Implementation
Specification. The new interfaces will build on the OpenGIS
Simple Features Specification to address feature collections and
The model that is currently used for 2D features will be extended
with 3D features in case the situation requires this. For this, a
data model is defined for 3D features. In the next subsections
the currently used geometric model is described to represent 2D
features (parcels), followed by considerations for maintaining 3D
features in the DBMS.
World (reality)
Conceptual model
Physical storage Logical model
Figure 5: capturing reality: from world to physical storage
4.1 Spatial model for 2D features
The currently used data model for the cadastral system (for
maintaining data on parcels as well as on the legal status of
parcels) is described in Oosterom and Lemmen (2001). The
spatial part of this data model will be described in the following.
The spatial data are represented in the DBMS using geometric
data types such as ‘point’, ‘line’ and ‘box’. In addition to the use
of these data types, explicit topology and historic information are
The most important tables are boundary (cadastral boundaries)
and parcel (parcel identifiers). The spatial extension of the
objects in the tables boundary and parcel is indicated with a
minimal bounding rectangle of type ‘box’. The box covers a
boundary or a complete parcel. The box can be spatially indexed
and is useful for efficient retrieval purposes based on rectangle
selections. There is no need for the geometric data type
‘polygon’, because the area features are stored topologically in
the parcel table and boundary table using the so-called
‘CHAIN-method’. The edges in the boundary table contain
references to other edges according to the winged edge
structure (Baumgart, 1975), which are used to form the complete
boundary chains.
This approach allows calculations on correctness of topology
after adjustment of the surveyed new boundaries to the
cadastral data. Furthermore, it opens the possibility to relate
attributes to the boundaries between parcels, e.g. relation to the
source documents of surveying, date of survey, names of
persons locating the boundary, etc. If each parcel would be