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

[Michael Barton]

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 at interbaun.com>
> Date: Thu, 21 Sep 2006 07:35:49 -0600
> To: <dylan.beaudette at gmail.com>
> Cc: <grassuser at grass.itc.it>, Michael Barton <michael.barton at asu.edu>, Moritz
> Lennert <mlennert at club.worldonline.be>, "Patton,Eric" <epatton at 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 at 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)