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 (<[email protected]>) 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 (< > [email protected]>) escribió: > >> Even Rouault <[email protected]> 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 >> [email protected] >> List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer >> Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer >> > > >
_______________________________________________ QGIS-Developer mailing list [email protected] List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer
