Ray Denenberg wrote:
> I think we're in danger of both oversimplifying and overcomplicating and that
> (1) we should get requirements from geo folks, and (2) linear range searching
> is probably not simply a special case and should be treated separately.
> Oversimplifying because point, line, area, and volume don't cover: (a) curve
> and (b) surface.
> Overcomplicating because it appears that the geo folks may only want a crude
> normalized rectangle (east bounding longitute, west bounding longitude, north
> bounding latitude, and south bounding latitude).  See:

Whew... I go away on travel for a week and all of a sudden the list
explodes.  I've got some catching up to do, but let me add a few
comments as (perhaps) the token GEO representative here.

The GEO folks specifically do _not_ want to limit searching to a crude
normalized rectangle - it's just that one developer (me) doesn't have
any interest or incentive in turning Isite into a full-blown GIS system
<g>.

The GEO profile specification for the representation of a spatial
footprint was rather carefully drafted to permit the use of more complex
polygonal footprints, of which a bounding rectangle is a special (albeit
simple) case.  We only implemented the overlap between bounding
rectangles in the search engine in Isite because a full implementation
was just outside the scope of what we wanted the software to do.  I
certainly have always expected this to be an area where the GIS vendors
would jump in.

The idea of the protocol (to me, anyway) has always been to
unambiguously encode the query for transmission from origin to target,
and to unambiguously encode the results for transmission back - that is
to say, the specification of the query should be possible, even if not
everyone implements it.  So far, we've been able to do this in ZLG
(Z39.50, The Last Generation) with the help of the GEO profile.

Note additionally, with respect to both spatial and temporal footprints,
it's important to treat intervals as data structures distinct from just
a Boolean combination of single terms.  I believe that it's necessary to
provide the ability to specify a date range/interval and spatial
range/interval (longitude, in particular) as a single term.

For one thing, there are really different comparison relations for date
intervals and single dates (indeed - the GEO profile allows explicit
specification of each).  For example, what does it mean for one interval
to be "before" another, or "less than" another?  Do we match when one
date in the target matches, or must the entire interval match?  Or do we
leave it up to the server to decide?  In the past, for date ranges, we
(FGDC) have used the structure attribute to signify this distinction.

It's even more critical for spatial footprints - longitude in particular
- because the "sense" of the interval is determined by examining the
western and eastern boundaries together.  My interval, for example,
might have a western bounding limit of 170 degrees and an eastern
bounding limit of -170 (that is, it's 20 degrees wide, centered on the
International Date Line).  There's a difference between saying "west>170
and east<-170" and saying "within [170,-170]".

--
Archie

-- Archie Warnock                       Internet: [log in to unmask]
-- A/WWW Enterprises                    http://www.awcubed.com
--       As a matter of fact, I _do_ speak for my employer.