[postgis-users] Topological Exceptions

[Chris Hermansen]

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 <mbdavis at refractions.net> 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
>> postgis-users at postgis.refractions.net
>> http://postgis.refractions.net/mailman/listinfo/postgis-users
>>
>>   
>


-- 
Regards,

Chris Hermansen · mailto:clh at timberline.ca
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.