[postgis-devel] PATCH: New positional operators based on Y position of bounding boxes

[strk at refractions.net]

On Wed, Jan 12, 2005 at 09:10:31AM -0000, Mark Cave-Ayland wrote:
> Hi strk, 
> 
> > -----Original Message-----
> > From: strk at refractions.net [mailto:strk at refractions.net] 
> > Sent: 11 January 2005 17:46
> > To: Mark Cave-Ayland
> > Cc: 'PostGIS Development Discussion'
> > Subject: Re: [postgis-devel] PATCH: New positional operators 
> > based on Y position of bounding boxes
> 
> (cut)
> 
> > > Well, I've been working on some code that opens the GiST index 
> > > relation directly and reads in the root node to calculate 
> > the extents 
> > > of the root node. Of course this does not reflect the true extents 
> > > since we do not know the visibility of each of the index entries 
> > > without reading the tuples themselves; however it is a very good 
> > > starting point. Here is the code that I have experimenting 
> > with (add 
> > > to the end of lwgeom_gist.c):
> > 
> > Wow.. I've been trying myself but didn't get feedback from 
> > pgsql-hackers and coudln't find documentation myself. Sounds 
> > good and simpler then I tought... Anyway, consider also the 
> > already present estimated_extent(), returning the extent of 
> > the computed histogram (but only works on 800). BTW, which 
> > pgsql versions will support your GiST root extractor ?
> 
> I think it should work on most PG versions - my inspirational code was the
> Gevel module which can be found at
> http://www.sai.msu.su/~megera/postgres/gist/. The plan was to use the root
> extractor to find the largest possible extent and then binary search inwards
> to find the real extent. I guess it really depends on whether people would
> find it useful as to whether to spend the time working on it - IIRC the main
> group of people that have asked about this are the CadCorp guys, however I
> know I would find it useful when working on larger tables consisting of
> millions of rows.

I've been asked to research on this for GUI applications, and for that
use the 'estimated' extent is ok (somehow better, if you consider
hard-deviants). It works even in absence of a GiST index (stats are
computed anyway), but only for PG8+.

Your version would be more widely usable (PG<80) and more accurate,
but would require a GiST index. I imagine it could work transparently
from inside extent() - using GiST if available, and brute force otherwise.

Probably we should not rush to have this included in RC1, but I'll make
some tests with it.

--strk;

> 
> 
> Kind regards,
> 
> Mark.
> 
> ------------------------
> WebBased Ltd
> South West Technology Centre
> Tamar Science Park
> Plymouth
> PL6 8BT 
> 
> T: +44 (0)1752 791021
> F: +44 (0)1752 791023
> W: http://www.webbased.co.uk
> 

-- 

For standing up against patentability of software,

  Thank You, Poland!

Read the intervention:    http://kwiki.ffii.org/ConsPolon041221En
Send your thanks:         thankyoupoland.info
Read/do more:		  http://www.noepatents.org/