The scale_exp function renamed to scale_polynomial and has an alias
scale_exp to preserve backward compatibility.
A new function using correct formula was added as scale_exponential.
After 6fcef30cc50, group separators were always included in the
results from format_number (even if a locale which doesn't use
them like the 'C' locale is specified). 6fcef30cc50 was added
to fix an old regression, but in doing so we lost flexibility
to skip unwanted separators.
Workaround this by introducing a new opt-in omit_group_separators
argument for format_number to skip the thousand separators when
desired. Also add an opt-in trim_trailing_zeroes argument for
further flexibility.
Allows for retrieving the feature ID of a feature object. Accepts
one argument which must be a feature object. Accordingly this
function can be used with the results of any other function
which returns feature objects, such as "get_feature", "overlay_*",
etc.
Fixes#51116
This function (available only in Processing expressions for now),
allows loading a map layer via a source string and provider name.
It is designed to allow use of the expression functions which
directly reference map layers (such as the aggregate functions)
with a hardcoded layer path, eg. then permitting these functions
to be used outside of a project (such as via the qgis_process tool)
This adds a newer style variable form of referencing the current
feature and its attributes in expressions.
The newly introduced variables are:
- @feature: a replacement for $currentfeature, contains the
current feature
- @id: a replacement for $id, contains the current feature id
- @geometry: a replacement for $geometry, contains the current
feature geometry
This is intended as a step towards eventually deprecating the
older $ style functions, and providing a more consistent
approach to expressions instead of the older unpredictable mix of @/$.
For now these old functions still work (and likely will ALWAYS
remain working for old project compatibility), AND they are also
still exposed in the UI just to avoid user confusion (eventually
we can hide them).
Returns a collection containing paths shared by the two
input geometries. Those going in the same direction are
in the first element of the collection, those going in
the opposite direction are in the second element. The
paths themselves are given in the direction of the first
geometry.
(Exposes the GEOS shared paths functionality for use
in expressions.)
- Make it more obvious that the distance is in CRS units, not a percentage, on the first example
- Add example that ends up with floating point coordinates
- Add example that returns NULL
