* include processing algorithm descriptions from yaml (with yaml fixes)
* create ui instead of cpp where possible and use -no-ui-lines to avoid
artificial ever changing line numbers in ts files
* drop old used scripts: create_new_ts.sh, create_new_ts.sh and
integrate_function_help.pl, update_ts_files.sh
causing rings errors
By default the algorithm now uses the strict OGC definition of polygon validity, where
a polygon is marked as invalid if a self-intersecting ring causes an interior hole.
If the "Ignore ring self intersections" option is checked, then this rule will be
ignored and a more lenient validity check will be performed.
Refs #16418, refs #21336
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
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)
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.
