[GRASS5] Postgresql and Grass

[David D Gray]

What I meant to say was... :)

It is going off-track a bit, but you may recall that we had a thread on
the devel list a few months back about inclusion of external software.
This also relates to reusable components within GRASS. There are
actually a lot (at least a few) implementations of various spatial data
structures in various parts of the project. Many of these have been
developed to satisfy the needs of a particular large-scale module or set
of modules, often from a contributed project. What we need is a set of
routines for spatial data-structures where the API is well-exposed and
easy to use for modular development and pluggability.

There is already a generalised binary tree implementation in libgis
which modules can link to for most purposes with little or no
modification. What we need is similar libraries for handling R-trees and
octrees and similar structures. Also for actual spatial structures, such
as quad-edge. (The GNU Triangulated Surface library might be a good
plug-in)

I think however it is important not to confuse the roles played by an
RDBMS or ODBMS with the management of spatial data structures
themselves. An interface allowing connection to heavier databases is a
good thing to create and maintain, and we should perhaps think about
that for a future version, but a simple table based structure within
GRASS is also necessary for the day to day management of map associated
attributes, and it seems our dbmi is quite adequate for the job. Until
we deal with maps that have 10's of thousands of entities (eg polygons)
there is no great advantage to having anything beyond a `flat' data
access structure for day-to-day GIS operation. Then we just plugin our
binary tree to dbmi - or even use a btree implementation.

In the long term what would be good to see would be a system of spatial
data management deployed in a way similar to how linear algebra software
is managed now: Standard routines and structures for all the major
functions with optimisation for particular platforms and a well-exposed
standard API. This approach would be appropriate as spatial data
processing, like linear algebra, is an area where much of the intensive
number-crunching is bound up. Unlike linear algebra, unfortunately, the
spatial data field is very `proprietary', not at all public domain, and
if GRASS was to take on the development of such a standard, we would be
on our own. So I would agree that advice and guidance from experts in
spatial data structuring and storage would be an essential minimum
requirement for the task. I would be happy to be involved in such a
project, but I am in no way an expert in the field.


David

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