[Yazlist] geo query structure
ancona at alexandria.ucsb.edu
Wed Jun 12 23:13:26 CEST 2002
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!
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.
> 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
More information about the Yazlist