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.
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.
Eric wrote:
v.what does not support layers.
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@club.worldonline.be>
Date: Tue, 19 Sep 2006 23:51:23 +0200 (CEST)
To: "Patton, Eric" <epatton@nrcan.gc.ca>
Cc: "'grassuser@grass.itc.it'" <grassuser@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