[QGIS-Developer] Feedback on introducing a new (abstract) class: QgsSimpleCurve

[Germán Carrillo]

Hi,

I've created a PR for introducing the QgsSimpleCurve class to QGIS core.

You can have a look at:
https://github.com/qgis/QGIS/pull/66346

Regards,

Germán


El jue, 28 may 2026 a las 9:25, Germán Carrillo (<carrillo.german at gmail.com>)
escribió:

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