[postgis-users] Strange problem with &&

[Paragon Corporation]

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: postgis-users-bounces at postgis.refractions.net
[mailto:postgis-users-bounces at postgis.refractions.net] 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: postgis-users-bounces at postgis.refractions.net
[mailto:postgis-users-bounces at postgis.refractions.net] 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
postgis-users at postgis.refractions.net
http://postgis.refractions.net/mailman/listinfo/postgis-users



_______________________________________________
postgis-users mailing list
postgis-users at postgis.refractions.net
http://postgis.refractions.net/mailman/listinfo/postgis-users