Opened 14 years ago

Closed 13 years ago

#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: master
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?

Change History (2)

comment:1 by strk, 13 years ago

Keywords: boxes added

comment:2 by strk, 13 years ago

Resolution: fixed
Status: newclosed

Current response is:

 wktint | ektint | ektdint | wktbox | ewktbox | binaryequal 
--------+--------+---------+--------+---------+-------------
 f      | f      | f       |        |         | t

I guess it means this is fixed (although puzzling in that two bit-wise equal geometries do not overlap, but that's another story)

Note: See TracTickets for help on using tickets.