[postgis-devel] PostGIS release

Michael Fuhr mike at fuhr.org
Thu Jul 12 18:49:31 PDT 2007


On Thu, Jul 12, 2007 at 06:37:44PM -0600, Michael Fuhr wrote:
> On Thu, Jul 12, 2007 at 06:49:02PM +0100, Mark Cave-Ayland wrote:
> > As for the regress_ogc results, Mike posted them on the list here:
> > http://postgis.refractions.net/pipermail/postgis-devel/2007-July/002621.html.
> 
> I posted additional test cases here:
> 
> http://postgis.refractions.net/pipermail/postgis-devel/2007-July/002633.html

I think I've tracked down what's happening.  If I define PGIS_DEBUG
I get the following:

findLineSegments 0x83f7cb8: not contained

This comes from lines 236ff in lwgeom/lwgeom_rtree.c:

        if(!isContained(root->interval, value))
        {
#ifdef PGIS_DEBUG
                lwnotice("findLineSegments %p: not contained.", root);
#endif
                return NULL;
        }

Later in the same file we find isContained():

uint32 isContained(INTERVAL *interval, double value)
{
        return FP_CONTAINS_INCL(interval->min, value, interval->max) ? 1 : 0;
}

Here's a test program using the relevant macros from lwgeom/liblwgeom.h:

#include <stdio.h>
#include <stdlib.h>

#define PGIS_EPSILON 1e-12
#define FP_LTEQ(A, B) ((A - PGIS_EPSILON) < B)
#define FP_CONTAINS_INCL(A, X, B) (FP_LTEQ(A, X) && FP_LTEQ(X, B))

int
main(int argc, char *argv[])
{
    double  a, x, b;

    if (argc != 4) {
        fprintf(stderr, "Syntax: %s a x b\n", argv[0]);
        return 1;
    }

    a = atof(argv[1]);
    x = atof(argv[2]);
    b = atof(argv[3]);

    printf("FP_CONTAINS_INCL(%f, %f, %f) = %d\n", a, x, b, FP_CONTAINS_INCL(a, x, b));

    return 0;
}

Here are a couple of test runs:

./pgis-test 16384 16384 16385
FP_CONTAINS_INCL(16384.000000, 16384.000000, 16385.000000) = 1

./pgis-test 16384.0001 16384.0001 16385
FP_CONTAINS_INCL(16384.000100, 16384.000100, 16385.000000) = 0

When A gets large enough, A - PGIS_EPSILON requires more precision
than available to be distinguishable from A, so A - PGIS_EPSILON
equals A and is no longer less than B.

-- 
Michael Fuhr



More information about the postgis-devel mailing list