[postgis-users] GEOS / Predicates Update

[strk]

I don't know much about C++, I'm not confortable in using
C++ libraries in my works (often give me problems).

Reference implementation - I think - should be written in C.
In this cases it looks like GEOS is a port, not the main thing,
the *real thing* is JTS, right ? 

My opinion is that you should not bother rewriting GEOS, but
provide some other mechanism to bypass the exception issues.
This sounds like a general problem with C++ libs, and since the
exception emulator code is available... I'd trow that in, or
implement some other way to let lib users choose what mechanism to
use for error handling.

--strk;

I think having GEOS written in C could be the definitive word


pramsey wrote:
> 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