Opened 7 years ago

Closed 6 years ago

Last modified 6 years ago

#1198 closed defect (wontfix)

ST_Union fails on some sets of polygons. Snapping works around the problem

Reported by: dmiranda Owned by: pramsey
Priority: medium Milestone: PostGIS 2.0.0
Component: postgis Version: trunk
Keywords: st_union topologyexception noded intersection Cc:

Description

How to reproduce:

-load either the attached shapefile or the sql into postgis -run the query:

select st_union(geom) from st_union_topology_exception;

-The following message should appear:

ERROR: GEOSUnionCascaded: TopologyException?: found non-noded intersection between LINESTRING (-54.7158 -28.0099, -54.7156 -28.0116) and LINESTRING (-54.7158 -28.0099, -54.7158 -28.0119) at -54.7158 -28.0099 SQL state: XX000

Other observations: -st_isvalid returns true for all the polygons -snapping may get rid of the problem (select st_union(st_snaptogrid(geom,0.00000000001)) from st_union_topology_exception; finishes without errors) -buffering by zero does not get rid of the problem -snapping stops solving the problem at 0.00000000000001, presumably near the float 64 resolution.

possibly related to #575, #1045 and/or #1173 (error message is similar)

Version: Ubuntu 11.04 Postgresql 9.1 postgis 2.0.0svn Rev: 7856 Last Changed Date: 2011-09-15 14:43:57 GEOS 3.4.0dev Rev: 3465 Last Changed Date: 2011-09-12 01:47:39

Attachments (2)

st_union_topology_exception_shp.zip (543.9 KB) - added by dmiranda 7 years ago.
Shapefile containing the polygons that trigger the st_union error
st_union_topology_exception_sql.zip (612.4 KB) - added by dmiranda 7 years ago.
SQL dump of the table containing the polygons that trigger the st_union error

Download all attachments as: .zip

Change History (8)

Changed 7 years ago by dmiranda

Shapefile containing the polygons that trigger the st_union error

Changed 7 years ago by dmiranda

SQL dump of the table containing the polygons that trigger the st_union error

comment:1 Changed 7 years ago by dmiranda

Summary: st_union fails on some sets of polygons. snappingST_Union fails on some sets of polygons. Snapping works around the problem

comment:2 Changed 7 years ago by jgrocha

The same dataset, imported in PostGIS 1.5 runs fine.

PostGIS version used: "1.5 USE_GEOS=1 USE_PROJ=1 USE_STATS=1"

Commands used: psql geotuga < st_union_topology_exception.sql

select gid from st_union_topology_exception where not st_isvalid(geom); No invalid geometries were found

psql geotuga -c "select st_astext(st_envelope(st_union(geom))) from st_union_topology_exception;" POLYGON((-55.3756654961996 -28.9576596206607,-55.3756654961996 -27.1734940596501,-53.0671265720575 -27.1734940596501,-53.0671265720575 -28.9576596206607,-55.3756654961996 -28.9576596206607))

select st_extent(geom) from st_union_topology_exception; "BOX(-55.3756654961996 -28.9576596206607,-53.0671265720575 -27.1734940596501)"

comment:3 Changed 7 years ago by dmiranda

Tried with downgraded geos to the ubuntugis unstable package. "POSTGIS="2.0.0SVN" GEOS="3.2.2-CAPI-1.6.2" PROJ="Rel. 4.7.1, 23 September 2009" LIBXML="2.7.8" USE_STATS (procs from 2.0 r7629 need upgrade)" Will handle this dataset, just like jgrocha said, but still gives the same error on the larger dataset.

comment:4 Changed 6 years ago by strk

Resolution: wontfix
Status: newclosed

Please try with GEOS-3.3.2. If the problem persists, file a ticket there: http://trac.osgeo.org/geos/

comment:5 Changed 6 years ago by pracine

Was this fixed?

I must say I experience this quite often with normal datasets with both ST_Union and ST_Difference with the latest tarball:

"POSTGIS="2.0.0beta5SVN" GEOS="3.3.2-CAPI-1.7.2" PROJ="Rel. 4.6.1, 21 August 2008" GDAL="GDAL 1.9.0, released 2011/12/29" LIBXML="2.7.8" (core procs from "2.0.0beta5SVN" need upgrade) RASTER (raster procs from "2.0.0beta5SVN" need upgrade)"

For ST_Union I can make it to work if I ST_SnapToGrid(geom, 0.000001). Below than 0.000001, it fails.

I can provide data if necessary.

comment:6 Changed 6 years ago by dmiranda

Pracine, I did not test it again, so I do not have your answer.

If you have data that consistently triggers the defect, please attach a new file and reopen the ticket (action->reopen).

Before doing so, please test with newest postgis (2.0.1SVN) and GEOS nightly and/or 3.3.3

Did you test the attached files to see if they trigger the defect in your case?

Note: See TracTickets for help on using tickets.