[postgis-devel] RC5 problem

strk at refractions.net strk at refractions.net
Sun Mar 27 14:42:11 PST 2005


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;


> strk at refractions.net wrote:
> 
> >This should be the behaviour since RC1.
> >Note that box3d is double precision, while box2d is
> >single precision. So you can choose which one to use.
> >Example:
> >
> >strk=# select xmin('POINT(1.0000000001 0)'::geometry::box3d);
> >    xmin
> >--------------
> >1.0000000001
> >(1 row)
> >
> >strk=# select xmin('POINT(1.0000000001 0)'::geometry::box2d);
> >xmin
> >------
> >   1
> >(1 row)
> > 
> >
> 
> I am willing to be convinced ... but
> 
> If xmin (<box3d>) existed
> and xmin(<box3d>) was removed
> 
> the same result could be accomplished by
> 
> select xmin('POINT(1.0000000001 0)'::geometry);
>     xmin
> --------------
> 1.0000000001
> (1 row)
> 
> 
> and using the implicit box2d -> box3d cast
> select xmin('POINT(1.0000000001 0)'::geometry::box2d);
> 
> xmin
> ------
>    1
> (1 row)
> 
> 
> you can still choose the precision level and undiscriminating users just 
> get an answer without thinking.
> 
> >Also note that geometry::box3d always *computes* the bounding
> >box while geometry::box2d uses the bbox cache if available
> >(which is the single-precision version).
> >
> > 
> >
> There are obviously internal performance issues that effect the 
> backend.  I am (in this discussion)
> thinking about userspace where in 0.9 and prior versions they could use 
> xmin(<geometry>) and now must
> declare a casting type.  Code will be broken, someone will have to 
> explain what changed, why it
> changed and how to correct the code.  Could'nt the internal issues be 
> dealt with a
> private function or xmin2d() and leave the user experience as similar as 
> possible to prior versions.
> 
> To me this is different from the QGIS issue, as geometry() is part of 
> the OGC SF-SQL spec and
> rejecting non conforming WKT is good.  xmin() and its kin are vendor 
> specific extensions
> so you have more latitude.
> 
> C.
> 
> _______________________________________________
> postgis-devel mailing list
> postgis-devel at postgis.refractions.net
> http://postgis.refractions.net/mailman/listinfo/postgis-devel



More information about the postgis-devel mailing list