Curve support in GEOS C API

[Even Rouault]

Dan,

Just commenting on your last question. I don't think using function 
pointers is feasible. I've vague memories of past times where I tried 
this and I remember that at least on Windows, with shared libraries, the 
address of a function inside the library is not the same as the address 
an external user gets, due to how the dynamic loader works (typically 
the address an external user gets is the one of some "trampoline" 
function that then jumps to the actual address inside the library)

Even

Le 07/01/2026 à 16:06, Daniel Baston a écrit :
> 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

-- 
http://www.spatialys.com
My software is free, but my time generally not.