[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