[postgis-users] GEOS / Predicates Update

[C F]

Thanks for the update.

Pardon my ignorance....

- PostgreSQL is written in C and GEOS is written in C++ and that's what's 
causing the discrepancies in exception handling, is that right?

- You probably have, but just to double check... have you guys tried the 
PostgreSQL lists with this problem?

- You mentioned that one solution may be to use newer compilers.  Would that 
mean that all three components (PostgreSQL, GEOS and PostGIS) would need to 
be compiled with these?  Correct me if I'm wrong, but that doesn't seem like 
a big deal to me.  Wouldn't that just be a matter of downloading the latest 
compilers and recompiling these things *IF* you want GEOS support (which I 
do)?  Or am I over simplifying..

>From: Paul Ramsey <pramsey at refractions.net>
>Reply-To: PostGIS Users Discussion <postgis-users at postgis.refractions.net>
>To: PostGIS Discussion <postgis-users at postgis.refractions.net>
>Subject: [postgis-users] GEOS / Predicates Update
>Date: Thu, 22 May 2003 09:45:15 -0700
>
>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
>
>
>_______________________________________________
>postgis-users mailing list
>postgis-users at postgis.refractions.net
>http://postgis.refractions.net/mailman/listinfo/postgis-users

_________________________________________________________________
MSN 8 with e-mail virus protection service: 2 months FREE*  
http://join.msn.com/?page=features/virus