[GRASS5] Postgresql and Grass

[Rich Shepard]

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.

  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.

  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.

Rich

Dr. Richard B. Shepard, President

                       Applied Ecosystem Services, Inc. (TM)
              Making environmentally-responsible mining happen. (SM)         
                       --------------------------------
            2404 SW 22nd Street | Troutdale, OR 97060-1247 | U.S.A.
 + 1 503-667-4517 (voice) | + 1 503-667-8863 (fax) | rshepard at appl-ecosys.com


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