[Yazlist] geo query structure

David Crossley crossley at indexgeo.com.au
Wed Jun 12 09:18:05 CEST 2002


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






More information about the Yazlist mailing list