[postgis-devel] Updates to GEOS & POSTGIS
Mark Cave-Ayland
mark.cave-ayland at ilande.co.uk
Fri Jan 18 00:41:13 PST 2008
On Thu, 2008-01-17 at 17:07 -0800, Ben Jubb wrote:
> Hi all,
> I've checked in some changes to GEOS & PostGIS, All changes are in the
> pursuit of getting prepared geometry (from JTS 1.9) into PostGIS.
>
> First in GEOS:
> exposed the prepared geometry objects in the CAPI, bumping the version
> of CAPI to 1.5.0.
> fixed a few small problems in the GEOS code.
>
> Then in PostGIS:
> Added new functions to lwgeom_geos_c.c to support prepared geometry
> predicates.
> bool containsPrepared( geom, geom)
> bool containsProperlyPrepared( geom, geom)
> bool coversPrepared( geom, geom)
> bool intersectsPrepared( geom, geom)
>
> These functions require a caching mechanism to retain some state between
> calls. All of these functions work the same way. The first argument is
> checked every time to see if its been seen before. If so, the geometry
> argument is prepared and cached, if it hasn't been already. Subsequent
> calls to these predicate functions with the same first argument will use
> the cached prepared geometry to do the test, potentially saving a lot of
> time.
>
> These functions only show improvements when the first (or both)
> argument(s) is(are) fairly large objects (>1000 points or so). The
> caching overhead wipes out any gains with smaller objects.
>
> The functions are exposed to PostgreSQL via these wrappers:
> ST_ContainsPrepared( geometry, geometry )
> ST_ContainsProperlyPrepared( geometry, geometry )
> ST_CoversPrepared( geometry, geometry )
> ST_IntersectsPrepared( geometry, geometry )
>
> as well, this function was added, for orthogonality:
> ST_ContainsProperly( geometry, geometry )
>
>
> Hopefully somebody has a big polygon and thousands of geometries to test
> against that polygon. This should make things happen a bit quicker.
> Hopefully alot quicker.
>
> cheers
> b
Hi Ben,
An interesting commit - it will be fascinating to see exactly how much
this will speed up these types of operations.
I had a quick look at your commit out of curiosity, and noted the
following things that might be worth looking at:
- Use of C++ (//) comments
I seem to remember that strk had to go through and change all //
comments to /*..*/ comments to get PostGIS to compile on some of the
more strict C compiler platforms - it may be worth changing these over.
- Missing initGEOS() call
Unlike the existing PostGIS functions that use GEOS, there is no
initGEOS call within the function.
- Size calculation
I noticed that in your code, you use the following to find out the size
of the geometry:
arg1_length = toast_raw_datum_size(PG_GETARG_DATUM(0)) - VARHDRSZ;
I think that since the Datum is detoasted into geom1, you should be able to use
the following a bit lower down instead (which should be more future-proof):
arg1_length = VARSIZE(geom1) - VARHDRSZ;
HTH,
Mark.
--
ILande - Open Source Consultancy
http://www.ilande.co.uk
More information about the postgis-devel
mailing list