<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
<title></title>
</head>
<body bgcolor="#ffffff" text="#000000">
<br>
<br>
Mark Cave-Ayland wrote:
<blockquote cite="mid:1200645673.5577.15.camel@mca-desktop" type="cite">
<pre wrap="">On Thu, 2008-01-17 at 17:07 -0800, Ben Jubb wrote:
</pre>
<blockquote type="cite">
<pre wrap="">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
</pre>
</blockquote>
<pre wrap=""><!---->
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.
</pre>
</blockquote>
Mark,<br>
thanks for the comments,<br>
<br>
- I'll change the comment style.. <br>
<br>
- added the initGEOS() calls, oops..<br>
<br>
- the size calculation: ill try your suggestion for getting arg1_length.<br>
<br>
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.<br>
<br>
cheers<br>
b<br>
</body>
</html>