<div dir="ltr">I'd like to get this behavior in 3.15. Is the consensus that it needs to be opt-in, via "WithParams" variants of all the GEOS overlay functions? Or should we explore turning it on in all cases, since many expected overlay results will change in 3.15 anyway? (<a href="https://github.com/libgeos/geos/pull/1412">https://github.com/libgeos/geos/pull/1412</a>)<div><br></div><div>As an example, the proposed behavior is</div><div><br></div><div>geosop intersection -a "POLYGON ((8 2, 10 0, 0 0, 0 10, 2 10, 3.67 8, 4 6, 5.5 3, 8 2))" -b "POLYGON ((2 10, 3.67 8, 4 6, 5.5 3, 8 2, 10 0, 10 10, 2 10))"<br><br>LINESTRING (2 10, 3.67 8, 4 6, 5.5 3, 8 2, 10 0, 8 2)<br></div><div><br></div><div>in place of the current result:</div><div><br></div><div>MULTILINESTRING ((8 2, 10 0), (2 10, 3.67 8), (3.67 8, 4 6), (4 6, 5.5 3), (5.5 3, 8 2))<br></div><div><br></div><div>Dan<br><div><br></div><div><br></div></div></div><br><div class="gmail_quote gmail_quote_container"><div dir="ltr" class="gmail_attr">On Thu, May 21, 2026 at 7:05 AM Sandro Santilli <<a href="mailto:strk@kbt.io">strk@kbt.io</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex">Just to add that PostGIS Topology also does the post-overlay linemerge:<br>
<br>
<a href="https://gitea.osgeo.org/postgis/postgis/src/branch/master/liblwgeom/topo/lwgeom_topo.c#L7520-L7534" rel="noreferrer" target="_blank">https://gitea.osgeo.org/postgis/postgis/src/branch/master/liblwgeom/topo/lwgeom_topo.c#L7520-L7534</a><br>
<br>
Allowing to request such behavior earlier would help performances there too,<br>
I'm in favour of such addition<br>
<br>
--strk;<br>
<br>
<br>
On Wed, May 20, 2026 at 09:22:45AM -0400, Daniel Baston wrote:<br>
> Hi,<br>
> <br>
> I've noticed that the GEOS overlay code has the capability to merge linear<br>
> output geometries, using LineBuilder::addResultLinesMerged. However, this<br>
> capability has never been enabled. GEOS clients ([1], [2]) sometimes end up<br>
> calling GEOSLineMerge as a follow-up step to overlay, but this is<br>
> inefficient and cumbersome. (Among other things, GEOSLineMerge silently<br>
> drops any non-linear inputs.)<br>
> <br>
> Does it make sense to consider enabling this behavior? It would be helpful<br>
> for reconstructing CompoundCurves, which have no way to retain their<br>
> complex parentage information through the noding journey. I guess we would<br>
> need a GEOSUnionWithParams, GEOSIntersectionWithParams, etc...<br>
> <br>
> Dan<br>
> <br>
> [1]<br>
> <a href="https://github.com/qgis/QGIS/blob/b298119a5b09ae3903596ec2ffaf8aaff7ba78a3/src/core/geometry/qgsgeos.cpp#L1985" rel="noreferrer" target="_blank">https://github.com/qgis/QGIS/blob/b298119a5b09ae3903596ec2ffaf8aaff7ba78a3/src/core/geometry/qgsgeos.cpp#L1985</a><br>
> [2]<br>
> <a href="https://github.com/OSGeo/gdal/blob/ad495515b681bfb5f660f5de17e9ef1c2c8f153f/apps/gdalalg_vector_dissolve.cpp#L134" rel="noreferrer" target="_blank">https://github.com/OSGeo/gdal/blob/ad495515b681bfb5f660f5de17e9ef1c2c8f153f/apps/gdalalg_vector_dissolve.cpp#L134</a><br>
</blockquote></div>