<div dir="ltr"><div dir="ltr">Hi,<div><br></div><div>I've created a PR for introducing the QgsSimpleCurve class to QGIS core.</div><div><br></div><div>You can have a look at:</div><div><a href="https://github.com/qgis/QGIS/pull/66346">https://github.com/qgis/QGIS/pull/66346</a></div><div><br></div><div>Regards,</div><div><br></div><div>Germán</div><div><br></div></div><br><div class="gmail_quote gmail_quote_container"><div dir="ltr" class="gmail_attr">El jue, 28 may 2026 a las 9:25, Germán Carrillo (<<a href="mailto:carrillo.german@gmail.com">carrillo.german@gmail.com</a>>) escribió:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div dir="ltr">Hi,<br><br>Thanks Greg, Nyall, Even, and Loïc for your responses.<br><br>And special thanks Even for clarifying the raised questions and for all the shared resources.<br><br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">If QgsSimpleCurve appears in the SIP Python bindings, it might be<br>appropriate to have a word in the doc about it being an implementation<br>detail not covered by standards.</blockquote><br>Yes, we'll state this for Python bindings.<br><br>If others still want to share their thoughts on this, please do so.<br><br>I'll prepare a PR soon and let you know when that happens.<br><br>Regards,<br><br>Germán</div><div><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">El jue, 28 may 2026 a las 6:44, Greg Troxel via QGIS-Developer (<<a href="mailto:qgis-developer@lists.osgeo.org" target="_blank">qgis-developer@lists.osgeo.org</a>>) escribió:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Even Rouault <<a href="mailto:even.rouault@spatialys.com" target="_blank">even.rouault@spatialys.com</a>> writes:<br>
<br>
Thanks - especially GDAL RFC49 is enlightening.<br>
<br>
>> For each, are there aspects that are not implemented in<br>
>> qgis/geos/gdal/postgis/?<br>
> SQL/MM could possibly have exposed such a class, but I guess that's<br>
> mostly seen as an implementation detail for implementations to avoid<br>
> code duplication, rather than something impacting operability.<br>
<br>
The point that I didn't understand from the original mail is, I think,<br>
that the new class is an implementation detail and not something that<br>
will result in objects of that class being stored and read from files.<br>
<br>
>> Do programs in the osgeo stack implement object types that are not in<br>
>> the standards?<br>
> Isn't that's > 90% of the job of making useful software, unless your<br>
> software is just about making a reference implementation of a<br>
> standard? Standards cover only the boring aspects :-)<br>
<br>
Sure, but it's good to know when that line is crossed, and there is<br>
features of software, vs object types that are written and read and<br>
might need to interoperate.<br>
<br>
> Personal opinion here: participation to standard working groups is<br>
> time consuming and implies many year involvement due to slow motion /<br>
> bureaucracy / opacity in group dynamics. That's not an activity<br>
> structured for small/medium businesses (more for big commercial<br>
> players that want to push their thing so they can later tick their<br>
> implementation is compliant in call for tenders, or government<br>
> agencies that have dedicated staff for interoperability topics),<br>
> unless you are really fond of that or have significant funding.<br>
<br>
Understood. I was trying to ask "could this be seen as a change to the<br>
standard and if so is that written down", and asking what the plan is.<br>
<br>
It sounds like this is an implementation detail and no objects of the<br>
new type would be written to file formats. Thus it is out of scope from<br>
the standards.<br>
<br>
>> I see you address gdal/geos but I don't see postgis mentioned.<br>
> PostGIS is C, so inheritance is not a natural concept there. PostGIS's<br>
<br>
In C, there is only the manual/hard/not-natural inheritance of<br>
same-layout structs and casts :-)<br>
<br>
> liblwgeom has identical layout for struct LWLINE<br>
> (<a href="https://github.com/postgis/postgis/blob/master/liblwgeom/liblwgeom.h.in#L480" rel="noreferrer" target="_blank">https://github.com/postgis/postgis/blob/master/liblwgeom/liblwgeom.h.in#L480</a>)<br>
> and LWCIRCSTRING<br>
> (<a href="https://github.com/postgis/postgis/blob/master/liblwgeom/liblwgeom.h.in#L504" rel="noreferrer" target="_blank">https://github.com/postgis/postgis/blob/master/liblwgeom/liblwgeom.h.in#L504</a>)<br>
<br>
but has no simplecurve.<br>
<br>
> See GDAL RFC 49 :<br>
> <a href="https://gdal.org/en/stable/development/rfc/rfc49_curve_geometries.html#new-cass-hierarchy" rel="noreferrer" target="_blank">https://gdal.org/en/stable/development/rfc/rfc49_curve_geometries.html#new-cass-hierarchy</a><br>
<br>
Thanks, that makes it all clear. And this is "abstract class" which<br>
means that there will never be an object of type OGRSimpleCurve in<br>
memory, or written to a file. And presumably, code won't return a<br>
pointer to a QgsSimpleCurve object to a plugin, even if it could only be<br>
accessed via virtual dispatch.<br>
<br>
I missed the "(abstract)" (which is clearly present on rereading) in the<br>
original question, and began to think about interoperability concerns.<br>
<br>
<br>
This proposal seems fine to me and I withdraw my questions as mostly<br>
answered and the rest explained why they don't really make sense to<br>
answer.<br>
_______________________________________________<br>
QGIS-Developer mailing list<br>
<a href="mailto:QGIS-Developer@lists.osgeo.org" target="_blank">QGIS-Developer@lists.osgeo.org</a><br>
List info: <a href="https://lists.osgeo.org/mailman/listinfo/qgis-developer" rel="noreferrer" target="_blank">https://lists.osgeo.org/mailman/listinfo/qgis-developer</a><br>
Unsubscribe: <a href="https://lists.osgeo.org/mailman/listinfo/qgis-developer" rel="noreferrer" target="_blank">https://lists.osgeo.org/mailman/listinfo/qgis-developer</a><br>
</blockquote></div><div><br clear="all"></div><div><br></div><div dir="ltr" class="gmail_signature"><div dir="ltr"><div><div dir="ltr"><div dir="ltr"><div dir="ltr"><div></div></div></div></div></div></div></div></div>
</blockquote></div><div><br></div><div dir="ltr" class="gmail_signature"><div dir="ltr"><div><div dir="ltr"><div dir="ltr"><div dir="ltr"><div></div></div></div></div></div></div></div></div>