[GRASS-dev] terminology issues in grass7

[Hamish]

look, the "maps in MAPSETs" concept has been successfully used by GRASS
for more than 20 years, and indeed they are mentioned in the original
Fort Hood specification from 1983. I'm willing to tweak it a bit, but
not prepared to abandon that tradition.


As Michael mentioned, any difference in opinion probably arises from the
native English speakers vs. not. Whereas the non-native speakers take a
much more literal view of the word than the native speakers would. I
would expect native speakers to consider the word first and foremost an
abstract idea and not explicitly as cartography (and thus have no problem
adapting their brains to GRASS's usage, as it's a completely natural idea
for them). It's no reflection at all on the non-native speakers -- it's
not at all surprising: foreign languages are taught in school as words
next to a picture, simply as a noun. All nuance is lost and can take a
lifetime to grasp.

[I don't like using this sort of argument as it leaves little room for
rebuttal; you'll just have to take my word that I'm not using it as a
rhetorical trick..]

Indeed it's funny to think of feeding a literal paper map into a vector
module; up until now I'd never even considered that. I'll second
Michael's observation that none of our students here have ever expressed
any difficulty with the concept of a "map" as data. To me the abstract
meaning is the primary definition and the cartography one is just a
subset of that. If you've seen a lot of confusion about it over in your
neck of the woods* then it reinforces the idea that it is in fact a lost-
in-translation issue.

[*] I'm assuming that phrase doesn't translate well either :) no worries,
it doesn't make much sense here either

continuing,
Maps are inherently an abstract idea. Those lines on the paper represent
something more. Given that mindset abstracting it a little more is not
such a big jump. Maps can be verbal; think of "the roadmap to peace"; a
plan; probably most common as some lines drawn on the back of a napkin.



my proposal to resolve this is as follows-

modules & libraries: keep as "map" where it needs to be short
documentation and discussions: use "map layer" as a bridge
GUI: use "layer" to avoid namespace overlap with Map Display window.

As long as we talk about "map layers" enough people will easily figure
it out when one or the other of those words are missing, even if the
implied meaning is not natural to them.

vector layer would have to change to avoid overlap with GUI rendering
map layer. (IMHO cat|keyset is gobbledygook jargon, it may say what it 
technically is, but it doesn't give any indication as to what it does)


For historical perspective I had a look through that 1987 video.
(the GRASS theme song is just awesome) At 1:20 into it William Shatner
discusses them as maps. At 2:06 he talks of them as layers. At 9:48 he
talks of them as "data layers", then goes back to talking about them as
maps again a few moments later. So free interchange between the terms is
nothing new.


I don't like "data layer", too generic. It does not say anything about
what it is. We're drowning in data these days & so we need to be as
descriptive as possible to keep it all straight. (no, "spatial data"
doesn't help narrow down the meaning much at all)


I've always found "data(base) tables" weird. I just think about chairs.
(difference being a table is not an abstract idea to begin with, it's 
just a table)


as for vector layer renaming, I'd continue on about how an abstract idea
can be much better than an overly mechanical description if the analogy
is just right, but really I've got to get back to more important work
and I am afraid these discussions get us nowhere, slowly.



if it ain't broke!,
Hamish