Because:
- it's unused in master, and is more code to maintain
just for possible use by plugins
- it's unmaintained, and has had no work done (beside compilation
fixes) in the recent past
- there's no unit tests or detailed documentation to show
how the class should be used
These classes are unused in the master QGIS code, and are
unmaintained and with no unit tests or other QA, and
have inflexible API (e.g. always requiring writing outputs
to shapefiles)
They all have equivalent algorithms available via Processing
(where the algorithms are unit tested and maintained). We should
be pushing all QGIS api users to use the Processing algorithms
instead.
Used for snapping geometries within a set of features to other
features from that same set.
Just like QgsGeometrySnapper, except that where QgsGeometrySnapper
requires a separate reference layer to snap to
QgsInternalGeometrySnapper snaps *within* a single layer. E.g.
allows you to close gaps within that layer.
With a new option to prefer to snap to closest point on geometry.
The old behaviour was to prefer to snap to nodes, even if a node
was further from the input geometry than a segment. The new option
allows you to snap geometries to the closest point, regardless
of whether it's a node or segment.
All pointer based methods have been removed.
Now we have only:
void setGeometry( const QgsGeometry& geom )
and
QgsGeometry geometry() const
Benefits include avoiding a whole lot of tricky pointer lifetime
issues, potential memory leaks, and finally closing #777, which
has survived for over 9 years!...
Impacts on PyQGIS code:
- no more need for the messy
g = QgsGeometry( feature.geometry() )
workaround, just use g = feature.geometry() instead
- IMPORTANT: you can no longer test whether a feature has geometry
using `if f.geometry():`, since QgsFeature::geometry() will
*always* return an object. Instead, use
`if not f.geometry().isEmpty():`, or preferably the new method
`if not f.hasGeometry():`
Fix#777
Rationale:
- there was a lot of large objects passed by value, so potentially
there's a speed bump from this
- even for implicitly shared classes like QString/QList there's still
a (small) cost for copying the objects when there's no reason to
- it's the right thing to do!
