[postgis-devel] [PostGIS] #410: ST_SetPoint and bounding box

[PostGIS]

#410: ST_SetPoint and bounding box
-----------------------+----------------------------------------------------
  Reporter:  sdikiy    |       Owner:  pramsey      
      Type:  defect    |      Status:  reopened     
  Priority:  critical  |   Milestone:  PostGIS 1.4.2
 Component:  postgis   |     Version:  1.4.X        
Resolution:            |    Keywords:  ST_SetPoint  
-----------------------+----------------------------------------------------
Changes (by robe):

  * status:  closed => reopened
  * resolution:  invalid =>
  * milestone:  => PostGIS 1.4.2

Comment:

 Okay I stand corrected.  I thought this was a bug in PostgreSQL, but not
 sure now.  I can recreate it what you are experiencing.

 On my "PostgreSQL 8.4.2, compiled by Visual C++ build 1400, 32-bit"  and
 "PostgreSQL 8.3.7, compiled by Visual C++ build 1400"  (running latest
 1.4.2 SVN)

 However, seems to behave fine on my 1.5.0SVN version (haven't upgraded
 that to 1.5.0 official yet).

 The reason I thought it was a PG bug was I ran into this same exact
 problem with a trigger on 64-bit Linux.  My hack solution was to do this
 in 1.3/1.4 (for 1.5 the nems of these functions have been changed to
 PostGIS_AddBBox..):

 {{{
 UPDATE foo SET the_geom= ST_DropBBox(the_geom);
 UPDATE foo SET the_geom=ST_AddBBOx(the_geom);

 SELECT st_astext(ST_Box2D(the_geom)), st_astext(ST_Envelope(the_geom2))
 FROM foo;
 }}}

 Anyrate its a bbox caching problem and given my 1.5 is not exhibiting this
 behavior (though I could just be lucky for some reason or its
 intermittent), seems like it could be  PostGIS bug.

 We'll have to check the 1.3 series as well since tha's the version I
 experienced this problem.

-- 
Ticket URL: <http://trac.osgeo.org/postgis/ticket/410#comment:4>
PostGIS <http://trac.osgeo.org/postgis/>
The PostGIS Trac is used for bug, enhancement & task tracking, a user and developer wiki, and a view into the subversion code repository of PostGIS project.