[GRASS5] Re: An internal db for GRASS

[Andrea Aime]

[snip]

> 2. It does not have spatial data structures. Just now there are flat
> record/hash table/BTree options. It would be nice to have a system with
> largely consistent features but give a wide variety of choices for the
> type of key to use, including spatial types.

For what concerns spatial data structures in a DB, Postgres supports
that and the forecoming OpenVectorDB will do as well. I think that
GRASS should support a file based approach, suitable to exchange data
and for small environments, and a full DBMS approach, as an option
for more complex works. To make that choice feasible vector API should
be independent of the archiving method chosen (apart from some
initialize
function in which one needs to specify which kind of acces wants to use)

> 
> The GIST library does have a larger variety of data structure types to
> choose from, and is aimed more at traditional uses of digital mapping,
> like GIS, but is not primarily for information handling like a
> traditional RDBMS. Maybe that could be used also. 
> 

GIST indexing capabilities would be very nice, since GIST can generate
r-tree indexes, that are very important to speed up vector analysis
operations
such as spatial queries (which are the polygons inside that area?) and
overlays. Since GIST is a generic toolkit used to build indexes, maybe
it
could be used to build point-quadtree indexes as well (like Chistian did
at italian GrassDay).

Bye
Andrea Aime

---------------------------------------- 
If you want to unsubscribe from GRASS Development Team mailing list write to:
minordomo at geog.uni-hannover.de with
subject 'unsubscribe grass5'