[GRASS5] Postgresql and Grass

[Eric G . Miller]

On Fri, Sep 15, 2000 at 10:09:27AM +0200, Michel Wurtz 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.
> 
> The negative point of this approach is that Grass won't work without
> PostgresSQL, but it will be something much more usable for "real work",
> where the attributes are as important as the geometry of objects.

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.

That said,  I've got some ideas about having it manage vector attribute
data.  GRASS definitely needs a better solution for this.  I'm not sure
we should tie it to any external product *exclusively*.  I think, better
to add some native flat-file attribute type database handling directly
in GRASS; then, tie in support for multiple external DBMSs (PostgreSQL,
RIM, Informix, Oracle, etc...).  I think this is what the DBMI interface
is all about, no?  Still, at a standalone level, GRASS needs to handle
attribute tables, not just category/labels.

While I'm at it... Think GRASS needs support for assigning colors to
areas and lines based on category numbers or ranges.  This should work
similar to r.colors.  Also, GRASS should be able to do selected subsets
from vector coverages for use in analysis and display.  It's sort of
like a v.reclass and r.mask which would transparently function with
d.vect, or other vector query processing analyses.  Need to work out a
protocol for making the selections, storing them on disk for later use,
and then modifying the vect libraries to make use of this info.

I'm not up to speed on what everyone is working on, so...

-- 
/bin/sh ~/.signature:
Command not found

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