This algorithm extracts point features corresponding to the minimum
and maximum pixel values contained within polygon zones.
The output will contain one point feature for the minimum and one
for the maximum raster value for every individual zonal feature
from a polygon layer.
This algorithm extracts extrema (minimum and maximum) values
from a given band of the raster layer.
The output is a vector layer containing point features for
the selected extrema, at the center of the associated pixel.
If multiple pixels in the raster share the minimum or maximum
value, then only one of these pixels will be included in the output.
The algorithm uses raster iterator to remain efficient on huge
rasters, and does not require reading the entire raster to
memory
And add to "Advanced Python field calculator" algorithm, as that
algorithm uses the Python exec() function and is a security
risk if run with untrusted/unchecked inputs
The older approach of storing parameters was insecure, and required
eval()ing the unchecked contents of the batch parameter file. This
is a security risk, as a malicious file could leak user information
or damage the system.
So,
- Switch to a newer ".batch" format which uses safe JSON objects
only for serializing parameter values.
- Allow loading the older .json files, but first show a warning
that they are a security risk and require to user to explicitly
agree to open the file
"forward declare" functions which will be patched when the processing
plugin starts, so that these are known and accessible during the PyQGIS
doc building. Also make these forward declared versions raise
QgsNotSupportedException, so that its clear why they aren't working
when the processing plugin hasn't started
Fixes https://github.com/qgis/pyqgis-api-docs-builder/issues/38
export the layer to an OGR compatible source first
Use the same logic we use eg for auto-exporting memory layers
so that GDAL tools "just work" with GRASS provider vector
layers
The inputs we use for these run tests have open options, and now
that we are respecting these and passing them to the GDAL command
we can't run these tests on the earlier GDAL versions which
didn't support open options.
The commands generated by the corresponding algorithms are already
well tested and still run on the earlier GDAL releases, it's just
the actual run test which will be skipped.
We now pass on the FORCE_SRS_DETECTION=YES open option which we
were previously dropping, so the results for these commands is
slightly different
Also drop test for older GEOS versions, it's covered by a test
for more recent versions and we have extensive test covering
the GDAL command line for this tool anyway.
