[postgis-devel] Call for 1.4.2 and 1.5.1 (Handling of Invalid Geometries)

[Martin Davis]

Well, I'm still not convinced.  It seems to me that it's much easier to 
check and prevent bad structure than bad topology (in terms of both  
amount of coding required and execution performance ).

Also I think the use cases are slightly different.  One situation is 
addressing what to do when structurally invalid geometries are inserted 
into the DB, whereas the situation you present is about modifying 
geometries which are already in the DB.  In the latter case I don't 
think it's unreasonable to assert that DB functions will never create 
structurally invalid geometry.

I think there's an expection by users that a software system provides 
them with as simple a model as possible that lets them perform the 
functions they need to.  Of course if the model is too restrictive then 
they are not going to be able to use it for as many tasks.  It's a 
judgement call about how flexible to allow the model to be, but I think 
there's value in avoiding unnecessary hidden pitfalls (like running a 
function that produces structurally invalid geometry).

strk wrote:
> On Wed, Feb 17, 2010 at 03:35:08PM -0800, Martin Davis wrote:
>   
>> Well, so it's still invalid.  So what?  Bottom line is that someone 
>> handed in garbage claiming it was a LinearRing.  They can't complain 
>> about being told that no, it's actually garbage.
>>
>> The idea is to allow more cases to enter the database in a graceful way, 
>> without requiring a huge effort to check for bad structure throughout 
>> the codebase.  There's no promise to perform magic.  There will always 
>> be geometries which are so badly munged that they can't be made valid no 
>> matter what.
>>     
>
> That's why we want to hold them. Only the user can "cure" them.
> Note that the "huge effort" required to check for bad structure throughout
> the code base is the same also required to check for NOT PRODUCING
> bad structures. That's to say, as we have code that can produce invalid
> topologies (ST_ShiftLongitude to cite one) we may as well have other
> code which can produce *structurally* invalid ones.
>
> ST_RemovePoint ?
> ST_RemoveDuplicatePoints ? 
>
> Yes, you can still call them bugs, but this doesn't prevent that
> from happening and thus you'd be with your data *locked* in postgis
> and you just can't help !
>
> --strk; 
>
>   ()   Free GIS & Flash consultant/developer
>   /\   http://foo.keybit.net/~strk/services.html
> _______________________________________________
> postgis-devel mailing list
> postgis-devel at postgis.refractions.net
> http://postgis.refractions.net/mailman/listinfo/postgis-devel
>
>   

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