418 
ISPRS, Vol.34, Part 2W2, “Dynamic and Multi-Dimensional GIS”, Bangkok, May 23-25, 2001 
ISPRS 
pedestrian paths, parking lots, etc. are also integrated in the 
model as 3D objects. Quite often terrain objects are the only 
clearly visible objects that can be used for positioning (see 
Figure 9). In our case, we obtained the terrain objects by 
overlapping dense laser data (0.60m x 2.00m) with data from the 
topographic base map of the Netherlands (scale 1:1000). Every 
2D point of the topographic map obtains Z-coordinate by 
interpolation on TIN created from the filtered laser data. 
Figure 9: An image from the video camera with marked points 
needed for positioning 
The procedure for 3D line feature extraction is an integration of 
algorithms for edge detection (on two or more images) and 3D 
line computation using knowledge based methods. The work on 
the algorithms for 3D line extraction as well as the final 
integration of partially reconstructed 3D models from the 
different approaches is in progress. 
5 IMPLEMENTATION 
The argument about advantages and disadvantages of 
developing a database system from “scratch” may give 
preferences to either of the approaches. A newly design 
database system gives the freedom to create operators that suit 
the tasks of the application in a better way. The utilisation of 
commercial database systems brings advantages in few 
directions: standard data definition and data manipulation (e.g. 
SQL) languages, a variety of indexing schemas, optimisations in 
maintenance of large data sets. Computer graphics specialists 
often consider commercial databases rather slow for real-time 
applications and develop their own databases (see [4]). 
However, the technology and software achievements in the last 
several years in the field of database research challenge with 
improved functionality and performance that may be sufficient for 
any application. Therefore we have decided on implementation 
of the model described above in a commercial database, i.e. the 
relational database Oracle 8/. The database offers a number of 
possibilities for representing the spatial objects described above. 
Three different implementations of the model were created and 
experimented. 
5.1 Relational implementation 
The first straightforward approach is the relational 
implementation. The IFO model can be converted directly into a 
relational data model according to the rules: 
• abstract object types are represented as relational tables 
(or relations) 
• derived object types are represented as relational tables or 
domains (if they are atomic objects to a complex object) 
• printed object types are represented as domains 
• IS-A relation is propagated until a printed object type. 
For each geometric object a separate relational table is created. 
This is to say that the entire model consists of seven relation 
tables. For simplicity, the names of the tables are chosen to 
correspond to the names of the objects, i.e. NODE, FACE, LINE, 
POINT, LINEONF, SURF and PHED. The implementation of the 
NODE table is trivial: one column for the identifier of the node 
and the three columns for the (geodetic) co-ordinates of the 
points. The table POINT accommodates the identifier of the 
point and the identifier of the node that describes this spatial 
object. Since the remaining tables have very similar structure, 
only the FACE table is explained. The relationship between a 
face and constituting nodes is one-to-many (1:m) which can be 
represented in a relational form by creating multiple rows or 
columns in the table. Since the multiple-column representation 
leads to a table with large amounts of zero fields, we give 
preferences to multiple-row representation. Therefore the FACE 
table has to consist of three columns, i.e. a column for the 
identifier of the face, a column indicating the order and the 
number of the nodes in a face, and a column containing the 
identifiers of the nodes. Thus each FACE is linked to the 
identifiers of the nodes and not to the co-ordinates. The 
LINEONF table contains columns for the six co-ordinates of the 
lines and identifier of the face that the line feature belongs to. 
Each line feature is thus represented by one row in the relational 
table. 
Let us adopt the following representation for a relational table: R 
= ({A t , ..., A n ), {PK}) where R = () is the relational table, {Ai, .... 
A n } are domains (columns) and {PK} is the primary key. Then we 
obtain the following relational mapping: 
NODE ({NID,X,Y,Z},{NID}) 
FACE ({FID,SEQF,NIDF},{FID}) 
POINT ({PID, NID},{PID}) 
LINE ({LID, SEQL,NIDL},{LID}) 
SURF ({SID,SEQS,FIDS},{SID}) 
PHED ({BID,SEQB,FIDB},BID}) 
LINEONF ({LFID.FID.X1 ,Y1 ,Z1 ,X2,Y2,Z2)},{LFID}) 
nX 
Figure 10: An example of 3D object with line features on face f1 
For example, a cube that consists of six faces (f1...f6), eight 
nodes (n1...n8) and two lines (L1 and L2) on the face f1 will be 
represented by the following records in the tables FACE, LINE 
and PHED: 
Fid 
FACE 
Seqf 
nid 
bid 
PHED 
Seqb 
Fid 
1 
1 
1 
1 
1 
6 
1 
2 
2 
1 
2 
5 
1 
3 
6 
1 
3 
1 
1 
4 
5 
1 
4 
2 
1 
5 
3 
6 
1 
5 
1 
6 
4 
6 
2 
6 
6 
3 
7 
6 
4 
8 
LINE 
Lid 
Fid X1 
y1 Z1 x2 y2 z2 
1 
1 
2 
1 
A pure relational representation is well known to be 
inappropriate for object-oriented models due to rather large 
amount of duplicated data to represent groups and aggregations 
of objects (i.e. one-to-many relationships). In our case for 
example, the column SEQF in the FACE table is a way out of 
storing 
by a m 
DBMS 
object- 
5.2 
Object 
data si 
objects 
advant 
entirely 
SQL s 
data ci 
compls 
straigh 
proces 
standa 
VRML 
views, 
the dal 
this typ 
create 
numbe 
XC nur 
create 
as 
select I 
from F> 
where I 
orderec 
5.3 
A step 
object-i 
from i 
implem 
table. 1 
stored 
based 
objects 
similar 
identify 
genera 
repress 
Our 3 
repress 
to desc 
column 
will be 
object. 
reductic 
Object- 
creatine 
Oracle 
many r 
are rei 
retrieve 
suitabls 
elemen 
perforrr 
nested 
geomel 
of objei 
data tyf 
Varravi 
create 1 
Nested 
create 1