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

GRASS GRASS user
1

----- Original Message Follows -----
From: Michael Barton <michael.barton@asu.edu>
To: Moritz Lennert <mlennert@club.worldonline.be>, "Patton,
Eric" <epatton@nrcan.gc.ca>
Cc: "'grassuser@grass.itc.it'" <grassuser@grass.itc.it>
Subject: Re: [GRASS-user] RE: Problem querying layers other
than '1' in gis.m
Date: Wed, 20 Sep 2006 07:48:43 -0700

You CAN link multiple tables to single vector objects.
That is what layers is all about. You need a separate CAT
column for each table you link. Each cat column is a
"layer". It serves as a key to link the object with a
record in a table.

I don't know if v.what (used in gui vector querying) will
query more than layer one. There was some discussion about
this awhile back and I can't remember the outcome. There
have been some other new changes to v.what that will
eventually go into 6.3. If layer support has been added,
this will go into 6.3 also.

v.what does not support layers.

Eric,

Your understanding of what layers are supposed to do is
correct, they are multiple linked tables to a single
topology layer, but there are unique cats for each linked
table.

Michael and Eric,

I had been planning on adding support for multiple linked
tables in v.what at some point, but since I deeply dislike
the terminology and think the general approach to this
problem is wrong in the first place I'm not motivated.
Personally I think that attribute management should be left
to the database backend and this so called feature should be
dropped as the terminology is confusing. But.... there is
deep resistance from a number of core developers who
designed and implemented this multiple table link feature,
so that is not likely to happen. The short and long of it
however, is that there are other aspects of GRASS
development which I'm more interested in and I think are
more useful so that is where I have been and will be putting
my limited time. If someone else wants to add "layers" to
v.what that is fine, but I won't be doing it in the
forseable future.

T
--
Trevor Wiens

--
Trevor Wiens
twiens@interbaun.com

2

On Wednesday 20 September 2006 08:09, twiens wrote:

----- Original Message Follows -----
From: Michael Barton <michael.barton@asu.edu>
To: Moritz Lennert <mlennert@club.worldonline.be>, "Patton,
Eric" <epatton@nrcan.gc.ca>
Cc: "'grassuser@grass.itc.it'" <grassuser@grass.itc.it>
Subject: Re: [GRASS-user] RE: Problem querying layers other
than '1' in gis.m
Date: Wed, 20 Sep 2006 07:48:43 -0700

> You CAN link multiple tables to single vector objects.
> That is what layers is all about. You need a separate CAT
> column for each table you link. Each cat column is a
> "layer". It serves as a key to link the object with a
> record in a table.
>
> I don't know if v.what (used in gui vector querying) will
> query more than layer one. There was some discussion about
> this awhile back and I can't remember the outcome. There
> have been some other new changes to v.what that will
> eventually go into 6.3. If layer support has been added,
> this will go into 6.3 also.

v.what does not support layers.

Eric,

Your understanding of what layers are supposed to do is
correct, they are multiple linked tables to a single
topology layer, but there are unique cats for each linked
table.

Michael and Eric,

I had been planning on adding support for multiple linked
tables in v.what at some point, but since I deeply dislike
the terminology and think the general approach to this
problem is wrong in the first place I'm not motivated.
Personally I think that attribute management should be left
to the database backend and this so called feature should be
dropped as the terminology is confusing. But.... there is
deep resistance from a number of core developers who
designed and implemented this multiple table link feature,
so that is not likely to happen. The short and long of it
however, is that there are other aspects of GRASS
development which I'm more interested in and I think are
more useful so that is where I have been and will be putting
my limited time. If someone else wants to add "layers" to
v.what that is fine, but I won't be doing it in the
forseable future.

T
--
Trevor Wiens

--
Trevor Wiens
twiens@interbaun.com

Trevor,

thanks for the insight into some of the behind the scenes GRASS development.
perhaps this would be a good topic for the steering committee to discuss?
querying attributes (often from multiple linked tables) is an important tool,
but if there is an underlying disagreement (with alternative data storage /
terminology approaches) I am fairly sure that others would be interested in
hearing about it, and possibly giving feedback (what do you think David
S. ?).

Thoughts?

--
Dylan Beaudette
Soils and Biogeochemistry Graduate Group
University of California at Davis
530.754.7341

3

On Wed, 20 Sep 2006 10:39:49 -0700
Dylan Beaudette wrote:

---snip---

> Michael and Eric,
>
> I had been planning on adding support for multiple linked
> tables in v.what at some point, but since I deeply dislike
> the terminology and think the general approach to this
> problem is wrong in the first place I'm not motivated.
> Personally I think that attribute management should be left
> to the database backend and this so called feature should be
> dropped as the terminology is confusing. But.... there is
> deep resistance from a number of core developers who
> designed and implemented this multiple table link feature,
> so that is not likely to happen. The short and long of it
> however, is that there are other aspects of GRASS
> development which I'm more interested in and I think are
> more useful so that is where I have been and will be putting
> my limited time. If someone else wants to add "layers" to
> v.what that is fine, but I won't be doing it in the
> forseable future.

--snip---

Trevor,

thanks for the insight into some of the behind the scenes GRASS development.
perhaps this would be a good topic for the steering committee to discuss?
querying attributes (often from multiple linked tables) is an important tool,
but if there is an underlying disagreement (with alternative data storage /
terminology approaches) I am fairly sure that others would be interested in
hearing about it, and possibly giving feedback (what do you think David
S. ?).

Thoughts?

Dylan,

As a very minor contributor to GRASS (contributing mostly to verbiage
on the lists rather than software), I'm not sure what insight I've
provided, other than my point of view. Some time ago when trying to
understand what 'layers' meant I raised the issue on the dev list and
others agreed with me that the terminology was confusing, but since it
was similar to the naming in OGR and Tiger files, no serious
consideration to renaming it was given. Further it was originally
named fields and then renamed to layers, which made the possibility of
renaming again more remote. Obviously 'link table' would have been a
reasonable choice. However it was and is my opinion that it would have
been simpler to simply allow for sql dynamic links for vector modules
and this allows much greater flexibility in the operation and supports a
superior SQL style of attribute management. I am extremely biased
however as someone who has done database application development for 15
years and uses PostgreSQL and PostGIS regularly.

Still, I do agree that the issue of the name is confusing and I don't
really care what terminology OGR or Tiger use, because to the average
user a layer is a single collection of vector or raster data. This term
is used this way in GIS textbooks and courses. If we actually care
about making inroads into the huge ESRI user base we need to make sure
that GRASS terminology is consistent and intuitive, otherwise the vast
majority of those users will never consider using GRASS. Let me be
clear on this, I don't suggest adopting ESRI terminology as their
terminology is often inconsistent and non-standard. However, in the
ESRI course discussion, the one point made over and over again is that
GRASS forces users to actually understand what they are doing rather
than clicking on buttons, thus it is not only a powerful analysis tool,
but also a pedagogical tool. This second role can only be effectively
fulfilled if the choice naming of features and modules is
logical, consistent, and intuitive.

I also agree that this is something the GRASS steering committee needs
to seriously consider. If retained it needs a clear and obvious name,
not an ambiguous and confusing one. If not retained other work will
need to be done to support dynamic sql classication of features, which
now, may be more work, so is not likely to happen.

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)

4

I agree with Trevor about terminology. A big reason that this feature is not
used is because most people don't understand what it does. This is
improving, but a better name would help.

My suggestions center on "key" "attkey" (attribute key) "dbkey" or something
else. Maybe we can even have a two word name like "table key". Essentially,
this is what is usually called a "key field".

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: Thu, 21 Sep 2006 07:35:49 -0600
To: <dylan.beaudette@gmail.com>
Cc: <grassuser@grass.itc.it>, Michael Barton <michael.barton@asu.edu>, Moritz
Lennert <mlennert@club.worldonline.be>, "Patton,Eric" <epatton@nrcan.gc.ca>
Subject: Re: [GRASS-user] RE: Problem querying layers other than '1' in gis.m

On Wed, 20 Sep 2006 10:39:49 -0700
Dylan Beaudette wrote:

---snip---

Michael and Eric,

I had been planning on adding support for multiple linked
tables in v.what at some point, but since I deeply dislike
the terminology and think the general approach to this
problem is wrong in the first place I'm not motivated.
Personally I think that attribute management should be left
to the database backend and this so called feature should be
dropped as the terminology is confusing. But.... there is
deep resistance from a number of core developers who
designed and implemented this multiple table link feature,
so that is not likely to happen. The short and long of it
however, is that there are other aspects of GRASS
development which I'm more interested in and I think are
more useful so that is where I have been and will be putting
my limited time. If someone else wants to add "layers" to
v.what that is fine, but I won't be doing it in the
forseable future.

--snip---

Trevor,

thanks for the insight into some of the behind the scenes GRASS development.
perhaps this would be a good topic for the steering committee to discuss?
querying attributes (often from multiple linked tables) is an important tool,
but if there is an underlying disagreement (with alternative data storage /
terminology approaches) I am fairly sure that others would be interested in
hearing about it, and possibly giving feedback (what do you think David
S. ?).

Thoughts?

Dylan,

As a very minor contributor to GRASS (contributing mostly to verbiage
on the lists rather than software), I'm not sure what insight I've
provided, other than my point of view. Some time ago when trying to
understand what 'layers' meant I raised the issue on the dev list and
others agreed with me that the terminology was confusing, but since it
was similar to the naming in OGR and Tiger files, no serious
consideration to renaming it was given. Further it was originally
named fields and then renamed to layers, which made the possibility of
renaming again more remote. Obviously 'link table' would have been a
reasonable choice. However it was and is my opinion that it would have
been simpler to simply allow for sql dynamic links for vector modules
and this allows much greater flexibility in the operation and supports a
superior SQL style of attribute management. I am extremely biased
however as someone who has done database application development for 15
years and uses PostgreSQL and PostGIS regularly.

Still, I do agree that the issue of the name is confusing and I don't
really care what terminology OGR or Tiger use, because to the average
user a layer is a single collection of vector or raster data. This term
is used this way in GIS textbooks and courses. If we actually care
about making inroads into the huge ESRI user base we need to make sure
that GRASS terminology is consistent and intuitive, otherwise the vast
majority of those users will never consider using GRASS. Let me be
clear on this, I don't suggest adopting ESRI terminology as their
terminology is often inconsistent and non-standard. However, in the
ESRI course discussion, the one point made over and over again is that
GRASS forces users to actually understand what they are doing rather
than clicking on buttons, thus it is not only a powerful analysis tool,
but also a pedagogical tool. This second role can only be effectively
fulfilled if the choice naming of features and modules is
logical, consistent, and intuitive.

I also agree that this is something the GRASS steering committee needs
to seriously consider. If retained it needs a clear and obvious name,
not an ambiguous and confusing one. If not retained other work will
need to be done to support dynamic sql classication of features, which
now, may be more work, so is not likely to happen.

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)