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
Now that the extra features of the "polygon from vector layer extent"
algorithm are covered by the new "Minimum bounding geometry" algorithm,
we can replace the previous two "polygon from vector extent" and
"polygon from raster extent" algorithms by a single "polygon
from layer extent" algorithm.
feature based algorithms
Instead of algorithms which handle both whole layers/groups
of features/individual features, we leave the whole layer
and group of features handling to the "Minimum bounding
geometry" algorithm.
The feature-by-feature algorithms are now native c++
algorithms.
This affects:
- bounding boxes
- convex hulls
- minimum enclosing circle
- minimum oriented rectangles
This algorithm creates geometries which enclose the features
from an input layer.
Numerous enclosing geometry types are supported, including
bounding boxes (envelopes), oriented rectangles, circles and
convex hulls.
Optionally, the features can be grouped by a field. If set,
this causes the output layer to contain one feature per grouped
value with a minimal geometry covering just the features with
matching values.
This is only used by virtual layers, but it
might be handy for others too and now I can
start to remove all specialized source
select add methods from the datas source
manager dialog.
This is only the first step: next is looping
through the source select provider registry
to get all needed GUI elements for the dialog.
required connections to a QgsLocator
Use this QgsLocatorModel subclass when you want the connections
between a QgsLocator and the model to be automatically created
for you. If more flexibility in model behavior is required,
use the base QgsLocatorModel class instead and setup the
connections manually.
Instead move it to a private QgsGeometry member. It's copied
with QgsGeometry, but not the underlying private geometry
data.
This means the error string can be changed without detaching
(and copying) the geometry data.
Also make greater use of error string for all use of GEOS
functions.
Instead of just forcing writing the triangulation to a shapefile (boo!)
change the parameter to use a QgsFeatureSink, so that anything
which implements the QgsFeatureSink interface can be used for
storing the triangulation.
These classes still need a lot of cleanup (e.g. use of proper
3d geometry classes instead of their own 3d line classes, etc)
and we don't want them locked into the 3.0 API.
Better to remove them from the API and reintroduce them after
they have been cleaned up (in >3.0). They are mostly implementation
details anyway, and unlikely to be used outside of the high
level interpolation classes.
We don't want these part of stable API - this namespace really shouldn't
exist, as it mostly contains code which is duplicated in other
parts of the API (with better maintained and tested versions).
