95 
ctangles used; 
<ing are: " it is 
the left/ to the 
ore particularly 
like arcs and 
iction of the 
i distributed on 
lot the optimal 
operation and 
rdinates: each 
area and with 
-es is the only 
is freeware; 
y of Postgres 
ypes. 
le hierarchical 
main directory 
LOCATIONS), 
tin in their turn 
subdirectories 
p setting. The 
: ixed, but they 
ations. 
vithin Grass in 
ssponding file 
values. These 
ated to each 
se of a Digital 
ifferent height 
y- 
re distributed 
, Coir, Hist,...) 
the raster file 
characteristics 
rojection; 
oe raster file; 
ter file; 
; of the grid; 
epresent the 
ì data are in 
es within the 
ave a header 
ile; 
ciated to the 
id in a record, 
ue. 
s possible to 
o, if we have 
archive more 
oint locations, 
use a DBMS 
ie number of 
data structure 
edure with a 
proj: 
0 
zone: 
32-33 
north: 
49 
south: 
34 
east: 
21 
west: 
4 
cols: 
6122 
rows: 
7202 
e-w resol: 
0.08333333 
n-s resol: 
0.08333333 
format: 
3 
comDressed: 
0 
Fig. 19 - Example of a raster file (DTMLARGO) header 
name I italgrav 
desc I description= point height 
16.098722I38.6677781154.190000 
16.019278I38.6680561151.050000 
16.106778I38.6683331149.790000 
16.405389138.6686111117.910000 
16.039556I38.6697221155.360000 
Figure 20: Example of Sites-points: partial reproduction of 
the ITALGRAV file 
The tests we have performed aim at determining the more 
efficient method to store data in the Geodetic GIS. The 
comparison is given in terms of answer time in retrieving 
the data by using the Grass or the Postgres archive. 
For the tests related to the raster data we use the 
DTMLARGO file (36134 points) described in Fig. 19, even 
if in the geodetic database we have raster files even of 
much larger dimensions. In any way the use of a smaller 
file is suggested by the observation that a much larger 
table (for instance the file DTM95 which has about 45 
millions data) is of difficult management within the DBMS. 
Nevertheless referring to the time performance if, as we 
suspect, Grass is better than Postgres, at most the DBMS 
archive can be comparable to the GIS one for small raster 
files. 
For the tests related to the site points we use the 
ITALGRAV file (244598 observations of free-air gravity 
anomalies), described in Fig. 20. 
The data, initially stored in ascii files in the old ITALGEO 
archive, have been inserted, after they have been made 
compatible with the Grass formats, in the GIS files. The 
same data have been inserted also in the tables of 
Postgres by means of software programs written for this 
purpose. 
Once stored the data, for the tests we use the d.rast and 
d.sites Grass commands for the data display. In the case 
of Postgres, two new commands have been written and 
integrated in Grass (d.pg.sites and d.pg.raster). In the 
command codes a call to a counter process C program 
has been inserted (Idle Counter Process ©1994-1999 
NSA srl Ennio Pozzetti). This allows for the count of the 
time needed by the different commands in order to display 
the query data region. 
To identify the different tests an alphanumeric code has 
been introduced: the first character (see Table 3) points 
out the dimension of the query window, while the second, 
a number, distinguishes different measures performed 
with the same window: 
code 
A 
B 
C 
D 
E 
F 
G 
window size (°) 
1.6 
3.2 
4.8 
6.4 
8.2 
10.0 
11.6 
Table 3 - Alphanumeric code associated to the window 
size in the Grass versus Postgres tests 
The basic dimension that we have selected for the 
measures is the window size commonly used for the local 
geoid computation (1.6° x 1.6°), while the larger windows 
size allows to determine the better performance in case of 
a generic query to the file. 
In Table 4 and 5 the results of the tests are shown: the 
parameter of interest is the ratio between the retrieval 
time by using the database Postgres and Grass. 
For the raster file the data insertion in the DBMS table 
imposes to manage each single raster cell as a sparse 
point, characterized by a couple of coordinates, with 
relevant increase in terms of space occupation on the 
disk. Moreover the proofs show that, if the data are 
originally gridded, the sequential access to the file is, in 
terms of time, more advantageous than an indexed 
access to a DBMS table. 
The Grass GIS, designed primarily for raster data 
management and processing, adopts the first solution 
and, although it is not optimized in this sense, it results 
efficient; so, in this case, we advise against the use of the 
DBMS. 
For the tests on the sparse data, we have performed 
different time measures corresponding to cases A, B, C, D 
in different zones of the map and in correspondence of 
different point densities. In the whole set of proofs the 
Postgres performances result better than the Grass ones. 
The last measures, corresponding to the code E, F, G 
have been carried out for the search of the balance point 
of the two methods. The results are positive for Grass 
(less query time) on windows much larger than those 
commonly used for the geoid computation. It is therefore 
evident that with this type of data it is better to use a 
DBMS interfaced with the GIS. In effect Grass pays the 
ineffectiveness of the d.sites command that always 
requires a fixed time (14-15 seconds), independently from 
the dimension of the window and from the number of data, 
necessary to visualize the data. The ratio between the 
time of execution of the d.sites command (which reads the 
data from the Grass file) and the time of execution of the 
d.pg.sites command (which reads the data from the 
Postgres table) is practically independent from the 
dimension of the window, but decreases correspondingly 
to the increase of the points density. When the selection 
involves the extraction of a large number of points 
(comparable with the total number of present points), the 
time required for the index management surpasses the 
benefits linked to the use of a DBMS indexing method. 
Moreover, the goodness of the results is, partly, 
conditioned by the choice of the positioning of the "virtual 
rectangles": in our case we have simply divided the area 
corresponding to the extension of the data in a uniform 
way from the spatial point of view, disregarding the 
different density of the data. The choice is not optimal and 
a rectangle distribution taking into account the specific 
point distribution (in Postgres there are not automatic 
mechanisms to this purpose) allows to obtain even better 
performances. So, in this case a DBMS interfaced to the 
GIS is the optimal solution.