This commit adds an epoch() function to the expression engine which
returns the interval in milliseconds between the unix epoch and a
given date value.
This adds a new item_variables expression function when expressions
are used inside a composition context.
The function takes a single argument, the id for an item inside
the composition, and returns a map of variable name to value
for that item.
This allows you to do things like insert text in a label fetching
properties of another item in the composition, eg
Insert scale of map into a label:
map_get( item_variables( 'map'),'map_scale')
Insert x coordinate of map center into a label:
x(map_get( item_variables( 'map'),'map_extent_center'))
- support negative start value (e.g. substr('hello',-2) returns 'lo')
- support negative length value (e.g. substr('hello',3,-1) returns 'll')
- length parameter now optional, defaults to end of string
(e.g. substr('hello world',7) returns 'world')
The new function returns an array of strings captured by capturing
groups in a supplied regular expression. For e.g., the following
expression: regexp_matches('qgis=>rocks','(.*)=>(.*)')
will return the following array: 'qgis', 'rocks'.
* is_selected() returns if the current feature is selected
* num_selected() returns the number of selected features on the current layer
* is_selected(layer, feature) returns if the "feature" is selected. "feature"
must be on "layer".
* num_selected(layer) returns the number of selected features on "layer"
The Expression LIKE binary operator does not care about escape % and _ char.
No-one has already open an issue about it but in the OGC element PropertyIsLike the user can defined is own wild and single char. This mean that QGIS has to escape % and _ if they are not used as wild and single char.
Exposes simplification and smoothing algorithms to expression
engine, via:
- simplify(): applies Douglas-Peucker geometry simplification
- simplify_vw(): applies Visvalingam-Whyatt geometry simplification
- smooth(): smoothes a geometry
Carto tip: use smooth along with geometry generators to minimise
the typical "GIS" noded look of rendered geometries!
angle_at_vertex: returns average (bisector) angle to a geometry
at a specified vertex index
distance_to_vertex: returns distance along geometry to a specified
vertex index
line_interpolate_angle: calculates the angle parallel to a geometry
at the specified distance along the geometry
Sponsored by Andreas Neumann
This feature adds a 'collect' aggregation method resulting in a
single multipart geometry from a list of geometries. This is exposed
in the expression engine via the existing aggregate() function,
as well as a new collect() function.
Adds new functions
- line_interpolate_point: interpolates a point by a given distance
along a linestring geometry
- line_locate_point: returns the distance along a linestring to
the closest position on the linestring to a given point
Adds a new method to QgsGeometry for merging linestrings.
By passing a multilinestring, any connected lines will
be joined into single linestrings. Behind the scenes this
uses GEOS' line merge.
A corresponding expression function "line_merge" has also
been added.
This commit adds a number of different forms of aggregates to
the expression engine.
1. Aggregates within the current layer, eg sum("passengers")
Supports sub expressions (ie sum("passengers"/2) ), group by
( sum("passengers", group_by:="line_segment") ), and optional
filters ( sum("passengers", filter:= "station_class" > 3 ) )
2. Relational aggregates, which calculate an aggregate over
all matching child features from a relation, eg
relation_aggregate( 'my_relation', 'mean', "some_child_field" )
3. A summary aggregate function, for calculating aggregates
on other layers. Eg aggregate('rail_station_layer','sum',"passengers")
The summary aggregate function supports an optional filter,
making it possible to calculate things like:
aggregate('rail_stations','sum',"passengers",
intersects(@atlas_geometry, $geometry ) )
for calculating the total number of passengers for the stations
inside the current atlas feature
In all cases the calculations are cached inside the expression
context, so they only need to be calculated once for each
set of expression evaluations.
Sponsored by Kanton of Zug, Switzerland
This commit sets the framework for allowing expression functions to
use named parameters. Ie, instead of:
clamp(1,2,3)
you can use:
clamp( min:=1, value:=2, max:=3)
This also allows arguments to be switched, eg:
clamp( value:=2, max:=3, min:=1)
Additionally, it allows for a more structured definition of function
parameters to handle optional arguments and default values for
parameters. These are currently being done using a hacky infinite
argument list.
I've utilised the postgres ':=' syntax for specifying named arguments
to avoid potential collisions which may arise with the equality test
if we re-used just the '=' operator alone.
Sponsored by North Road