Martin, I like the direction you're headed in here because it seems it can be done with the technology as-is.
Does anybody know what happens if one encounters this while processing through e.g. JDBC? Would one expect an exception of some sort to be thrown? Martin Davis wrote: > Sounds good to me. > If you wanted to see which geoms caused the problem, couldn't you just > run another query looking only for ones which returned NULL from the > operation, and then check the log? > > The log msg could also give the first couple of points of the > offending geoms - that would narrow it down pretty good. > > Does ST_Contains (and the other predicates) ever result in > TopologyExceptions? They are generally pretty darn robust, to my > knowledge. It's the overlay ops which are the real bad boys. > > Paul Ramsey wrote: >> On 3/12/08, Martin Davis <[EMAIL PROTECTED]> wrote: >> >> >>> 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? >>> >> >> I prefer using something like NULL to trying to create a new geometry >> type to encompass the error... particularly if the error conditions >> aren't that interesting to people. We can get into the log easily >> enough by using a WARNING log level, the only question then is how to >> identify which geometries caused the failure. One way might be to >> hash the geometries, so that if people want to find their bad >> geometries from the log they can just select for the hash value. >> >> This means that the return values of >> >> ST_Contains(geom,geom) => true, false or null >> >> and >> >> ST_Intersection(geom,geom) => geometry or null >> >> I just checked, and null seems to be interpreted as false in a WHERE >> clause, so adding this behavior probably wouldn't wreck too many >> joins. >> >> Paul >> _______________________________________________ >> postgis-users mailing list >> [email protected] >> http://postgis.refractions.net/mailman/listinfo/postgis-users >> >> > -- Regards, Chris Hermansen · mailto:[EMAIL PROTECTED] tel:+1.604.714.2878 · fax:+1.604.733.0631 Timberline Natural Resource Group · http://www.timberline.ca 401 · 958 West 8th Avenue · Vancouver BC · Canada · V5Z 1E5 C'est ma façon de parler. _______________________________________________ postgis-users mailing list [email protected] http://postgis.refractions.net/mailman/listinfo/postgis-users
