- Fix loss of coordinates when not rounding a particular dimension
- Don't segmentize curved geometries
- Add extra unit tests
- Make createEmptyWithSameType() protected and skip from Python bindings.
This method relies on low-level manipulation of the returned geometry
which we do not want to expose as public/fixed API
Because feature.geometry().geometry() is confusing, and impossible
to search for in python code (e.g. is input.geometry() a QgsGeometry
or a QgsAbstractGeometry?)
But more importantantly: also add a const version
QgsGeometry::constGet(). The non-const
version is slow, since it now forces a detach to avoid corrupting
geometries (since QgsGeometry is shared, it's not safe to directly
access its primitive QgsAbstractGeometry and start messing with
it without first detaching). This is a big risk in the 2.x API
which could potentially corrupt feature geometries with unexpected
outcomes.
Update all uses to constGet where possible.
By moving logic to abstract geometry subclasses so that they
can trivially retrieve the vertex number, instead of relying
on the inefficient coordinateSequence method.
Has flow on speed boosts to many geometry operations like
calculation of closest points in a geometry, which will
benefit snapping related operations.
Previously the method in QgsGeometryUtils was relying on
QgsAbstractGeometry::coordinateSequence, which is an absolute
performance killer.
Instead move to optimised methods in the various abstract
geometry subclasses which rely only on trivial calculations.
Introducing:
1. STL-style iterator: QgsAbstractGeometry::vertex_iterator
2. Java-style iterator: QgsVertexIterator (built on top of STL-style)
The iterators are modeled after Qt's STL-style and Java-style iterators,
the idea is to replace nextVertex() method and later introduce iterators
for other bits (e.g. part_iterator, ring_iterator).
In python, the wkb type of a QgsPoint will by default be determined from
the provided parameters, where Z and M will be added as required if the
wkbType is Undefined.
QgsPoint(x, y, z=nan, m=nan, wkbType=QgsWkbTypes.Undefined)
Thanks to the python API support of named parameters, it's also
straightforward to specify z, m and wkbType in any desired combination.
On the other hand, on C++ side it's often preferable to use
QgsPoint(QgsWkbTypes::WkbType wkbType, double x, double y, double z, double m);
due to the lack of named parameters which make it harder to specify a
specific type and the advantage of typesafety that makes it possible to
verload the first constructor with this one.
