Newsgroups: comp.infosystems.gis
Date:         Thu, 30 Jul 1992 09:17:39 PDT
              <GIS-L@UBVM.BITNET>
From:         Jim Tenbrink <esri!harley!jimt@UUNET.UU.NET>
Subject:      Re: Re : Map layers and overlay
X-To:         uunet!UBVM.cc.buffalo.edu!GIS-L@uunet.UU.NET

> Subject:      Re : Map layers and overlay
> ... Let us say
> that in a future object-oriented world, we are faced with the decision of
> whether there would be any value in classifying map layers into different
> categories, in order that these layers can have individual properties and
> behaviours. My question now is what the nature of these individual methods
> might be ? There are some obvious applications pertaining to data quality, eg,
> one might wish to flag to users that they are attempting to overlay data sets
> of widely disparate resolutions, or that there are problems in combining
> continuously measured variables with categorical data. Stepping beyond
> concerns of data quality, however, it is interesting to speculate on the
> utility of classifying layers according to semantic content. Ideas anyone ?
>
> --
> Loughborough University of Technology          tel : (0509)263171  ext 4164
> Computer-Human Interaction Research Centre     fax : (0509)610815
> Leicestershire  LE11 3TU           e-mail - (Janet):C.V.Copas@uk.ac.lut
> G Britain                 (Internet):C.V.Copas%lut.ac.uk@nsfnet-relay.ac.uk
>

This is interesting. I interpret what you're saying as on-the-fly
theme creation (yes, no??)

I see three issues here.

1. A **very** smart spacial query language.
2. **Very** late binding of data to an object definition.
3. Preserving the notion of maintaining raw geographic data in the form
   of map layers.

(1) won't happen---simply because definitions of geographic entities and
operations won't please all the people all of the time (what's
`near'?).  So algorithms which require those precise definitions will
be stymied.  So, your ``methods'' will be a set of highly interactive,
thought amplyifying, tools designed to let >you< collate raw data into
whatever type of theme you're interested in.

(2) All object defining paradigms which I have seen require precise
definition of the data which is to be encapsulated. For the same reason
that a smart spacial query language won't be developed, the form of
object data cannot be totally specified ahead of time. So, late binding
of data (with variant forms) to objects is required.

(3) Given tools for creating selection sets from a raw data store, and
object definitions for attaching semantics to those selection sets, the form
of the raw data store becomes more of an implementation issue than a geographic
one.  This is where the ol' ``why do I have to store the same line three times''
issue finally meets with a (possible) answer. Suppose a line in
a data store is viewed as a portion of a coastline, a portion of
a political boundary, and a property boundary. Since our raw data store no
longer attaches semantics to ``lines'', there is no reason to store this line
more than once (especially now that dynseg is a reality).

Am I addressing the issues which you raised? I'm a comp. sci. major, not a
geographer :)

Jim TenBrink
ESRI
jtenbrink@esri.com
(my thoughts are my own)
Comments: Gated by NETNEWS@AUVM.AMERICAN.EDU