Ticket #749 (closed defect: fixed)
Bounding Box calculation disagrees with cached bounding box ST_GeomFromText/ST_GeomFromEWKT weirdness
| Reported by: | robe | Owned by: | pramsey |
|---|---|---|---|
| Priority: | medium | Milestone: | PostGIS 2.0.0 |
| Component: | postgis | Version: | trunk |
| Keywords: | boxes | Cc: |
Description
I don't know if this is limited to empty geometries or not, but there seems to be something whether bizarre going on with cached vs. non-cached boxes. Botht he gserialized and non-gserialized (current) display some suspicious behavior though the behavior is different:
SELECT foo1.wktgeom && foo1.wktgeom As wktint, foo1.ewktgeom && foo1.ewktgeom As ektint, PostGIS_DropBBOX(foo1.ewktgeom) && PostGIS_DropBBOX(foo1.ewktgeom) As ektdint,
Box2d(foo1.wktgeom) as wktbox,Box2d(foo1.ewktgeom) as ewktbox,
foo1.wktgeom::bytea = foo1.ewktgeom::bytea As binaryequal
FROM (
(SELECT ST_GeomFromText('GEOMETRYCOLLECTION EMPTY') As wktgeom,
ST_GeomFromEWKT('GEOMETRYCOLLECTION EMPTY') As ewktgeom )
) As foo1 ;
-- with gserialized enabled the output of the above is: (note the boxes are NULL which I guess is fine) wktint | ektint | ektdint | wktbox | ewktbox | binaryequal
f | t | f | | | t
NOTE: The difference between ektint (this is with the cached bounding box), and ektdint -- when I drop the cached bounding box I get a different answer (which agrees with the ST_GeomFromText answer).
-- with gserialized off (our current svn) --
wktint | ektint | ektdint | wktbox | ewktbox | binaryequal
t | t | f | BOX(0 0,0 0) | BOX(0 0,0 0) | t
I assume I should not be concerned that the bounding boxes of serialzed vs. gserialized are at odds?
