[postgis-users] GEOS / Predicates Update

[Paul Ramsey]

PostGIS'ers,
   It has been a while since I told you all that predicates would be 
available in PostGIS "soon", so I think I should provide an update.
   a) the GEOS library supports the spatial predicates and a few of the 
operators (geos.refractions.net) and has been tested against a pretty 
comprehensive test harness. GEOS seems to be ready to go.
   b) the CVS version of PostGIS includes support for building in GEOS 
and a relate() function available in SQL. The current implementation 
does not do very good memory management, so repeated invocations of the 
GEOS functions will leak memory into the postgres instance over time.
   c) we have been unable to implement proper exception handling in 
PostGIS for GEOS exceptions. This is a BIG PROBLEM.  GEOS throws 
exceptions for things it cannot handle topologically, primarily for 
illegal geometries.  Ideally, PostGIS would catch these exceptions and 
translate them into PostgreSQL errors or warnings, depending on 
severity.  This is how Dave designed his implementation.  However, 
there appear to be some low level bugs in C/C++ interaction which cause 
exceptions thrown by GEOS to be interpreted by the parent process 
(postgres) as SIGABORT, which shuts down the backend immediately.  The 
net effect is that any exception GEOS hits causes the backend to 
immediately terminate, instead of handling the exceptions.  No amount 
of repositioning of the exception handling code has fixed this. We have 
put the exception handling right back into the GEOS library, and the 
result is still the same -- as soon as an exception is raise, the 
backend terminates.
   Dave has already posted a detailed technical description of the 
problem to this list.
   We are at a bit of an impasse right now, because there seems to be no 
fast-and-easy way to avoid this problem. Our current options appear to 
be:
   - Try the very latest gcc, glibc, and libstdc++ libraries and see if 
the problem has been resolved. It has been reported to the maintainers 
about a year ago, as far as we can tell.  While this might fix the 
problem, it will make deployment very difficult for people, since 
almost no linux distributions have the very latest versions of these 
libraries.  Commercial UNIX'es will also be terra incognito.
   - Re-write some chunks of GEOS to not throw exceptions. This is bad 
for two reasons.  It is a large amount of work, and it also is bad 
design.  The exceptions are there for a reason, and replacing them with 
large chains of null handling will be unpleasant.  There are some 
"exception emulation" libraries for C which could make the process less 
unpleasant, but it will still not be nice at all.
   - Re-write GEOS entirely, and again, in C. This at least would be a 
clean implementation of the algorithms, but it is even more work, and 
would constitute yet another port of JTS which would have to be kept 
synchronous with the JTS R&D over time.

All the options suck, which is why we have not chosen one yet.
That's the state of things now,
P.


      Paul Ramsey
      Refractions Research
      Email: pramsey at refractions.net
      Phone: (250) 885-0632