[postgis-devel] Updates to GEOS & POSTGIS

Ben Jubb benjubb at refractions.net
Fri Jan 18 09:26:52 PST 2008



Mark Cave-Ayland wrote:
> 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.
>
>   
Mark,
thanks for the comments,

- I'll change the comment style..

- added the initGEOS() calls, oops..

- the size calculation: ill try your suggestion for getting arg1_length.

The method I use to check the identity of the first geometry argument is 
troublesome to me.  Right now, I do a memcmp() on the de-toasted 
argument, and the previously stored argument in the cache.  This seems 
like alot of work to me, but I having trouble coming up with a better 
way.  One way that occured to me is to store the toasted data in the 
cache instead, and do the comparison on the compressed data instead.  
But is there a future-proof way to get the uncompressed data for the 
datum?  Looks like I need to rip out the guts of toast_fetch_datum() to 
do it.

cheers
b
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/postgis-devel/attachments/20080118/6d9be61e/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: benjubb.vcf
Type: text/x-vcard
Size: 255 bytes
Desc: not available
URL: <http://lists.osgeo.org/pipermail/postgis-devel/attachments/20080118/6d9be61e/attachment.vcf>


More information about the postgis-devel mailing list