[postgis-users] Topological Exceptions

[Chris Hermansen]

I can be so tiresome sometimes!

What I meant to ask was, when bad geometry is encountered and some
predicates are tempted to give up, what happens in the JDBC context - is
an exception thrown.  Clearly if you move over to the returning nulls
then a Java null is the reasonable behaviour.

Sorry to be so unclear!

Martin Davis wrote:
> I would expect that JDBC would simply return a standard SQL null
> value.  I'm not sure whether JDBC returns an specific object
> representing null, or simply a Java null - I suspect the latter.
>
> Chris Hermansen wrote:
>> 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.