[postgis-users] Topological Exceptions

Martin Davis mbdavis at refractions.net
Wed Mar 12 15:45:01 PDT 2008

Seems like a good idea, Regina.  It would certainly be nice to be able 
to detect all errors in a single query. 

It would be nice if the value returned was distinguishable from any 
expect legal return value.  Thus I would vote for null to be returned, 
rather than an empty GC.  This also has the advantage that it can be 
checked for easily, and will probably cause further processing to fail, 
so as not to mask the error.

Of course, this will need to be accompanied by some good documentation 
about when this failure return value might be encountered (and maybe 
some hints about what to do about it - although this is heavily 

Orginally the idea was that it was nice to report the actual nature of 
the exception, since it contains an indication of where the error 
occurred.   It would be nice to be able to continue to have access to 
this information.  One way to do this would be to have a parallel set of 
functions which would abort as they do now.  Or is there some other way 
to report this info - to a log somewhere perhaps?

Obe, Regina wrote:
> I've been doing a lot of work using ST_Intersection, ST_Difference, 
> ST_Union etc to cut out slices of geometries I don't want and slicing 
> up geometries into smaller pieces, reunioning etc.
> I've been running into a lot of Topological Exceptions of the form 
> directed Edge this and non-noded that.  For the most part I've been 
> able to overcome these by slicing things smaller or skipping over 
> problem regions (e.g. areas where the difference is a line or point or 
> something of that sort).
> I think a lot of people have run into the same issues and have gotten 
> frustrated and there doesn't seem to be a simple solution suggested to 
> overcome these.
> Is there any way we can change (add overloaded functions or some 
> setting parameter) - that take additional parameters to simply ignore 
> these errors that says return empty collection or NULL when a GEOS 
> error is thrown.  That way I can simply ignore these and throw them 
> out of my equation and move on.
> Just a thought.  I'm sure my suggestion is rather simple-minded and 
> I'm sure I'm missing some reason of why this is not feasible.  An 
> explanation of why my suggestion is stupid at anyrate would be nice.
> Thanks,
> Regina
> ------------------------------------------------------------------------
> *The substance of this message, including any attachments, may be 
> confidential, legally privileged and/or exempt from disclosure 
> pursuant to Massachusetts law. It is intended solely for the 
> addressee. If you received this in error, please contact the sender 
> and delete the material from any computer. *
> ------------------------------------------------------------------------
> * Help make the earth a greener place. If at all possible resist 
> printing this email and join us in saving paper. *
> * *
> * *
> ------------------------------------------------------------------------
> _______________________________________________
> postgis-users mailing list
> postgis-users at postgis.refractions.net
> http://postgis.refractions.net/mailman/listinfo/postgis-users

Martin Davis
Senior Technical Architect
Refractions Research, Inc.
(250) 383-3022

More information about the postgis-users mailing list