Opened 6 years ago

Closed 6 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:


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

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 6 years ago.

Download all attachments as: .zip

Change History (9)

Changed 6 years ago by sdikiy

comment:1 in reply to: ↑ description Changed 6 years ago by sdikiy

Replying to sdikiy:

see attach for more results

line 32: must be FALSE

line 47 and 54 must be same

comment:2 follow-up: Changed 6 years ago by robe

  • Resolution set to invalid
  • Status changed from new to closed


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.

comment:3 in reply to: ↑ 2 Changed 6 years ago by sdikiy

Replying to robe:


Which version of PostgreSQL are you running?

Do a

SELECT version();

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

GIS_TEST=# SELECT 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');
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 Changed 6 years ago by robe

  • Milestone set to PostGIS 1.4.2
  • Resolution invalid deleted
  • Status changed from closed to reopened

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 Changed 6 years ago by sdikiy

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 Changed 6 years ago by robe

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);

Like we have for LWGEOM_affine

comment:7 Changed 6 years ago by robe

Forgot and of course release tmp memory afterward.

comment:8 Changed 6 years ago by pramsey

  • Resolution set to fixed
  • Status changed from reopened to closed

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.