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
of main algorithm
Using code like:
buffered_layer = processing.run(..., context, feedback)['OUTPUT']
...
return {'OUTPUT': buffered_layer}
can cause issues if done as a sub-step of a larger processing algorithm. This
is because ownership of the generated layer is transferred to the caller
(Python) by processing.run. When the algorithm returns, Processing
attempts to move ownership of the layer from the context to the caller,
resulting in a crash.
(This is by design, because processing.run has been optimised for the
most common use case, which is one-off execution of algorithms as part
of a script, not as part of another processing algorithm. Accordingly
by design it returns layers and ownership to the caller, making things
easier for callers as they do not then have to resolve the layer reference
from the context object and handle ownership themselves)
This commit adds a new "is_child_algorithm" argument to processing.run.
For algorithms which are executed as sub-steps of a larger algorithm
is_child_algorithm should be set to True to avoid any ownership issues
with layers. E.g.
buffered_layer = processing.run(..., context, feedback, is_child_algorithm=True)['OUTPUT']
...
return {'OUTPUT': buffered_layer}
Instead of requiring clients to generate temporary file names themselves,
(or use the cryptic "memory:" string!), this PR adds a static constant
QgsProcessing.TEMPORARY_OUTPUT
If a layer/sink output parameter is set to QgsProcessing.TEMPORARY_OUTPUT,
then the temporary output filename will be generated automatically at
algorithm run time. This means callers don't need to mess around with
finding appropriate temporary folders and paths.
Another benefit is that TEMPORARY_OUTPUT is stored in the processing
history, so if you re-run a previous algorithm which was set to
output to a temporary file, it no longer tries to use that same
previous temporary path and instead generates a new one.
This algorithm cannot output cross-validation results and topographic
parameters simultaneously, hence two tools needed. Thanks to Pedro Venâncio
for finding this and proposing a fix.
(fix#20586).
Without this parameter it is not possible to remove collars surrounding
input raster which may overlap with other input rasters. As this is very
frequent case algorithm is useless without such parameter. To keep API
compatibility new parameter is optional and not used by default.
This allows users to pass additional command-line arguments which are
not exposed in the algorithm definition. The most frequent use case is
enabling transparency and adding nodata values.
The SAGA version of this algorithm is of limited use in QGIS, because the
volume calculated is embedded only in the SAGA terminal output. This prevents
it being saved to a file, or reused within a model as an input to a later
model step.
It's also very user-unfriendly, because users must know to manually scan
the algorithm log to find the SAGA output.
Given that the maths here is trivial, this commit ports the algorithm across
to be a native QGIS c++ algorithm. The algorithm duplicates the SAGA alg
1:1, but outputs the volume (and area) to either a HTML report, or a vector
table. Additionally, the outputs are exported as numeric outputs from the
algorithm, allowing them to be re-used within models.
(It's also considerably faster, because it avoids the forced conversion
to SAGA raster format)
Fixes#8607 (properly, even though that report is closed)
This allows optional creation of geodesic lines, which represent the
shortest distance between the points based on the ellipsoid.
When geodesic mode is used, it is possible to split the created lines
at the antimeridian (±180 degrees longitude), which can improve
rendering of the lines. Additionally, the distance between vertices
can be specified. A smaller distance results in a denser, more accurate
line.
Ports the similar algorithm from the shape tools plugin to c++, and utilises
built in QgsDistanceArea ellipsoidal calculations to split the lines.
This algorithm splits a line into multiple geodesic segments, whenever the
line crosses the antimeridian (±180 degrees longitude)
Splitting at the antimeridian helps the visual display of the lines in some
projections. The returned geometry will always be a multi-part geometry.
Whenever line segments in the input geometry cross the antimeridian,
they will be split into two segments, with the latitude of the breakpoint
being determined using a geodesic line connecting the points either side
of this segment. The current project ellipsoid setting will be used when
calculating this breakpoint.
If the input geometry contains M or Z values, these will be linearly
interpolated for the new vertices created at the antimeridian.
Supports in-place edit mode also.
These algorithms allow users to convert z or m values present in feature
geometries to attributes in the layer. By default the z/m value from the
first vertex in the feature is extracted, but optionally statistics
can be calculated on ALL the z/m values from the geometry (e.g. calculating
mean/min/max/sum/etc of z values).
Like the vector zonal stats algorithm, but this one works with
the zones defined in another raster.
Iterates over the input rasters in blocks to be nice and
memory efficient.
From the algorithm help:
"This algorithm calculates statistics for a raster layer's
values, categorized by zones defined in another raster layer.
If the reference layer parameter is set to "Input layer",
then zones are determined by sampling the zone raster layer
value at the centroid of each pixel from the source raster
layer.
If the reference layer parameter is set to "Zones layer",
then the input raster layer will be sampled at the centroid
of each pixel from the zones raster layer.
If either the source raster layer or the zone raster layer
value is NODATA for a pixel, that pixel's value will be
skipped and not including in the calculated statistics."
