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
