You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Since the merge of the new geometry engine, the role of QgsGeometry is undefined. It currently acts as just an implicitly shared container for a QgsAbstractGeometryV2, plus a random bunch of methods for modifying and converting the geometry.
I'd like to see this refined in QGIS 3.0. My thoughts:
rename QgsGeometry to QgsGeometryContainer, to better indicate what it's used for and differentiate it from QgsAbstractGeometryV2
move all geometry modification (eg buffer, addRing, addPart, ...) and relation methods ( eg contains, crosses, ...) out of this class. Many are already implemented in either QgsGeometryEngine, QgsAbstractGeometryV2 or QgsGeometryUtils and the QgsGeometry versions are just wrappers around these
move all the creation methods (eg fromQPointF, ... ) to QgsGeometryFactory (or to their relevant geometry class, eg QgsPointV2::fromQPointF )
What would remain in QgsGeometryContainer would be:
methods for accessing and setting the contained QgsAbstractGeometryV2, isEmpty()
some conversion routines, eg convertToMultiType, convertToSingleType, segmentize, and a general "bool convertTo( QgsWKBTypes::Type )" and "bool canConvertTo( QgsWKBTypes::Type )"
The text was updated successfully, but these errors were encountered:
Related to this, I think the geometry model should work in an inherited way, so you could do a QgsPoint.buffer() and QgsLine.buffer() without writing the typecasting code to (and from) QgsGeometry all the time.
We could merge the QgsPoint and QgsPointXY classes
Typecasting to and from QgsGeometry should have more descriptive function names than get() and set().
(According to the documentation set() will be removed from the python api in qgis4 anyway)
@raymondnijssen I think parts of this does not require QGIS 4. Mainly because inheritance is not involved in the way your comment suggest.
You can already right now today add a new method
QgsGeometry QgsGeometry::buffer()
{
.... write some code that calls QgsAbstractGeometry::buffer on the contained geometry.
}
PS: and I am very much in favor of doing this!! This will mean that there is less reason to actually call get() and constGet() which will make the API way easier to use.
Since the merge of the new geometry engine, the role of QgsGeometry is undefined. It currently acts as just an implicitly shared container for a QgsAbstractGeometryV2, plus a random bunch of methods for modifying and converting the geometry.
I'd like to see this refined in QGIS 3.0. My thoughts:
What would remain in QgsGeometryContainer would be:
The text was updated successfully, but these errors were encountered: