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

[Greg Troxel]

Germán Carrillo via QGIS-Developer <qgis-developer at lists.osgeo.org>
writes:

> In the context of the crowdfunded project to improve Circular Arcs support
> in GEOS/QGIS, between Opengis.ch and Dan Baston from iSciences, we'd like
> to ask you for technical feedback at an early stage of the QGIS
> implementation.

I know there are various specifications and standards about kinds of
features.   I would like to see written up the high-level information
about what's going on, including:

  What are the relevant standards?

  For each, are there aspects that are not implemented in
  qgis/geos/gdal/postgis/?

  Do programs in the osgeo stack implement object types that  are not in
  the standards?

  In addition to actual standards, is the feature class under discussion
  implemented in any proprietary software?

  If the proposal is about an object type that's not in the standards,
  is there text available that is basically a proposed diff to each
  standard to add it?   Is there intent to actually propose that, or is
  this going down the path of diverging from the standard?

  In the design document that includes standards information, what would
  be the grand plan for which of the osgeo components would get support,
  and is there a preferred ordering to minimize effort?


I see you address gdal/geos but I don't see postgis mentioned.

> We've come to the conclusion that in order to avoid code duplication in the
> QgsGeos class, when importing/exporting LineString or CircularString
> geometries from/to GEOS (used, e.g., in QgsGeos::fromGeos()
> and QgsGeos::asGeos() methods), we would need to introduce a new abstract
> class called QgsSimpleCurve.
>
> This new class would inherit from QgsCurve and would be the base class for
> QgsLineString and QgsCircularString. Namely, importing/exporting
> QgsCircularString geometries would largely benefit from the existing
> import/export code for QgsLineString, so we'd be reusing as much code as
> possible.

An inheritance diagram would help to be sure I'm following.  And
explaining what the rules are for class membership.  I'm a little
worried about multiple inheritance and can't tell that you are intending
to really avoid that.

> Moreover, other projects like GDAL/OGR [1] and GEOS itself [2], already
> have SimpleCurve classes to ease implementation, even if a SimpleCurve
> class is not part of the SQL/MM standard.

is Simple Features also relevant?

> An alternative would be to keep using QgsCurve as the base class, and add
> some methods to it that would be ONLY used by
> QgsLineString/QgsCircularString, ensuring that QgsCompoundCurve returns
> exceptions when those methods are called.

This feels like adding rules to close off things and thus awkward.  My
gut reaction is don't do it; it will cause trouble.

> Since this decision is one of the building blocks for improving Circular
> Arcs support in QGIS (e.g., for integrating a brand new Geometry Splitter
> from GEOS, expected for the 3.15 release), we'd like to kindly ask for your
> feedback before proceeding with a PR, so that we can assess early whether
> the community estimates this move as risky or as a natural step for the
> QGIS project.
>
> Also, let us know if a QEP would be needed here, or if we could go on with
> this discussion and then with a well isolated PR.

If others think my requests for the larger picture make sense, that fits
with QEP.