This adds a new "Model Variables" dock panel to the model editor, allowing
users to create and set custom expression variables for use in the model.
These variables are available anywhere expressions are (correctly) evaluated
within the model, so can be used as input parameter values for child
algorithms, within data-defined dynamic parameters, etc.
The use case here is for models which use a constant value throughout
multiple steps within the model (e.g. @target_resolution: a target
raster resolution, @max_simplification: a simplification value for
input features coming from different sources, etc), allowing users
one single place to define and edit these constant values (instead
of hunting down and setting them in multiple places throughout the model).
These variables are stored within the model itself, and are not exposed
outside of the model designer dialog.
OTB only supports gdal and ogr providers for now. Maybe memory
provider can be easily supported using some conversion on the fly.
For the moment, we can go with this method. IO Formats in OTB not
using GDAL/OGR (LUM, ONERA) are not supported by QGis. Those can be
treated as simple files.
nyalldawson, pointed that AUTHORITY id can have types not starting
with 'EPSG:'. Current otb takes just EPSG number and run with it. The
algorithm doesn't know what to with a number which is not EPSG because
it uses Gdal's 'ImportFromEpsg' method AFAIR.
QgsProecessing Exception is raised in both the above invalid cases.
This can easily go into GuiTests.py but we tend to keep it out due to
usage of create_from_metadata(). All widget in GuiTests uses
create_from_class() which will not work for this special widget
* fixes#20516 : Allow Constraint widget in attribute type form to be empty so expression could be removed
per widget modification
* correct tests
* Add the clear button on field expression widget when widget is allowed to be empty
* Change API since version to 3.6
This is a continuation of:
- #8db3dead87e385f2798356d
- #5c97d22b16320874dbe1
This commit only affects users that have multiple GRASS installations on
their Macs. Using the most recent GRASS version is what we do on Linux too.
After @Nyalldawson suggestion [1], we've implemented a Processing plugin
that exposes a GRASS Addon [2]. In order to do this we had to subclass
`Grass7AlgorithmProvider` and override `createAlgsList()`.
`createAlgsList()` had to be overriden in order to change the
"description folder" location.
Nyall wrote:
> And if you do it right (and only import existing
> processing grass code, minimising the copy/paste of this code), then
> your provider will automatically inherit any future fixes and
> features added to the main grass provider.
With this commit we convert the `descriptionFolder` to a class attribute
and in this way, subclasses of `Grass7AlgorithmProvider` will no longer
have to override `createAlgsList()` and will be able to continue inheriting
future enhancements.
References:
1. https://lists.osgeo.org/pipermail/qgis-developer/2019-February/056155.html
2. 948820b1c0/estimap_recreation_provider.py (L40-59)
This potentially avoids a second expensive feature request after
building a spatial index and later needing to re-request features
which match spatial index search.
It's non-default, as it requires the index to store all feature
geometries, so it's more memory expensive.
