Opened 15 years ago

Closed 15 years ago

#410 closed defect (fixed)

ST_SetPoint and bounding box

Reported by: sdikiy Owned by: pramsey
Priority: critical Milestone: PostGIS 1.4.2
Component: postgis Version: 1.4.X
Keywords: ST_SetPoint Cc:

Description

ST_SetPoint return old bounding box for geometry.
as a result:

(1)
INSERT INTO foo(the_geom) VALUES (ST_GeomFromText('LINESTRING(0 0, 1 3)'));
select the_geom=ST_SetPoint(the_geom, 0, 'POINT(100000 200000)') from foo;
Returns TRUE. Must be FALSE

see attach for more results

Attachments (1)

ST_SetPoint_AND_BB.txt (1.8 KB ) - added by sdikiy 15 years ago.

Download all attachments as: .zip

Change History (9)

by sdikiy, 15 years ago

Attachment: ST_SetPoint_AND_BB.txt added

in reply to:  description comment:1 by sdikiy, 15 years ago

Replying to sdikiy:

see attach for more results

line 32: must be FALSE

line 47 and 54 must be same

comment:2 by robe, 15 years ago

Resolution: invalid
Status: newclosed

sdikiy,

Which version of PostgreSQL are you running?

Do a

SELECT version();

I believe the error you are experiencing is not a PostGIS bug, but a PostgreSQL bug that was fixed in later versions of PostgreSQL.

If you are running PostgreSQL 8.3, make sure you are running 8.3.7 or above. You should preferably be running the latest version 8.3.9. For PostgreSQL 8.4, you should be running 8.4.1 or 8.4.2.

in reply to:  2 comment:3 by sdikiy, 15 years ago

Replying to robe:

sdikiy,

Which version of PostgreSQL are you running?

Do a

SELECT version();

GIS_TEST=# SELECT version();
                           version
-------------------------------------------------------------
 PostgreSQL 8.4.1, compiled by Visual C++ build 1400, 32-bit
(1 row)

GIS_TEST=# SELECT PostGIS_Full_Version();
                                postgis_full_version
-------------------------------------------------------------------------------------
 POSTGIS="1.4.0" GEOS="3.1.1-CAPI-1.6.0" PROJ="Rel. 4.6.1, 21 August 2008" USE_STATS
(1 row)

Robe, if you have 5 minutes time, please do it and send the result

SELECT version();
SELECT PostGIS_Full_Version();
SELECT DropGeometryColumn( 'foo', 'the_geom');
SELECT DropGeometryColumn( 'foo', 'the_geom2');
DROP TABLE foo;
CREATE TABLE foo ()WITH (OIDS = TRUE);
SELECT AddGeometryColumn( 'foo', 'the_geom', -1, 'LINESTRING', 2);
SELECT AddGeometryColumn( 'foo', 'the_geom2', -1, 'LINESTRING', 2);
INSERT INTO foo(the_geom, the_geom2) VALUES (ST_GeomFromText('LINESTRING(0 0, 1 3)'), ST_GeomFromText('LINESTRING(0 0, 1 3)'));
UPDATE foo SET the_geom=ST_SetPoint(the_geom, 0, 'POINT(100000 200000)');
SELECT st_astext(the_geom), st_astext(the_geom2) FROM foo;
SELECT st_astext(ST_Envelope(the_geom)), st_astext(ST_Envelope(the_geom2)) FROM foo;

comment:4 by robe, 15 years ago

Milestone: PostGIS 1.4.2
Resolution: invalid
Status: closedreopened

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.

comment:5 by sdikiy, 15 years ago

this is a very old problem. I found it 3-4 years ago. :-(

 PostgreSQL 8.2.4 on i686-pc-mingw32, compiled by GCC gcc.exe (GCC) 3.4.2 (mingw-special)
 POSTGIS="1.1.6" GEOS="2.2.3-CAPI-1.1.1" PROJ="Rel. 4.5.0, 22 Oct 2006" USE_STATS

comment:6 by robe, 15 years ago

Okay I think I isolated the issue in the code, though am afraid to change anything since I'm not sure the ramifications and where else this is an issue. Besides don't have my development environment currently available.

In the LWGEOM_affine, we recalculate the bounding box, but that logic seems to be missing in the LWGEOM_setpoint_linestring function. I'm guessing we need to replace 3184 with a : LWGEOM *tmp; tmp = pglwgeom_deserialize(geom); lwgeom_drop_bbox(tmp); tmp→bbox = lwgeom_compute_box2d(tmp); result = pglwgeom_serialize(tmp);

http://postgis.refractions.net/documentation/postgis-doxygen/d3/dcc/lwgeom__functions__basic_8c_78f265e0836ad97219c91d2c7f6dac2f.html#78f265e0836ad97219c91d2c7f6dac2f

Like we have for LWGEOM_affine http://postgis.refractions.net/documentation/postgis-doxygen/d3/dcc/lwgeom__functions__basic_8c_4493fb570acc2219101e6308bdc2662e.html#4493fb570acc2219101e6308bdc2662e

comment:7 by robe, 15 years ago

Forgot and of course release tmp memory afterward.

comment:8 by pramsey, 15 years ago

Resolution: fixed
Status: reopenedclosed

Fix applied to 1.4 (r5382), 1.5 (r5383), trunk (r5384). Change should fix ST_SetPoint, ST_AddPoint, ST_RemovePoint.

Note: See TracTickets for help on using tickets.