ISPRS, Vol.34, Part 2W2, “Dynamic and Multi-Dimensional GIS", Bangkok, May 23-25, 2001 
275 
1), 
,15, 15,24, 
s ( 
L, 
1) , 
15,15,0, 
*8) ; 
jth 
ape, 1) 
)jects within the 
lay, split/merge 
¡D data; 
data model are 
ntation of geo- 
and/or circular 
lines). Possible 
nplexity): 
CAD models; 
aces with each 
ay be difficult to 
ore 3D points of 
etrahedron is a 
itage is that the 
which lie per 
»del error). For 
edral networks 
ircular arcs 
'ence is to us 
therefore first 
cylinders. Th 
be defined an 
:he geo-objecl 
and retrieve 31 
3D features, 
ions do not 
i whether and 
recognised in 
2 using a topological model to maintain and retrieve 3D 
objects 
A topological model for 3D objects is currently developed at 
our Department (Zlatanova and Verbree, 2000). A 3D 
geometry object is therein defined as a polyhedron 
consisting of nodes and faces. The edge is not used in this 
model, since this did not bring significant facilitation. The 
topological model is being implemented in Oracle. 
5 COLLECTION AND PREPARING 3D DATA: INSERTING 
3D DATA INTO THE 2D GEO-DBMS 
3D spatial information of objects under and above the ground is 
available with designers, mostly as CAD models. Therefore, it is 
examined how this information can be used and what 
conversions and generalisations are needed to obtain the 
(spatial) relevant information, such as the outer boundary of the 
object. The alternative is to collect and measure 3D data, but 
this can be very difficult in the case of subsurface constructions. 
Aspects that should be looked at are: 
exchange formats; 
converting the used CAD primitives to meaningful and 
usable geo primitives fitting in the chosen 3D data model; 
converting the detailed file-based models to a collection of 
real-world objects containing relevant geo-information; 
converting the models defined in local co-ordinate systems 
to models defined in the national spatial reference system. 
5.1 From local co-ordinates to national spatial reference 
system(s) 
The transformation of a local co-ordinate system to a national 
reference system is object of special interest. 
In the Netherlands, the horizontal location of a point can be 
defined in the national reference framework. The Netherlands’ 
Kadaster maintains this framework (co-ordinate system), by 
means of 6,000 points for which the exact location is determined 
and preserved (Kadaster, 1999). 
The vertical location of a point can be defined in respect to NAP: 
Normaal Amsterdam Peil (The Netherlands National Ordnance 
Datum). This is the tidal plane of reference used in the 
Netherlands to measure the altitude of land and structures. The 
NAP is at approximately the same height as mean sea level. It is 
visible in the landscape by about 55,000 marks. These marks 
are placed in buildings, bridges etc.. Almost everywhere in the 
Netherlands a mark can be found within one kilometre, which 
can be used for height determination. The Directorate-General of 
Public Works and Water Management is responsible for 
maintaining the height marks (2000). 
5.2 Definition of 3D geo-data in respect to 2D geo-data 
The insertion of the 3D data into the current (2D) geo-DBMS 
touches the fundamental issue of combining 2D and 3D data in 
one environment: what is the vertical relation between 2D and 
3D data. In other words: what is the ‘horizontal zero level’ on 
which the 2D geo-objects are defined. With this, two possible 
representations of z-co-ordinates of the 3D geo-objects can be 
distinguished: 
1. an absolute z-co-ordinate, defined in the national reference 
system 
When z-co-ordinates of the 3D geo-objects are stored in a 
national reference system, the height of surface parcels is 
needed to be able to define geometrical and topological 
relations between the 3D objects and the 2D parcels. The 
collection and input of this additional information will take 
considerable time. Moreover, the complexity of the 2D data 
increases, since 2D parcels need to be defined in 3D 
space. This can not be done by simply adding one z-co- 
ordinate per parcel, since parcels contain too much spatial 
variance for this approach (even in a ‘flat’ country like the 
Netherlands). 
2. a relative z-co-ordinate, defined in relation to the surface 
When z-co-ordinates of the 3D geo-objects are stored in 
respect to the surface, the current geo-DBMS does not to 
need to be extended with additional z-information on 
current 2D geo-data, saving time and data complexity. On 
the other hand, other difficulties arise, such as the 
conversion of the z-co-ordinates of the 3D geo-objects, 
known in the national spatial reference system, to relative 
co-ordinates. In this case only the 3D situation in the 
surrounding of the 3D geo-object needs to be explored, 
instead of locating all 2D geo-data in 3D space. 
6. QUERYING AND VIEWING 
The incorporation of 3D geo-objects into the existing geo-DBMS 
based on 2D parcels makes it possible to query the data 2D, 3D 
and in combination with each other. A query example from the 
previous section which shows the additional value of the 
integration of 2D data and 3D data in one DBMS, is: 
find all 2D objects which ‘intersect’ with (the 
projection) of a certain 3D object 
From a DBMS point of view, the relations between 2D parcels 
and 3D constructions should be derived by the spatial system. 
As the current cadastral model is based on a topology structure, 
which is stored in the DBMS, but not managed by the DBMS, it 
is not possible to select the parcels which are overlapped by an 
object from our geom3d table with a SQL query. For this 
purpose, the parcels should be ‘materialised’ first to polygons 
and with these polygons the actual overlap computation can be 
performed. As the first query below shows, it is possible to select 
parcels based on (projected) overlap of their bounding box with 
the 2D and 3D objects from the geom3d table, introduced in 
section 4.2. It is also possible to select the parcel boundaries 
based on overlap with the objects from the geom3d table. 
/* parcel selection based on bbox */ 
select distinct municip, section, parcel 
from parcel p, geom3d g3d 
where sdo_geom.relate 
(p.bbox, 1 anyinteract 1 ,g3d.shape,.1) = 1 TRUE 1 ; 
/* boundary selection based on true shape */. 
select b.shape 
from b.shape, geom3d g3d 
where sdo_geom.relate 
(b.shape, 1 anyinteract’,g3d.shape,.1) = 1 TRUE 1 ; 
An inventory is made of all required queries, which can benefit 
from the existence of 2D and 3D data in one geo-DBMS. These 
queries will be implemented.