These algorithms calculate the boolean OR or AND for a set of input
rasters. For AND, if all of the input rasters have a non-zero value
for a pixel, that pixel will be set to 1 in the output raster, otherwise
it will be set to 0. For OR, if ANY of the input rasters have a non-zero
value for a pixel, that pixel will be set to 1 in the output raster,
else 0.
A reference layer parameter specifies an existing raster layer to use
as a reference when creating the output raster. The output raster will
have the same extent, CRS, and pixel dimensions as this layer
By default, a nodata pixel in ANY of the input layers will result in
a nodata pixel in the output raster. If the 'Treat nodata values
as false' option is checked, then nodata inputs will be treated the
same as a 0 input value.
Makes for much simpler raster boolean logic calculation without
the complexity of using the raster calculator (and that's not
always possible to do anyway, e.g. when ANY of the input rasters
has a nodata pixel). It's also scalable dynamic to any number of
input rasters (unlike raster calc), so is more flexible when
used within models.
Fixes:
- enum parameters set to "allow multiple" only allow a single
value selection when used in modeler
- optional enum parameters cannot be set to no value when
used outside of modeler
Fixes#20406
And add a Processing setting to allow these to be shown. When shown, they
are highlighted in red with a tooltip explaining that the algorithm
has known issues
implements Processing providers
Plugins which implement providers should include the
hasProcessingProvider=yes
line within their metadata.txt file. This allows for rapid
identification of all plugins which implement Processing
functionality.
* 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.
