[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