[postgis-users] Problems with geometry's after "translate"

Mark Cave-Ayland mark.cave-ayland at ilande.co.uk
Tue Aug 29 05:07:21 PDT 2006


On Tue, 2006-08-29 at 08:52 -0300, Antonio Grassi wrote:
> Hello. I've come across a strange situation. It would be very helpfull
> if someone out there could give me an idea of what's going on. Here is
> a sequence of SQL commands issued directly through 'psql' to the
> Postgres server. 
> 
> 1) INSERT INTO table(gid,the_geom)
> VALUES(1,geometryFromText('LINESTRING(583945 6137700, 583945
> 6137690)',-1));
> 
> 2) SELECT gid,asText(the_geom) FROM table WHERE the_geom &&
> geometryFromText('POLYGON((583943 6137697, 583947 6137697, 583947
> 6137693, 583943 6137693, 583943 6137697))',-1); 
> 
> This works as expected, and the geometry I've just created in step 1
> is listed in the results.
> 
> gid |                  astext
> ----+-------------------------------------------
> 1    | LINESTRING(583945 6137700,583945 6137690) 
> 
> 
> 3) UPDATE table SET the_geom = translate(the_geom, 10, 0, 0) WHERE gid
> = 1;
> 
> 4) SELECT gid,asText(the_geom) FROM table WHERE gid = 1;
> 
> gid |                  astext
> ----+------------------------------------------- 
> 1    | LINESTRING(583955 6137700,583955 6137690)
> 
> Well, finally, I try to repeat step 2 with a new polygon to again
> select that record.
> 
> 5) SELECT gid,asText(the_geom) FROM table WHERE the_geom &&
> geometryFromText('POLYGON((583953 6137697, 583957 6137697, 583957
> 6137693, 583953 6137693, 583953 6137697))',-1); 
> 
> gid | astext
> ----+--------
> (0 rows)
> 
> 
> If there isn't something I'm understanding bad, the final step should
> have retorned me the record created in step 1 and moved in step 3.
> I've tried this with different geometrys, and it's the same. After
> using 'translate' over the geometry, it's not accessible anymore using
> the '&&' operator. It doesn't work neither if using 'intersects'
> instead of '&&'. 
> 
> I'm using postgres 8.1.4 and postgis 1.1.2. I've using postgres
> +postgis for a pair of years, and this is the first time I've seen
> this occur.
> 
> Well, thanks very much,
> Antonio Grassi


Hi Antonio,

I believe that this may have been caused by the affine() bounding box
bug which should have been fixed in PostGIS 1.1.3 - can you upgrade to
the 1.1.3 release and let us know if the problem still exists?


Kind regards,

Mark.






More information about the postgis-users mailing list