Opened 16 years ago
Closed 15 years ago
#93 closed task (fixed)
ST_Extent() and ST_Estimated_Extent() return BOX2DFLOAT4s
Reported by: | mcayland | Owned by: | mcayland |
---|---|---|---|
Priority: | medium | Milestone: | PostGIS 1.4.0 |
Component: | postgis | Version: | 1.4 |
Keywords: | Cc: |
Description (last modified by )
In the case of ST_Extent(), this is serious because it means that ST_Extent(col) will never return the exact extent of a column - it will always be inflated by a small amount due to the extra conversion between BOX3D and BOX2DFLOAT4.
- BOX2DFLOAT4s should never be exposed to the user, especially in that
ST_Extent() returns a string containing BOX (a legacy PostgreSQL type) rather than BOX3D *
ST_Estimated_Extent() should also return a string beginning 'BOX3D' for the same reason.
Attachments (1)
Change History (9)
comment:1 by , 16 years ago
comment:2 by , 16 years ago
box3d_extent is not recognize by other Postgis function who already are able to deal with box3d
SELECT ST_Extent('surfaceProperty') FROM 'PrimitiveGeoFeature'; BOX(45.174 30.466,45.891 30.899)
SELECT ST_MAX(ST_Extent('surfaceProperty')) FROM 'PrimitiveGeoFeature'; ERROR: function st_max(box3d_extent) does not exist
SELECT ST_MAX(ST_Extent('surfaceProperty')::box2d) FROM 'PrimitiveGeoFeature'; ERROR: cannot cast type box3d_extent to box2d
comment:3 by , 16 years ago
I've just committed the missing casts to trunk as r3938 which should resolve the issue. Please can you test?
ATB,
Mark.
comment:4 by , 16 years ago
Mark,
On PostgreSQL 8.3.7 postgis.sql load end on error.
⇒box2d function not yet defined in the new cast
I join a patch on postgis.sql.in.c who do the job on my box
And then with you're new cast, that's look good :
SELECT ST_XMAX(ST_Extent('surfaceProperty')::box2d) FROM 'PrimitiveGeoFeature'; 45.8910026550293
SELECT ST_XMAX(ST_Extent('surfaceProperty')) FROM 'PrimitiveGeoFeature'; 45.891
— Olivier
comment:5 by , 16 years ago
Ooops - looks like I was using the wrong version of postgis.sql for testing Can you test SVN trunk now?
ATB,
Mark.
by , 16 years ago
Attachment: | DIFF_r3938 added |
---|
comment:7 by , 16 years ago
Description: | modified (diff) |
---|---|
Priority: | → medium |
comment:8 by , 15 years ago
Resolution: | worksforme → fixed |
---|---|
Status: | assigned → closed |
Since no-one else has found any more bugs with the additional casts in place, I'm marking this as fixed.
ATB,
Mark.
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.