We don't want labels to be positioned using unclipped feature
geometries, rather we want them to be positioned nicely on the
visible portions of features
Offers the same functionality as the Random points inside polygons
algorithm, and in addition it includes (possible to opt-out) the attributes
from the containing polygon and the ability to specify a seed for the random
number generator.
Could replace the Python algorithm Random points inside polygons, but
this C++ implementation only supports "Points count" ("number of points
for each feature") directly, while "Points density" is supported by allowing the
point count to be data defined (using the polygon area to calculate the
number of points).
[FEATURE] Introduces memory dataset groups for mesh layer. These dataset groups are temporary and are not kept when the project is closed.
Memory dataset groups can be created from the mesh calculator with a new option.
Allows the possibility to remove or save these memory dataset groups to a file with specified driver.
and still be able to store generic labels on the item (like the field name and the field alias)
This fixes that there has been no example values in the expression builder on the fields when an alias has been used
Now it's possible to get a breakdown of the various stages of
project load, in order to identify the causes of slow project
load times.
TODO: in 99% of cases this will be caused by one or more layers,
so it would be nice to further break down the individual layer load
times, e.g. so that for a WFS layer we see the time taken for
the initial server capabilities queries, etc...
For now, you just get the overall load time of each individual
layer.
Long story short: calling provider's addFeatures
is implemented for some providers in a way that
will roll back all changes on errors, leaving
the backend storage unchanged.
Adding a QgsFeatureSink flag to control this
behavior allows certain providers to support
partial feature addition.
The issue comes from QgsVectorDataProvider::commitChanges
that is documented to leave the provider unchanged (roll
back) on any error, giving the client code the possibility
to fix errors (in the editing buffer) and re-commit.
Without a full rollback implementation in the memory
provider and after the type check introduction in this
PR we ended up with situations like this:
vl = ... an empty memory layer
self.assertTrue(vl.addFeatures([valid, invalid]))
self.assertFalse(vl.commitChanges())
self.assertEqual(vl.featureCount(), 1) <--- fails!
We actually had 3 features from vl.getFeatures():
[valid, invalid, valid] (the first from the provider
the second and third from the editing buffer).
On the other hand, QgsFeatureSink would probably assume
that addFeatures will allow partial additions.
BTW: This is for sure the longest commit message I've ever
written.
Fixes#36715
Adds a method to check for QVariant conversions, also
check for integral type narrowing so that for example
floating point 123.45 does not get down casted to integer
without raising an error.
Also
* in settings UI, add a 'Early resampling' checkbox
* in raster properties UI, add similar checkbox
* serialize/deserialize new settings in QgsRasterLayer XML
Fixes#36820
The way QGIS is currently handling resampling is sub-optimal given GDAL >= 2
capability of having sub-pixel accuracy. So when a QgsRasterResampleFilter
is set, make it try to delegate resampling back to the underlying input interface,
and implement that improved resampling in the GDAL provider.
The GDAL resampling will take into account the settings of the QGIS resample
filter: zoom-in resampling kernel, zoom-out resampling kernel and max resampling
factor. The later is important to avoid performance issues if not enough overview
levels are generated (in the case, we will fallback to the generic method, which
may introduce sub-pixel shifts)
occurring for drawing a symbol preview
Because these have no map association, certain settings like
sizes in "meters in map units" will have no meaning, and may need
special handling
Refs #28690
