--- "Eric G . Miller" <egm2@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@geog.uni-hannover.de with
subject 'unsubscribe grass5'