"Extract within distance" algorithms
These algorithms allow users to select or extract features from one
layer which are within a certain distance of features from another
reference layer.
The distance checking is heavily optimised, using spatial indices
to restrict the number of features retrieved, and also automatically
handing the check off to the database server for postgis layers.
The distance parameter can also be data-defined.
Sponsored by QTIBIA Engineering
Allows users to select a list of fields to keep, and all other fields
will be dropped from the layer. Helps with making flexible models where
input datasets may have a range of different fields and you need to drop
all but a certain subset of these
This algorithm calculates the rotation required to align point features
with their nearest feature from another reference layer. A new field is
added to the output layer which is filled with the angle (in degrees,
clockwise) to the nearest reference feature.
Optionally, the output layer's symbology can be set to automatically
use the calculated rotation field to rotate marker symbols.
If desired, a maximum distance to use when aligning points can be set,
to avoid aligning isolated points to distant features.
Designed for use cases like aligning building point symbols to follow
the nearest road direction!
When an algorithm returns this flag, and after executing it in a model it doesn't set a
certain output which remaining model algorithms depend on, then these branches are
pruned back and don't get executed for the model run.
Allows for creation of algorithms which impact the overall model flow.
This algorithm filters features by their geometry type. Incoming
features will be directed to different outputs based on whether
they have a point, line or polygon geometry.
Allows for model creation which responds to different input
layer geometry types by applying different logic depending on the
input geometry type.
Takes an input layer, existing field and a new name for the field, and
outputs a new layer with the selected field renamed.
While this result could also be achieved with the Refactor Fields
algorithm, Refactor Fields isn't particularly model friendly. It
relies on a constant, fixed table structure, and can't adapt to
input tables with different field structures.
In constrast, this simple Rename Field algorithm adapts nicely for
model use, because it operates on a single field only and leaves
all the other fields untouched.
Offers the following benefits over the GRASS/SAGA versions:
- Full support for z/m values and handling curved geometries without loss
of curves
- Works with all native data types, no need for format transformation
- Supports dynamic (data defined, per feature) translate/scale/rotate parameters
- Allows transformation and scaling of both Z and M values (if present)
- Supports in-place edit mode
Fixes#33550
This algorithm splits features into multiple output features by
splitting a field's value with a specified character.
For instance, if a layer contains features with multiple comma
separated values contained in a single field, this algorithm can
be used to split these values up across multiple output features.
Geometries and other attributes remain unchanged in the output.
Optionally, the separator string can be a regular expression for
added flexibility.
Designed for use in models which need to process input files
with multiple concatenated values in a single attribute, e.g.
geocoding a table with "address1,address2,address3" format strings
This algorithm calculates the area and percentage cover
by which features from an input layer are overlapped by
features from a selection of overlay layers.
New attributes are added to the output layer reporting
the total area of overlap and percentage of the input
feature overlapped by each of the selected overlay layers.
This is quite a common GIS task request, yet is full
of traps for inexperienced users, and the amount of
manual data work usually done by users to calculate
these figures can often lead to mistakes and inaccurate
results. It's nice to have a robust, fast, inbuilt
algorithm which allows this task to be done in a
single step without risk of human error.
There's two motivations for this:
- the existing one was getting massive and took ages to run, which was
a pain when developing. Smaller batches allow just a subset of test to
be run which is much faster.
- There's a random segfault on test exit which occurs on Travis. Rather
then disabling these absolutely critical tests altogether, I'm using
this as a method of bisecting exactly which alg is causing this.
