Curve support in GEOS C API

[Paul Ramsey]

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

> The parameters for this conversion (and whether to perform it all) could be held by the context handle, and controlled with functions like GEOSContext_setCurveToLine([ DISABLED / STEP_DEGREES / MAX_DEVIATION ]) and GEOSContext_setLineToCurve([ DISABLED / SOME_OTHER_TOLERANCE]). I would also expose a GEOSCurveToLine(GEOSGeometry*, params) and GEOSLineToCurve(GEOSGeometry*, params).

Looks like we are getting more params :)

> If needed, we could also provide a capabilities function that would take a function name (or pointer?) and report whether the function supports curves in the current GEOS version.

I’m not sure that’s needed? I’m trying to figure out a scenario where knowing in advance would change a decision to force linearization on or not.

P

> 
> Does this seem like a reasonable approach?
> 
> Dan

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