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
PostgreSQL 11 and 12 handle floating point values differently; the test
originally passed on PostgreSQL 12, but not on 11 (Travis). Now, with
floating point data truncated to only 6 digits, they run on both
versions of the DBMS.
See https://www.postgresql.org/docs/12/release-12.html
Turns out that what passes on Python 3.8 and PostgreSQL 12 won't pass on
Python 3.7 and PostgreSQL 11 (Travis). So we round the floating point
comparisons to 5 digits in the testcases.
Turns out the DBMS won't return a type name of "int", but "int4". We
changed the test accordingly to reflect what QGIS should expect from the
database.
Bigint PostgreSQL fields are handled correctly if they are part of a
composite primary key. As a bonus, we always pass double values as
quoted to the DBMS (but not cast to text). With this one can work with
tables with real/double primary keys without the penalty of casting
these values to text. Fixes#37126.
Included support for json/jsonb in this method, as there already exists
for QgsPostgresProvider::changeAttributeValues; fixed how the provider
deals with bigint primary keys in this case; added a few tests that
exercise changing of attributes, geometries, and primary keys of
features.
