Curve support in GEOS C API

[Heiskanen Mika (FMI)]

Hi,

Also note that curvifying the output is far from trivial. See for example the work by Raph Levien (doctoral dissertation, Kurbo library).

Mika
________________________________
From: Graham Toal <gtoal at gtoal.com>
Sent: Wednesday, January 7, 2026 21:22
To: GEOS Development List <geos-devel at lists.osgeo.org>
Subject: Re: Curve support in GEOS C API

On Wed, Jan 7, 2026 at 10:29 AM Paul Ramsey <pramsey at cleverelephant.ca<mailto:pramsey at cleverelephant.ca>> wrote:
On Jan 7, 2026, at 7:06 AM, Daniel Baston <dbaston at gmail.com<mailto: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/21084283/attachment-0001.htm>