Opened 12 years ago

Closed 12 years ago

#408 closed enhancement (fixed)

Catch "Exception in LWGEOM2GEOS" in ST_IsValid

Reported by: ddegasperi Owned by: strk
Priority: medium Milestone:
Component: postgis Version: 1.4.X
Keywords: Cc:

Description

i've got following Exception:

 NOTICE: IllegalArgumentException: point array must contain 0 or >1 elements, ERROR:  Exception in LWGEOM2GEOS

by executing this query (or try to do anything else on it, except for numpoints or geometrytype):

 SELECT isvalid('0105000020E0670000010000000102000020E06700000100000016DA52BA62A04141FFF3AD290B735241');

ST_IsValid should catch this Exception and return an appropriate result (false)

Change History (7)

comment:1 Changed 12 years ago by pramsey

Non possible.

The :text entry first gets passed into the text parsing routines which is where the failure actually occurs, not in st_isvalid. We have had internal arguments many times about where validity checking should occur, and the current situation is that trivially invalid geometries (1-point lines, unclosed polygons) are failed during parsing.

IMO, they shouldn't fail, but that's a personal opinion, not a consensus one.

comment:2 in reply to:  1 Changed 12 years ago by kneufeld

Replying to strk:

I might be missing something, but wouldn't an exception
from LWGEOM2GEOS mean unambiguosly that the geometry
is invalid ?

... thinkin loud ... could also be an OOM actually ...

--strk;

Yes, an exception is thrown in LWGEOM2GEOS, but there is also an exception in the parser...

postgis=# BEGIN;
BEGIN
postgis=# SELECT '0105000020E0670000010000000102000020E06700000100000016DA52BA62A04141FFF3AD290B735241'::geometry;
ERROR:  geometry requires more points
postgis=# SELECT 'some other sql statement';
ERROR:  current transaction is aborted, commands ignored until end of transaction block

comment:3 in reply to:  1 Changed 12 years ago by ddegasperi

Replying to pramsey:

Non possible.

The :text entry first gets passed into the text parsing routines which is where the failure actually occurs, not in st_isvalid. We have had internal arguments many times about where validity checking should occur, and the current situation is that trivially invalid geometries (1-point lines, unclosed polygons) are failed during parsing.

IMO, they shouldn't fail, but that's a personal opinion, not a consensus one.

Should shp2pgsql be allowed to insert trivially invalid geometries?

comment:4 Changed 12 years ago by strk

Oh well, I guess if the problem occurs they user must have put the goemetry in the database somehow (maybe not trough the parser). It'd still be worth handling that validity case from ST_IsValid, we can postpone parser work :)

comment:5 in reply to:  4 Changed 12 years ago by kneufeld

Replying to strk:

Oh well, I guess if the problem occurs they user must have put the goemetry in the database somehow (maybe not trough the parser). It'd still be worth handling that validity case from ST_IsValid, we can postpone parser work :)

Yes, I concur. Once a geometry is in the system, a user could modify it beyond recognition (st_removepoint, etc). ST_IsValid then should return a boolean, catching all errors appropriately.

comment:6 Changed 12 years ago by strk

Owner: changed from pramsey to strk

I'm working on this in trunk

comment:7 Changed 12 years ago by strk

Resolution: fixed
Status: newclosed

See if you like what you get with r5207

Note: See TracTickets for help on using tickets.