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;
BEGIN
retobj := ST_Extent(ageom);
RETURN retobj;
END;$BODY$
LANGUAGE 'plpgsql' IMMUTABLE
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)'));
st_extent
--------------
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'
LANGUAGE 'C' IMMUTABLE;
...
CREATE AGGREGATE ST_Extent(
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;
st_geomfromtext
-----------------
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...
ATB,
Mark.
--
Mark Cave-Ayland
Sirius Corporation - The Open Source Experts
http://www.siriusit.co.uk
T: +44 870 608 0063
_______________________________________________
postgis-users mailing list
[email protected]
http://postgis.refractions.net/mailman/listinfo/postgis-users
