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

[Trevor_Wiens2]

----- Original Message Follows -----
From: Moritz Lennert <mlennert@club.worldonline.be>
To: Trevor Wiens <twiens@interbaun.com>
Cc: "Patton, Eric" <epatton@nrcan.gc.ca>, 'Michael Barton '
<michael.barton@asu.edu>, "''grassuser@grass.itc.it' '"
<grassuser@grass.itc.it>, GRASS-DEV <grass-dev@grass.itc.it>
Subject: Re: [GRASS-user] RE: Problem querying layers other
than '1' in gi s.m
Date: Fri, 22 Sep 2006 16:56:20 +0200

---snip---

> Vector
> objects should IMO have one and only one cat value. This
> shouldn't change, but instead attributes should identify
feature themes.

Now I am getting bitten by the vocabulary: what are
"feature themes" ?

Sorry. Bad choice of words. Terminology is a tricky thing.
Right now cats in one or more 'layers' are used to identify
thematically distinct but topologically related spatial
objects. Such as forest areas and lakes, or sites at
different times. What seems much more natural to me is
leaving the attribute management to the database where more
elegant tools exist. Thus grass modules instead having a
layer option need a input key and possibly an output key
option depending on the module. If no key field is specified
(which would be an attribute in the table linked to the
vector file), then all objects in the vector file are
processed. However if a key is used to query the vector file
for a list of objects for processing. In the case where the
same vector object has two cats, the vector attribute tables
will have to have a one to many relationship from the vector
file to the attribute table. Now modules could also allow a
query specification to allow for complex querying across
multiple keys and attributes, but output would probably have
to be limited to a series of key fields (most likely only
integers)

Now it could be argued that this is not essentially
different than the 'layer' feature now, but what is
fundamentally different is access to and control of the
attribute tables. In this case, all attribute management
stays in the database where it belongs. It makes a clear
distinction between GIS thinking and database thinking and
enables a great deal more elegance to attribute management
than is currently supported. As a proper database GUI is
built for GRASS, or if people choose to use other tools like
PgAdmin for example, then attribute management becomes much
more natural and easy.

The benefits of this system can be seen in a simple example.
Right now if you have a point file and you want to create a
buffer around those points all the attribute information is
lost and must be patched back in. By keeping attributes in
the database it would be much simpler to have an attribute
in the new vector linking back to the old key and thus
effectively keeping all the old attribute information linked
to the derived layer.

---snip---

> Thinking long term however, it has been amply
> demonstrated that the vector library although a big
> improvement for the old days, still needs a lot of work.
> Memory management issues periodically arise on the dev
list with large data streams and that data streams will
> continue to swamp memory and swap space so proper
> caching is required for optimal processing.

I'm not sure that this is directly linked to the database
question, though, or ?

See above

---snip---

I would like to come to a point where we are not only
speaking about how bad the current system is, but how
_concretely_ a new system should look like.

Is the above concrete enough to give you an idea what I'm
thinking?

T

--
Trevor Wiens
twiens@interbaun.com

[cmbarton]

A couple of clarifications.

Sorry. Bad choice of words. Terminology is a tricky thing.
Right now cats in one or more 'layers' are used to identify
thematically distinct but topologically related spatial
objects. Such as forest areas and lakes, or sites at
different times.

While they *can* be used that way (and I know that's what some of the
explantions have said), they are actually much more generic.

What seems much more natural to me is
leaving the attribute management to the database where more
elegant tools exist. Thus grass modules instead having a
layer option need a input key and possibly an output key
option depending on the module. If no key field is specified
(which would be an attribute in the table linked to the
vector file), then all objects in the vector file are
processed. However if a key is used to query the vector file
for a list of objects for processing. In the case where the
same vector object has two cats, the vector attribute tables
will have to have a one to many relationship from the vector
file to the attribute table. Now modules could also allow a
query specification to allow for complex querying across
multiple keys and attributes, but output would probably have
to be limited to a series of key fields (most likely only
integers)

Really, this is exactly what "layers" are now. AFAICT, the biggest problem
is in the terminology. Each "layer" is an integer key field in database
terminology. Multiple layers simply means multiple key fields, each of which
can be linked with an attribute table using v.db.connect.

Now it could be argued that this is not essentially
different than the 'layer' feature now, but what is
fundamentally different is access to and control of the
attribute tables. In this case, all attribute management
stays in the database where it belongs.

Again, except for the key fields confusingly labeled as "layers" and one
other legacy feature from GRASS 5, all attribute management does stay in the
database. The "cat" value in the key (aka "layer), connects a vector object
with its corresponding record(s) in the attribute table. The GRASS 5 legacy
is that you can have a single text field that accompanies each key. This is
a left over when the only vector database easily available consisted of a
single integer field (cat) and single text field (label) for each vector
file. This mirrored the attribute structure of raster files. We could
probably drop the "label" field from the vector database structure with
little loss and some gain in understandability. We could then rename
"layers" and "cat" to "key fields" or "keys". This brings up another
terminological confusion. We commonly refer to a "cat" value. This is simply
the integer value within each key.

I think it would help a lot if we simply dropped "cat" and "layer" (keeping
a reference to these terms in the documentation for legacy data) and used
some version of key and value. For example:

v.centroids input=name output=name [option=string] [layer=integer]
[cat=integer] [step=integer] [--overwrite]

Becomes...

v.centroids input=name output=name [option=string] [key=integer]
[keyvalue=integer] [step=integer] [--overwrite]

OR

v.db.connect [-pgcod] map=name [driver=string] [database=string]
[table=string] [key=string] [layer=integer]

Becomes...

v.db.connect [-pgcod] map=name [driver=string] [database=string]
[table=string] [dbkey=string] [vectkey=integer]

OR

v.db.update map=string [layer=integer] column=string value=string
[where=string]

Becomes...

v.db.update map=string [key=integer] column=string value=string
[where=string]

It makes a clear
distinction between GIS thinking and database thinking and
enables a great deal more elegance to attribute management
than is currently supported. As a proper database GUI is
built for GRASS, or if people choose to use other tools like
PgAdmin for example, then attribute management becomes much
more natural and easy.

I agree

The benefits of this system can be seen in a simple example.
Right now if you have a point file and you want to create a
buffer around those points all the attribute information is
lost and must be patched back in.

This is only lost if the key (aka "layer"/"cat") is lost. If it is
maintained, one only has to run v.db.connect to re-establish the link
between the vector key and the attribute table.

By keeping attributes in
the database it would be much simpler to have an attribute
in the new vector linking back to the old key and thus
effectively keeping all the old attribute information linked
to the derived layer.

As per above. If the layer/cat is being lost, it needs to be fixed.

So I guess the main issue is simply one of terminology (and maybe getting
rid of the confusing "label" legacy).

Also better explanation is needed. I did an explanation on the WIKI some
time back after I achieved 'layer enlightenment'. Please don't hesitate to
add to it.

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

[mlennert]

Michael has already said most of what I wanted to say, but some small additions.

Michael Barton wrote:

What seems much more natural to me is
leaving the attribute management to the database where more
elegant tools exist. Thus grass modules instead having a
layer option need a input key and possibly an output key
option depending on the module. If no key field is specified
(which would be an attribute in the table linked to the
vector file), then all objects in the vector file are
processed. However if a key is used to query the vector file
for a list of objects for processing. In the case where the
same vector object has two cats, the vector attribute tables
will have to have a one to many relationship from the vector
file to the attribute table. Now modules could also allow a
query specification to allow for complex querying across
multiple keys and attributes, but output would probably have
to be limited to a series of key fields (most likely only
integers)

Really, this is exactly what "layers" are now. AFAICT, the biggest problem
is in the terminology. Each "layer" is an integer key field in database
terminology. Multiple layers simply means multiple key fields, each of which
can be linked with an attribute table using v.db.connect.

What is missing as far as I can tell (but I don't know if Trevor's solution would solve that) is that you cannot query across multiple tables in the current system (i.e. you cannot query for those points in a map which have value X in table Y where Y.key = maptable.key). You have to first create a new table or view combining Y and maptable and the link the map to that new table or view.

Now it could be argued that this is not essentially
different than the 'layer' feature now, but what is
fundamentally different is access to and control of the
attribute tables. In this case, all attribute management
stays in the database where it belongs.

Again, except for the key fields confusingly labeled as "layers" and one
other legacy feature from GRASS 5, all attribute management does stay in the
database.

Unless you use it in the way I suggested in an earlier mail, i.e. cat 1 = coniferous, cat 2 = broadleaved, cat 10 = pine, etc.

The way it 'should' be used to stick with Trevor's suggestions is

cat 1 = tree number 1
cat 2 = tree number 2

etc.

And then have a table with columns

treenumber, species, etc,

with possibly another table with

species, type

where type= conferous or broadleaved

And then, if you need a map of coniferous and broadleaved trees, you create a view:

CREATE VIEW v1 AS SELECT treenumber, type FROM trees, types WHERE trees.species=types.species

And then link to v1 with

v.db.connect map table=v1 key=treenumber

The "cat" value in the key (aka "layer), connects a vector object
with its corresponding record(s) in the attribute table. The GRASS 5 legacy
is that you can have a single text field that accompanies each key. This is
a left over when the only vector database easily available consisted of a
single integer field (cat) and single text field (label) for each vector
file. This mirrored the attribute structure of raster files. We could
probably drop the "label" field from the vector database structure with
little loss and some gain in understandability. We could then rename
"layers" and "cat" to "key fields" or "keys". This brings up another
terminological confusion. We commonly refer to a "cat" value. This is simply
the integer value within each key.

I think it would help a lot if we simply dropped "cat" and "layer" (keeping
a reference to these terms in the documentation for legacy data) and used
some version of key and value. For example:

I'm really not sure that the layer, cat terminology is really the problem, here...

The benefits of this system can be seen in a simple example.
Right now if you have a point file and you want to create a
buffer around those points all the attribute information is
lost and must be patched back in.

This is only lost if the key (aka "layer"/"cat") is lost. If it is
maintained, one only has to run v.db.connect to re-establish the link
between the vector key and the attribute table.

>

By keeping attributes in
the database it would be much simpler to have an attribute
in the new vector linking back to the old key and thus
effectively keeping all the old attribute information linked
to the derived layer.

As per above. If the layer/cat is being lost, it needs to be fixed.

v.buffer is a very special case, and I don't know how you would solve the question in your system: the attribute information is lost since v.buffer fusions overlapping buffers into one single buffer. As mentioned on the man page, there is no automatic way to know which cat (or keyvalue) to give to this single fusioned buffer.

It might be an idea to add a flag to v.buffer to not fusion buffers, and then keep the cats (or keyvalues)

So I guess the main issue is simply one of terminology (and maybe getting
rid of the confusing "label" legacy).

As already mentioned, I'm not sure if this is really the issue, but if you think it helps making things more clear for users, I don't have any objections.

One thing that might be useful, is to add an option to v.category to justcopy the category value from one layer to another, thus allowing to link one map to different tables with the same key value. But then again, this should probably be done within the database using views or new tables, and not on the map side...

Also better explanation is needed. I did an explanation on the WIKI some
time back after I achieved 'layer enlightenment'. Please don't hesitate to
add to it.

For those looking for it:
http://grass.gdf-hannover.de/wiki/Vector_Database_Management#Concepts_and_jargon

Moritz

[Trevor_Wiens2]

On Tue, 26 Sep 2006 11:32:38 +0200
Moritz Lennert wrote:

Michael has already said most of what I wanted to say, but some small
additions.

Michael Barton wrote:
>> What seems much more natural to me is
>> leaving the attribute management to the database where more
>> elegant tools exist. Thus grass modules instead having a
>> layer option need a input key and possibly an output key
>> option depending on the module. If no key field is specified
>> (which would be an attribute in the table linked to the
>> vector file), then all objects in the vector file are
>> processed. However if a key is used to query the vector file
>> for a list of objects for processing. In the case where the
>> same vector object has two cats, the vector attribute tables
>> will have to have a one to many relationship from the vector
>> file to the attribute table. Now modules could also allow a
>> query specification to allow for complex querying across
>> multiple keys and attributes, but output would probably have
>> to be limited to a series of key fields (most likely only
>> integers)
>
> Really, this is exactly what "layers" are now. AFAICT, the biggest problem
> is in the terminology. Each "layer" is an integer key field in database
> terminology. Multiple layers simply means multiple key fields, each of which
> can be linked with an attribute table using v.db.connect.

No, not really. What I describe is functionality identical to current
layers, but the critical distinction is that all the attribute
information can be managed in the database independent of GRASS or
without GRASS even running. Right now the cat values for a vector
object can only be accessed through GRASS. If GRASS built a simple
table for each vector object with a cat (or perhaps more clearly
named an objectid) and a user defined key as well as allowing users to
add other keys to that table, then there would be no need to run GRASS
to update attribute information for those objects. For example, lets say
you have a series of weather sites which would have a incremental
objectid and a user defined key such as a stationid. If you want to
be able to occasionally interpolate precipitation surfaces from these
sites since all the attribute information is accessible independent
of GRASS (I envision using PostgreSQL in this case) you can write you
application in whatever environment you like and access the database
outside of GRASS and add and edit new time data as needed. Then when it
is time to create your new surface you fire up GRASS do your
multi-table query without any call to v.db.connect because it is no
longer needed and get the result. Done.

What is missing as far as I can tell (but I don't know if Trevor's
solution would solve that) is that you cannot query across multiple
tables in the current system (i.e. you cannot query for those points in
a map which have value X in table Y where Y.key = maptable.key). You
have to first create a new table or view combining Y and maptable and
the link the map to that new table or view.

>> Now it could be argued that this is not essentially
>> different than the 'layer' feature now, but what is
>> fundamentally different is access to and control of the
>> attribute tables. In this case, all attribute management
>> stays in the database where it belongs.
>
> Again, except for the key fields confusingly labeled as "layers" and one
> other legacy feature from GRASS 5, all attribute management does stay in the
> database.

Unless you use it in the way I suggested in an earlier mail, i.e. cat 1
= coniferous, cat 2 = broadleaved, cat 10 = pine, etc.

The way it 'should' be used to stick with Trevor's suggestions is

cat 1 = tree number 1
cat 2 = tree number 2

etc.

And then have a table with columns

treenumber, species, etc,

with possibly another table with

species, type

where type= conferous or broadleaved

And then, if you need a map of coniferous and broadleaved trees, you
create a view:

CREATE VIEW v1 AS SELECT treenumber, type FROM trees, types WHERE
trees.species=types.species

Why bother with v.db.connect at all? Just allow a query to be used to
select the vector object keys (cats) and let the module in question
work with that list. I realize that many people not familiar with SQL
will find this difficult, but surely we could consider as part of
upgrading the GUI front end with a simple query builder.

A view would be convenient for ongoing use, but shouldn't be necessary
for single time uses.

And then link to v1 with

v.db.connect map table=v1 key=treenumber

> The "cat" value in the key (aka "layer), connects a vector object
> with its corresponding record(s) in the attribute table. The GRASS 5 legacy
> is that you can have a single text field that accompanies each key. This is
> a left over when the only vector database easily available consisted of a
> single integer field (cat) and single text field (label) for each vector
> file. This mirrored the attribute structure of raster files. We could
> probably drop the "label" field from the vector database structure with
> little loss and some gain in understandability. We could then rename
> "layers" and "cat" to "key fields" or "keys". This brings up another
> terminological confusion. We commonly refer to a "cat" value. This is simply
> the integer value within each key.
>
> I think it would help a lot if we simply dropped "cat" and "layer" (keeping
> a reference to these terms in the documentation for legacy data) and used
> some version of key and value. For example:

I'm really not sure that the layer, cat terminology is really the
problem, here...

Well changing the terminology would certainly help, but the fundamental
problem was clearly defined by Moritz when he suggested that the
problem is mixing of database concepts with GIS concepts. Thus my
suggestion to keep database functions in the database.

>
>> The benefits of this system can be seen in a simple example.
>> Right now if you have a point file and you want to create a
>> buffer around those points all the attribute information is
>> lost and must be patched back in.
>
> This is only lost if the key (aka "layer"/"cat") is lost. If it is
> maintained, one only has to run v.db.connect to re-establish the link
> between the vector key and the attribute table.
>
>> By keeping attributes in
>> the database it would be much simpler to have an attribute
>> in the new vector linking back to the old key and thus
>> effectively keeping all the old attribute information linked
>> to the derived layer.
>>
>
> As per above. If the layer/cat is being lost, it needs to be fixed.

v.buffer is a very special case, and I don't know how you would solve
the question in your system: the attribute information is lost since
v.buffer fusions overlapping buffers into one single buffer. As
mentioned on the man page, there is no automatic way to know which cat
(or keyvalue) to give to this single fusioned buffer.

My solution would work in the sense that new areas created would be
given a new objectid whereas areas (technically centroids associated
with areas) up to the point of overlap would retain their original
objectid and thus would have direct access to any associated attribute
information through a simple query.

It is important to note that my objectid terminology only makes sense
if this value is singular and immutable.

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)

[mlennert]

On Tue, September 26, 2006 15:37, Trevor Wiens wrote:

On Tue, 26 Sep 2006 11:32:38 +0200
Moritz Lennert wrote:

Michael has already said most of what I wanted to say, but some small
additions.

Michael Barton wrote:
>> What seems much more natural to me is
>> leaving the attribute management to the database where more
>> elegant tools exist. Thus grass modules instead having a
>> layer option need a input key and possibly an output key
>> option depending on the module. If no key field is specified
>> (which would be an attribute in the table linked to the
>> vector file), then all objects in the vector file are
>> processed. However if a key is used to query the vector file
>> for a list of objects for processing. In the case where the
>> same vector object has two cats, the vector attribute tables
>> will have to have a one to many relationship from the vector
>> file to the attribute table. Now modules could also allow a
>> query specification to allow for complex querying across
>> multiple keys and attributes, but output would probably have
>> to be limited to a series of key fields (most likely only
>> integers)
>
> Really, this is exactly what "layers" are now. AFAICT, the biggest
problem
> is in the terminology. Each "layer" is an integer key field in
database
> terminology. Multiple layers simply means multiple key fields, each of
which
> can be linked with an attribute table using v.db.connect.

No, not really. What I describe is functionality identical to current
layers, but the critical distinction is that all the attribute
information can be managed in the database independent of GRASS or
without GRASS even running. Right now the cat values for a vector
object can only be accessed through GRASS. If GRASS built a simple
table for each vector object with a cat (or perhaps more clearly
named an objectid) and a user defined key as well as allowing users to
add other keys to that table, then there would be no need to run GRASS
to update attribute information for those objects. For example, lets say
you have a series of weather sites which would have a incremental
objectid and a user defined key such as a stationid. If you want to
be able to occasionally interpolate precipitation surfaces from these
sites since all the attribute information is accessible independent
of GRASS (I envision using PostgreSQL in this case) you can write you
application in whatever environment you like and access the database
outside of GRASS and add and edit new time data as needed. Then when it
is time to create your new surface you fire up GRASS do your
multi-table query without any call to v.db.connect because it is no
longer needed and get the result. Done.

I don't really understand this argument. Why can't you do exactly this
with GRASS today ? First of all why do you need a separate objectid and
stationid if each station is represented by one object (let's say a point)
? You could just use the cat value of each object. You would then have a
table in PostgreSQL in which you have these cat values (possibly in a
colum you could
call stationid) and all other attributes you would like in this same
table. If you get new data for the stations you can add it to the table
without having to go through GRASS. Then when you enter grass, this new
information is available as long as your map remains linked to that table.

The only thing you cannot do currently (if I'm not mistaken) is use
aggregate queries on that table if you have more than one row for each
station. But I don't think that this is due to the general data model of
GRASS, but rather to the fact that it is not implemented.

[...]

> Again, except for the key fields confusingly labeled as "layers" and
one
> other legacy feature from GRASS 5, all attribute management does stay
in the
> database.

Unless you use it in the way I suggested in an earlier mail, i.e. cat 1
= coniferous, cat 2 = broadleaved, cat 10 = pine, etc.

The way it 'should' be used to stick with Trevor's suggestions is

cat 1 = tree number 1
cat 2 = tree number 2

etc.

And then have a table with columns

treenumber, species, etc,

with possibly another table with

species, type

where type= conferous or broadleaved

And then, if you need a map of coniferous and broadleaved trees, you
create a view:

CREATE VIEW v1 AS SELECT treenumber, type FROM trees, types WHERE
trees.species=types.species

Why bother with v.db.connect at all? Just allow a query to be used to
select the vector object keys (cats) and let the module in question
work with that list.

I think this is potentially possible with the current model, just not
implemented. The database drivers allow any kind of query you want, and it
should not be too complicated to rewrite modules in a way to allow more
arbitrary queries then just with the current 'where' option.

Any query which returns cat values allows you to then work with these cat
values (I am currently reworking d.vect.chart to do just that) and
it should, therefore, not be too difficult to imagine modules which allow
you to define an arbitrary query and to the fulfill their task on the
basis of this query.

According to the use you make of it you obviously can have a problem if
you have more than one object with the same cat value (I have that problem
in d.vect.cat, for example), but there are ways to work around this.

I realize that many people not familiar with SQL
will find this difficult, but surely we could consider as part of
upgrading the GUI front end with a simple query builder.

I should also be possible to offer both solutions.

A view would be convenient for ongoing use, but shouldn't be necessary
for single time uses.

I agree totally.

[...]

Well changing the terminology would certainly help, but the fundamental
problem was clearly defined by Moritz when he suggested that the
problem is mixing of database concepts with GIS concepts. Thus my
suggestion to keep database functions in the database.

Well GIS as such makes no sense if it is not understood as the link
between geometries and data, so you always have to mix the two in one way
or another. The question is more on how to do this in a way which is most
efficiently _and_ offers the most functionality.

v.buffer is a very special case, and I don't know how you would solve
the question in your system: the attribute information is lost since
v.buffer fusions overlapping buffers into one single buffer. As
mentioned on the man page, there is no automatic way to know which cat
(or keyvalue) to give to this single fusioned buffer.

My solution would work in the sense that new areas created would be
given a new objectid whereas areas (technically centroids associated
with areas) up to the point of overlap would retain their original
objectid and thus would have direct access to any associated attribute
information through a simple query.

Well, it should be no problem to reprogram v.buffer to do just that. Its
current implementation works with the assumption that as you could
potentially have overlaps, you treat all buffers as if they were overlaps,
but you could obviously include some test in the code which treats buffers
differentially. Again, I don't see how this is a problem of the model
rather than of the implementation of a particular module.

It is important to note that my objectid terminology only makes sense
if this value is singular and immutable.

This might actually be the fundamental point in the argument. Currently
GRASS doesn't enforce this as a rule (well actually, IIUC, each object has
a its line number as a unique identifier, this is just not visible to the
user). The question is whether it should enforce something like this, or
whether the current model doesn't allow more flexibility by allowing to
limit yourself to unique id's for each object, but also allowing the use
of non-unique id's, or multiple id's.

Moritz

[cmbarton]

I agree.

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, 26 Sep 2006 20:27:11 +0200 (CEST)
To: Trevor Wiens <twiens@interbaun.com>
Cc: Michael Barton <michael.barton@asu.edu>, "''grassuser@grass.itc.it' '"
<grassuser@grass.itc.it>, GRASS-DEV <grass-dev@grass.itc.it>
Subject: Re: [GRASS-dev] Re: [GRASS-user] RE: Problem querying layers other
than '1' in gi s.m

On Tue, September 26, 2006 15:37, Trevor Wiens wrote:

On Tue, 26 Sep 2006 11:32:38 +0200
Moritz Lennert wrote:

Michael has already said most of what I wanted to say, but some small
additions.

Michael Barton wrote:

What seems much more natural to me is
leaving the attribute management to the database where more
elegant tools exist. Thus grass modules instead having a
layer option need a input key and possibly an output key
option depending on the module. If no key field is specified
(which would be an attribute in the table linked to the
vector file), then all objects in the vector file are
processed. However if a key is used to query the vector file
for a list of objects for processing. In the case where the
same vector object has two cats, the vector attribute tables
will have to have a one to many relationship from the vector
file to the attribute table. Now modules could also allow a
query specification to allow for complex querying across
multiple keys and attributes, but output would probably have
to be limited to a series of key fields (most likely only
integers)

Really, this is exactly what "layers" are now. AFAICT, the biggest

problem

is in the terminology. Each "layer" is an integer key field in

database

terminology. Multiple layers simply means multiple key fields, each of

which

can be linked with an attribute table using v.db.connect.

No, not really. What I describe is functionality identical to current
layers, but the critical distinction is that all the attribute
information can be managed in the database independent of GRASS or
without GRASS even running. Right now the cat values for a vector
object can only be accessed through GRASS. If GRASS built a simple
table for each vector object with a cat (or perhaps more clearly
named an objectid) and a user defined key as well as allowing users to
add other keys to that table, then there would be no need to run GRASS
to update attribute information for those objects. For example, lets say
you have a series of weather sites which would have a incremental
objectid and a user defined key such as a stationid. If you want to
be able to occasionally interpolate precipitation surfaces from these
sites since all the attribute information is accessible independent
of GRASS (I envision using PostgreSQL in this case) you can write you
application in whatever environment you like and access the database
outside of GRASS and add and edit new time data as needed. Then when it
is time to create your new surface you fire up GRASS do your
multi-table query without any call to v.db.connect because it is no
longer needed and get the result. Done.

I don't really understand this argument. Why can't you do exactly this
with GRASS today ? First of all why do you need a separate objectid and
stationid if each station is represented by one object (let's say a point)
? You could just use the cat value of each object. You would then have a
table in PostgreSQL in which you have these cat values (possibly in a
colum you could
call stationid) and all other attributes you would like in this same
table. If you get new data for the stations you can add it to the table
without having to go through GRASS. Then when you enter grass, this new
information is available as long as your map remains linked to that table.

The only thing you cannot do currently (if I'm not mistaken) is use
aggregate queries on that table if you have more than one row for each
station. But I don't think that this is due to the general data model of
GRASS, but rather to the fact that it is not implemented.

[...]

Again, except for the key fields confusingly labeled as "layers" and

one

other legacy feature from GRASS 5, all attribute management does stay

in the

database.

Unless you use it in the way I suggested in an earlier mail, i.e. cat 1
= coniferous, cat 2 = broadleaved, cat 10 = pine, etc.

The way it 'should' be used to stick with Trevor's suggestions is

cat 1 = tree number 1
cat 2 = tree number 2

etc.

And then have a table with columns

treenumber, species, etc,

with possibly another table with

species, type

where type= conferous or broadleaved

And then, if you need a map of coniferous and broadleaved trees, you
create a view:

CREATE VIEW v1 AS SELECT treenumber, type FROM trees, types WHERE
trees.species=types.species

Why bother with v.db.connect at all? Just allow a query to be used to
select the vector object keys (cats) and let the module in question
work with that list.

I think this is potentially possible with the current model, just not
implemented. The database drivers allow any kind of query you want, and it
should not be too complicated to rewrite modules in a way to allow more
arbitrary queries then just with the current 'where' option.

Any query which returns cat values allows you to then work with these cat
values (I am currently reworking d.vect.chart to do just that) and
it should, therefore, not be too difficult to imagine modules which allow
you to define an arbitrary query and to the fulfill their task on the
basis of this query.

According to the use you make of it you obviously can have a problem if
you have more than one object with the same cat value (I have that problem
in d.vect.cat, for example), but there are ways to work around this.

I realize that many people not familiar with SQL
will find this difficult, but surely we could consider as part of
upgrading the GUI front end with a simple query builder.

I should also be possible to offer both solutions.

A view would be convenient for ongoing use, but shouldn't be necessary
for single time uses.

I agree totally.

[...]

Well changing the terminology would certainly help, but the fundamental
problem was clearly defined by Moritz when he suggested that the
problem is mixing of database concepts with GIS concepts. Thus my
suggestion to keep database functions in the database.

Well GIS as such makes no sense if it is not understood as the link
between geometries and data, so you always have to mix the two in one way
or another. The question is more on how to do this in a way which is most
efficiently _and_ offers the most functionality.

v.buffer is a very special case, and I don't know how you would solve
the question in your system: the attribute information is lost since
v.buffer fusions overlapping buffers into one single buffer. As
mentioned on the man page, there is no automatic way to know which cat
(or keyvalue) to give to this single fusioned buffer.

My solution would work in the sense that new areas created would be
given a new objectid whereas areas (technically centroids associated
with areas) up to the point of overlap would retain their original
objectid and thus would have direct access to any associated attribute
information through a simple query.

Well, it should be no problem to reprogram v.buffer to do just that. Its
current implementation works with the assumption that as you could
potentially have overlaps, you treat all buffers as if they were overlaps,
but you could obviously include some test in the code which treats buffers
differentially. Again, I don't see how this is a problem of the model
rather than of the implementation of a particular module.

It is important to note that my objectid terminology only makes sense
if this value is singular and immutable.

This might actually be the fundamental point in the argument. Currently
GRASS doesn't enforce this as a rule (well actually, IIUC, each object has
a its line number as a unique identifier, this is just not visible to the
user). The question is whether it should enforce something like this, or
whether the current model doesn't allow more flexibility by allowing to
limit yourself to unique id's for each object, but also allowing the use
of non-unique id's, or multiple id's.

Moritz

[Trevor_Wiens2]

On Tue, 26 Sep 2006 20:27:11 +0200 (CEST)
Moritz Lennert wrote:

On Tue, September 26, 2006 15:37, Trevor Wiens wrote:
> On Tue, 26 Sep 2006 11:32:38 +0200
> Moritz Lennert wrote:
>
>> Michael has already said most of what I wanted to say, but some small
>> additions.
>>
>> Michael Barton wrote:
>> >> What seems much more natural to me is
>> >> leaving the attribute management to the database where more
>> >> elegant tools exist. Thus grass modules instead having a
>> >> layer option need a input key and possibly an output key
>> >> option depending on the module. If no key field is specified
>> >> (which would be an attribute in the table linked to the
>> >> vector file), then all objects in the vector file are
>> >> processed. However if a key is used to query the vector file
>> >> for a list of objects for processing. In the case where the
>> >> same vector object has two cats, the vector attribute tables
>> >> will have to have a one to many relationship from the vector
>> >> file to the attribute table. Now modules could also allow a
>> >> query specification to allow for complex querying across
>> >> multiple keys and attributes, but output would probably have
>> >> to be limited to a series of key fields (most likely only
>> >> integers)
>> >
>> > Really, this is exactly what "layers" are now. AFAICT, the biggest
>> problem
>> > is in the terminology. Each "layer" is an integer key field in
>> database
>> > terminology. Multiple layers simply means multiple key fields, each of
>> which
>> > can be linked with an attribute table using v.db.connect.
>>
>
> No, not really. What I describe is functionality identical to current
> layers, but the critical distinction is that all the attribute
> information can be managed in the database independent of GRASS or
> without GRASS even running. Right now the cat values for a vector
> object can only be accessed through GRASS. If GRASS built a simple
> table for each vector object with a cat (or perhaps more clearly
> named an objectid) and a user defined key as well as allowing users to
> add other keys to that table, then there would be no need to run GRASS
> to update attribute information for those objects. For example, lets say
> you have a series of weather sites which would have a incremental
> objectid and a user defined key such as a stationid. If you want to
> be able to occasionally interpolate precipitation surfaces from these
> sites since all the attribute information is accessible independent
> of GRASS (I envision using PostgreSQL in this case) you can write you
> application in whatever environment you like and access the database
> outside of GRASS and add and edit new time data as needed. Then when it
> is time to create your new surface you fire up GRASS do your
> multi-table query without any call to v.db.connect because it is no
> longer needed and get the result. Done.

I don't really understand this argument. Why can't you do exactly this
with GRASS today ?

You can and if arbitrary queries were permitted, then layers wouldn't
be necessary. I'm simply trying to point out that layers are confusing
and keep attribute management partially hidden within GRASS because
there is no way of knowing outside the system if a vector object has
more than one cat value. If the layers feature were removed and
replaced with immutable singular keys, then all attribute management
would be forced into the realm of attribute tables. I like this idea
because it is cleaner.

First of all why do you need a separate objectid and
stationid if each station is represented by one object (let's say a point)
?

You don't, but users are often confused by integer keys so I added this
as human friendly key in addition to the system key.

---snip---

Well GIS as such makes no sense if it is not understood as the link
between geometries and data, so you always have to mix the two in one way
or another. The question is more on how to do this in a way which is most
efficiently _and_ offers the most functionality.

Yes. Absolutely. IMO, layers are not the most efficient solution. There
has been discussions before, and many people still seem confused. This
seems to indicate that this was not the optimal solution. Now I am
biased, but I assume that most people can readily grasp the concept of
multiple attribute tables linking to the main table to select and
classify vector objects. If that is the case then my proposed method
would be much simpler to understand.

The second part is functionality. Again arbitrary queries would provide
all the same functionality in clear fashion. Now it might be easier to
perform certain actions with layers as they provide a simple short-cut
to different views (not literal SQL sense) of the data, but are more
limiting for one time uses.

Now while writing this, if we were to support arbitrary queries, we
might want to consider also providing view support (in the SQL sense) to
allow users to easily store the classification schemes they wanted and
reference them quickly, just as layers could be referenced now.

>> v.buffer is a very special case, and I don't know how you would solve
>> the question in your system: the attribute information is lost since
>> v.buffer fusions overlapping buffers into one single buffer. As
>> mentioned on the man page, there is no automatic way to know which cat
>> (or keyvalue) to give to this single fusioned buffer.
>
> My solution would work in the sense that new areas created would be
> given a new objectid whereas areas (technically centroids associated
> with areas) up to the point of overlap would retain their original
> objectid and thus would have direct access to any associated attribute
> information through a simple query.

Well, it should be no problem to reprogram v.buffer to do just that. Its
current implementation works with the assumption that as you could
potentially have overlaps, you treat all buffers as if they were overlaps,
but you could obviously include some test in the code which treats buffers
differentially. Again, I don't see how this is a problem of the model
rather than of the implementation of a particular module.

I used this as an example because it was one of my frustrations when I
first started using vectors in GRASS was keeping attributes attached.
In the end, I abandoned GRASS for PostGIS for a large part of my vector
work because attribute management is simple and obvious. I still only
use GRASS vectors when I need functionality that isn't available or is
still flaky in PostGIS because all my data is already in PostgreSQL and
I'm comfortable with SQL.

> It is important to note that my objectid terminology only makes sense
> if this value is singular and immutable.

This might actually be the fundamental point in the argument. Currently
GRASS doesn't enforce this as a rule (well actually, IIUC, each object has
a its line number as a unique identifier, this is just not visible to the
user). The question is whether it should enforce something like this, or
whether the current model doesn't allow more flexibility by allowing to
limit yourself to unique id's for each object, but also allowing the use
of non-unique id's, or multiple id's.

To reiterate, arbitrary queries provide the same functionality without
obscure naming conventions and partially obscured attribute management.

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)

[cmbarton]

Trevor,

I won't belabor this, because I think you and Moritz both have important
points. But want mention a couple things.

Doing what you suggest *is* 'cleaner' in a pure database sense. However, you
can do that now by simply using GRASS tools to assign unique cat values to
layer 1, and forgetting about the other layers.

Layers *are* shortcuts, that are especially handy for one-to-many and
many-to-one relationships between vector objects and attribute records. They
make intermediary tables unnecessary and can help save space for vector
files with large numbers redundant objects linked to an attribute table with
few records (many-to-one join). They also save a link, sort of like a view
(see below), between vector objects and attribute table records so that you
can query with specifying one of the join clauses in a where statement. The
'where [vector key]=[table key]...' is implied once you've run v.db.connect.
But I suppose that this is where the cleaner joins that you mention come in.

It would be nice to be able to do multi-table joins. But I'm not sure you
cannot do that already if you're working with a DBMS that supports true SQL
queries, like PostgreSQL or SQLite. I think that GRASS will simply pass on
an SQL query to the DBMS. If so, then multi-table joins might be doable. Has
anybody tried this?

There seems to be some confusion in your statement about not liking GRASS as
a database and so switching to PostgreSQL. Perhaps what you really mean is
that you find dbf limiting for attribute management and prefer PostgreSQL. A
dbf format table structure and database driver is included with the standard
GRASS build. However, the dbf tables link to vectors exactly like PostgreSQL
tables--via the key we call a cat value in a layer. They are
interchangeable, structurally, with PostgreSQL, MySQL, SQLite, etc. For each
of the supported DBMS's there needs to be a GRASS driver. The dbf driver is
fairly limited in terms of SQL, but the drivers for other systems are much
richer. But in any case, you can link different PostgreSQL tables to each
GRASS key field that you create as a layer (You probably already know that,
but others might want to have this clarified). We are seriously considering
switching to SQLite as the database driver and table structure that comes
with the default build. This would offer a much richer set of SQL, although
tables still have to link up with vector objects somehow.

It would indeed be nice to be able to save views, although this has nothing
to do with keys. By semi-permanently linking multiple tables with the
objects of a vector file, layers can sort of serve as views, but they don't
have the richness or flexibility of real views.

It would also be nice to be able to select vector objects and their linked
attribute records interactively from a map. This is one nice feature of
ArcGIS and MapInfo that GRASS lacks.

What I think Moritz is getting at is that you can simply ignore layers 2
through whatever and do exactly what you are proposing. Or you can use
layers as a short cut to joining multiple tables to vectors.

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

[Cannata_Massimiliano]

Sorry to jump into the discussion, but I agree too.
Two different type vector time series exist:
1 - the geometry is changing in time, and this can be handled with layers
2 - the attribute change in time but the geometry is constant (e.g.: rain gauges station)

For the second type, it is harder to manage in GRASS (or at least i cannot see any one) and I usually manage it in an external database by importing the selected tuples (the ones at a given time), and then deleting the vector when is no more needed.
Of course it is time consuming and a better solution would be nice
It would be nice to be able to create a connection with a selection from a table and not just with the table itself.... but I know this was not considered in developing phase and it will be a really hard work now.

I also want to highlight that in the GRASS wiki we open an article for time series managment in GRASS (http://grass.gdf-hannover.de/wiki/Time_series_in_GRASS), till now it was focused on rater time series but vector time series should also be considered
I think this a key factor in environmental modelling into GRASS because a well defined data format for time series will allow the development of related tool for time series analysis, visualization and managment.

Massimiliano

--

Dr. Eng. Massimiliano Cannata
Responsabile Area Geomatica (w3.ist.supsi.ch:8001/geomatica/)
Istituto Scienze della Terra
Scuola Universitaria Professionale della Svizzera Italiana
Via Trevano, c.p. 72
CH-6952 Canobbio-Lugano
Tel: +41 (0)58 666 62 14
Fax +41 (0)58 666 62 09

Michael Barton wrote:

I agree.

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, 26 Sep 2006 20:27:11 +0200 (CEST)
To: Trevor Wiens <twiens@interbaun.com>
Cc: Michael Barton <michael.barton@asu.edu>, "''grassuser@grass.itc.it' '"
<grassuser@grass.itc.it>, GRASS-DEV <grass-dev@grass.itc.it>
Subject: Re: [GRASS-dev] Re: [GRASS-user] RE: Problem querying layers other
than '1' in gi s.m

On Tue, September 26, 2006 15:37, Trevor Wiens wrote:
    

On Tue, 26 Sep 2006 11:32:38 +0200
Moritz Lennert wrote:

Michael has already said most of what I wanted to say, but some small
additions.

Michael Barton wrote:
        

What seems much more natural to me is
leaving the attribute management to the database where more
elegant tools exist. Thus grass modules instead having a
layer option need a input key and possibly an output key
option depending on the module. If no key field is specified
(which would be an attribute in the table linked to the
vector file), then all objects in the vector file are
processed. However if a key is used to query the vector file
for a list of objects for processing. In the case where the
same vector object has two cats, the vector attribute tables
will have to have a one to many relationship from the vector
file to the attribute table. Now modules could also allow a
query specification to allow for complex querying across
multiple keys and attributes, but output would probably have
to be limited to a series of key fields (most likely only
integers)
            

Really, this is exactly what "layers" are now. AFAICT, the biggest
          

problem
        

is in the terminology. Each "layer" is an integer key field in
          

database
        

terminology. Multiple layers simply means multiple key fields, each of
          

which
        

can be linked with an attribute table using v.db.connect.
          

No, not really. What I describe is functionality identical to current
layers, but the critical distinction is that all the attribute
information can be managed in the database independent of GRASS or
without GRASS even running. Right now the cat values for a vector
object can only be accessed through GRASS. If GRASS built a simple
table for each vector object with a cat (or perhaps more clearly
named an objectid) and a user defined key as well as allowing users to
add other keys to that table, then there would be no need to run GRASS
to update attribute information for those objects. For example, lets say
you have a series of weather sites which would have a incremental
objectid and a user defined key such as a stationid. If you want to
be able to occasionally interpolate precipitation surfaces from these
sites since all the attribute information is accessible independent
of GRASS (I envision using PostgreSQL in this case) you can write you
application in whatever environment you like and access the database
outside of GRASS and add and edit new time data as needed. Then when it
is time to create your new surface you fire up GRASS do your
multi-table query without any call to v.db.connect because it is no
longer needed and get the result. Done.
      

I don't really understand this argument. Why can't you do exactly this
with GRASS today ? First of all why do you need a separate objectid and
stationid if each station is represented by one object (let's say a point)
? You could just use the cat value of each object. You would then have a
table in PostgreSQL in which you have these cat values (possibly in a
colum you could
call stationid) and all other attributes you would like in this same
table. If you get new data for the stations you can add it to the table
without having to go through GRASS. Then when you enter grass, this new
information is available as long as your map remains linked to that table.

The only thing you cannot do currently (if I'm not mistaken) is use
aggregate queries on that table if you have more than one row for each
station. But I don't think that this is due to the general data model of
GRASS, but rather to the fact that it is not implemented.

[...]

Again, except for the key fields confusingly labeled as "layers" and
          

one
        

other legacy feature from GRASS 5, all attribute management does stay
          

in the
        

database.
          

Unless you use it in the way I suggested in an earlier mail, i.e. cat 1
= coniferous, cat 2 = broadleaved, cat 10 = pine, etc.

The way it 'should' be used to stick with Trevor's suggestions is

cat 1 = tree number 1
cat 2 = tree number 2

etc.

And then have a table with columns

treenumber, species, etc,

with possibly another table with

species, type

where type= conferous or broadleaved

And then, if you need a map of coniferous and broadleaved trees, you
create a view:

CREATE VIEW v1 AS SELECT treenumber, type FROM trees, types WHERE
trees.species=types.species

Why bother with v.db.connect at all? Just allow a query to be used to
select the vector object keys (cats) and let the module in question
work with that list.
      

I think this is potentially possible with the current model, just not
implemented. The database drivers allow any kind of query you want, and it
should not be too complicated to rewrite modules in a way to allow more
arbitrary queries then just with the current 'where' option.

Any query which returns cat values allows you to then work with these cat
values (I am currently reworking d.vect.chart to do just that) and
it should, therefore, not be too difficult to imagine modules which allow
you to define an arbitrary query and to the fulfill their task on the
basis of this query.

According to the use you make of it you obviously can have a problem if
you have more than one object with the same cat value (I have that problem
in d.vect.cat, for example), but there are ways to work around this.

I realize that many people not familiar with SQL
will find this difficult, but surely we could consider as part of
upgrading the GUI front end with a simple query builder.
      

I should also be possible to offer both solutions.

A view would be convenient for ongoing use, but shouldn't be necessary
for single time uses.
      

I agree totally.

[...]

Well changing the terminology would certainly help, but the fundamental
problem was clearly defined by Moritz when he suggested that the
problem is mixing of database concepts with GIS concepts. Thus my
suggestion to keep database functions in the database.
      

Well GIS as such makes no sense if it is not understood as the link
between geometries and data, so you always have to mix the two in one way
or another. The question is more on how to do this in a way which is most
efficiently _and_ offers the most functionality.

v.buffer is a very special case, and I don't know how you would solve
the question in your system: the attribute information is lost since
v.buffer fusions overlapping buffers into one single buffer. As
mentioned on the man page, there is no automatic way to know which cat
(or keyvalue) to give to this single fusioned buffer.
        

My solution would work in the sense that new areas created would be
given a new objectid whereas areas (technically centroids associated
with areas) up to the point of overlap would retain their original
objectid and thus would have direct access to any associated attribute
information through a simple query.
      

Well, it should be no problem to reprogram v.buffer to do just that. Its
current implementation works with the assumption that as you could
potentially have overlaps, you treat all buffers as if they were overlaps,
but you could obviously include some test in the code which treats buffers
differentially. Again, I don't see how this is a problem of the model
rather than of the implementation of a particular module.

It is important to note that my objectid terminology only makes sense
if this value is singular and immutable.
      

This might actually be the fundamental point in the argument. Currently
GRASS doesn't enforce this as a rule (well actually, IIUC, each object has
a its line number as a unique identifier, this is just not visible to the
user). The question is whether it should enforce something like this, or
whether the current model doesn't allow more flexibility by allowing to
limit yourself to unique id's for each object, but also allowing the use
of non-unique id's, or multiple id's.

Moritz

_______________________________________________
grassuser mailing list
grassuser@grass.itc.it
http://grass.itc.it/mailman/listinfo/grassuser

[Radim_Blazek3]

On 9/27/06, Michael Barton <michael.barton@asu.edu> wrote:

Trevor,

I won't belabor this, because I think you and Moritz both have important
points. But want mention a couple things.

Doing what you suggest *is* 'cleaner' in a pure database sense. However, you
can do that now by simply using GRASS tools to assign unique cat values to
layer 1, and forgetting about the other layers.

Yes. It was forseen and considered that multilayer concept can
be difficult for some users and all modules are using default layer 1.
If you don't like layers you can completely forget about them
and do whatever you want with tables attached in database
and unique cat assigned to each geometry.

In general, I only ask you not remove some functionality just because
it seems to be difficult/useless/not used until you have a better replacement.
For me it is completely OK if you implement the same functionality on
DB side and show us that it has better performance and it is simpler code.

My only wish is that existing functionality (in core libs) is not removed
without replacement just for "I dont need that" reasons.

I know about problems with current vectors, but this is not one
of them. It would be better to solve real problems.

OK, that is all from me on this issue.

Radim

Layers *are* shortcuts, that are especially handy for one-to-many and
many-to-one relationships between vector objects and attribute records. They
make intermediary tables unnecessary and can help save space for vector
files with large numbers redundant objects linked to an attribute table with
few records (many-to-one join). They also save a link, sort of like a view
(see below), between vector objects and attribute table records so that you
can query with specifying one of the join clauses in a where statement. The
'where [vector key]=[table key]...' is implied once you've run v.db.connect.
But I suppose that this is where the cleaner joins that you mention come in.

It would be nice to be able to do multi-table joins. But I'm not sure you
cannot do that already if you're working with a DBMS that supports true SQL
queries, like PostgreSQL or SQLite. I think that GRASS will simply pass on
an SQL query to the DBMS. If so, then multi-table joins might be doable. Has
anybody tried this?

There seems to be some confusion in your statement about not liking GRASS as
a database and so switching to PostgreSQL. Perhaps what you really mean is
that you find dbf limiting for attribute management and prefer PostgreSQL. A
dbf format table structure and database driver is included with the standard
GRASS build. However, the dbf tables link to vectors exactly like PostgreSQL
tables--via the key we call a cat value in a layer. They are
interchangeable, structurally, with PostgreSQL, MySQL, SQLite, etc. For each
of the supported DBMS's there needs to be a GRASS driver. The dbf driver is
fairly limited in terms of SQL, but the drivers for other systems are much
richer. But in any case, you can link different PostgreSQL tables to each
GRASS key field that you create as a layer (You probably already know that,
but others might want to have this clarified). We are seriously considering
switching to SQLite as the database driver and table structure that comes
with the default build. This would offer a much richer set of SQL, although
tables still have to link up with vector objects somehow.

It would indeed be nice to be able to save views, although this has nothing
to do with keys. By semi-permanently linking multiple tables with the
objects of a vector file, layers can sort of serve as views, but they don't
have the richness or flexibility of real views.

It would also be nice to be able to select vector objects and their linked
attribute records interactively from a map. This is one nice feature of
ArcGIS and MapInfo that GRASS lacks.

What I think Moritz is getting at is that you can simply ignore layers 2
through whatever and do exactly what you are proposing. Or you can use
layers as a short cut to joining multiple tables to vectors.

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

_______________________________________________
grass-dev mailing list
grass-dev@grass.itc.it
http://grass.itc.it/mailman/listinfo/grass-dev

[Trevor_Wiens2]

On Tue, 26 Sep 2006 23:35:25 -0700
Michael Barton wrote:

-snip-

There seems to be some confusion in your statement about not liking GRASS as
a database and so switching to PostgreSQL. Perhaps what you really mean is
that you find dbf limiting for attribute management and prefer PostgreSQL.

That is not what I said. What I said was that because I find attribute
management awkward in GRASS I use PostGIS (the PostgreSQL equivalent
to Oracle Spatial) for most vector work unless I need features in
GRASS not found in PostGIS. In comparisons for operations such as
overlays or point in polygon searches, GRASS is slightly faster than
PostGIS, but in most cases the performance hit hasn't been significant
and in the end, it is much faster to use PostGIS instead of GRASS
because I don't have to import and export and reconnect attribute data.
I get the results I want in a single query. I would like to have that
same kind of control within GRASS.

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)

[cmbarton]

Sorry. I misunderstood.

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: Trevor Wiens <twiens@interbaun.com>
Date: Wed, 27 Sep 2006 09:36:44 -0600
To: Michael Barton <michael.barton@asu.edu>
Cc: Moritz Lennert <mlennert@club.worldonline.be>, "''grassuser@grass.itc.it'
'" <grassuser@grass.itc.it>, GRASS-DEV <grass-dev@grass.itc.it>
Subject: Re: [GRASS-dev] Re: [GRASS-user] RE: Problem querying layers other
than '1' in gi s.m

On Tue, 26 Sep 2006 23:35:25 -0700
Michael Barton wrote:

-snip-

There seems to be some confusion in your statement about not liking GRASS as
a database and so switching to PostgreSQL. Perhaps what you really mean is
that you find dbf limiting for attribute management and prefer PostgreSQL.

That is not what I said. What I said was that because I find attribute
management awkward in GRASS I use PostGIS (the PostgreSQL equivalent
to Oracle Spatial) for most vector work unless I need features in
GRASS not found in PostGIS. In comparisons for operations such as
overlays or point in polygon searches, GRASS is slightly faster than
PostGIS, but in most cases the performance hit hasn't been significant
and in the end, it is much faster to use PostGIS instead of GRASS
because I don't have to import and export and reconnect attribute data.
I get the results I want in a single query. I would like to have that
same kind of control within GRASS.

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)

[Trevor_Wiens2]

On Wed, 27 Sep 2006 09:00:53 -0700
Michael Barton wrote:

Sorry. I misunderstood.

Michael

No problem.

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)

[cmbarton]

I realize that Moritz has also answered, but will add a couple thoughts here
because I'm very interested in temporal GIS at the moment. See below.

Michale
__________________________________________
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: Massimiliano Cannata <massimiliano.cannata@supsi.ch>
Date: Wed, 27 Sep 2006 10:28:49 +0200
To: Michael Barton <michael.barton@asu.edu>
Cc: Moritz Lennert <mlennert@club.worldonline.be>, Trevor Wiens
<twiens@interbaun.com>, "''grassuser@grass.itc.it' '"
<grassuser@grass.itc.it>, GRASS-DEV <grass-dev@grass.itc.it>
Subject: Re: [GRASS-dev] Re: [GRASS-user] RE: Problem querying layers other
than '1' in gi s.m

Sorry to jump into the discussion, but I agree too.
Two different type vector time series exist:
1 - the geometry is changing in time, and this can be handled with layers
2 - the attribute change in time but the geometry is constant (e.g.:
rain gauges station)

For the second type, it is harder to manage in GRASS (or at least i
cannot see any one) and I usually manage it in an external database by
importing the selected tuples (the ones at a given time), and then
deleting the vector when is no more needed.
Of course it is time consuming and a better solution would be nice
It would be nice to be able to create a connection with a selection from
a table and not just with the table itself.... but I know this was not
considered in developing phase and it will be a really hard work now.

If I understand you, I think it would work better the other way around.

Case 2. Each vector "layer" (i.e., key field) can be assigned to a different
attribute table that represents the value for a particular set of vector
objects at a given time. Each "layer" links to a table that records the
state of the objects at a different time. That is, layers allow a single
vector file to be simultaneously linked to multiple attribute tables.

Case 1. For changing geometry, however, you need to have different vector
objects. In this case, you need to link different vector files (representing
objects with changing geometry) to a single attribute table. As far as I
know, you can link any number of different vector files to a single table.
For this, you would only use a single vector "layer" (i.e., key field) to
link each vector file to the table.

Here is an ugly schematic.

Case 1 (assumes number of objects stays the same, but their geometry
changes).

vector with geometry 1 (layer 1 key) ---\
vector with geometry 2 (layer 1 key) ------ (matching key) attribute table
vector with geometry 3 (layer 1 key) ---/

Case 2 (assumes unchanging vector geometry but changing attributes over
time).

vector (layer 1 key) --- (matching key) attribute table time 1
         (layer 2 key) --- (matching key) attribute table time 2
         (layer 3 key) --- (matching key) attribute table time 3

I also want to highlight that in the GRASS wiki we open an article for
time series managment in GRASS
(http://grass.gdf-hannover.de/wiki/Time_series_in_GRASS), till now it
was focused on rater time series but vector time series should also be
considered
I think this a key factor in environmental modelling into GRASS because
a well defined data format for time series will allow the development of
related tool for time series analysis, visualization and managment.

Massimiliano

--

Dr. Eng. Massimiliano Cannata
Responsabile Area Geomatica (w3.ist.supsi.ch:8001/geomatica/)
Istituto Scienze della Terra
Scuola Universitaria Professionale della Svizzera Italiana
Via Trevano, c.p. 72
CH-6952 Canobbio-Lugano
Tel: +41 (0)58 666 62 14
Fax +41 (0)58 666 62 09

Michael Barton wrote:

I agree.

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, 26 Sep 2006 20:27:11 +0200 (CEST)
To: Trevor Wiens <twiens@interbaun.com>
Cc: Michael Barton <michael.barton@asu.edu>, "''grassuser@grass.itc.it' '"
<grassuser@grass.itc.it>, GRASS-DEV <grass-dev@grass.itc.it>
Subject: Re: [GRASS-dev] Re: [GRASS-user] RE: Problem querying layers other
than '1' in gi s.m

On Tue, September 26, 2006 15:37, Trevor Wiens wrote:
    

On Tue, 26 Sep 2006 11:32:38 +0200
Moritz Lennert wrote:

Michael has already said most of what I wanted to say, but some small
additions.

Michael Barton wrote:
        

What seems much more natural to me is
leaving the attribute management to the database where more
elegant tools exist. Thus grass modules instead having a
layer option need a input key and possibly an output key
option depending on the module. If no key field is specified
(which would be an attribute in the table linked to the
vector file), then all objects in the vector file are
processed. However if a key is used to query the vector file
for a list of objects for processing. In the case where the
same vector object has two cats, the vector attribute tables
will have to have a one to many relationship from the vector
file to the attribute table. Now modules could also allow a
query specification to allow for complex querying across
multiple keys and attributes, but output would probably have
to be limited to a series of key fields (most likely only
integers)
           

Really, this is exactly what "layers" are now. AFAICT, the biggest
          

problem
        

is in the terminology. Each "layer" is an integer key field in
          

database
        

terminology. Multiple layers simply means multiple key fields, each of
          

which
        

can be linked with an attribute table using v.db.connect.
          

No, not really. What I describe is functionality identical to current
layers, but the critical distinction is that all the attribute
information can be managed in the database independent of GRASS or
without GRASS even running. Right now the cat values for a vector
object can only be accessed through GRASS. If GRASS built a simple
table for each vector object with a cat (or perhaps more clearly
named an objectid) and a user defined key as well as allowing users to
add other keys to that table, then there would be no need to run GRASS
to update attribute information for those objects. For example, lets say
you have a series of weather sites which would have a incremental
objectid and a user defined key such as a stationid. If you want to
be able to occasionally interpolate precipitation surfaces from these
sites since all the attribute information is accessible independent
of GRASS (I envision using PostgreSQL in this case) you can write you
application in whatever environment you like and access the database
outside of GRASS and add and edit new time data as needed. Then when it
is time to create your new surface you fire up GRASS do your
multi-table query without any call to v.db.connect because it is no
longer needed and get the result. Done.
      

I don't really understand this argument. Why can't you do exactly this
with GRASS today ? First of all why do you need a separate objectid and
stationid if each station is represented by one object (let's say a point)
? You could just use the cat value of each object. You would then have a
table in PostgreSQL in which you have these cat values (possibly in a
colum you could
call stationid) and all other attributes you would like in this same
table. If you get new data for the stations you can add it to the table
without having to go through GRASS. Then when you enter grass, this new
information is available as long as your map remains linked to that table.

The only thing you cannot do currently (if I'm not mistaken) is use
aggregate queries on that table if you have more than one row for each
station. But I don't think that this is due to the general data model of
GRASS, but rather to the fact that it is not implemented.

[...]

Again, except for the key fields confusingly labeled as "layers" and
          

one
        

other legacy feature from GRASS 5, all attribute management does stay
          

in the
        

database.
          

Unless you use it in the way I suggested in an earlier mail, i.e. cat 1
= coniferous, cat 2 = broadleaved, cat 10 = pine, etc.

The way it 'should' be used to stick with Trevor's suggestions is

cat 1 = tree number 1
cat 2 = tree number 2

etc.

And then have a table with columns

treenumber, species, etc,

with possibly another table with

species, type

where type= conferous or broadleaved

And then, if you need a map of coniferous and broadleaved trees, you
create a view:

CREATE VIEW v1 AS SELECT treenumber, type FROM trees, types WHERE
trees.species=types.species

Why bother with v.db.connect at all? Just allow a query to be used to
select the vector object keys (cats) and let the module in question
work with that list.
      

I think this is potentially possible with the current model, just not
implemented. The database drivers allow any kind of query you want, and it
should not be too complicated to rewrite modules in a way to allow more
arbitrary queries then just with the current 'where' option.

Any query which returns cat values allows you to then work with these cat
values (I am currently reworking d.vect.chart to do just that) and
it should, therefore, not be too difficult to imagine modules which allow
you to define an arbitrary query and to the fulfill their task on the
basis of this query.

According to the use you make of it you obviously can have a problem if
you have more than one object with the same cat value (I have that problem
in d.vect.cat, for example), but there are ways to work around this.

I realize that many people not familiar with SQL
will find this difficult, but surely we could consider as part of
upgrading the GUI front end with a simple query builder.
      

I should also be possible to offer both solutions.

A view would be convenient for ongoing use, but shouldn't be necessary
for single time uses.
      

I agree totally.

[...]

Well changing the terminology would certainly help, but the fundamental
problem was clearly defined by Moritz when he suggested that the
problem is mixing of database concepts with GIS concepts. Thus my
suggestion to keep database functions in the database.
      

Well GIS as such makes no sense if it is not understood as the link
between geometries and data, so you always have to mix the two in one way
or another. The question is more on how to do this in a way which is most
efficiently _and_ offers the most functionality.

v.buffer is a very special case, and I don't know how you would solve
the question in your system: the attribute information is lost since
v.buffer fusions overlapping buffers into one single buffer. As
mentioned on the man page, there is no automatic way to know which cat
(or keyvalue) to give to this single fusioned buffer.
        

My solution would work in the sense that new areas created would be
given a new objectid whereas areas (technically centroids associated
with areas) up to the point of overlap would retain their original
objectid and thus would have direct access to any associated attribute
information through a simple query.
      

Well, it should be no problem to reprogram v.buffer to do just that. Its
current implementation works with the assumption that as you could
potentially have overlaps, you treat all buffers as if they were overlaps,
but you could obviously include some test in the code which treats buffers
differentially. Again, I don't see how this is a problem of the model
rather than of the implementation of a particular module.

It is important to note that my objectid terminology only makes sense
if this value is singular and immutable.
      

This might actually be the fundamental point in the argument. Currently
GRASS doesn't enforce this as a rule (well actually, IIUC, each object has
a its line number as a unique identifier, this is just not visible to the
user). The question is whether it should enforce something like this, or
whether the current model doesn't allow more flexibility by allowing to
limit yourself to unique id's for each object, but also allowing the use
of non-unique id's, or multiple id's.

Moritz

_______________________________________________
grassuser mailing list
grassuser@grass.itc.it
http://grass.itc.it/mailman/listinfo/grassuser

[mlennert]

Trevor Wiens wrote:

On Tue, 26 Sep 2006 23:35:25 -0700
Michael Barton wrote:

-snip-

There seems to be some confusion in your statement about not liking GRASS as
a database and so switching to PostgreSQL. Perhaps what you really mean is
that you find dbf limiting for attribute management and prefer PostgreSQL.

That is not what I said. What I said was that because I find attribute
management awkward in GRASS I use PostGIS (the PostgreSQL equivalent
to Oracle Spatial) for most vector work unless I need features in
GRASS not found in PostGIS. In comparisons for operations such as
overlays or point in polygon searches, GRASS is slightly faster than
PostGIS, but in most cases the performance hit hasn't been significant
and in the end, it is much faster to use PostGIS instead of GRASS
because I don't have to import and export and reconnect attribute data.
I get the results I want in a single query. I would like to have that
same kind of control within GRASS.

Trying to take this a bit further, I have implemented a version of the just posted d.vect.chart2 (http://grass.itc.it/pipermail/grass5/2006-October/026503.html) in a way that it allows an arbitrary SQL query as source of the displayed data (attached). This module (called d.vect.chart.sql for the purpose of this proof of concept) contains an sql option which allows the user to use any arbitrary sql query to define the data to be charted. This query has to return the data in a certain order. A -s flag indicates that the query also returns a sizecol and the user has to tell the module how many data columns there are (this could probably be handled using the SQL parser, but I didn't think it important at this stage).

So, you can run it as such

d.vect.chart.sql -s map=communes ncols=1 scale=0.0001 sql="select t1.pop_2001, t2.pop_2001, t1.comcod from bel_espon143 as t1, commcen as t2 where t1.comcod=t2.comcod order by t1.pop_2001 desc "

which shows that you can combine any table you want as long as the query results correspond to the required format.

This module is only proof of concept and certainly needs improvements and checks, but it works for me in its current state.

Trevor is this more in line with what you are looking for ? Maybe we should think about reworking more modules to allow such an arbitrary sql query at least as an option ?

Moritz

**************************
> d.vect.chart.sql -h

Description:
  Displays charts of GRASS vector data in the active frame on the graphics monitor based on an arbitrary sql query

Keywords:
  display

Usage:
  d.vect.chart.sql [-csr] map=name [type=string[,string,...]]
    [layer=value] sql=string ncols=value [ctype=string] [size=value]
    [scale=value] [ocolor=string] [colors=string[,string,...]]
    [max_ref=value[,value,...]]

Flags:
   -c Center the bar chart around a data point
   -s SQL query contains size column
   -r use square root of sizecol (to make area of pie, not diameter, proportional to sizecol)

Parameters:
       map Name of input vector map
      type Type
             options: point,line,boundary,centroid,area
             default: point,line,boundary,centroid
     layer Layer number
             default: 1
       sql SQL statement retrieving the data in the following order: data columns, [size column], key column
     ncols Number of data columns (without size column)
     ctype Chart type
             options: pie,bar
             default: pie
      size Size of chart (diameter for pie, total width for bar)
             default: 40
     scale Scale for size (to get size in pixels)
             default: 1
    ocolor Outline color
             default: black
    colors Colors used to fill charts
   max_ref Maximum value used for bar plot reference

(attachments)

d.vect.chart.sql.tgz (6.34 KB)

[Trevor_Wiens2]

On Tue, 10 Oct 2006 14:45:59 +0200
Moritz Lennert wrote:

Trevor Wiens wrote:
> On Tue, 26 Sep 2006 23:35:25 -0700
> Michael Barton wrote:
>
> -snip-
>> There seems to be some confusion in your statement about not liking GRASS as
>> a database and so switching to PostgreSQL. Perhaps what you really mean is
>> that you find dbf limiting for attribute management and prefer PostgreSQL.
>
> That is not what I said. What I said was that because I find attribute
> management awkward in GRASS I use PostGIS (the PostgreSQL equivalent
> to Oracle Spatial) for most vector work unless I need features in
> GRASS not found in PostGIS. In comparisons for operations such as
> overlays or point in polygon searches, GRASS is slightly faster than
> PostGIS, but in most cases the performance hit hasn't been significant
> and in the end, it is much faster to use PostGIS instead of GRASS
> because I don't have to import and export and reconnect attribute data.
> I get the results I want in a single query. I would like to have that
> same kind of control within GRASS.

Trying to take this a bit further, I have implemented a version of the
just posted d.vect.chart2
(http://grass.itc.it/pipermail/grass5/2006-October/026503.html) in a way
that it allows an arbitrary SQL query as source of the displayed data
(attached). This module (called d.vect.chart.sql for the purpose of this
proof of concept) contains an sql option which allows the user to use
any arbitrary sql query to define the data to be charted. This query has
to return the data in a certain order. A -s flag indicates that the
query also returns a sizecol and the user has to tell the module how
many data columns there are (this could probably be handled using the
SQL parser, but I didn't think it important at this stage).

So, you can run it as such

d.vect.chart.sql -s map=communes ncols=1 scale=0.0001 sql="select
t1.pop_2001, t2.pop_2001, t1.comcod from bel_espon143 as t1, commcen as
t2 where t1.comcod=t2.comcod order by t1.pop_2001 desc "

which shows that you can combine any table you want as long as the query
results correspond to the required format.

This module is only proof of concept and certainly needs improvements
and checks, but it works for me in its current state.

Trevor is this more in line with what you are looking for ? Maybe we
should think about reworking more modules to allow such an arbitrary sql
query at least as an option ?

Moritz,

Thanks for doing this. Hopefully I'll have time to download it and
play with tonight. I was really wanting to pickup the gauntlet Radim had
thrown down regarding implementing v.overlay according to my scheme,
but I've got deadlines looming and not had any time to do any hacking
at all.

Yes, this is part of what I envision. I see two functions for
arbitrary queries. First, as a vector object filter system to
replace the 'layers feature' and second, as a means to provide
more control over the creation of attribute tables for functions
creating new vector files such as v.overlay, or v.buffer, etc.

I wonder now how many steps it takes to recreate your arbitrary query
graph with 'layers' and I wonder about performance differences between
the two.

T

Moritz

**************************
> d.vect.chart.sql -h

Description:
  Displays charts of GRASS vector data in the active frame on the
graphics monitor based on an arbitrary sql query

Keywords:
  display

Usage:
  d.vect.chart.sql [-csr] map=name [type=string[,string,...]]
    [layer=value] sql=string ncols=value [ctype=string] [size=value]
    [scale=value] [ocolor=string] [colors=string[,string,...]]
    [max_ref=value[,value,...]]

Flags:
   -c Center the bar chart around a data point
   -s SQL query contains size column
   -r use square root of sizecol (to make area of pie, not diameter,
proportional to sizecol)

Parameters:
       map Name of input vector map
      type Type
             options: point,line,boundary,centroid,area
             default: point,line,boundary,centroid
     layer Layer number
             default: 1
       sql SQL statement retrieving the data in the following order:
data columns, [size column], key column
     ncols Number of data columns (without size column)
     ctype Chart type
             options: pie,bar
             default: pie
      size Size of chart (diameter for pie, total width for bar)
             default: 40
     scale Scale for size (to get size in pixels)
             default: 1
    ocolor Outline color
             default: black
    colors Colors used to fill charts
   max_ref Maximum value used for bar plot reference

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

[mlennert]

Trevor Wiens wrote:

I wonder now how many steps it takes to recreate your arbitrary query
graph with 'layers' and I wonder about performance differences between
the two.

I'm not sure you can handle this via layers. Currently you have to do the following (untested):

echo "create view temp as select t1.pop_2001 as pop1, t2.pop_2001 as pop2, t1.comcod from bel_espon143 as t1, commcen as t2 where t1.comcod=t2.comcod order by t1.pop_2001 desc" | db.execute

v.db.connect -o map=communes table=temp key=comcod

d.vect.chart map=communes scale=0.0001 columns=pop1 sizecol=pop2

v.db.connect -o map=communes table=original_table key=keycolumn

echo "drop view temp" | db.execute

So, in order to get back to the exact previous situation four extra steps of creating the view, linking to the view, linking back to the original data table and erasing the view.

Moritz

[Trevor_Wiens2]

On Tue, 10 Oct 2006 16:53:26 +0200
Moritz Lennert wrote:

Trevor Wiens wrote:

> I wonder now how many steps it takes to recreate your arbitrary query
> graph with 'layers' and I wonder about performance differences between
> the two.

I'm not sure you can handle this via layers. Currently you have to do
the following (untested):

echo "create view temp as select t1.pop_2001 as pop1, t2.pop_2001 as
pop2, t1.comcod from bel_espon143 as t1, commcen as t2 where
t1.comcod=t2.comcod order by t1.pop_2001 desc" | db.execute

v.db.connect -o map=communes table=temp key=comcod

d.vect.chart map=communes scale=0.0001 columns=pop1 sizecol=pop2

v.db.connect -o map=communes table=original_table key=keycolumn

echo "drop view temp" | db.execute

So, in order to get back to the exact previous situation four extra
steps of creating the view, linking to the view, linking back to the
original data table and erasing the view.

Moritz

That is what I thought. Although the concept of layers probably sounded
good at the time, my guess is that once implemented in all modules,
arbitrary queries will prove to be much more flexible and
operationally quicker (but perhaps computationally slower).

I should add however, in defence of layers, that for users without
knowledge of SQL, arbitrary queries might in fact be much more
difficult to use than layers. On the other hand, if one is serious about
GIS at some point one has to get serious about attribute management
which means moving beyond flat files anyway. So... I suppose arbitrary
queries would push people to learning things that are useful later on.
Since layers are counter-intuitive and require learning anyway....

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)

[mlennert]

Trevor Wiens wrote:

On Tue, 10 Oct 2006 16:53:26 +0200
Moritz Lennert wrote:

Trevor Wiens wrote:

I wonder now how many steps it takes to recreate your arbitrary query
graph with 'layers' and I wonder about performance differences between
the two.

I'm not sure you can handle this via layers. Currently you have to do the following (untested):

echo "create view temp as select t1.pop_2001 as pop1, t2.pop_2001 as pop2, t1.comcod from bel_espon143 as t1, commcen as t2 where t1.comcod=t2.comcod order by t1.pop_2001 desc" | db.execute

v.db.connect -o map=communes table=temp key=comcod

d.vect.chart map=communes scale=0.0001 columns=pop1 sizecol=pop2

v.db.connect -o map=communes table=original_table key=keycolumn

echo "drop view temp" | db.execute

So, in order to get back to the exact previous situation four extra steps of creating the view, linking to the view, linking back to the original data table and erasing the view.

Moritz

That is what I thought. Although the concept of layers probably sounded
good at the time, my guess is that once implemented in all modules,
arbitrary queries will prove to be much more flexible and
operationally quicker (but perhaps computationally slower).

I should add however, in defence of layers, that for users without
knowledge of SQL, arbitrary queries might in fact be much more
difficult to use than layers. On the other hand, if one is serious about
GIS at some point one has to get serious about attribute management
which means moving beyond flat files anyway. So... I suppose arbitrary
queries would push people to learning things that are useful later on.
Since layers are counter-intuitive and require learning anyway....

I don't want to break off another debate on layers, here, but I don't think that the issue here really are the layers. It is the use of sql within the module. As was stated several times before, you don't even have to think about layers, if you don't want to in GRASS.
However, some people have found applications of layers which they found very useful, and I doubt that all of the can be solved by arbitrary SQL queries, as some of them concern the underlying geometry, and not only the attributes.

But I'd rather think about the best way to implement arbitrary queries in modules than continue this debate

Moritz

[Trevor_Wiens2]

On Tue, 10 Oct 2006 17:22:29 +0200
Moritz Lennert wrote:

I don't want to break off another debate on layers, here, but I don't
think that the issue here really are the layers. It is the use of sql
within the module. As was stated several times before, you don't even
have to think about layers, if you don't want to in GRASS.
However, some people have found applications of layers which they found
very useful, and I doubt that all of the can be solved by arbitrary SQL
queries, as some of them concern the underlying geometry, and not only
the attributes.

But I'd rather think about the best way to implement arbitrary queries
in modules than continue this debate

Agreed. I was just thinking aloud about the benefits and short-comings
of arbitrary queries. My point being is that arbitrary queries although
very powerful and flexible will be daunting for some users. Based on
that I think we will need to have a few basic examples that can be
included in the help pages for modules where arbitrary queries will be
available as well as a link to an external SQL intro page or a brief
tutorial within GRASS on SQL usage. For the second case, I have a
reasonably human friendly into to SQL which I co-wrote some years
ago for an application which had both a query builder and the ability to
manually edit or create your own queries. I could probably adapt that
(after I find it) for GRASS use once we get that far.

In thinking of checks, probably you'll only need to check that the
query is returning all the fields needed. It would also be a good idea
to check the validity of the query as soon into the function as
possible and trap and report any exceptions so if something is funny it
will fail early and noisily.

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)