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

[strk at refractions.net]

On Tue, Jan 11, 2005 at 02:35:38PM -0000, Mark Cave-Ayland wrote:
> Hi strk,
> 
> > -----Original Message-----
> > From: strk at refractions.net [mailto:strk at refractions.net] 
> > Sent: 11 January 2005 12:24
> > To: Mark Cave-Ayland
> > Cc: 'PostGIS Development Discussion'
> > Subject: Re: [postgis-devel] PATCH: New positional operators 
> > based on Y position of bounding boxes
> 
> (cut)
>  
> > Your naming is good, and having dopped box2d operators I 
> > think Paul won't be against adding these *useful* ones.
> 
> Great. I've committed the changes to CVS.

Thanks. I've deleted lwgeom/lwgeom.sql.in from the repository.
It is no more maintained nor used since a long time (I'm sorry 
you lost time modifying it as well).

> > Then we should take a breath to plan release path.
> 
> OK. I did have a few things that I did notice from current CVS:
> 
> 	- There is still mention of PG 7.1 in the .sql.in files, even though
> LWGEOM
> 	is only supported for PG >= 7.2.

I'm really sorry about it, but - yes - it's true.
We should remove all 71 special handling around.

> 	- I did not notice any SRID checking in the LWGEOM_* functions in
> lwgeom_gist.c.
> 	Hence the following works without throwing an error in CVS:
> 
> 	mca1=# select astext(the_geom) from t1 where setSRID(the_geom, -1)
> |&>
> 	 setSRID('POINT(0 0)'::geometry, -2);
> 
> 	   astext
> 	------------
>  	POINT(0 0)
>  	POINT(0 1)
>  	POINT(0 2)
> 	(3 rows)

Added SRID checks.

> 
> 
> 	- It suddenly occurred to me that using the new operators, it may be
> possible to
> 	devise a binary search algorithm to determine the extents of a
> column. For example,
> 	using queries like:
> 
> 		SELECT 1 FROM my_geom_column WHERE my_geom_column >>
> 'POINT(A B)' LIMIT 2
> 
> 	where A and B are altered using a standard binary search, it should
> be possible to
> 	quickly find the right-most geometry in the column when a GiST index
> is present by
> 	looking at the number of records returned. If this is repeated for
> the remaining 3
> 	sides then we have a "quick" way of accurately determining the
> overall extent of a
> 	column.

Sounds hard to me... how can you binary search a space with
unknown boundaries ? Anyway, now that you make me think about
this I implemented btree index on geometry for use in ORDER BY
and GROUP BY. geom1 < geom2 if geom1.bbox.xmin < geom2.bbox.xmax
and consequently other geoms too... I think it would be easier
that way (but you need to build a btree index).

--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
> 
> 
> _______________________________________________
> postgis-devel mailing list
> postgis-devel at postgis.refractions.net
> http://postgis.refractions.net/mailman/listinfo/postgis-devel

-- 

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/