95
ctangles used;
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.
