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!
Returns true if the symbol layer rendering can cause visible
artifacts across a single feature when the feature is rendered
as a series of adjacent map tiles each containing a portion
of the feature's geometry.
This depends on the symbol layer derived class itself - eg
a simple solid color fill won't show any artifacts, but a shapeburst
fill WILL.
check if a node has already been determined to evaluate to a static,
precalculated value, and if so, use this value for the node instead
of attempting to compile the actual contents of the node itself
If we are certain that a node is static and will never change,
the this potentially allows us to short-cut a large part of the
filter expressions content. We already use this short-cut when
evaluating expressions on the QGIS side since years, and its
proven to be stable and reliable. By respecting this during
expression compilation we can offer a huge speed up to certain
filter expressions, especially those which utilise QGIS variables
which are known to be static (such as atlas variables, map scales,
etc). Previously ANY use of a qgis variable would always cause
expression compilation to fail and require a full set of feature
fetching from the provider.
(Resulted in orders of magnitude faster atlas export for a complex
atlas.)
field) when the attribute form is opened.
This is incredibly expensive, yet only required in a very very small
corner case (field is from a joined layer without the upsert on edit
capabilities).
Refine logic to avoid the scan wherever we can.
Fixes#41366Fixes#36863
