This algorithm compares two vector layers, and determines which features
are unchanged, added or deleted between the two. It is designed for comparing
two different versions of the same dataset.
When comparing features, the original and revised feature geometries will be
compared against each other. Depending on the Geometry Comparison Behavior setting,
the comparison will either be made using an exact comparison (where geometries must
be an exact match for each other, including the order and count of vertices) or a
topological comparison only (where are geometries area considered equal if all of
the their component edges overlap. E.g. lines with the same vertex locations but
opposite direction will be considered equal by this method). If the topological
comparison is selected then any z or m values present in the geometries will not
be compared.
By default, the algorithm compares all attributes from the original and revised
features. If the Attributes to Consider for Match parameter is changed, then only
the selected attributes will be compared (e.g. allowing users to ignore a timestamp
or ID field which is expected to change between the revisions).
If any features in the original or revised layers do not have an associated geometry,
then care must be taken to ensure that these features have a unique set of
attributes selected for comparison. If this condition is not met, warnings will be
raised and the resultant outputs may be misleading.
The algorithm outputs three layers, one containing all features which are considered
to be unchanged between the revisions, one containing features deleted from the
original layer which are not present in the revised layer, and one containing features
add to the revised layer which are not present in the original layer.
* [FEATURE] Allow customization of the items show is browser. User can select in Interface Customization dialog to hide some of the items in the browser panel
Funded by Limerick City and County Council
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.
position in status bar
When a GPS device is connected, whenever the user moves the cursor
over the canvas a live status bar message displays the distance
and bearing from the cursor to the GPS fix position.
Project distance and bearing settings are respected in this display.
operation is in progress
This causes the status bar coordinates widget to show nonsense coordinates
during the pan operation. The cursor world position ISN'T changing during
a pan operation, it stuck to a fixed location!
E.g. when joining a 7 feature polygon layer to a 3.2 million feature polygon
layer, processing time (on a debug build) has dropped from 696 seconds
to 1.3 seconds
to take attributes from matching feature with largest area of overlap only
This allows for easy polygon->polygon joins, where you expect there to be
only a single matching feature and don't want to include features which
are just touching or have just tiny sliver polygon overlaps.
Sponsored by SMEC/SJ
Where selecting a cell and then typing enters a "weak" edit mode, whereby
pressing a cursor key will immediately end editing and move to another
cell. But double-clicking a cell to edit enters a "strong" edit mode,
where cursor key presses are used to navigate through the current
cell text
