ISPRS, Vol.34, Part 2W2, “Dynamic and Multi-Dimensional GIS”, Bangkok, May 23-25, 2001 
boundary of each enclave. If a parcel has more than one 
enclave, then these additional references from parcel to 
boundary are stored in another table, called parcel_over, which 
can store up to 10 references. In case more references are 
needed, more parcel_over records are used. The structure of the 
topological references and the relationship between parcels and 
boundaries is visualised in Figure 6. The spatial database 
contains the geometric representation of the boundaries of about 
7 million parcels (Oosterom and Lemmen, 2001). 
Figure 6: topology model in the spatial DBMS of the 
Kadaster 
4.2 Spatial model for 3D Features 
The data model for 2D features will be extended with a data 
model for 3D features. This data model will be used to represent 
the relevant spatial properties of real world objects. 
Storing 3D co-ordinates and topology references is not a 
problem in current DBMSs. However, 3D models are not 
supported by DBMSs. They do not recognise the stored topology 
as such, nor can they perform a 3D spatial indexing or represent 
and manipulate spatial objects in 3D. Although, there are 
DBMSs that contain some or parts of the mentioned 
functionalities. However, the performance improvement using 3D 
spatial indexing as an extension of 2D indexing is expected to be 
not significant: the third dimension used by spatial data will be 
many times less selective than the used x,y space. 
An experiment with Oracle showed that is possible to define 3D 
co-ordinates. However, geometry functions omit the z-value. In 
the following example, a spatial feature table (geom3d, with the 
attributes TAG and SDO_GEOMETRY) is created in which a 2D 
polygon together with a 3D polygon is inserted. After that, the 
geometrical functions AREA and LENGTH are performed on 
both polygons. A geometry validate is performed as well to show 
that the polygons are both valid. 
As one sees in the results of the queries SDO_AREA and 
SDO_LENGTH return the same value for both polygons, 
although the 3D polygon actually has a greater area and length. 
/* */ 
/* create table */ 
/* */ 
create table geom3d ( 
shape mdsys.sdo_geometry not null, 
TAG number(11) not null); 
/* */ 
/* inserting data */ 
/* */ 
/* 66: a 2D polygon */ 
insert into geom3d (shape,TAG) values ( 
mdsys.SDO_GEOMETRY(2003, NULL, NULL, 
mdsys.SDO_ELEM_INFO_ARRAY(1, 1003, 1), 
mdsys.SDO_ORDINATE_ARRAY(12,15, 15,15, 15,24, 
12,24, 12,15)), 66); 
/* 88: a 3D polygon */ 
insert into geom3d (shape,TAG) values ( 
mdsys.SDO_GEOMETRY(3003, NULL, NULL, 
mdsys.SDO_ELEM_INFO_ARRAY(l, 1003, 1), 
mdsys.SDO ORDINATE_ARRAY(12,15,0, 15,15,0, 
15,24,999,' 12,24,999, 12,15,0)), 88); 
select TAG, 
SDO_GEOM.SDO_AREA(shape, 1) area, 
SDO_GEOM.SDO_LENGTH(shape, 1) length 
from geom3d; 
TAG 
AREA 
LENGTH 
66 
27 
24 
88 
27 
24 
SDO 
GEOM.VALIDATE 
GEOMETRY 
geom_validate 
from geom3d; 
GEOM VALIDATE 
TRUE 
TRUE 
A full functional support of 3D geographical objects within the 
DBMS will enable: 
to check correctness (after edit operations); 
to avoid redundancy; 
to maintain consistency; 
to facilitate complex operators (map overlay, split/merge 
operations); 
to use topology in spatial queries; 
to integrate (store and query) 2D data and 3D data; 
The geometric primitives for the 3D cadastral data model are 
extrapolated from (in analogy with) the representation of geo 
objects in the 2D cadastral data model: point, line and/or circular 
arc and polygon (described by a sequence of lines). Possible 
alternatives for this model are (decreasing in complexity): 
objects based on primitives available in 3D CAD models; 
polyhedrons and spheres/cylinders; 
polyhedrons; 
tetrahedrons. 
Polyhedrons are solids, bounded by flat surfaces with each 
surface bounded by straight lines. Note that it may be difficult to 
describe a polyhedron correctly, as the four or more 3D points of 
a face do not always lie in a flat surface. A tetrahedron is a 
polyhedron with four triangular faces. The advantage is that the 
faces are always defined by three 3D points, which lie per 
definition in a flat surface (introducing no model error). For 
further explanation on tetrahedrons and tetrahedral networks 
see Kraak and Verbree (1992) and Pilouk (1996). 
Since the Kadaster uses straight lines and circular arcs to 
represent spatial features in 2D the initial preference is to use 
these as the base in 3D. The 3D primitives will therefore firstly 
be composed of polyhedrons and spheres/cylinders. The 
bounding envelope of a 3D real world object will be defined and 
used to represent the geo-objects. Attributes of the geo-objects 
will also be stored. The data model to maintain and retrieve 3D 
objects will be implemented in two ways: 
1. using self containing 3D geometric data types 
Now, z-values can be used to represent 3D features. 
However, as was seen, geometry functions do not 
recognise the z-value in Oracle. It is examined whether and 
how the relevant 3D information still can be recognised in 
spatial queries.