[postgis-devel] xmin(geometry) behaviour

[strk at refractions.net]

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