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. 
4. CAPTURING THE WORLD IN A GEO-DBMS: DATA 
DEFINITIONS OF 2D AND 3D FEATURES 
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 
SDO_GEOMETRY as: 
CREATE TYPE sdo_geometry AS OBJECT ( 
SDO_GTYPE NUMBER, 
SDO_SRID NUMBER, 
SDO_POINT SDO_POINT_TYPE, 
SDO_ELEM_INFO MDSYS.SDO_ELEM_INFO_ARRAY, 
SDO_ORDINATES MDSYS.SDO_ORDINATE_ARRAY); 
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 
rectangle: 
(6,30) 
(9, 30) 
SDO_GEOMETRY Colunn = 
SDO_GTYPE < 9 ' 21 > 
SDO_SRID = NULL 
SDO_POINT = NULL 
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 
stored. 
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