values should be reused when creating new features
While there has long been a global option that causes ALL field
values for ALL layers to be remembered and reused during a QGIS
session when creating new features, this new setting offers
per-layer, per-field control over whether values should be
reused.
It allows for finer control over form behavior, where eg some
values may be desirable to reuse but others should be cleared
or set from default value expressions.
When enabled, this snapping mode snaps to the beginning or end
vertex of lines only. When snapping to a polygon layer, only
the first vertex in rings will be snapped to.
Refs Natural resources Canada Contract: 3000720707
for when a URI cannot be opened in a QGIS install, but the URI
matches a format which could potentially be opened in a different QGIS
install.
This can be used to show user-friendly warning messages advising user why
a particular uri cannot be opened on their QGIS install. For example, if
a QGIS install is built without the PDAL library then las/laz files are
unusable, and this method can be used to retrieve a user-friendly warning
as to why the las/laz files cannot be used on their QGIS build.
Instead of just showing the user a generic "not a valid or recognized data
source" error, we can use this api to show more helpful URIs about the
specific uri.
Initially intended to help advise users why LAS/LAZ files cannot be
opened on their QGIS install, but also could be used e.g. by mdal
to advise users about missing third party libraries preventing
them from opening certain mesh files, etc....
calculations
Since GRASS upstream is moving away from the previous calculations which
all of QGIS' ellipsoidal distance/areas formulas are based on, let's
follow suit and delegate all these calculations to the GeographicLib
routines exposed through the PROJ api.
Refs https://github.com/OSGeo/grass/pull/1283
stage, be more intelligent about compiling AND or OR nodes
We can take advantage of the fact that and AND node will ALWAYS
be false if either input node is static and evaluates to FALSE,
and that OR nodes will always be true if either input is static
and evaluates to TRUE.
In some cases this allows us the shortcut and cut out non-static
nodes during preparation, resulting in faster evaluation and
more easily compiled expressions...
and destination points
Allows users to data define the starting and ending points for
label callout lines, which is useful when needing to manually
control the exact placement of individual callout lines.
add an explicit log level getter/setter to QgsProcessingContext which
algorithms can use to determine an appropriate level of feedback
to push to users.
Initially the verbose log only triggers the full verbose output
of model executions (which is also used when running models through
the model designer), but the intention is that more algorithms
will fine tune their output based on the logging level.
qgis_process also gains a new --verbose switch to enable verbose
log output.
* hopefully fixes CRS problem
* fix the 3D map position shift
* remove qDebug
* add catch throw around transformInPlace
* switch to using QgsCoordinateTransform::transform
* move QgsCoordinateTransform to transform context
* remove TODO and fix layout
* add docs
* rename variable
* hadle bounding box coordinate transformation
the checkbox form widget
In QGIS 2.x we always displayed the underlying raw value of a field
using the checkbox widget in the attribute table or in identify results
(i.e. the text display of the field would always match the value
the user had set for the checked or unchecked representation status,
e.g. "yes"/"no", "present"/"absent", etc)
This was changed in 3.0 so that the representation status ONLY affected
how the underlying stored values are mapped to a boolean true or false
value, and accordingly the attribute table/identify results started
only showing "true" or "false" strings.
This new setting allows users to control whether they want plain text
displays of the field to use the 3.x "true"/"false" behavior (the
default), or if they want to see the 2.x style actual field value.
the referenced fields of an expression
Avoids some cases where use of various expression functions which
normally trigger all attributes to be requested, yet can be pre-computed
during prepare stages, cause non-provider fields to be listed in
the referenced columns and accordingly prevent expression compilation.
Notably this can occur when using an expression like:
aggregate( .... , filter:=
"some_child_field"=attribute(@atlas_feature, 'some_atlas_field_name') )
where the whole attribute(@atlas_feature....) part is a constant
static value and can be compiled down to a trivial, index-friendly
"some_child_field"=### filter for the aggregate provider request.
Ultimately giving a big performance boost to the atlas!
