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

[Eric_Patton]

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@grass.itc.it'; twiens@interbaun.com;
dylan.beaudette@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@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

[mlennert]

Patton, Eric wrote:

Just a correction, Moritz...

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

Yes, sorry, it was late.

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

Each object in a GRASS map can, but does not need to, have one or more "category" value(s) assigned to it. These values are not necessarily unique, so you can have different objects with the same category value (i.e. you could have a map of roads with the category values representing the types of roads from 1 interstate to 5 local).

Categories can be organised by layers, in order to allow a logical organisation of information. You could use one layer to define road type, another layer to define administrative responsibilites (1 = federal, 2 = state, 3 = local), etc.

IIUC, the main aim of such organisation in layers, is to allow the combination of different types of objects (e.g. wells, rivers, roads and houses) into the same map and to allow the linkage of these different types of objects to different tables.

You can actually assign several category values to one object within the same layer. I don't really see the use of that (but I imagine there is one).

For each layer of a map, you can define one and only one connection to a data table. This makes sense, as otherwise, how should grass know which table to use (for example if you use d.vect map where=). GRASS is not an RDBMS, it is a geographical analysis system.

In order to link your objects (identified by layer+category combinations) to the table, you need to have within that table a 'key' column with the same values as the categories. So, the link between a map's layer and a table is one-to-one (one table for one layer). You can have a one-to-many relation for a map (i.e. many tables for one map) by using different layers.

To take your above example, if you want to link your map to all tables ('Sample_Stations', 'Biology', 'Geology', 'Geochem', etc), you have two choices:

1) The most obvious, the easiest and in my eyes to most sensible solution is to combine the table within your database into one table or one view and to link this to the map.

2) Within the map you create a layer for each table, each layer containing the same category value for a given object. This is not easy to do and is definitely not what the layers were created for in the first place.

It would be interesting to hear how many people actually use layers and how they use them. I personally don't use them at all, as I normally don't mix different types of objects in the same map. Maybe others could give some use cases.

I think you have to see the whole vector attribute system as the product of GRASS' history. Before version 5.7/6.0, any vector map could only be linked to one single attribute list. So, there is obviously room for improvement (Radim has listed some here: http://freegis.org/cgi-bin/viewcvs.cgi/grass6/doc/vector/TODO?rev=HEAD&content-type=text/vnd.viewcvs-markup).

That's also why I plea for _Trevor_ (this time I got it right ) to give some details about his ideas.

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?

No, you can give different category values to a given object in different layers and then link these layers to the respective tables.

I think once our minds become clearer about these layers, we should write a small text for the wiki...

Moritz

[Radim_Blazek3]

On 9/22/06, Moritz Lennert <mlennert@club.worldonline.be> wrote:

You can actually assign several category values to one object within the
same layer. I don't really see the use of that (but I imagine there is one).

There are more, examples:
- Overlapping areas, e.g. a road on a bridge and a road below
- Many records with different time for the same point

It would be interesting to hear how many people actually use layers and
how they use them. I personally don't use them at all, as I normally
don't mix different types of objects in the same map. Maybe others could
give some use cases.

An example from my last project are targets of bombing (WWII)
where each target (can be point, line or area) has many attacks
(dates differ) in one layer (table) and summary table (bombs/target)
is linked to the second layer. Here you have both mix of types
and layers.

Radim

[mlennert]

Radim Blazek wrote:

On 9/22/06, Moritz Lennert <mlennert@club.worldonline.be> wrote:

You can actually assign several category values to one object within the
same layer. I don't really see the use of that (but I imagine there is one).

There are more, examples:
- Overlapping areas, e.g. a road on a bridge and a road below
- Many records with different time for the same point

Both of these examples use different layers to store information, not different category values in the same layer, or ?

For the first example, I understand the idea of layers (and am not sure how you would do this within a database), for the second example, couldn't you just have one table with all the records and then do queries such as

where cat= and timestamp=

?

It would be interesting to hear how many people actually use layers and
how they use them. I personally don't use them at all, as I normally
don't mix different types of objects in the same map. Maybe others could
give some use cases.

An example from my last project are targets of bombing (WWII)
where each target (can be point, line or area) has many attacks
(dates differ) in one layer (table) and summary table (bombs/target)
is linked to the second layer. Here you have both mix of types
and layers.

If I follow Trevor's argumentation, this should be done by having just one category for each vector object (whatever its type) and then a table with all the individual attacks. You should then be able to use aggregate queries such as

select category, count(attacks) from table_attacks group by category

to get the summary which you should then be able to display.

Trevor, did I understand you right ?

Moritz

[Radim_Blazek3]

On 9/22/06, Moritz Lennert <mlennert@club.worldonline.be> wrote:

> There are more, examples:
> - Overlapping areas, e.g. a road on a bridge and a road below
> - Many records with different time for the same point

Both of these examples use different layers to store information, not
different category values in the same layer, or ?

No. One layer, more cats per geometry.

Radim

[mlennert]

Radim Blazek wrote:

On 9/22/06, Moritz Lennert <mlennert@club.worldonline.be> wrote:

> There are more, examples:
> - Overlapping areas, e.g. a road on a bridge and a road below
> - Many records with different time for the same point

Both of these examples use different layers to store information, not
different category values in the same layer, or ?

No. One layer, more cats per geometry.

What's the advantage of doing this in one layer ? Why not use one layer with one category value and store different time records for the same category in the one table linked to that layer ?

Moritz

[Radim_Blazek3]

On 9/26/06, Moritz Lennert <mlennert@club.worldonline.be> wrote:

Radim Blazek wrote:
> On 9/22/06, Moritz Lennert <mlennert@club.worldonline.be> wrote:
>> > There are more, examples:
>> > - Overlapping areas, e.g. a road on a bridge and a road below
>> > - Many records with different time for the same point
>>
>> Both of these examples use different layers to store information, not
>> different category values in the same layer, or ?
>
> No. One layer, more cats per geometry.

What's the advantage of doing this in one layer ? Why not use one layer
with one category value and store different time records for the same
category in the one table linked to that layer ?

That would be also possible in theory but GRASS does not work in this manner.
The reason is that this way it is not possible to model for example overlapping
areas. Imagine 2 areas, bridge over another road, each road has one
record in table.

Map:
           +-------+
           | A |
+---------+--------+-----------+
| B | A/B | B |
+---------+--------+-----------+
           | A |
           +--------+

Table:
+------+--------+
| cat | road |
+------+--------+
| 1 | A |
+------+--------+
| 2 | B |
+------+--------+

Now try to fill in cats to the map. It is impossible. You need to give
more cats to the overlappig part.

In theory you could move the relations to a database as suggested Trevor,
but it would be difficult and not efficient to reflect any operations
on geometry
in database. It is very easy to assign 2 cats to the overlapping parts
from 2 input areas, to do that in database (from GRASS) is much more complex.
If you want, you have to move to database everything, i.e. also geometry.

Radim

[mlennert]

On Tue, September 26, 2006 17:06, Radim Blazek wrote:

On 9/26/06, Moritz Lennert <mlennert@club.worldonline.be> wrote:

Radim Blazek wrote:
> On 9/22/06, Moritz Lennert <mlennert@club.worldonline.be> wrote:
>> > There are more, examples:
>> > - Overlapping areas, e.g. a road on a bridge and a road below
>> > - Many records with different time for the same point
>>
>> Both of these examples use different layers to store information, not
>> different category values in the same layer, or ?
>
> No. One layer, more cats per geometry.

What's the advantage of doing this in one layer ? Why not use one layer
with one category value and store different time records for the same
category in the one table linked to that layer ?

That would be also possible in theory but GRASS does not work in this
manner.
The reason is that this way it is not possible to model for example
overlapping
areas. Imagine 2 areas, bridge over another road, each road has one
record in table.

Map:
           +-------+
           | A |
+---------+--------+-----------+
| B | A/B | B |
+---------+--------+-----------+
           | A |
           +--------+

Table:
+------+--------+
| cat | road |
+------+--------+
| 1 | A |
+------+--------+
| 2 | B |
+------+--------+

Now try to fill in cats to the map. It is impossible. You need to give
more cats to the overlappig part.

In theory you could move the relations to a database as suggested Trevor,
but it would be difficult and not efficient to reflect any operations
on geometry
in database. It is very easy to assign 2 cats to the overlapping parts
from 2 input areas, to do that in database (from GRASS) is much more
complex.

Thanks for the explanation. I understand the overlapping areas argument.
What about the time series ?

If you want, you have to move to database everything, i.e. also geometry.

The PostGIS solution. But am I right in thinking that PostGIS is
non-topological, with the consequence that you get all the potential
'spaghetti geometry' problems ?

Moritz

[Trevor_Wiens2]

On Tue, 26 Sep 2006 17:06:13 +0200
Radim Blazek wrote:

---snip---

In theory you could move the relations to a database as suggested Trevor,
but it would be difficult and not efficient to reflect any operations
on geometry in database.

It is very easy to assign 2 cats to the overlapping parts
from 2 input areas, to do that in database (from GRASS) is much more complex.
If you want, you have to move to database everything, i.e. also geometry.

I completely disagree. It would be very easy to describe overlapping
areas with database attributes, in fact, IMO much easier than with
layers. You are correct however, that storing this information
internally in GRASS is more efficient for the very small percent of the
time where a module will need to reference this information for some
purpose other than getting a list of objects to consider for
processing. Right now almost all modules allow for some filtering by a
query so AFAICT using arbitrary queries to replace the 'layers feature'
would have a negligible impact on performance in most cases. If this is
not the case please elaborate.

It does not follow that moving attribute management into the database
requires the movement of geometry as well, or at least you've not
demonstrated it, only stated it.

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)

[Radim_Blazek3]

On 9/27/06, Trevor Wiens <twiens@interbaun.com> wrote:

On Tue, 26 Sep 2006 17:06:13 +0200
Radim Blazek wrote:

---snip---
>
> In theory you could move the relations to a database as suggested Trevor,
> but it would be difficult and not efficient to reflect any operations
> on geometry in database.
>
> It is very easy to assign 2 cats to the overlapping parts
> from 2 input areas, to do that in database (from GRASS) is much more complex.
> If you want, you have to move to database everything, i.e. also geometry.

I completely disagree. It would be very easy to describe overlapping
areas with database attributes, in fact, IMO much easier than with
layers. You are correct however, that storing this information
internally in GRASS is more efficient for the very small percent of the
time where a module will need to reference this information for some
purpose other than getting a list of objects to consider for
processing. Right now almost all modules allow for some filtering by a
query so AFAICT using arbitrary queries to replace the 'layers feature'
would have a negligible impact on performance in most cases. If this is
not the case please elaborate.

It does not follow that moving attribute management into the database
requires the movement of geometry as well, or at least you've not
demonstrated it, only stated it.

Try to rewrite v.overlay using your model.

Radim

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)