Get location of PostGIS / GEOS topology exception

Question

I use ST_LineMerge to combine many overlapping lines, splitting them where they branch off. A prerequisite to this process is to ST_Collect my geoms of interest, then ST_Node them to ensure all intersections are noded.

When running ST_Node(ST_Collect(geom)) on some of my geometries, I get the following error which I believe comes from GEOS here:

ERROR:  GEOSNode: TopologyException: 
Iterated noding failed to converge after 6 iterations

When running this for large areas (all of the US, for example), it's difficult to identify where this is happening so I can fix the geometry. All input linestrings pass ST_IsValid(geom), and I end up having to narrow down potential locations by filtering my input and seeing what throws an error.

Is there any way to catch this exception and have it produce something like XXX problem at or near point....

Here's a MWE of my process:

with geoms as (
select  '0102000020110F000003000000DC874D65FCC25EC176032C6B350C5341B336429FFEC25EC1F962BBD9480C5341FC849518FFC25EC15BE20F5F500C5341'::geometry as geom
union
select '0102000020110F000006000000FA9BBFD3FCC25EC1B978232F390C5341B336429FFEC25EC1F962BBD9480C5341A77E6BE5FEC25EC1357C21334D0C5341C3EBA27BFEC25EC11BE5A4C34A0C5341B61D8CACFCC25EC1BCF273143C0C5341FA9BBFD3FCC25EC1B978232F390C5341'::geometry as geom
)

select  st_node(st_collect(geom)) from geoms;

Apologies for the ugly format- the process succeeds when using the ST_AsGeoJSON() versions of the polygons.

Here's my PostGIS full version:

POSTGIS="2.5.3 r17699" [EXTENSION] 
PGSQL="110" GEOS="3.7.1-CAPI-1.11.1 27a5e771" 
PROJ="Rel. 4.9.3, 15 August 2016" 
GDAL="GDAL 2.2.3, released 2017/11/20" 
LIBXML="2.9.4" LIBJSON="0.12.1" LIBPROTOBUF="1.2.1" RASTER

How can I identify the location of this error (or feature IDs, etc) ?

Answer 1

That's a tough one. PostGIS isn't designed to report the noding issues encountered while executing ST_Node. There could be many locations of noding failures, so this would probably have to be built as a separate function, which would capture the locations where repeated noding occurred, and output them as a MultiPoint. This is technically feasible, but would require some significant coding effort.

The hope for near/medium term is to improve the noding process, so that it will no longer run into these kinds of robustness issues (likely by providing a noder based on snap-rounding to a given precision model).

For now you may have to use some other tool which uses the same noding engine but allows more control/insight into the results of the noding. JTS provides this capability. Shapely should do as well (and uses GEOS directly). Both of these will require a certain amount of coding, however.

Answer 2

I found the same issue while preparing noded lines to use on St_polygonize. I was using ST_node(st_collect(geom)).

Following Paul Ramsey's article, I ended up using st_union(geom) instead for the same purpose.

In earlier tests (with a data sample) st_union was a slower solution compared with st_node + st_collect, but at that time I found no topology Errors.