Curve support in GEOS C API

[Graham Toal]

On Wed, Jan 7, 2026 at 10:29 AM Paul Ramsey <pramsey at cleverelephant.ca>
wrote:

> On Jan 7, 2026, at 7:06 AM, Daniel Baston <dbaston at gmail.com> wrote:
>
> I have been incrementally adding curve support in GEOS, for example in
> https://github.com/libgeos/geos/pull/1347.  I've been thinking about the
> best way for applications such as QGIS/PostGIS/GDAL to integrate this
> functionality.
>
> 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.
>
>
> 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.
>

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.

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.

(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.)

That's all I have to add to this discussion, I'll bow out now.

G
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/geos-devel/attachments/20260107/20c35804/attachment.htm>