2. DESIGN 
2.1 General Design 
The project demands the handling 
of various kind of spatial data 
like images from several 
sensors, training areas and 
classification-results. Keeping 
track of all the information to 
the data (image-sizes, ground- 
coordinates, etc.) is quite 
tedious and leads to long 
listings (on paper) with which 
nobody can efficiently work. So 
we let the computer store that 
information in a database. 
It has been decided to create an 
own database for the project and 
not to use a commercial one. 
Objectives for this decision has 
been the ability to design a 
system especially dedicated for 
the project and therefor being 
efficient [Lee, 1988], no need 
for relational calculus 
[Schumacher, 1991], the lack of 
money to purchase a commercial 
DBMS and the advantage to work 
in an homogeneous environment 
for the entire project. This 
environment is the VDA (Visual 
Data Analysis) software-package 
PV-WAVE, in which about 90$ of 
the projects modules are 
developed. Especially routines 
like user-interfaces or 
analyzing features are written 
in WAVE, dedicated and time- 
consuming subroutines are added 
in FORTRAN or C [Sasse, 1992]. 
The database will be entirely 
developed in WAVE. 
A definition of a database can 
be found in [Deen, 1985] : "A 
generalized integrated 
collection of data together with 
its description, which is 
managed in such a way that it 
can fulfil the differing needs 
of its users". This means more 
than just a collection of data. 
What we have to do is to define 
what information we want to 
combine with our data and how 
this information can be stored 
440 
on 
we 
efficiently. Concentrating 
the first and important data 
work with, the image-data, we 
find, that it is not possible to 
store all data on disc at the 
same time (the project- 
workstation has two discs with 
600 MB each). This leads to the 
concept of a meta-database 
[Meissner, 1990], thus spoiling 
our definition from data stored 
together with its description. A 
meta-database is best described 
with the example of a fictive 
literature DB: Rather than 
actually storing the content of 
each book entered in the 
database just the information 
like author, title, short 
abstract, etc. -is collected; 
i.e. the objects themselves are 
physically not stored in the 
database. With this concept it 
is possible to store our 
objects, the images, on tape or 
somewhere else in a network of 
workstations. 
We also have different kind of 
data to work with, beneath 
images training areas and 
classification results. It may 
be useful integrating GCP - and 
DEM-data. So the objects are 
grouped in classes of objects 
(clusters). 
We have to write modules to work 
with the database : modules for 
data-definition and -editing 
(new entry, edit entry, delete 
entry) and others for 
information-retrieval (show all 
objects in a specified area). 
These modules have to be 
designed class-oriented, i.e. a 
module has to serve its purpose 
for all objects in a single 
class. 
2.2 Data Models 
The physical model describes how 
the data are actually stored. In 
our MDB we distinguish three 
degrees of file-levels. There is 
one 1st degree file containing 
the list (catalog) of all