LWGEOM_expand produces inconsistent results

[alexz]

# 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?
t	f

(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

[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.

[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?

[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.

[alexz]

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

[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.

[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.

[strk]

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

[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.

[mcayland]

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