[GRASS-user] RE: Problem querying layers other than '1' in gi s.m

twiens twiens at interbaun.com
Fri Sep 22 14:30:17 EDT 2006

----- Original Message Follows -----
From: Moritz Lennert <mlennert at club.worldonline.be>
To: Trevor Wiens <twiens at interbaun.com>
Cc: "Patton, Eric" <epatton at nrcan.gc.ca>, 'Michael Barton '
<michael.barton at asu.edu>, "''grassuser at grass.itc.it' '"
<grassuser at grass.itc.it>, GRASS-DEV <grass-dev at grass.itc.it>
Subject: Re: [GRASS-user] RE: Problem querying layers other
than '1' in gi s.m
Date: Fri, 22 Sep 2006 16:56:20 +0200


> > Vector
> > objects should IMO have one and only one cat value. This
> > shouldn't change, but instead attributes should identify
> feature themes. 
> Now I am getting bitten by the vocabulary: what are
> "feature themes" ? ;-)

Sorry. Bad choice of words. Terminology is a tricky thing.
Right now cats in one or more 'layers' are used to identify
thematically distinct but topologically related spatial
objects. Such as forest areas and lakes, or sites at
different times. What seems much more natural to me is
leaving the attribute management to the database where more
elegant tools exist. Thus grass modules instead having a
layer option need a input key and possibly an output key
option depending on the module. If no key field is specified
(which would be an attribute in the table linked to the
vector file), then all objects in the vector file are
processed. However if a key is used to query the vector file
for a list of objects for processing. In the case where the
same vector object has two cats, the vector attribute tables
will have to have a one to many relationship from the vector
file to the attribute table. Now modules could also allow a
query specification to allow for complex querying across
multiple keys and attributes, but output would probably have
to be limited to a series of key fields (most likely only

Now it could be argued that this is not essentially
different than the 'layer' feature now, but what is
fundamentally different is access to and control of the
attribute tables. In this case, all attribute management
stays in the database where it belongs. It makes a clear
distinction between GIS thinking and database thinking and
enables a great deal more elegance to attribute management
than is currently supported. As a proper database GUI is
built for GRASS, or if people choose to use other tools like
PgAdmin for example, then attribute management becomes much
more natural and easy. 

The benefits of this system can be seen in a simple example.
Right now if you have a point file and you want to create a
buffer around those points all the attribute information is
lost and must be patched back in. By keeping attributes in
the database it would be much simpler to have an attribute
in the new vector linking back to the old key and thus
effectively keeping all the old attribute information linked
to the derived layer.


> > Thinking long term however, it has been amply
> > demonstrated that the vector library although a big
> > improvement for the old days, still needs a lot of work.
> > Memory management issues periodically arise on the dev
> list with large data streams and that data streams will
> > continue to swamp memory and swap space so proper
> > caching is required for optimal processing.
> I'm not sure that this is directly linked to the database
> question,  though, or ?

See above


> I would like to come to a point where we are not only
> speaking about how  bad the current system is, but how
> _concretely_ a new system should look  like.

Is the above concrete enough to give you an idea what I'm


Trevor Wiens
twiens at interbaun.com

More information about the grass-user mailing list