IsValid XX000: GEOS isvalid() threw an error!

[Lars Aksel Opsahl]

When running on later geos versions I get an exception and the call returns

Here are there result from 3 different systems, where the one with latest geos fails first.

The file /tmp/testIsValid.sql that we test with will be uploaded.

psql:/tmp/testIsValid.sql:5: ERROR:  XX000: GEOS isvalid() threw an error!
LOCATION:  isvalid, lwgeom_geos.c:1677
                                                                                                                                                    postgis_full_version                                                                                                                                                    
----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
 POSTGIS="3.4.0 0874ea3" [EXTENSION] PGSQL="120" GEOS="3.10.1-CAPI-1.16.0" SFCGAL="1.3.7" PROJ="8.2.0 NETWORK_ENABLED=OFF URL_ENDPOINT=https://cdn.proj.org USER_WRITABLE_DIRECTORY=/tmp/proj DATABASE_PATH=/usr/share/proj/proj.db" LIBXML="2.9.10" LIBJSON="0.13.1" LIBPROTOBUF="1.3.3" WAGYU="0.5.0 (Internal)" TOPOLOGY
(1 row)

 postgis_geos_version 
----------------------
 3.10.1-CAPI-1.16.0
(1 row)

 st_isvalid 
------------
 t
(1 row)
                                                                                              postgis_full_version                                                                                              
----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
 POSTGIS="3.4.0dev 3.3.0rc2-958-g4c776d418" [EXTENSION] PGSQL="120" GEOS="3.9.1-CAPI-1.14.2" SFCGAL="1.3.7" PROJ="7.2.1" LIBXML="2.9.10" LIBJSON="0.13.1" LIBPROTOBUF="1.3.3" WAGYU="0.5.0 (Internal)" TOPOLOGY
(1 row)

 postgis_geos_version 
----------------------
 3.9.1-CAPI-1.14.2
(1 row)

 st_isvalid 
------------
 t
(1 row)
                                                                                                           postgis_full_version                                                                                                            
-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
 POSTGIS="3.1.1 aaf4c79" [EXTENSION] PGSQL="120" GEOS="3.9.0-CAPI-1.16.2" SFCGAL="1.3.7" PROJ="7.2.1" GDAL="GDAL 3.2.1, released 2020/12/29" LIBXML="2.9.10" LIBJSON="0.13.1" LIBPROTOBUF="1.3.3" WAGYU="0.5.0 (Internal)" TOPOLOGY RASTER
(1 row)

 postgis_geos_version 
----------------------
 3.9.0-CAPI-1.16.2
(1 row) 

[Lars Aksel Opsahl]

/tmp/testIsValid.sql

[Lars Aksel Opsahl]

Can display the geometetry in geos

[strk]

When I try the query against POSTGIS="3.4.0 3.4.0" on PostgreSQL 12.16 I get:

ERROR: Pointarray length (-1132134400) is too large

But it works against POSTGIS="3.5.0dev 3.4.0rc1-191-g57c5dad0f" on PostgreSQL 13.5:

$ psql -tAf testIsValid.sql 
t
POSTGIS="3.5.0dev 3.4.0rc1-191-g57c5dad0f" [EXTENSION] PGSQL="130" GEOS="3.12.0dev-CAPI-1.18.0" PROJ="9.1.1 NETWORK_ENABLED=OFF URL_ENDPOINT=https://cdn.proj.org USER_WRITABLE_DIRECTORY=/tmp/proj DATABASE_PATH=/opt/proj-9.1/share/proj/proj.db" LIBXML="2.9.13" LIBJSON="0.15" LIBPROTOBUF="1.3.3" WAGYU="0.5.0 (Internal)" TOPOLOGY
3.12.0dev-CAPI-1.18.0

GEOS-3.10.1 is pretty old as the latest release of the 3.10 series is 3.10.5, releases on March 2023

[strk]

The subject polygon is a 77 rings polygon. Dumping all rings and checking ST_IsValid against each of them works fine. The biggest ring has 2124 points.

Something in ring number 11 confuses PostGIS:

postgis_ticket_5528=# select st_isvalid( ST_MakePolygon( ( SELECT ST_ExteriorRing(g) from t5528 ), ( SELECT array_agg( ST_ExteriorRing(geom) ORDER BY path[1] ) FROM t5528_rings where path[1] > 0 and path[1] < 11 ) ) );
 st_isvalid 
------------
 t
(1 row)

postgis_ticket_5528=# select st_isvalid( ST_MakePolygon( ( SELECT ST_ExteriorRing(g) from t5528 ), ( SELECT array_agg( ST_ExteriorRing(geom) ORDER BY path[1] ) FROM t5528_rings where path[1] > 0 and path[1] < 12 ) ) );
ERROR:  GEOS isvalid() threw an error!

[strk]

This can be reproduced also against GEOS-3.10.2, and both with ST_IsValid and ST_IsValidDetail:

postgis_ticket_5528=# select postgis_geos_compiled_version();
 postgis_geos_compiled_version 
-------------------------------
 3.10.2
(1 row)

postgis_ticket_5528=# select postgis_geos_version();
 postgis_geos_version 
----------------------
 3.10.2-CAPI-1.16.0
(1 row)

postgis_ticket_5528=# select st_isvaliddetail(g, 0) from t5528.original_input ;
ERROR:  GEOS isvaliddetail() threw an exception!

[strk]

Simplifying the exterior ring, even with a tolerance of 0, removes the problem, so maybe this is related to this change in 3.10.3:

• Fix IsValidOp to handle repeated node points (JTS-845, Martin Davis)

That's ​https://github.com/locationtech/jts/issues/845 which seem to result in an IllegalArgumentException thrown when input contains repeated points.

[strk]

Confirmed: this is fixed upstream by GEOS-3.10.3, with no need to recompile postgis.

[strk]

GEOS-3.11.2 is also ok

[Lars Aksel Opsahl]

Thanks for the tip to ​​https://github.com/locationtech/jts/issues/845 I now use a wrapper ​https://gitlab.com/nibioopensource/resolve-overlap-and-gap/-/commit/ef85d769f9ac921ee1599a984ab4813c98b0fe05 in ​https://gitlab.com/nibioopensource/resolve-overlap-and-gap to handle this issue.