[postgis-devel] xmin(geometry) behaviour

[strk at refractions.net]

Ok. I did it.
xmin,xmax,ymin,ymax have been dropped from lwpostgis.sql in current CVS.
SCRIPT_VERSION has been incremented to 0.2.2.
A dump/reload is required for upgrading.

This is for the braves upgrading from RC5:

DROP FUNCTION xmin(box2d);
DROP FUNCTION xmax(box2d);
DROP FUNCTION ymin(box2d);
DROP FUNCTION ymax(box2d);
CREATE OR REPLACE FUNCTION postgis_scripts_installed() RETURNS text
        AS 'SELECT \'0.2.2\'::text AS version'
        LANGUAGE 'sql' IMMUTABLE;

Here are changes since RC5:

        - BUGFIX dumper 64bit
        - BUGFIX in multi()
        - early return [when noop] from multi()
        - dropped {x,y}{min,max}(box2d) functions

Ready for RC6 ?

--strk;


On Mon, Mar 28, 2005 at 12:23:16PM +0200, strk at refractions.net wrote:
> Just another thought...
> I think this issue requires far more time then expected 1.0.0 release
> time. I was thinking about this: why don't we drop box3d completely
> and have a box4d (4 doubles) instead ?
> 
> A box4d should be able to express non-existent 4th and 3rd ranges
> to be used as a box2d and box3d as well.
> 
> The box2d itself should also be dropped (both box3d and box2d would
> continue to exist but not from a user point of view).
> 
> In this way we can have a single box type for user view, which will
> be able to contain the cached BOX2DFLOAT4, and the computed BOX4D.
> 
> The BOX4D type would be the unique key type for use in queries
> (2d/3d/4d containment, overlap ops).
> 
> One problem I see with this is that users actually storing BOX3D in
> their column will see their table size grow... also I don't really
> like to have 3 types to maintain (and 2 are already too much).
> 
> The box2d type was intended to be used for smaller indexes, and maybe
> storing float values in the geometries was not a good idea also
> (comparing with double precision cache).
> 
> Well.. enough storming for today.
> 
> --strk;
> 
> 
> 
> On Mon, Mar 28, 2005 at 11:56:41AM +0200, strk at refractions.net wrote:
> > On Sun, Mar 27, 2005 at 11:16:27PM -0500, Carl Anderson wrote:
> > [ ... full quoting at end of mail ...]
> > > I believe the default should be to have more precision and reduced 
> > > precision should be explicit
> > > requests.  
> > 
> > What others think about this ?
> > 
> > SELECT min(xmin(geometry)) <-- should this do full geometries scan
> > 			       yelding double precision result or
> > 			       use cached bbox yelding single precision
> > 			       result ?
> > 
> > In any case I'd avoid adding another function like xmin2d(), but
> > rather add {x,y,z}{min,max}(geometry).
> > 
> > Note that a dump/reload will be needed to upgrade from RC5 to next
> > release if we make this change.
> > 
> > --strk;
> > 
> > On Sun, Mar 27, 2005 at 11:16:27PM -0500, Carl Anderson wrote:
> > > strk at refractions.net wrote:
> > > 
> > > >On Sat, Mar 26, 2005 at 05:34:46PM -0500, Carl Anderson wrote:
> > > > 
> > > >
> > > >>possibly too late in the development cycle for this discussion.
> > > >>   
> > > >>
> > > >
> > > >Indeed.
> > > >
> > > >I was not trying to convince you.
> > > >I do see the problem, but I was giving you more information.
> > > >The solution you suggest is a non-solution as a box2d::box3d
> > > >cast doesn't give you more precision. The precision issue
> > > >is not related to output but internal representation:
> > > >
> > > >=# select xmin('POINT(1.0000000001 0)'::geometry::box3d);
> > > >1.0000000001
> > > >=# select xmin('POINT(1.0000000001 0)'::geometry::box3d::box2d);
> > > >   1
> > > >=# select xmin('POINT(1.0000000001 0)'::geometry::box3d::box2d::box3d);
> > > >   1
> > > >
> > > >The first call is the only one giving you full precision.
> > > >
> > > >The question here is if we really want to keep support for BOX3D
> > > >for other then just an input type support (implicitly casting
> > > >to box2d for any operation, for example).
> > > >
> > > >--strk;
> > > > 
> > > >
> > > 
> > > but the behavior demonstrated is the same in the present and my pondered 
> > > states
> > > (I pondered renaming xmin(box2d) to xmin2d(box2d), and leaving xmin(box3d) )
> > > passing through box2d will reduce precision, as a feature of the box2d 
> > > type no
> > > matter what the precision of the desination type will be.
> > > 
> > > xmin(box3d) uses   BOX3D_xmin
> > > xmin(box2d)  casts box2d into box3d and flows into BOX3D_xmin
> > > xmin(box3d::box2d::box3d) casts box3d into box2d casted into box3d and 
> > > flows into BOX3D_xmin
> > > 
> > > I believe the default should be to have more precision and reduced 
> > > precision should be explicit
> > > requests.  As you demonstrated you can't add precision after removing it.
> > > 
> > > I yield to your judgement, and thank you for your consideration.
> > > 
> > > C.
> > > 
> > > _______________________________________________
> > > postgis-devel mailing list
> > > postgis-devel at postgis.refractions.net
> > > http://postgis.refractions.net/mailman/listinfo/postgis-devel
> > _______________________________________________
> > postgis-devel mailing list
> > postgis-devel at postgis.refractions.net
> > http://postgis.refractions.net/mailman/listinfo/postgis-devel
> _______________________________________________
> postgis-devel mailing list
> postgis-devel at postgis.refractions.net
> http://postgis.refractions.net/mailman/listinfo/postgis-devel