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

Patton, Eric epatton at nrcan.gc.ca
Fri Sep 22 07:31:56 EDT 2006


Just a correction, Moritz...

I think you were quoting Trevor's responses below and attributing them to me
;)

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

On Wed, September 20, 2006 16:48, Michael Barton wrote:
> You CAN link multiple tables to single vector objects. That is what
>layers is all about. You need a separate CAT column for each table you
link.
>Each cat column is a "layer". It serves as a key to link the object with a
> record in a table.

So, does each cat column in each table need to have the SAME ID  for a given
vector object?

~ Eric.





-----Original Message-----
From: Moritz Lennert
To: Michael Barton
Cc: Patton, Eric; 'grassuser at grass.itc.it'; twiens at interbaun.com;
dylan.beaudette at gmail.com
Sent: 9/21/2006 4:17 PM
Subject: Re: [GRASS-user] RE: Problem querying layers other than '1' in
gis.m



Yes, sorry, my first explanation was wrong. What I meant is that you
cannot link an object which only has one category defined in one layer
to
more than one table.

I'm not sure I understand what you mean by CAT "column". If you want to
link a map to a second table, you have to create category values in
another layer for the objects you want to link.

In other words
If your object only has

cat layer 1: 555

You cannot link this object to two tables.

But if it has

cat layer 1: 555
cat layer 2: 9

Then you can link it to one table using cat layer 1 and another table
using cat layer 2.

Now, if you have two tables which would use the same key (i.e. let's say
you have a map of countries and two tables listing attributes of these
countries, both of them containing a key column with integer country
codes), you can either duplicate your category values, so that cat layer
1
and cat layer 2 are identical and then you can link each of these layers
to one of the tables (which would be quite some work if you have a lot
of
objects, as I don't know of a way of copying cat values automatically
from
one layer to another), or you can simply combine the two tables in your
database system (more difficult with dbf tables, but easy in RDBMS).

The main idea of having layers in GRASS is to allow the same graphical
object to represent different functions, i.e. a road can be a road and a
state boundary, or it can have a national and an international function,
etc.

>
> I don't know if v.what (used in gui vector querying) will query more
than
> layer one. There was some discussion about this awhile back and I
can't
> remember the outcome. There have been some other new changes to v.what
> that
> will eventually go into 6.3. If layer support has been added, this
will go
> into 6.3 also.



This is actually not true, your module is better than you think ;-):

GRASS 6.3.cvs (BELGIQUE):~ > v.what -a map=test distance=1000
east_north=185558,127480.5625

East: 185558
North: 127480.5625
Map: test
Mapset: mlennert
Point

Layer: 1
Category: 2
driver: sqlite
database: /home/mlennert/GRASSDATA/BELGIQUE/mlennert/sqlite.db
table: test
key column: cat
cat : 2
pop : 5000
Layer: 2  <=======================
Category: 22
driver: sqlite
database: /home/mlennert/GRASSDATA/BELGIQUE/mlennert/sqlite.db
table: test2
key column: cat
cat : 22
rain : 123

The same works for d.what.vect.

I actually think the system is not that bad, but you have to understand
it
and use it for what it's designed for.

Eric wrote:
> Personally I think that attribute management should be left
> to the database backend and this so called feature should be
> dropped as the terminology is confusing.

Aside the issue of terminology, could you sketch out your ideas of how
you
would manage the above examples within a DBMS ? Do you mean that if a
road
has two functions, road and boundary, then this should be integrated
into
one table linked to the map ?

> But.... there is
> deep resistance from a number of core developers who
> designed and implemented this multiple table link feature,
> so that is not likely to happen.

The main vector architect, Radim, has left GRASS behind, in order to
concentrate more on other things (QGIS), so I don't think that
resistance
is that strong. If you can come up if a good proposal of how to
implement
a better alternative, then this would always be welcome.

Moritz

>
> 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
>
>
>
>> From: Moritz Lennert <mlennert at club.worldonline.be>
>> Date: Tue, 19 Sep 2006 23:51:23 +0200 (CEST)
>> To: "Patton, Eric" <epatton at nrcan.gc.ca>
>> Cc: "'grassuser at grass.itc.it'" <grassuser at grass.itc.it>
>> Subject: Re: [GRASS-user] RE: Problem querying layers other than '1'
in
>> gis.m
>>
>> On Tue, September 19, 2006 21:34, Patton, Eric wrote:
>>> I'm having trouble querying layer two on my vector map in gis.m. I
can
>>> query both the columns and data of layer one without problems. Maybe
I
>>> misunderstand the use of the tool. Are we supposed to be able to
query
>>> multiple layers on gis.m? If not, disregard the following. If so,
read
>>> on.
>>>
>>> I attached a second table to a vector point map on layer 2 like so:
>>>
>>> v.db.connect map=Station_46_Interp driver=sqlite
>>>
database=/home/epatton/Projects/Cheticamp/PERMANENT/databases/Cheticamp.
>>> db table=Benthos key=Timestamp layer=2
>>>
>>> And v.db.connect shows that two tables are now connected:
>>>
>>> v.db.connect -g map=Station_46_Interp driver=sqlite
>>>
database=/home/epatton/Projects/Cheticamp/PERMANENT/databases/Cheticamp.
>>> db table=Benthos key=Timestamp layer=2
>>>
>>> 1 Station_46_Interp cat
>>> /home/epatton/Projects/Cheticamp/PERMANENT/databases/Cheticamp.db
>>> sqlite
>>> 2 Benthos Timestamp
>>> /home/epatton/Projects/Cheticamp/PERMANENT/databases/Cheticamp.db
>>> sqlite
>>>
>>> I can query layer 1 in gis.m by showing the table columns using the
>>> 'show columns' button:
>>>
>>> Displaying column types/names for database connection of layer 1:
>>> INTEGER|cat
>>> INTEGER|Timestamp
>>> DOUBLE PRECISION|Easting
>>> DOUBLE PRECISION|Northing
>>>
>>> And similarly for layer 2:
>>>
>>> Displaying column types/names for database connection of layer 2:
>>> INTEGER|Station_ID
>>> INTEGER|Depth_m
>>> INTEGER|Latitude
>>> INTEGER|Longitude
>>> INTEGER|Julian_Day
>>> INTEGER|UTM_time
>>> INTEGER|Sediment_type
>>> INTEGER|Description
>>> INTEGER|Easting
>>> INTEGER|Northing
>>> INTEGER|Timestamp
>>>
>>> However, the 'show attribute data' button only works for layer 1,
not
>>> layer 2:
>>>
>>> Command output pasted from gis.m Output window:
>>>
>>> db.select table=Station_46_Interp
>>>
database=/home/epatton/Projects/Cheticamp/PERMANENT/databases/Cheticamp.
>>> db driver=sqlite 2
>>>
>>> The table connected on layer 2 is Benthos, not Station_46_Interp.
>>> It look like the value "2" is simply appended after the driver
>>> parameter, giving the understandable error from gis.m of " Sorry <2>
is
>>> not a valid option".
>>
>> Are you sure that you are using the layers correctly ? I've that the
>> same
>> head scratching which lead to this thread:
>> http://grass.itc.it/pipermail/grass5/2005-September/019592.html
>>
>> The way I understand it, you cannot link the same features to two
>> different tables. You would have to duplicate your points from layer
1
>> to
>> layer 2 to be able to link them to another table.
>>
>> Would be great to be able to link to several tables. Can't you just
>> create
>> a view which combines the two tables and link your map to that ?
>>
>> Moritz
>>
>>
>
>





More information about the grass-user mailing list