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

[Greg Troxel]

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.