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
situation-dependent).
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
[email protected]
http://postgis.refractions.net/mailman/listinfo/postgis-users
--
Martin Davis
Senior Technical Architect
Refractions Research, Inc.
(250) 383-3022
_______________________________________________
postgis-users mailing list
[email protected]
http://postgis.refractions.net/mailman/listinfo/postgis-users
