You are using an outdated browser that does not fully support the intranda viewer.
As a result, some pages may not be displayed correctly.

We recommend you use one of the following browsers:

Full text

International cooperation and technology transfer
Mussio, Luigi

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.
Binary raster file
Header file for raster map
Categories information
Color table
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.
Filel File2 Elementl Element2...
Fig. 1 - The hierarchical GRASS database structure.