Hi Martin,
See below.
On Jun 12, 2009, at 11:27 AM, Martin Landa wrote:
Hi,
2009/6/12 Michael Barton <michael.bar...@asu.edu>:
[...]
I probably shouldn't add more, but I will anyway.
I like calling vector and raster files maps. It is really easy for
users to
understand what these files are. Maps can be added to display
layers (i.e.,
like layers in a CAD or drawing package) for display and
visualization.
that can be also confusing, data can be stored e.g. in the database as
PostGIS tables - vector and also raster data (see wktraster) instead
of files. I would hesitate to use "files" in this connection. Also
"files maps" seems to be strange to me - I still see "map" as
something related to the cartography. I would call it "data layers".
From this perspective, data layers seems sensible and I even talk
about geospatial data when I teach GIS. I also understand the
cartographic perspective that maps are the final, often paper, result
of combining multiple geospatial data layers. Nonetheless, most users
will find it less confusing if we just continue to call them maps--
with the idea that we've moved maps from paper to digital media. Note
that this was the original usage in one of the world's oldest GIS
systems still in use (i.e., GRASS). And looking at the 1980's video
that someone rediscovered, the parallels between paper maps and
digital maps were made so that potential users could better understand
a GIS. From a personal perspective, I really don't mind data layers at
all. I just think that map is easer for most users to understand even
if it seems somewhat inaccurate from a more technical perspective.
The features that are currently called vector "layers" really serve a
database function. Given that, my preference is that they be called
something in database jargon that is also very easily recognizable.
AFAIK,
the term "layer" is not a term commonly used for DBMS files and
functions.
The closest common term for what our "layer" does is a key field.
Whether or
not the key field is use to connect the vector to an attribute
table, that
is what it is good for ultimately. So that is why I favor some
version of
"key" for this feature.
It's not always related to the database function, but you are right in
the most cases it is. I still see "something-set" as good choice,
because it's grouping cats/keys/ids to the set. E.g. if we use
'keyset', then we should call 'cat' as 'key'. Note that we already use
'feature id' for different meaning - every feature has unique fid.
Keyset is fine with me too. We are talking about a single column of
values, or database field. So simply "key" is OK too-as in the vector
has 2 keys, one of which is linked with attribute table A.
I agree with you that feature ID is incorrect. Each vector has a
unique feature ID, but this is not what links it with an attribute
table. The ID relates to the vector object. Cat values can be
identical to the ID values, but this is not at all necessary.
Michael
Martin
--
Martin Landa <landa.martin gmail.com> * http://gama.fsv.cvut.cz/~landa
______________________________
C. Michael Barton, Professor of Anthropology
Director of Graduate Studies, School of Human Evolution & Social Change
Director, Center for Social Dynamics & Complexity
Arizona State University
Tempe, AZ 85287-2402
USA
voice: 480-965-6262; fax: 480-965-7671
www: http://www.public.asu.edu/~cmbarton
_______________________________________________
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev
