Thank you for the reply. I’ve prepared two examples to illustrate the behavior I’m observing:
CREATE TABLE example1 AS SELECT * FROM (VALUES (1, 'POLYGON ((10 10, 30 10, 30 30, 10 30, 10 10))'::geometry), (2, 'POLYGON ((0 10, 10 10, 9.5 20, 10 30, 0 30, 0 10))'::geometry), (3, 'POLYGON ((10 10, 9.5 20, 10 30, 10 10))'::geometry) ) AS v(id, geom); CREATE TABLE example1_c AS SELECT id, ST_CoverageClean(geom,0.0,1) OVER () AS GEOM FROM example1; In this example, polygon 3 is removed, even though it is not a gap or an overlap. Could this be due to the use of the maximum inscribed circle method, which might classify this polygon as a gap? Here’s another example: CREATE TABLE example2 AS SELECT * FROM (VALUES (1, 'POLYGON ((10 10, 30 10, 30 30, 10 30, 10 10))'::geometry), (2, 'POLYGON ((0 10, 10 10, 9.5 20, 9.5 20.5, 10 30, 0 30, 0 10))'::geometry), (3, 'POLYGON ((10 10, 9.5 20, 9.5 20.5, 10 30, 10 10))'::geometry) ) AS v(id, geom); CREATE TABLE example2_c AS SELECT id, ST_CoverageClean(geom,0.0,1) OVER () AS GEOM FROM example2; In this case, polygon 3 is also removed. Additionally, the vertex at (9.5, 20.5) appears to have been snapped to (9.5, 20), even though I set the snappingDistance to 0.0, expecting no snapping to occur. I don’t think these results are necessarily incorrect—polygon 3 is arguably a sliver in both examples—but I’d like to better understand how the snappingDistance and gapMaximumWidth parameters work together, especially before applying this function in production workflows. On Tue, Sep 23, 2025 at 6:21 PM Paul Ramsey <pram...@cleverelephant.ca> wrote: > If you want to pose your question closer to the actual code that > implements it, asking in the GEOS list might be good. In general, as Greg > notes, a simple example geometry demonstrating your misgivings, if such a > thing exists, is a great way to seed a discussion. Particularly for > something as “personal” as coverage cleaning, there is a lot of opinion > involved in what is “correct” for any given input. > > ATB, > P > > > On Sep 23, 2025, at 5:24 AM, Douglas Fan <douglas.mh...@gmail.com> > wrote: > > > > Dear PostGIS Developers and Users, > > > > First of all, thank you for the development of the new ST_CoverageClean > function in PostGIS 3.6.0. It’s a fantastic addition that has already > helped a lot in my work with polygonal coverages. I really appreciate the > effort that went into making this tool available. > > While testing the function, I’ve encountered some behaviors that I’d > like to better understand, particularly regarding the snappingDistance and > gapMaximumWidth parameters. > > > > From the documentation, I understand that: > > 1. snappingDistance controls vertex snapping, with -1 applying an > automatic distance, and 0.0 disabling snapping. > > 2. gapMaximumWidth closes gaps smaller than the specified tolerance. > > > > However, during testing with various combinations (e.g., > snappingDistance set to -1, 0.0, 1, 2 and gapMaximumWidth set to 0, 1, 2), > I noticed: > > 1. Even when snappingDistance is explicitly set to 0.0, small sliver > vertices still appear to be snapped or altered when gapMaximumWidth is > greater than 0. > > 2. Slivers that are thinner than the gapMaximumWidth are removed, even > when they are not actual gaps or overlaps. > > > > This behavior seems counterintuitive, as I expected no snapping to occur > with snappingDistance = 0.0. Could this be due to internal gap cleaning > logic that also affects vertex positions? Or is there an implicit snapping > step tied to gapMaximumWidth? > > > > I’d be grateful for any insights into: > > > > 1. How do these two parameters interact? > > 2. Best practices or recommended workflows for cleaning polygonal > coverages with minimal geometry distortion. > > 3. Any known edge cases or limitations when using ST_CoverageClean. > > 4. Whether gapMaximumWidth also triggers geometry simplification or > sliver removal beyond gap closing. > > > > Thanks in advance for your help and for the continued development of > PostGIS. > > > > Best regards, > > Man Ho Fan > >
