[GRASS-dev] terminology issues in grass7

[Michael Barton]

There are 2 issues being discussed here. I'll guess I'll go with the  
flow, however, and comment on both

On Aug 11, 2008, at 12:26 PM, Paul Kelly wrote:

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

See below.

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

Issue 1:

In short, yes. For example, when you color a vector area map randomly,  
it does so by cat numbers. If a map has multiple "layers" (i.e.,  
catsets) with different features grouped according to cat values in  
different ways, you will get a different map depend which "layer" you  
choose. You also can query and/or display directly on the cats in a  
"layer"; selecting all the features with cat=1 in layer=1 might well  
be a different result from selecting all features with cat=1 in layer=2.

Each "layer" is a 1-column "table" tightly coupled to the features in  
a vector data file. You can use the column (i.e., cat) values in each  
of these coupled tables (i.e., layers) as key fields to match with the  
key fields of a loosely coupled attribute table. That is to link two  
tables in a RDBMS, you need a key field in each of the tables being  
linked. Each GRASS "layer" holds the key field (i.e., "cat" or  
"category") in the vector object table. These must be matched by a key  
field in an attribute table (i.e., with integer values only).

In this sense, we could call a layer a "cat table". However, to just  
refer to them as tables is something of a misnomer given that most  
people will be thinking of the potentially larger attribute tables.  
"Catset" also captures this concisely.


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

Issue 2:

Actually, each raster and vector file is a file of geospatial data of  
some kind. To make a map (a visual and perhaps also an analytical  
entity), we combine or composite one or more of these files and  
display it in a GIS. The metaphor of combining multiple layers to  
produce a map is pretty widely understood too. I kind of like the  
conceptual clarity of differentiating the spatial data "layers" from  
the "map" that is produced in the GIS by compositing one or more layers.

The big issue comes if we want to switch the terminology as expressed  
in GRASS command modules: d.rast map=myraster vs. d.rast layer=myraster.

This begins to seem very reasonable if we are looking at the  
possibility of having something along the lines of d.rast  
layers=myraster1,myraster2,myraster3 map=mycompositedmap.ps

g.pnmcomp has similar syntax, but uses the generic "input=" and  
"output=" instead of "layers=" and "map="

Layers compositing into a map also makes much sense in the GUI canvas  
context. If you are combining a series of maps in a display context,  
what are you making in the end?

A few cents worth of thoughts.

Michael