[postgis-devel] I want boxes
pramsey at opengeo.org
Tue Sep 27 10:15:40 PDT 2011
What an exciting opportunity to try out strategy numbers... through
the magic of PostgreSQL's GiST framework, both strategies can be made
available using different operators (because we love, love, love
obscure combinations of symbols).
On Tue, Sep 27, 2011 at 10:07 AM, Paragon Corporation <lr at pcorp.us> wrote:
> If it's not that much harder -- box is better even for things that are
> Take a road -- I can do tests to confirm but box is better because I can
> never use the centroid
> Centroid tells me the closest is the farthest. Not terribly useful. At
> least the box will let me know it's useless.
> With centroid I have no idea if I'm dealing with largish or smallish things
> to consider how credible the answer is.
>> -----Original Message-----
>> From: Paul Ramsey [mailto:pramsey at opengeo.org]
>> Sent: Tuesday, September 27, 2011 1:03 PM
>> To: Paragon Corporation
>> Cc: Sandro Santilli; nicklas.aven at jordogskog.no
>> Subject: Re: I want boxes
>> Just to point out:
>> The problem with the centroid is that, for large long
>> features, lt's overselective. So to get the "full potential
>> set" of things you'll have to winnow down, you need a large
>> first limit.
>> The problem with the box is that, for large long features,
>> it's underselective. So you'll get lots of things that aren't
>> actually very close still showing up al their boxes interact
>> with the candidate, causing zero-distance returns. The net
>> result is that you'll still need a large first limit, to
>> ensure that in addition to all the zero-distance false
>> positives you also have the non-zero results that might
>> actually be the closest.
>> Which is not to say the box-distance might not be better in
>> the end, just I'm finding in hard to visualize an extreme improvement.
>> On Tue, Sep 27, 2011 at 9:57 AM, Paragon Corporation
>> <lr at pcorp.us> wrote:
>> > If it weren't for the fact it's the centroid of the box, I
>> would agree
>> > with you.
>> > But honestly in many of my cases the centroid of my object
>> is no where
>> > near the centroid of the box so pretty useless to base
>> anything on it.
>> > Works fine for parcels but not much else I have.
>> > for the case of polygons etc. as Nicklas and I think others have
>> > pointed out, the objective is a little different
>> > not to get the best sort but faster compute the maximum
>> distance you
>> > need to stretch out to grab the top 10.
>> > Though I'm curious how Oracle's NN which is also imperfect works.
>> > Haven't paid much attention to that.
>> > Thanks,
>> > Regina
>> >> -----Original Message-----
>> >> From: Paul Ramsey [mailto:pramsey at opengeo.org]
>> >> Sent: Tuesday, September 27, 2011 12:52 PM
>> >> To: Paragon Corporation
>> >> Cc: Sandro Santilli; nicklas.aven at jordogskog.no
>> >> Subject: Re: I want boxes
>> >> I can almost guarantee you that boxes will be just as bad but in a
>> >> different way... and centroids are always relative to the box :) I
>> >> will think on doing box distance.
>> >> P.
>> >> On Tue, Sep 27, 2011 at 9:48 AM, Paragon Corporation <lr at pcorp.us>
>> >> wrote:
>> >> > As I pointed out to strk -- the centroid appears to be
>> ceontroid of
>> >> > the box which is even less useful than I had originally
>> >> thought. That
>> >> > said box distance is way better.
>> >> >
>> >> > Is it possible to have the distance be box based instead of
>> >> centroid.
>> >> > Centroid isn't terrible useful.
More information about the postgis-devel