[postgis-devel] Issue 93 in postgis: ST_Extent() and ST_Estimated_Extent() return BOX2DFLOAT4s

[codesite-noreply at google.com]

Updates:
	Status: Testing

Comment #1 on issue 93 by mark.cav... at siriusit.co.uk: ST_Extent() and  
ST_Estimated_Extent() return BOX2DFLOAT4s
http://code.google.com/p/postgis/issues/detail?id=93

Fix committed to SVN trunk.

Changing the aggregate function from BOX2DFLOAT4 to BOX3D is the easy part,  
since the
routines already exist for ST_Extent3D(). The hard part is that if we use a  
box3d to
output the extent, then we would change the output from:

BOX(x y, x y)

to:

BOX3D(x y z, x y z)

Since this string is likely parsed by client applications, we need a way to  
preserve
the output format. I've done this by introducing a new SQL type called  
box3d_extent
which is only used by ST_Extent() that uses the same output formats. This  
is only a
temporary hack until we move to the next major version...

ST_Estimated_Extent() we are not too worried about the accuracy since it is  
based on
sampling so I have left this - but when we change the format for  
ST_Extent() in the
future, we should do the same here too.


--
You received this message because you are listed in the owner
or CC fields of this issue, or because you starred this issue.
You may adjust your issue notification preferences at:
http://code.google.com/hosting/settings