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

[Michael Barton]

A couple of clarifications.

> 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. 

While they *can* be used that way (and I know that's what some of the
explantions have said), they are actually much more generic.

> 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
> integers)

Really, this is exactly what "layers" are now. AFAICT, the biggest problem
is in the terminology. Each "layer" is an integer key field in database
terminology. Multiple layers simply means multiple key fields, each of which
can be linked with an attribute table using v.db.connect.


> 
> 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.

Again, except for the key fields confusingly labeled as "layers" and one
other legacy feature from GRASS 5, all attribute management does stay in the
database. The "cat" value in the key (aka "layer), connects a vector object
with its corresponding record(s) in the attribute table. The GRASS 5 legacy
is that you can have a single text field that accompanies each key. This is
a left over when the only vector database easily available consisted of a
single integer field (cat) and single text field (label) for each vector
file. This mirrored the attribute structure of raster files. We could
probably drop the "label" field from the vector database structure with
little loss and some gain in understandability. We could then rename
"layers" and "cat" to "key fields" or "keys". This brings up another
terminological confusion. We commonly refer to a "cat" value. This is simply
the integer value within each key.

I think it would help a lot if we simply dropped "cat" and "layer" (keeping
a reference to these terms in the documentation for legacy data) and used
some version of key and value. For example:

v.centroids input=name output=name [option=string] [layer=integer]
[cat=integer] [step=integer] [--overwrite]

Becomes...

v.centroids input=name output=name [option=string] [key=integer]
[keyvalue=integer] [step=integer] [--overwrite]

OR

v.db.connect [-pgcod] map=name [driver=string] [database=string]
[table=string] [key=string] [layer=integer]

Becomes...

v.db.connect [-pgcod] map=name [driver=string] [database=string]
[table=string] [dbkey=string] [vectkey=integer]

OR

v.db.update map=string [layer=integer] column=string value=string
[where=string]

Becomes...

v.db.update map=string [key=integer] column=string value=string
[where=string]

> 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.

I agree

> 
> 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.

This is only lost if the key (aka "layer"/"cat") is lost. If it is
maintained, one only has to run v.db.connect to re-establish the link
between the vector key and the attribute table.

> 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.
> 

As per above. If the layer/cat is being lost, it needs to be fixed.

So I guess the main issue is simply one of terminology (and maybe getting
rid of the confusing "label" legacy).

Also better explanation is needed. I did an explanation on the WIKI some
time back after I achieved 'layer enlightenment'. Please don't hesitate to
add to it.

Michael

__________________________________________
Michael Barton, Professor of Anthropology
School of Human Evolution & Social Change
Center for Social Dynamics & Complexity
Arizona State University

phone: 480-965-6213
fax: 480-965-7671
www: http://www.public.asu.edu/~cmbarton