126 
of Geology- at the Baylor University , Waco - Texas 
(Clamons S.F. and Byars B.W., 1997), which is intended 
as responsible for the design of the system at the 
database and fundamental libraries level. 
Regarding this aspect, we have that GRASS, like the 
other GIS, is not only a useful viewer or analyzer of spatial 
data but, in some ways, also a database management 
system (DBMS). The database in GRASS is based on the 
UNIX (operating system under which the GIS is 
implemented) hierarchical directory structure (Fig. 1). 
The main directory (GISDBASE) contains subdirectories 
(LOCATIONS), which are independent databases and 
contain in their turn subdirectories (MAPSETS) with files 
and subdirectories (ELEMENTS). Users may only access 
mapsets that they own. 
At the last level of the tree we have files and directories. 
As an example of File in a mapset we may recall the 
‘SEARCH_PATH’ file, containing the lists of the mapsets 
necessary to find a file. As an example of Element, we 
report the structure related to the cell layers. 
The raster maps are described, as shown in Table 2, by 
several different elements. In the same way we have 
different elements for vectorial layers. 
Element 
Description 
Cell 
Binary raster file 
Cellhd 
Header file for raster map 
Cat 
Categories information 
Coir 
Color table 
Hist 
Metadata 
Table 2 - The database principal directories used for the 
description of the raster maps 
In GRASS the database access is controlled by few 
simple rules and it is quite efficient for the spatial data 
handling. Anyway this system does not have the 
possibilities for optimizing the managing of attribute 
information, system files and objects interrelationships. 
These performances can be obtained only by interfacing a 
real DBMS to GRASS. The use of a DBMS also provides 
some auxiliary functionalities, which are fundamental 
when more people work on different projects by using part 
of the same dataset. 
In fact, by adopting a DBMS approach (talking about 
DBMS, we refer only to a relational one and we disregard 
the others - hierarchical , network, ...- because they are 
generally inadequated in interfacing a GIS), the data are 
organized within a specific schema based on a logic data 
model; in this frame the set of the allowed operators for 
handling data and the data relationships are also defined. 
Because in general different users access the information 
stored in the same database, the DBMS provide tools to 
control data consistency (to avoid the concurrent access 
to two or more copies of data which result different one 
from the other), to support data integrity, integration and 
reliability (i.e. the protection from unintentional user errors, 
equipment or programs failures). 
Moreover a DBMS must provide a minimal data 
redundancy (which is important in cases, as ours, in which 
we have to store a large amount of data) and, at the same 
time, an easier and standardized access to the data. 
Finally the last relevant characteristics of a DBMS are the 
physical and logical data independence; the first one 
refers to the possibility of changing the physical structure 
of the data without changing the application programs 
working on the database; the second one guarantees that 
it is allowed to modify the logical database model without 
changing the application programs not involved in the 
variation. The combination of these two properties makes 
it possible both to solve the problems related to hardware 
(disk or memory) and operating system substitution and to 
extend the database with new relations. 
All the tools and capabilities provided by a DBMS make it 
in general more efficient in storing and managing data 
than the usual flat ASCII files approach. So we feel that 
an effort must be made in order to study links as robust as 
possible between DBMS data and the GIS we have 
chosen for handling the geodetic data. 
Before coming to the point, let us remind that the 
fundamental notion in a RDBMS (Relational Database 
Management System) is that of a table or relation. A 
database is represented by a collection of relations 
containing tuples, which represent real-world entities or 
relationships between entities. Each relation has attributes 
of fixed types that represent the properties of the entities. 
So in a RDBMS each row (or instance) in a table (or 
relation) has the same collection of columns (or attributes) 
and each attribute is of specific type. A relation has a 
primary key, which is a combination of the attributes of a 
relation that, taken together, uniquely identify the tuple. 
In a table it is not allowed to have two identical rows and 
to have different formats for the values of the same 
attribute corresponding to two different rows. 
For example, in a geodetic database we may consider the 
relation describing the DTM’s outliers and the relation 
illustrating the methodologies that we can apply in the 
DTM preprocessing in order to individuate these 
anomalous values. The relation “DTM outliers” is shown in 
Table 3, in which we have also introduced an auxiliary 
information, i. e. the status of the outlier. 
GISDBASE 
LOCATION 1 LOCATION2 ... 
MAPSET1 MAPSET2 ... 
Filel File2 Elementl Element2... 
Fig. 1 - The hierarchical GRASS database structure.