Opened 16 years ago
Last modified 16 years ago
#93 closed task (fixed)
ST_Extent() and ST_Estimated_Extent() return BOX2DFLOAT4s — at Version 7
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.
Change History (8)
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 |
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.