[postgis-users] box2d return from function!

Mark Cave-Ayland mark.cave-ayland at siriusit.co.uk
Fri Jun 27 05:48:41 PDT 2008

Obe, Regina wrote:
> Dan,
> Okay I'm confused.  I tried this and it worked fine in both 8.2 1.3.3
> and 8.3 1.3.3
> CREATE OR REPLACE FUNCTION fntestbox2d(ageom geometry)
>   RETURNS box2d AS
> $BODY$
> DECLARE retobj box2d;
> 	retobj := ST_Extent(ageom);
> 	RETURN retobj;
> What are you trying to do?  the cast from box to box2d as Mark noted is
> a limitation of some sort.
> Thanks,
> Regina  

Sorry, perhaps I wasn't too clear in my previous email. What I mean is 
that the output below is totally wrong:

postgis=# select st_extent(st_geomfromtext('POINT(0 0)'));
  BOX(0 0,0 0)
(1 row)

Now the problem stems from the definition here in lwpostgis.sql:

CREATE OR REPLACE FUNCTION ST_Combine_BBox(box2d,geometry)
         RETURNS box2d
         AS '$libdir/lwpostgis', 'BOX2DFLOAT4_combine'


         sfunc = ST_combine_bbox,
         basetype = geometry,
         stype = box2d

This means that the extent is being calculated using internal BOX2Ds 
which means we are *rounding up* each individual value from double to 
single precision - hence we are immediately introducing errors in the 
extent calculation :(

What is then even worse is that the BOX2D input/output routines use the 
output prefix "BOX" rather than BOX2D which becomes clearer with the 
below example:

postgis=# select st_geomfromtext('POINT(0 0)')::box2d;
  BOX(0 0,0 0)
(1 row)

So it is almost too easy to get confused between PostGIS and the 
PostgreSQL native BOX type which is really not good. The solution would 
be to change the stype to box3d to make the calculation result correct, 
and then change the output type. I'd be quite tempted to make ST_Extent 
return a POLYGON geometry in the SVN head...



Mark Cave-Ayland
Sirius Corporation - The Open Source Experts
T: +44 870 608 0063

More information about the postgis-users mailing list