* 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
Paraphrasing Phil Thomson's advice on https://www.riverbankcomputing.com/pipermail/pyqt/2017-July/039450.html:
"
/Factory/ is used when the instance returned is guaranteed to be new to Python.
In this case it isn't because it has already been seen when being returned by by the python function
creating the provider subclass.
(However for a different sub-class implemented in C++ then it would be the first time it was seen
by Python so the /Factory/ on create() would be correct.)
You might try using /TransferBack/ on createProvider() instead - that might be the best compromise.
to transform the vertices of a QgsAbstractGeometry
E.g.
class Transformer(QgsAbstractGeometryTransformer):
def transformPoint(self, x, y, z, m):
return True, x * 2, y + 1, z, m
transformer = Transformer()
g = QgsGeometry.fromWkt('LineString(3 0, 10 0, 10 10)')
g.get().transform(transformer)
print(g.asWkt()) # 'LineString (6 1, 20 1, 20 11)'
prefer something like "admin_name" over "type_name".
By penalising results with "type", "class", "cat" in their names
we are less likely to accidentally select a category field as the
friendly identifier when a better one exists.
Also add tests for this logic.
for "early" raster resampling
Notably, this adds the "Average" resampling as an option for
early resampling methods. (A nice side effect is that we also
get mode, cubic spline, Lanczos, ... for free!)
Fixes#40746
setting a cache image, and prefer any cached image with
parameters which exactly match the current cache parameters
This allows us to properly handle the case where:
- one map job is canceled, but some layers did finish rendering
- while the canceling is occuring on a different thread, we start
a new map render using the same cache and set new extent/map to pixel
for it
- the canceled job cleans up and stores the cache images for
the layers which DID finish rendering -- in this case we need
to explicitly state the previous extent/map to pixel when storing
the cache image, as they won't match the cache's current parameters
QgsCoordinateReferenceSystemRegistry
This was the last bit of untested, direct sql database access relating
to custom projections. Now everything is nice and central and protected
by unit tests.
object
Updates the definition and parameters of the coordinate reference system to their
latest values.
This only has an effect if the CRS is a user defined custom CRS, and the definition
of that custom CRS has changed. In this case the parameters of the object (such as the
proj and WKT string definitions, and other related properties) will be updated to
reflect the current definition of the custom CRS.
Any objects which store CRS objects should connect to the QgsApplication::coordinateReferenceSystemRegistry()'s
QgsCoordinateReferenceSystemRegistry::userCrsChanged() signal and call this method
on their stored CRS objects whenever the signal is emitted in order to update these
CRSes to their new definitions.
Refs #40704
to QgsApplication
In the long term all methods for retrieving available CRS details
should be moved here (instead of being scattered all over the place,
as they are now). But for now the logic for saving and updating
user CRS definitions has been moved here only.
The initial motivation is to create a central place where objects
can connect to in order to listen for when a user makes changes
to their custom projections.
Refs #40704
results as well as map layers
This extends the recent addition of smooth map updates for raster
layers to also apply to map labels. Now you'll see a scaled/transformed
version of the previous map render's labels while the new labeling
results are being generated in the background.
Avoids "flashy" redraws of map labels
map layer renderers
These renderers can then use the layer rendering time for the previous
map render job to refine their logic regarding when its appropriate
to start compositing the layer render
