[postgis-devel] RC5 problem
carl.anderson at vadose.org
Sun Mar 27 20:16:27 PST 2005
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.
>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);
>=# select xmin('POINT(1.0000000001 0)'::geometry::box3d::box2d);
>=# select xmin('POINT(1.0000000001 0)'::geometry::box3d::box2d::box3d);
>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).
but the behavior demonstrated is the same in the present and my pondered
(I pondered renaming xmin(box2d) to xmin2d(box2d), and leaving xmin(box3d) )
passing through box2d will reduce precision, as a feature of the box2d
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.
More information about the postgis-devel