[GRASS5] Postgresql and Grass

[sixote alin]

--- "Eric G . Miller" <egm2 at jps.net> wrote:
> 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 agree that there must be created a way to copy lines
and areas
subselected from a primary coverage by a set of rules.
this is already done for
sites (see for example d.site.pg). the protocol you
mention may be as simple as 
copying the whole set of lines to a new struct, then
deleting unmatched lines, 
v.support does the rest of job. 
it seems that the v.reclass may serve as a prototype,
although
others (like v.in.shape and corresponding libs) may do
better for this
purpose.
alex

__________________________________________________
Do You Yahoo!?
Yahoo! Mail - Free email you can access from anywhere!
http://mail.yahoo.com/

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