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

strk strk at keybit.net
Wed Feb 17 13:06:57 PST 2010


On Wed, Feb 17, 2010 at 11:33:22AM -0800, Kevin Neufeld wrote:
> On 2/17/2010 10:40 AM, Paul Ramsey wrote:
> >Better to accept invalidity in
> >all its flavors and provide the tools to identify and work on
> >improving it inside the database.
> 
> I'm torn.  I totally agree that PostGIS needs to accept invalid geometries 
> for all the reasons Chris and Paul gave.  But I'm kinda with Mark on this 
> one - there is a difference between geometry invalidity and what 
> constitutes a geometry in the first place.  Shouldn't a POLYGON at least 
> look something like a POLYGON before being allowed into PostGIS? Obviously 
> in this case, it makes most sense to automatically add any missing 
> closing-ring points.  But what if the polygon only has one point (ie. 
> 'POLYGON((0 1))')?

I just committed handling of this by ST_MakeClean:

# select st_astext(g) as orig,
	 st_isvalidreason(g) as invalidity,
	 st_astext(st_makevalid(g)) as valid
from (
select '0103000000010000000100000000000000000000000000000000000000'::geometry
as g) as foo;
-[ RECORD 1 ]-------------------------------------------------------------------
orig       | POLYGON((0 0))
invalidity | IllegalArgumentException: point array must contain 0 or >1 elements
           :
valid      | POINT(0 0)

Get these dirty things in, DBs shouldn't be picky.
We have already st_isvalid() for use to check state !

--strk;

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



More information about the postgis-devel mailing list