Opened 6 years ago

Closed 6 years ago

#581 closed defect (fixed)

LWGEOM_expand produces inconsistent results

Reported by: alexz Owned by: mcayland
Priority: high Milestone: PostGIS 1.5.2
Component: postgis Version: 1.5.X
Keywords: Cc:

Description

# SELECT dropbbox(ST_expand(setsrid(makepoint(-122.50367,37.74189),4326), 0.00004)) && dropbbox(ST_expand(setsrid(makepoint(-122.50376,37.74185),4326), 0.00004)), ST_expand(setsrid(makepoint(-122.50367,37.74189),4326), 0.00004) && ST_expand(setsrid(makepoint(-122.50376,37.74185),4326), 0.00004);

?column??column?
tf

(1 row)

See also:

http://postgis.refractions.net/pipermail/postgis-users/2010-September/027614.html http://archives.postgresql.org/pgsql-bugs/2010-08/msg00361.php

Attachments (1)

postgis-ptarray-compute-box2d.patch (1.1 KB) - added by mcayland 6 years ago.

Download all attachments as: .zip

Change History (11)

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

Just a wild guess, but I suspect this is the same issue as we resolved in #410

that the cached box is not being recalculated during st_expand call.

comment:2 in reply to: ↑ 1 Changed 6 years ago by alexz

Replying to robe:

Just a wild guess, but I suspect this is the same issue as we resolved in #410

that the cached box is not being recalculated during st_expand call.

Perhaps, but I doubt it. I saw this problem with 1.5.2 (r5851 & r5885) and trunk (r5889). Potentially #410 wasn't actually corrected?

comment:3 Changed 6 years ago by robe

that's not quite what I meant. I meant its the same class of a problem and similar fix applied in #410 would fix this as well.

comment:4 Changed 6 years ago by alexz

In which case, yes, it sure seems like a similar problem.

comment:5 Changed 6 years ago by mcayland

Okay - Alex, please can you try the attached patch?

The culprit in this scenario appears to be ptarray_compute_box2d() introducing errors into the BOX2DFLOAT4 bounding box cache. Currently the function works by converting each point from double to single precision and then comparing the extents with the current bounding box to expand it as required. Unfortunately this has the side effect of introducing cumulative errors into the bounding box which is why the incorrect answer is given.

The attached patch works by performing the entire calculation using full precision BOX3D and then converting to BOX2DFLOAT4 at the end.

Paul, Regina & Kevin - I've tested this patch against 1.5 and trunk and it appears to pass all regression tests for me. I'd like to get this into 1.5.2 if Alex agrees that this resolves his issue.

Mark.

Changed 6 years ago by mcayland

comment:6 Changed 6 years ago by alexz

That patch doesn't change the results of the query in the body of the bug report for me.

Because I had to blow away the database for other reasons I took the following steps:

Patch postgis. Install postgis. Restart postgres. Create new database with SQL files from the postgis install. Run said query. One column is true, one false.

comment:7 Changed 6 years ago by strk

The patch works fine here. alexz: make sure to rebuild (make clean).

comment:8 Changed 6 years ago by alexz

As an aside, 'make clean' fails in one of the documentation directories. Whoops.

So I ran make -k clean, rebuilt, and it passes the query above.

comment:9 Changed 6 years ago by mcayland

  • Owner changed from pramsey to mcayland

comment:10 Changed 6 years ago by mcayland

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

Thanks for testing the patch. I've applied a modified version to trunk as r5923, 1.5 as r5924 and 1.4 as r5925.

Note: See TracTickets for help on using tickets.