This commit adds a new mode to the attribute table dialog for searching
and filtering features. When activated (using a button on the toolbar
or by pressng CTRL+F), the dialog will switch to form view and all
widgets are replaced with their search widget wrapper variant.
Alongside each widget is a tool button with options for controlling
the search/filter behaviour for that field, eg "equal to", "not equal
to", "is null", "greater than", etc.., with the options presented
matching themselves to the corresponding field and widget type.
New buttons appear at the bottom of the form for either selecting
matching features (with options for add to selection/remove from
selection/select within current selection) or filtering features
in the table (with options for adding features to a current filter
or further restricting a current filter).
Sponsored by SIGE
fix#14582
See: https://hub.qgis.org/issues/14582
The commit removes the a-flag when the grass region for raster analysis is set. The a-flag causes in some cases unwanted rounding of raster extend / resolution, and should not be set hardcoded in processing. It is usually used in combination with the "res" option.
For aligning the pixels of the GRASS region to a specific raster, the align option should be used (and not the a-flag). See: https://grass.osgeo.org/grass70/manuals/g.region.html
GRASS 6.4 algs do not use the a-flag either, which explains why this bug appears only for GRASS 7.
* Some formats require a compulsory encoding, typically UTF-8.
Change initMetadata() to indicate UTF-8 compulsory encoding for
GeoJSON, GeoRSS, GML, GPKG, GPX, KML, SQLite, SpatiaLite, FileGDB,
XLSX and ODS
* QgsVectorFileWriter::init(): make it override the user specified
encoding if the format has a compulsory encoding. And remove hard-coded
case for KML.
- add selectByRect( QgsRectangle&, SelectBehaviour) and
selectByIds( QgsFeatureIds, SelectBehaviour) for selecting
by rect and ids respectively, with options to add to selection/
remove from selection/intersect with current selection
- deprecate select( QgsRectangle ) and setSelectedFeatures in
favour of new methods
- add unit tests
Makes it simple for scripts to select by expression. The method
also accepts a parameter which dictates whether matching features
are added to an existing selection, removed from the selection
or intersected with the current selection.
The existing code from the select by expression dialog has been
moved to QgsVectorLayer, and optimised for maximum possible speed.
Also added unit tests.
This adds a new option in composer map properties:
"Follow visibility preset" with a combo box to choose the active preset.
This is an alternative to "lock layers" (and "lock layer styles") functionality
which would just copy preset's configuration, while the new option links to preset.
The difference is that when a preset is updated, composer map will automatically
pick the new configuration when following the preset, while there is no update
if "lock layers" (and "lock layer styles") option is used.
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
Can be used to store the results of expensive sub-expression
calculations (eg layer aggregates), so that future expression
evaluation using the same context does not have to recalculate
the cached values.