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

Michael Barton michael.barton at asu.edu
Thu Sep 21 16:29:54 EDT 2006


Good explanation. 

CAT "column" simply means cat field. It is a "column" or "field" in a
database sense of integer values that serve as a key field to link a vector
object with an attribute table, as you point out below.

Michael
__________________________________________
Michael Barton, Professor of Anthropology
School of Human Evolution & Social Change
Center for Social Dynamics and 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: Thu, 21 Sep 2006 22:17:57 +0200 (CEST)
> To: Michael Barton <michael.barton at asu.edu>
> Cc: "Patton, Eric" <epatton at nrcan.gc.ca>, "'grassuser at grass.itc.it'"
> <grassuser at grass.itc.it>, <twiens at interbaun.com>, <dylan.beaudette at gmail.com>
> Subject: Re: [GRASS-user] RE: Problem querying layers other than '1' in  gis.m
> 
> 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
>>> 
>>> 
>> 
>> 
> 
> 




More information about the grass-user mailing list