[GRASS5] Postgresql and Grass

[Robert Lagacé]

Rich Shepard wrote:
> 
> On Fri, 15 Sep 2000, Eric G . Miller wrote:
> 
> > > I wonder if putting Postgress along Grass is really good on the long
> > > term.  It seems to me that Grass could (should ?) be the (geo)graphical
> > > interface to postgress, at least for the vector data (i.e. areas, lines
> > > and sites), and that all attributes should be managed by the RDBMS.
> 
> > I don't think Postgres is appropriate for managing vector or raster data
> > that you're working on.  Publishing it, or using it in some read-only
> > fashion (like spatial web-browser app) is not a bad idea.  Postgres
> > geometry does not support topology.  A problem, IMHO.  Non-topological
> > GIS's can lead to really messed up vector coverages.  I've looked at this,
> > and every solution with Postgres handling the data seems messy to me.
> > It'd be easier to export vector data to postgres for some other
> > application to make use of than to do the reverse.  See all the problems
> > with v.in.shape for instance.  Same thing here.
> 
>   I used to think that postgres would work because it supports graphic
> shapes. After doing some minimal research, I also became convinced that we
> need an object-oriented dbms rather than the object-relational dbms that
> postgres is.
> 
>   I've also done some reading on spatial data structures and learned that
> there are several approaches, all of which appear equally useful to me. But,
> I'm not a computer scientist with a deep understanding of data structures
> and GIS internals.
> 
>   What I do know is that Bruce has assembled a team at Baylor that includes
> CS faculty with expertise in this subject. Perhaps we should ask the
> database experts to design an attribute database that works with vector and
> raster data and is specific to GRASS. This will not preclude tieing to any
> other dbms (via ODBC, for example), but will put multiple table database
> capabilities in GRASS for those of us end users who don't need to link to an
> enterprise-level or university-level system.
> 

My thinking goes in that direction and I will like to be in contact with those 
at Baylor.  GRASS GIS and attribute data are organised on file structure with
flat 
files.  We need to design a equivalent structure that can be implemented by any 
database management software (DBMS).  The metadata need to be in the DBMS.

>   A multiple-table (probably relational) design is needed because not all
> attributes of a single object should (can?) be stored in one table. Soils
> data, for example.
>

We started to do work in this direction.  We do our analysis using object 
oriented approchs but we do relational implemtation.  On a short term, SQL 
interface is a viable approch to many DBMS.
 
>   As long as we have this discussion, I'd like to see the database experts
> show us some suggestions. I, for one, would be way over my head otherwise