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

[Germán Carrillo]

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/20260528/5ad1b088/attachment.htm>