On Fri, 22 Sep 2006 08:31:56 -0300
Patton, Eric wrote:
Eric,
Perhaps it would be helpful for you to read:
http://www.grass.itc.it/grass63/manuals/html63_user/vectorintro.html
and carefully read the section on attribute management and layers. This
was drafted to help explain this confusing 'feature'.
Just a correction, Moritz...
I think you were quoting Trevor's responses below and attributing them to me
Yes Moritz did attribute my views about the layer feature to you.
I am still confused about how layers work in Grass. From what I remember in
my brief time using Access, when a one-to-many table connection is made,
each table must have a Primary Key column where the key identifies unique
records in each table, AND the SAME Primary Key ID is used in all tables for
one features' attributes. So the attributes of Primary Key ID #5 in table
'Sample_Stations' correspond to attributes of Key ID #5 in the tables
'Biology', 'Geology', 'Geochem', etc. All attached layers, in other words,
have the SAME ID (cat) in each table that unites all attibutes for each
vector geometry under one category ID (all tables have cat #5 for a
particular sample station, say).However, in your example below, you have DIFFERENT cat IDs in each attached
table...so I'm confused about how Grass 'knows' that cat 1 in table 1
matches cat 22 in table 2. How is this connection made if there is no common
ID between various attributes in each table? Does Grass simply match on a
row-by-row basis (i.e., record one in table one will be linked to record one
in table two)?
This is one of my complaints. The regular database approach would be
each feature has a single attribute id and the vectors objects would
link to a primary table through that attribute. Classification of
specific objects could be done through other tables linking to the
first or through attributes in that table. The GRASS layer feature
allows each vector object to have 0, 1 or more cats in each layer.
Why you ask? Since most GRASS modules only recognize the vector objects
category, it was decided that rather than simply have a query
function provide the list of objects to be considered by a particular
module, that multiple cats would be used instead.
If you want to hear the reasoning behind some of it you might want to
read through the threads:
http://grass.itc.it/pipermail/grass-dev/2006-March/021503.html
http://grass.itc.it/pipermail/grass-dev/2006-March/021516.html
Moritz,
We went through all this before in March. My suggestions are two
fold:
1. If we retain 'layers' then change the name. The name is confusing
and inappropriate. I don't care about OGR or other abuses of the term.
Suggestions such as 'link' or 'key_field' make sense.
2. Is it possible by allowing attribute based queries to provide vector
object identification in the system to replicate all the existing
functionality. I can not think of a case where this wouldn't work, and
since there is effort to move to SQLite and better attribute
management, now is a natural time to consider this option. Vector
objects should IMO have one and only one cat value. This shouldn't
change, but instead attributes should identify feature themes. I
realize that this is a major change and since I don't have the time to
do it myself, I doubt anyone else is going to take this on.
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. Something for the GRASS steering committee to consider is
if we should be thinking of updating the raster library in the next
major revision of GRASS, or instead fixing the vector library. I really
wish I had the time to put into this, but I just don't. I'm trying to
get something working to explore some new ideas for a new wxPython GUI,
but haven't got very far past the drawing board yet, so I can't take
anything on until I can get that out the door.
Still, the 'layer feature' is largely not used. If we are going to
consider replacing it, there needs to be serious thought into how a
database attribute based system would be implemented so that it would
actually be easy and obvious, rather then cryptic and confusing. If we
can't come up with a replacement that is clearly superior then we need
to focus efforts in renaming and documenting.
T
--
Trevor Wiens
twiens@interbaun.com
The significant problems that we face cannot be solved at the same
level of thinking we were at when we created them.
(Albert Einstein)