We no longer require the seperate CRS parameter, because the extent
parameter contains the CRS information itself. This means the algorithm
is simplified to just picking the layer and drawing the desired area
on the canvas.
Include descriptive text with the specified parameter value
in error, and always check that sources were loaded to avoid
raw Python exceptions when they are not
This forces Python code and plugins to become datum transform
aware, and given that upgrading python code is easy (just
add QgsProject.instance() as a new argument to the constructor)
it's relatively painless to force this on PyQGIS users.
Also fix upgrade the easy QgsCoordinateTransform c++ constructors
where the project is available, or where using QgsProject::instance()
is safe to do.
For others, just avoid the deprecated warnings until we can
get access to the correct project instance where the transform
is being constructed.
Also modify alg to export a vector table of candidates instead of
a HTML list, since a vector table is more useful inside of
models and can be used for further analysis steps.
initAlgorithm() method
This allows 2 benefits:
- algorithms can be subclassed and have subclasses add additional
parameters/outputs to the algorithm. With the previous approach
of declaring parameters/outputs in the constructor, it's not
possible to call virtual methods to add additional parameters/
outputs (since you can't call virtual methods from a constructor).
- initAlgorithm takes a variant map argument, allowing the algorithm
to dynamically adjust its declared parameters and outputs according
to this configuration map. This potentially allows model algorithms which
can be configured to have variable numbers of parameters and
outputs at run time. E.g. a "router" algorithm which directs
features to one of any number of output sinks depending on some
user configured criteria.
have specific icons, instead of generic qgis icon
We consider these 'top level' algorithms, and using the
standard algorithm icon should help reflect this and
differentiate them from 3rd party algorithms.
Algorithms and other processing code should use this method
(instead of dataobjects.getLayerFromString) to
retrieve layers from a string, as it considers the processing
context and allows resolving strings to temporarily stored layers.
This permits processing models to function correctly when
intermediate results are stored as memory layers. Subsequent
model algorithms can then access these temporary layers as inputs.
All temporary layers will be removed when the context object
is destroyed after the model algorithm is run.
Also
- simplify and add tests
- remove large memory leak (persistant store of all non-project layers)
- remove broken support for direct loading postgres/virtual layers
by string (Python version was very broken and would never match
a postgres/virtual layer)
If you have a layer with an unknown CRS, this algorithm gives a list
of possible candidate CRSes which the layer could be in.
It allows users to set the area (and corresponding CRS) which they know
the layer should be located near. The algorithm then tests every CRS
in the database to see what candidate CRSes would cause the layer
to be located at that preset area.
It's much faster than it sounds!! (just a couple of seconds)
Sponsored by SMEC/Surbana Jurong
