Le 28/05/2026 à 00:05, Greg Troxel via QGIS-Developer a écrit :
Germán Carrillo via QGIS-Developer<[email protected]>
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.
+1 from me for QgsSimpleCurve. Obviously strongly biased as the author
of GDAL's OGRSimpleCurve.
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.
An alternative approach could have been to have QgsSimpleCurve as a
member of QgsLineString & QgsCircularString, using composition rather
than derivation, but that would likely be a rather verbose approach,
probably not much better than copying&pasting code between both classes.
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/?
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.
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 :-)
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?
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.
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
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)
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.
See GDAL RFC 49 :
https://gdal.org/en/stable/development/rfc/rfc49_curve_geometries.html#new-cass-hierarchy
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?
SQL/MM is the ISO extension of Simple Features adding curve geometries.
Old draft at
https://web.archive.org/web/20071212154300/http://jtc1sc32.org/doc/N1101-1150/32N1107-WD13249-3--spatial.pdf
, otherwise pay 100 + CHF to ISO. Although I see at the bottom of
https://www.ogc.org/standards/sfa/ there's apparently an ongoing effort
to reconcile both.
--
Very grumpy about LLMs: FOSS is about increasing public capital,
not becoming enslaved to private equity of giga corporations
--
http://www.spatialys.com
My software is free, but my time generally not.
_______________________________________________
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
