[postgis-users] Topological Exceptions

[Martin Davis]

A reasonable concern.

To which some might be tempted to reply RTFM.  (I think this is the 
solution offered by some proprietary vendors...)

Would having parallel sets of functions, (Paranoid/Laissez-faire) be an 
option?  Unpleasant to widen the API, however.



Paul Ramsey wrote:
> Before getting too enthused about this, the net effect will be to
> convert a whole bunch of questions about "why is my query failing" to
> "why is my query returning incomplete answers"...
>
> We can still spit out NOTICEs, but will people put 2 + 2 together and
> recognize that their return sets are partials because of the topology
> failures?
>
> P
>
> On 3/12/08, Paul Ramsey <pramsey at cleverelephant.ca> 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
>
>   

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