NetNews Usenet Archive 1993 #3/NN_1993_3.iso/spool/comp/infosyst/gis/5088

Text File | 1993-01-28 | 5.2 KB | 101 lines

Comments: Gated by [e-mail]
Path: sparky!uunet!charon.amdahl.com!pacbell.com!decwrl!sdd.hp.com!zaphod.mps.ohio-state.edu!usc!howland.reston.ans.net!paladin.american.edu!auvm!ATTMAIL.COM!RWELEBNY
Phone: [phone]
Fax-Phone: [phone]
Content-Type: Text
Message-ID: <[e-mail]>
Newsgroups: comp.infosystems.gis
Date:         Tue, 26 Jan 1993 21:51:20 GMT
Sender:       Geographic Information Systems Discussion List <[e-mail]>
From:         [e-mail]
Subject:      Terminology
Lines: 87

Jeff Nugent at SUNY Syracuse posed an inquiry regarding GIS terminology.
Having sent him a direct response, it came to mind that those on the net might
take interest in (or issue with) with some of the thoughts I expressed in my
response.

The original message read:

What is the accepted term for those GIS files that contain both spatial and
attribute components?  Those of us who use Arc/Info call them coverages, but
is this term acceptable for GIS files produced from other software?  The term
data layer or data theme doesn't work, since a layer may be composed of many
files, each corresponding to a tile.  And a tile is merely a spatila sub-set
of a region.  All this may sound trivial (like the geographic/geographical
dabate), but I don't want to corrupt concepts or terms in our discipline with
software specific terms or commands (someone who's been around longer than I
can enlighten me as to whether we have always built (from BUILD) topology, or
if we merely created topology in the days before Arc/Info became popular).

           - - - - - - - - - - - - - - - - - - -

The following is an excerpt of what I sent Jeff:

 ------------- Attached Message Follows -------------

You have flagged what I consider to be a very interesting subject.  Having
years of experience developing applications in most of the commercially
available GIS software environs, I have come to appreciate that terminology
can become a volatile issue.  The volatility seems to revolve around "term
bias" that comes from familiarity with one or another commercial product.

In your introductory sentence, you referred to files containing "both spatial
and attribute conponents."  I have observed that many folks use the term
"spatial" in lieu of "graphic" or "graphical."  I submit that virtually all of
the data in residence in the GIS is spatial by virtue of its association with
a location relative to the planet.  This holds whether such data generates a
graphical display, or defines the characteristics (attributes) of that which
is displayed graphically.

In the case of "coverages" and "tiles", you are clearly in "Arc/Info Land".
Since Arc/Info has such a widely installed base, these terms tend to slant the
general understanding of how a GIS works, and what its databases are made of.

Coverages, as defined by Arc/Info, denote just what the word implies.
Generally, this is suggestive that one may not use shared primitives where
appropriate, but must import another coverage that may replicate lines in
order to denote a different theme (as county - state - shoreline - etc.).
This is not very efficient in terms of both processing and storage.  Some
products (typically those embodying more modern architectures) can make use of
shared primitives and/or objects.  These tend to provide advantages, but do
confuse the terminologies, since different descriptors need to be applied to
the inherent characteristics.  Thus you may encounter themes (as you cited),
libraries, objects, collections, layers, etc.  There seems to be no accepted
convention.

Tiles are unique to systems which are not able to deal with densly populated
data sets that encompass very large areas.  Tiling is a "cheap" way of
chopping a geographic area into hunks which can be managed within the
limitations of the software (and in some remote cases, the hardware).  This
requirement is counter-productive, and imposes severe limitations on the value
of a GIS.  When one considers the need for relational modeling in very large
very dense areas, the existence of "tiles" can render a system useless.  The
same is true when one attempts to trace through a topological data structure
under the same conditions.

The term "tile" is unique to Arc/Info.  Other vendors call it "faceting",
"partitioning" and even "windowing."  Again, this technique was necessitated
by the fundamental architectures inherent in the software products that are
now considered to be "mature."  Modern data architectures obviate the need for
tiling, which was really a holdover from the old days of CADD, and was founded
on the "map sheet mentality."  Modern systems permit the defining of map
sheets within the seamless spatial environment, but with none of the penalties
associated with tiling.

As I recall, we were "building" topology from day one, and term was and is NOT
unique to Arc/Info.  Most sysems provide the ability to "clean and build"
topological data structures from "spaghetti digitizing."  Modern systems do so
with no need to break the area into "manageable" sub-sets.

I hope that these thoughts have provided some benefit. * etc. etc. *

                   - - - - -  end attachment - - - - - - -

I welcome the comments of interested readers.

R.J. Welebny
301-445-6100
internet![e-mail]