[Yazlist] geo query structure

dan ancona ancona at alexandria.ucsb.edu
Thu Jun 13 19:31:48 CEST 2002


Ah, if only I were working with a single server, things would be SO much
easier.  I'm not, though - this is for a Z39.50 driver for our middleware.  
In operation, it's going to potentially talk to any server & dataset
that's out there, so I'm trying to implement it to reflect what's
typically implemented as much as possible.

One of our main design objectives is to allow for as much heterogeneity as
possible.  We don't want to be in the position of having to encourage
server vendors or collection developers to do anything in particular.

So it's flexible.  I'm translating our XML based general query language
into Z RPN queries with XSLT, and there's a seperate XSLT for each server.  
So it'd be simple to rip out the boolean mishmush for a given query and
stick in 2060 based queries.

Dan

On 13 Jun 2002, David Crossley wrote:

> Hey Dan, i did not recommend that anyone stop using
> Use Attribute 2060. You would do better to encourage your
> server vendor to support the necessary functionality.
> The workaround method is not sustainable.
> --David
> 
> dan ancona wrote:
> > Hi - thanks for the message and the search term order, that's totally
> > doing it.  On your advice I skipped 2060 etc, and just went through and
> > double checked my bounding box code.  Now it's working great and I'm going
> > to stick with the same solution for temporal searches!  Woop!
> > 
> > Dan
> > 
> > On 12 Jun 2002, David Crossley wrote:
> > 
> > > Here is how i do it ...
> > > # Use Attribute: bounding rectangle (2060)
> > > # Relation Attribute: overlaps (7)
> > > # Structure Attribute: co-ordinate string (201)
> > > # with new GEO search term order: N W S E
> > > # try Jervis Bay on the east coast of Australia ...
> > > 
> > > Z> find @attr 1=2060 @attr 2=7 @attr 4=201 "-35 150.5 -35.5 151"
> > > 
> > > Of course you need to be sure that the target can cope.
> > > Not all can. Some only do the overlaps (7). Some give the
> > > same answer for overlaps and within! Some do not support
> > > 2060 at all.
> > > 
> > > That is why i too have been using a complex boolean of
> > > relational stuff against the individual bounding co-ordinates.
> > > The logic was hard to determine for each case and i shudder
> > > at the load that could be imposed on the target.
> > > --David
> > > 
> > > dan ancona wrote:
> > > > Hiya - This may mostly be a question for Mr. Nebert, but hopefully the
> > > > answer will be of more or less general interest.
> > > > 
> > > > I'm looking at the GEO spec here...
> > > > 
> > > > http://www.blueangeltech.com/standards/GeoProfile/annex_a.htm
> > > > 
> > > > and I'd like to use Relation Attributes 7 (overlaps), 8 (fully enclosed
> > > > within), 9 (encloses), etc. for my spatial searching.  I had been
> > > > assembling these queries manually (i.e. ANDing or ORing all the query
> > > > terms against the appropriate bounding box coords), but the implementation
> > > > I came up with is broken, and since GEO seems to support an easier way,
> > > > I'm trying to annoy myself as little as possible by reimplementing it as
> > > > such.
> > > > 
> > > > But I'm not quite sure how to structure the query - specifically, how the
> > > > query "Search Term Region" is described.  I guessed something like this...
> > > > 
> > > > Z> f @attr 2=8 @attr 2060 90 -90 180 -180 
> > > > Prefix query error
> > > > 
> > > > (2060 is "bounding box", which seemed like the right field to query
> > > > against), but you can see the results.  I was guessing it goes N S E W
> > > > from trying to interpret the spec, but I'm not sure...anyway, how do I
> > > > make this go?  I'm guessing however this works, it works more or less the
> > > > same for temporal searching; that's the next feature I have to figure out.
> > > > 
> > > > Thanks!
> > > > 
> > > > dan
> 
> 
> 
> _______________________________________________
> Yazlist mailing list
> Yazlist at indexdata.dk
> http://www.indexdata.dk/mailman/listinfo/yazlist
> 





More information about the Yazlist mailing list