[postgis-devel] getPoint2d_p

Paul Ramsey pramsey at cleverelephant.ca
Sat Dec 13 16:19:42 PST 2008


I'm looking at the simple distance calculating function, and I see this:

double lwgeom_pointarray_length2d(POINTARRAY *pts)
{
        double dist = 0.0;
        int i;
        POINT2D frm;
        POINT2D to;

        if ( pts->npoints < 2 ) return 0.0;
        for (i=0; i<pts->npoints-1;i++)
        {
                getPoint2d_p(pts, i, &frm);
                getPoint2d_p(pts, i+1, &to);
                dist += sqrt( ( (frm.x - to.x)*(frm.x - to.x) )  +
                                ((frm.y - to.y)*(frm.y - to.y) ) );
        }
        return dist;
}

That's simple enough... but what burns me is that getPoint2d_p does this:

int
getPoint2d_p(const POINTARRAY *pa, int n, POINT2D *point)
{
        memcpy(point, getPoint_internal(pa, n), sizeof(POINT2D));
        return 1;
}

We're just reading, why the memcpy? Sure, it's pretty darn fast, hand
optimized assembler by the gods of gcc and all that, but surely it
would nicer to just get a pointer into a structure.

All this derives from having our point arrays stored in "uchar
*serialized_pointlist" the primary advantage being ... ? Comments say
that we don't have to worry about 2/3/4D. OK, I can see that. But...
wouldn't an "double *pointlist" work even better? We could reference
into it with accessors just as currently, but we wouldn't need the
memcpy.

I'm still grasping at this stuff, deeper thoughts desperately wanted.

BTW, I'm doing a project that involves some simple computational
geometry and implementing some extra primitives native to PostGIS, and
building unit tests with cunit (I feel much more confident testing
each little block of code along the way). Unfortunately I'm building
against 1.3, which makes things well-nigh impossible. I think I might
have to flip this project around and develop on 1.4 using liblwgeom,
then back-port for the client, or I'll be spending all my time
scabbing bits of liblwgeom into my framework instead of working on the
actual code.

P.



More information about the postgis-devel mailing list