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.
This command adds a plugin to active plugins and calls initProcessing(),
initializing only Processing related components of that plugin.
The new initProcessing() hook should be implemented by plugins
which provide Processing providers or algorithm, and should only
implement code which is required to load the provider and algorithms.
Strictly no GUI related code should be used here, that MUST
be moved out of initializers and deferred to the plugin's
initGui implementation.
For non-point geometry subclasses (points are always valid!) we
now cache the results of a geometry validity check. Subsequent
checks utilise the cached result wherever possible.
Because QgsGeometry/QgsFeature objects are implicitly shared, this
means that we avoid a *lot* of duplicate validity checks as
features and geometries are thrown around during processing model
execution.
The new behavior is to store a value in user's QSettings
(that overrides the global settings) only if the the value
has changed from the default reported by QgsSettings.
If a value was changed and it is changed back to the default
the override must be removed from the user settings.
The rationale is that global settings should be the ultimate
source of default values, unless the user override the
default with a different value.
Fixes#21049
For the c++ api dox this expands to "\c nullptr" (the
\c directive indicates a code literal value), and for sipify/Python
it expands to ``None`` (`` is sphinx annotation for literal values)
Makes for nicer dox for both c++ and Python!
