So if we would like to maintain the RDBMS approach, we 
must extend the system in order to store new data type. 
These non-standard scheme use special “bulk” or “long” 
data types (also of variable length) , in which a sequence 
of coordinates or identifiers may be regarded as a single 
unit, identified by a unique record identifier. Obviously in 
this case we must interpret the content of the bulk field by 
using a purposely arranged query language. 
3.-THE POSTGRES DBMS 
We are left now with the problem of finding a DBMS with 
special characteristics allowing to easy manage 
geographical data. To this purpose a number of good 
commercial products exist. But, as the International Geoid 
Service, which is a Service of the International 
Association of Geodesy devoted to geoid computation, 
has as one of its main aims to promote international 
cooperation and technology transfer, the choice of the 
authors has fallen on the POSTGRES DBMS. In fact it 
seems a good tool for our applications and it has the 
advantage to be free and source code available. 
POSTGRES was originally developed within the 
University of California at the Berkeley Computer Science 
Department, has been sponsored by the Defence 
Advanced Research Projects Agency (DARPA), the Army 
Research Office (ARO), the National Science Foundation 
(NSF) and ELS, Inc. 
It is substantially an object-relational DBMS (i.e. it is a 
RDBMS with some object-oriented features). 
In 1994 a SQL standard language interpreter was added 
(POSTGRES95) instead of the original Posquel. 
POSTGRES SQL supports the usual SQL types (int, float, 
real, smallint, char, varchar, date, time) as well as other 
types of general utility and a rich set of geometric types 
(Table 11). 
By 1996, it became POSTGRESQL; in this version build- 
in types have been improved, including new wide-range 
date/time types and additional geometric type support. 
The fundamental notion in POSTGRES is that of class 
(collection of object instances). Each instance has the 
same collection of attributes and each attribute is of a 
specific type. Each instance has a permanent object 
identifier (OID) that is unique. 
Features of a map can be described by instances 
corresponding to geometric data types. For instance the 
geometrical description of the region corresponding to 
DTM source code 6 is shown in Table 12. 
As it is immediately evident this kind of description is 
much more compact and efficient in terms of data storage 
and retrieval than the tools offered by traditional DBMS. 
Moreover regarding POSTGRES we would like to remark 
that interesting geometric operators and functions (Table 
13 and 14) are available, even if the authors at the 
moment have not yet experimented their functionality. 
4.- CONCLUSIONS AND ACKNOLEWGEMENT 
The interfacing between the Geographic Resources 
Analysing Support System GRASS customised to build up 
a geodetic GIS and the object- relational DBMS 
POSTGRES has been individuated to be adequate to the 
purpose of efficiently storing our datasets. 
The next step is the definition of the conceptual model 
and the definition of the instances involved in the logical 
model. 
The authors would like to thank the GRASS Information 
Center and Research Group 
(http://www.bavlor.edu/~grass) and the 
POSTGRES Group (http://www.postgresql.org). 
GEOMETRIC TYPE 
STORAGE 
(bytes) 
REPRESENTATION 
DESCRIPTION 
Point 
16 
(X,V) 
Point in space 
Line 
32 
((x1,y1),(x2,y2)) 
Infinite line 
Lseq 
32 
((x1,y1),(x2,y2)) 
Segment 
Box 
32 
((x1,y1),(x2,y2)) 
Rectangular box 
Path 
4+32 n 
((X1.V1 )....) 
Closed path 
Path 
4+32n 
I(x1 ,y1 ),—l 
Open path 
Polygon 
4+32n 
((Xl.y1 )....) 
Polygon 
Circle 
24 
<( x .y).r> 
Circle 
Table 11 - Geometric data type available in POSTGRES 
Polygonjd 
Poligon_data type 
A6 
((46.37, 10.71),(47.63, 10.71),(47.63, 9.44),(47.40, 9.44),...) 
Table 12 - “Polygon” relation