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)
This reverts commit 3081f2a85c53da24f1022c0057077b1cba71d9d7.
Revert the commit. It causes too much failures on Travis-CI. See
https://api.travis-ci.org/v3/job/694715036/log.txt
Furthermore for the failed cases, I don't have locally the same differences
as on Travis-CI. So might be GDAL dependent or something else.
Not worth the huge trouble to update for nearest neighbour resampling
changes.
Instead of doing our own nearest neighbour resampling, use directly the
one of GDAL to avoid creating a temporary buffer. Should hopefully be
slightly more performant, and at least less complicated on QGIS side.
Update a few test cases that are sensitive to the difference in
resampling
* Remove old / confusing comments
* Rename various variables to be hopefully clearer
Should result in no functional change, but acts as a preparation
for follow-up changes
For devices which report faulty bearing measurements, this option can
be used to instead calculate the GPS bearing based on the previous
two recorded locations
Using test data with a HUGE polygon with several hundreds of thousands
of vertices and nearly a thousand of holes, split geometry was taking
really long time. On my laptop ~67 seconds for a simple split line.
With this fix, the time went down to ~10 seconds for the test polygon.
The issue was that split tool was doing an expensive exact intersection
calculation for each polygon part returned from polygonize, and then
calculating areas to see whether the original polygon part and intersected
part were more or less the same. I think that can be replaced by a much
simpler point in polygon test to figure out whether the particular
polygon part from polygonize is falls inside the original geometry
or whether it falls into a hole or exterior.
In my tests the time could be further improved to ~3 seconds by disabling
mergeGeometriesMultiTypeSplit() function - it is a bit of a mistery to me
what problem does it solve, however it has N^2 running time with N being
number of rings - but I did not feel adventurous enough to poke into it.
(mainly because there are no unit tests that would verify its behavior)
* test for feature list combo box having identifier value further than fetching limit
* fix feature list combo box having identifier value further than fetching limit
fixes#37266
* make the test a bit more robust
* fix compilation with older Qt
* correctly keep current value
* determine if keep current entry using the current index
* Revert "determine if keep current entry using the current index"
This reverts commit ff3658ba471450bc333a0a24f86e32f85da43c7f.
spaces or other special characters
Because we actually store the field name as an expression, we need
to make sure we correctly represent these field names as valid
expressions and not just the raw name string
