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

Thu Sep 21 16:17:57 EDT 2006

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