<div dir="ltr">Thanks, I figured there was a reason I hadn't seen this pattern in the wild :)<div><br></div><div>Dan</div></div><br><div class="gmail_quote gmail_quote_container"><div dir="ltr" class="gmail_attr">On Wed, Jan 7, 2026 at 10:31 AM Even Rouault <<a href="mailto:even.rouault@spatialys.com">even.rouault@spatialys.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex">Dan,<br>
<br>
Just commenting on your last question. I don't think using function <br>
pointers is feasible. I've vague memories of past times where I tried <br>
this and I remember that at least on Windows, with shared libraries, the <br>
address of a function inside the library is not the same as the address <br>
an external user gets, due to how the dynamic loader works (typically <br>
the address an external user gets is the one of some "trampoline" <br>
function that then jumps to the actual address inside the library)<br>
<br>
Even<br>
<br>
Le 07/01/2026 à 16:06, Daniel Baston a écrit :<br>
> Hi,<br>
><br>
> I have been incrementally adding curve support in GEOS, for example in <br>
> <a href="https://github.com/libgeos/geos/pull/1347" rel="noreferrer" target="_blank">https://github.com/libgeos/geos/pull/1347</a>. I've been thinking about <br>
> the best way for applications such as QGIS/PostGIS/GDAL to integrate <br>
> this functionality.<br>
><br>
> Currently, these applications linearize all geometries before sending <br>
> them to GEOS. That will not be necessary for GEOSNode and a list of <br>
> functions that will likely increase over multiple GEOS releases. It <br>
> seems cumbersome for applications to rely on GEOS version checks to <br>
> know if linearization is needed, so I think GEOS should offer an <br>
> ability to automatically linearize inputs and curvify outputs where <br>
> needed. The parameters for this conversion (and whether to perform it <br>
> all) could be held by the context handle, and controlled with <br>
> functions like GEOSContext_setCurveToLine([ DISABLED / STEP_DEGREES / <br>
> MAX_DEVIATION ]) and GEOSContext_setLineToCurve([ DISABLED / <br>
> SOME_OTHER_TOLERANCE]). I would also expose a <br>
> GEOSCurveToLine(GEOSGeometry*, params) and <br>
> GEOSLineToCurve(GEOSGeometry*, params).<br>
><br>
> If needed, we could also provide a capabilities function that would <br>
> take a function name (or pointer?) and report whether the function <br>
> supports curves in the current GEOS version.<br>
><br>
> Does this seem like a reasonable approach?<br>
><br>
> Dan<br>
<br>
-- <br>
<a href="http://www.spatialys.com" rel="noreferrer" target="_blank">http://www.spatialys.com</a><br>
My software is free, but my time generally not.<br>
<br>
</blockquote></div>