[postgis-users] Box2D on Postgis 1.0.0 RC1

[Hubert Fröhlich]

Hi strk,


> 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 ?
> 

Thanks for the clarification. Maybe you could add some sentence to the 
docs?

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