It's hard! I was just thinking that a light snap using the ST_ReducePrecision might also be good to avoid the generation of some super-tiny slivers, but whether that's done during preprocessing of rings or using ST_CoverageSimplify after polygons are re-formed is an unknown. I look forward to your blog post! P
On Thu, Jan 15, 2026 at 5:59 PM Mike Treglia <[email protected]> wrote: > Thanks, Paul! Appreciate these thoughts - and considerations. I'll keep > these ideas in mind as I proceed and see where I end up. Definitely trying > to keep things simpler than not all things considered... we'll see! > Best, > Mike > > On Thu, Jan 15, 2026 at 1:16 PM Paul Ramsey <[email protected]> > wrote: > >> >> >> On Jan 15, 2026, at 9:46 AM, Mike Treglia <[email protected]> wrote: >> >> Is there an obvious or more optimal way to do that >> st_union(st_exteriorring(geom)) step for large datasets? >> >> >> Just spitballing… >> >> Starting with an ST_Subdivide on all the rings, writing out the ring >> segments and a unique key into a staging table. >> Then do the st_union on a gridded basis. I think that should be safe? >> The part I worry about is doing the polygon building, unless you do the >> build with overlapping grid cells to select potential input ring segments, >> and then post-filter the polygon collection you get to remove any >> overlapping/duplicated polygons. My concern is that a very large input >> polygon relative to the grid size might fail to be built, if all its >> component pieces do not happen to fall into a single grid cell. >> At some point you end up building something of the scale and complexity >> of the topology module, and maybe you would be able to get some good >> results starting there instead. >> P. >> >
