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

strk strk at keybit.net
Thu Feb 25 06:02:47 PST 2010


On Wed, Feb 24, 2010 at 02:26:14PM -0800, Martin Davis wrote:

> 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.

No, it's not unreasonable, as it isn't unreasable to deliver bug-free
software. Just it's not always that easy. And locking data in due to
a bug is hardly a good idea to me.

Now what we could do is allow them to flow out but not allowing them
to get in. But this would prevent us to prepare automated testcases
for the case the geometries are in.

Or, we could allow them both in and out using "canonical" input and
output functions but forbid them when using *standard* input/output
functions (ST_AsText, ST_GeometryFromText).

--strk; 

  ()   Free GIS & Flash consultant/developer
  /\   http://foo.keybit.net/~strk/services.html



More information about the postgis-devel mailing list