Correct, just for 3.15 and up. Dan
On Wed, Jan 7, 2026 at 10:18 AM Regina Obe <[email protected]> wrote: > So this would just be for GEOS 3.15 and above right? So projects would > still need to change if GEOS >= 3.15 to know if curve support is available. > > > > That’s fine. But backporting would not be fine. > > > > *From:* Daniel Baston <[email protected]> > *Sent:* Wednesday, January 7, 2026 10:07 AM > *To:* GEOS Development List <[email protected]> > *Subject:* Curve support in GEOS C API > > > > Hi, > > 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. 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). > > > > 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. > > > > Does this seem like a reasonable approach? > > > > Dan >
