[postgis-users] Box2D on Postgis 1.0.0 RC1

[strk at refractions.net]

On Fri, Jan 28, 2005 at 03:02:43PM +0100, Hubert Fröhlich wrote:
> Hi list,
> 
> I am using PostgresQL 8.0.0 final, GEOS 2.1.1 and Postgis 1.0.0 RC1
> 
> Maybe the problem has gone with RC2, but I haven´t been able to get the 
> new release:
> 
> test1=# select box3d(geometryfromtext('POLYGON((-0.03 -0.03, -0.03 
> 12.03, 12.03 12.03, 12.03 -0.03, -0.03 -0.03))', 31494));
>                box3d
> ------------------------------------
>  BOX3D(-0.03 -0.03 0,12.03 12.03 0)
> (1 row)
> 
> so far ok, but ...
> 
> test1=# select box2d(geometryfromtext('POLYGON((-0.03 -0.03, -0.03 
> 12.03, 12.03 12.03, 12.03 -0.03, -0.03 -0.03))', 31494));
>                                      box2d 
> 
> --------------------------------------------------------------------------------
>  BOX(-0.0300000011920929 -0.0300000011920929,12.0300006866455 
> 12.0300006866455)
> (1 row)
> 
> 
> Can you fix it ( or is it already fixed) ?

It is untouched in RC2, and it's not a bug.

BOX2D use float values, BOX3D uses doubles.
An algorithm is used to ensure a BOX2D derived from a BOX3D
always covers an area at least as big. 15 decimal digits
output is forced on BOX2D output. 

Check these:

strk=# select box2d('BOX(0.4 -0.03,12.03 12.03)');
                                    box2d
------------------------------------------------------------------------------
 BOX(0.400000005960464 -0.0299999993294477,12.0299997329712 12.0299997329712)
(1 row)

As you can see your numbers, expressed in decimal form, when converted
to binary loose that 'roundness', in this case they become higher
for the "min" values and lower for the "max" values, practically resulting
in a smaller area.


strk=# select box2d('BOX3D(0.4 -0.03 0,12.03 12.03 0)'::box3d);
                                    box2d
------------------------------------------------------------------------------
 BOX(0.399999976158142 -0.0300000011920929,12.0300006866455 12.0300006866455)
(1 row)

Here the algorithm ensured the BOX2D actually covers at least the area
covered by the input BOX3D.

If we didn't force 15 decimal digits users would not notice this,
and maybe that would be a good thing. How many users care about precision
of the text form for BOX3D and BOX2D ?

--strk;


> 
> Greetings,
> Hubert
> 
> 
> -- 
> -------------------------------------------------------------------------------
> Dr.-Ing. Hubert Fröhlich			
> Bezirksfinanzdirektion München 			
> Alexandrastr. 3, D-80538 München, GERMANY
> Tel. :+49 (0)89 / 2190 - 2980
> Fax  :+49 (0)89 / 2190 - 2997
> hubert dot froehlich at bvv dot bayern dot de
> _______________________________________________
> postgis-users mailing list
> postgis-users at postgis.refractions.net
> http://postgis.refractions.net/mailman/listinfo/postgis-users