Okay I remember now why I had a before trigger because I needed to update the data before it hits the database and so I put that trigger back as a before, but I added A dropbbox, addbbox to it. The reason disabling it allowed me from adding the BBOX before was for a duh reason. I have the trigger set to deal with tolerance issues, so feeding in the same geometry or within a tolerance does nothing.
Anyrate in my lab tests this seems to be working, but holding my breath for field results to come back. I'm still puzzled why anything I am doing would be interfering with cache box setting. At first I thought maybe PostGIS is using some sort of index trigger to set the box2d, but in hindsight I don't see why it would need to since every function call I do (e.g. mostly translates and set points) seems to return with a ST_HasBBOX = true and box is different from whats in the db. So I assume all functions must slap on a recalculated BBOX. Am I wrong in that assumption? Thanks, Regina -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Paragon Corporation Sent: Friday, November 07, 2008 10:40 PM To: 'PostGIS Users Discussion' Subject: RE: [postgis-users] Strange problem with && Mark, If I do a BOX3D check, the answers agree. I assume that is because only the box2d is cached and the BOX3D is always calculated from scratch? So it does seem to be a trigger issue interfering with the cache_box logic. The only geometries affected as afar as I can tell are those moved as a part of the triggers. I thought I had fixed it, but turns out moving my first trigger to be an after just allowed me to fix the defective cached boxes but the problem still continues as people move things. I have a transaction log table that keeps track of trigger edits - and doing a sampling of one SELECT ST_Box2D(ST_AsHexEWKB(old_the_geom)) As old_calcbbox, ST_Box2d(old_the_geom) As old_storedbbox, ST_Box2d(the_geom) As new_storedbbox, ST_Box2D(ST_AsHexEWKB(the_geom)) As newcalcbbox , ST_Box3D(the_geom) As new3dbox FROM us.edge_trans WHERE trans_id = 446 ---See how the stored bbox is the same as what the original was before the move. Old_calcbox: BOX(-9735475 5010606,-9735186 5010845) Old_storedbox: BOX(-9735475 5010606,-9735186 5010845) New_storedbox: BOX(-9735475 5010606,-9735186 5010845) New_calcbox: BOX(-9735475 5010606,-9735172 5010845) New_3dbox BOX3D(-9735474.33497473 5010606.13458183 0,-9735172.74302071 5010844.6196023 0) So I guess maybe I'll try just have to put in yet another step at the end that sets a new bbox if the cached is wrong. Thanks, Regina -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Mark Cave-Ayland Sent: Friday, November 07, 2008 9:54 AM To: PostGIS Users Discussion Subject: Re: [postgis-users] Strange problem with && Paragon Corporation wrote: > I thought maybe this was a bug in GIST from before my upgrade, so I > dropped my gist index on the affected table and readded it and still > get the same bizarre behavior. Hi Regina, Does changing ST_box2d() to ST_box3d() help at all? ATB, Mark. -- Mark Cave-Ayland Sirius Corporation - The Open Source Experts http://www.siriusit.co.uk T: +44 870 608 0063 _______________________________________________ postgis-users mailing list [email protected] http://postgis.refractions.net/mailman/listinfo/postgis-users _______________________________________________ postgis-users mailing list [email protected] http://postgis.refractions.net/mailman/listinfo/postgis-users _______________________________________________ postgis-users mailing list [email protected] http://postgis.refractions.net/mailman/listinfo/postgis-users
