<div dir="ltr"><div dir="ltr">On Wed, Jan 7, 2026 at 10:29 AM Paul Ramsey <<a href="mailto:pramsey@cleverelephant.ca">pramsey@cleverelephant.ca</a>> wrote:</div><div class="gmail_quote gmail_quote_container"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div><div><blockquote type="cite"><div>On Jan 7, 2026, at 7:06 AM, Daniel Baston <<a href="mailto:dbaston@gmail.com" target="_blank">dbaston@gmail.com</a>> wrote:</div><br><div><div dir="ltr"><div dir="ltr">I have been incrementally adding curve support in GEOS, for example in <a href="https://github.com/libgeos/geos/pull/1347" target="_blank">https://github.com/libgeos/geos/pull/1347</a>.  I've been thinking about the best way for applications such as QGIS/PostGIS/GDAL to integrate this functionality.</div><div dir="ltr"><br></div><div dir="ltr">Currently, these applications linearize all geometries before sending them to GEOS. That will not be necessary for GEOSNode and a list of functions that will likely increase over multiple GEOS releases. It seems cumbersome for applications to rely on GEOS version checks to know if linearization is needed, so I think GEOS should offer an ability to automatically linearize inputs and curvify outputs where needed. </div></div></div></blockquote><div><br></div><div>Yes, I think centralizing this code makes sense. Unfortunately it doesn’t mean we can get rid of any of our linearizing or delinearizing code, since we’ll need it for backwards compatibility for years.</div></div></div></blockquote><div><br></div><div>I'm a bit of an outsider to this project so I'm not fully up to speed on the current developments, and you should take my comment with the usual amount of salt if I've grasped the wrong end of the stick.</div><div><br></div><div>I assume what you're discussing is working with composite/piecewise Bezier splines directly rather than converting paths to straight line segments, working with those, and finally converting back to as good a spline approximation as can be found.  I'm not an expert in this area but I have done a bit of first-hand work with similar code and I've certainly read a lot on the subject in the last couple of years.  So... it is certainly a good direction to head in to work directly from Bezier polylines in many - even most - cases, *however* there are some constructs such as offsetting a Bezier curve for which it is a mathematical impossibility to perform by manipulating the control points, or to represent exactly with another Bezier curve: for those cases you pretty much have to use the original scheme of converting to and from straight line segments.  So my recommendation would be to leave that method as an integral part of the system, but to incrementally add code to optimise using true curves whenever possible.  The specifications and interface calls that the user sees should not change as the internal implementation is moved from one style to another.</div><div><br></div><div>(I have one other tangential point to make just in case it hasn't already been noted - polyline Bezier paths must support closed paths that loop.  These are often overlooked in packages and ensuring continuity when the start and end  of a path are joined is sometimes a problem.  It won't be, if designed in from the start, and in fact a looping path ought not to even need a specific start/end node.)</div><div><br></div><div>That's all I have to add to this discussion, I'll bow out now.</div><div><br></div><div>G</div></div></div>