[GRASS-dev] terminology issues in grass7

Paul Kelly paul-grass at stjohnspoint.co.uk
Mon Aug 11 15:26:54 EDT 2008


On Mon, 11 Aug 2008, Maciej Sieczka wrote:

> Paul Kelly pisze:
>
>> I think though, that connecting multiple layers to different tables is the 
>> main application for layers? Are they much use for anything else? In which 
>> case, calling them tables makes things clearer. Perhaps even table would be 
>> enough - each vector map can be connected to multiple tables, each vector 
>> map can have multiple tables, each vector map can have multiple table 
>> links... is there a big difference in meaning between those different 
>> sentences? I feel removing the word "link" improves the clarity of the 
>> meaning without adding any additional ambiguity.
>
> I don't agree with Paul. In GRASS vector terminology the term "table"
> already has a very well defined meaning and it must not be used for
> anything else.
>
> (A "table" is an object in the database that stores the given "layer"'s
> attributes, and the "table" and "layer"'s geometrical features are
> linked using "key column" in which the "categories" are stored inside
> the "table".)

Agree 100%. In fact, that was exactly my point. In the interests of 
clarity/simplicity, I was proposing to consider a table as "belonging" to 
a particular map, e.g. the table containing a key column (or key field) 
whose values correspond to the categories in layer 1 of vector map x 
could be considered as table 1 of vector map x. The fact that tables may 
belong to multiple vector maps, and indeed exist independently outside of 
GRASS, doesn't IMO impede on the clarity of this relationship between a 
vector map and multiple tables: the same table may belong to different 
vector maps and be associated with a different table number in each.

> Regarding Moritz's remark I indeed missed the fact that the vector map
> having 0 or more "layers" does not directly imply it has the same number
> of data "tables". Given that, "table link" to replace "layer" as I
> suggested is bad. If we are to change the term, we should do it right.
> How do you like "category set" then, "catset" in short? Together with
> with replacing term vector "map" with vector "layer" it would yield:
>
> Each vector "feature" (line, point etc.) can have 0 or more "categories"
> in a vector "layer". Each "category" belongs to only 1 "category set".
> Each "category set" of a vector "layer" can be connected or not with a
> single database "table". The "key column" in that "table" stores the
> "categories" of "features" present in the given "category set".
>
> Any good?

I think we are thinking the same :) IIUC, a category set is quite 
meaningless unless the table containing more information on each category 
in the set is also known. My proposal is simply to leave the concept that 
a category set can be meaningful in the context of more than one linked 
table to advanced users, and associate the table directory with the vector 
map. This could lead to the situation where, e.g. table 0 of vector map x 
and table 1 of vector map y refer to the same table.

My question is still open though - are there any other practical 
applications for layers, other than enabling vector maps to be connecyed 
to multiple tables?

> Talking about layers (in their current meaning) - there is no convenient
> tool to report the number of layers in a vector map. There is only
> v.category opt=report. Could v.info be extended in this regard? Oh, and
> the regular v.info already reports number of "dblinks" (which I guess
> might be renamed to "table links", but I won't insist), while v.info -t
> doesn't. Could this be addressed too please?
>
>> With regard to calling maps something different though, I think that would 
>> be very confusing and not a good idea (especially if they were renamed to 
>> layers). Map has IMHO a much clearer meaning than layer. There is the issue 
>> of ambiguity with a printed map I suppose, but use of the word in that 
>> context is kind of non-technical I feel. The use of the word map has a 
>> clearly defined historical meaning in GRASS (and influences other words 
>> too, e.g. a mapset = a collection of maps - should this be renamed a 
>> layerset?) and I feel that it should stay.
>
> Paul has points here. Yet I *guess* I'd prefer to trade legacy for
> clarity anyway. Calling GRASS "maps" "layers" would improve clarity
> IMHO, especially for newcommers. Word "map" has been in use for
> centuries and the word immediately brings a nice picture with north
> arrow, legend and stuff to my mind. "Layer" is *the* GIS word for a set
> of features that can be represented graphically as a map, as well as a
> table or a set of statistic properties etc.

Well I have no idea here; all I can do is point out that I learned GIS 
from GRASS and have no experience of any other GIS, and the concept that 
each raster and vector file is actually a real map was really helpful to 
me when learning. :)

Paul


More information about the grass-dev mailing list