Ticket #408 (closed enhancement: fixed)

Opened 2 years ago

Last modified 2 years ago

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

follow-ups: ↓ 2 ↓ 3   Changed 2 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.

in reply to: ↑ 1   Changed 2 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

in reply to: ↑ 1   Changed 2 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?

follow-up: ↓ 5   Changed 2 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 :)

in reply to: ↑ 4   Changed 2 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.

  Changed 2 years ago by strk

  • owner changed from pramsey to strk

I'm working on this in trunk

  Changed 2 years ago by strk

  • status changed from new to closed
  • resolution set to fixed

See if you like what you get with r5207

Note: See TracTickets for help on using tickets.