We now buffer the request for the input to a resample filter by
a variable number of pixels (depending on the resampling type)
in order to fetch the neighbouring pixels to the edges of individual
raster blocks. This allows the resampling to utilise these
neighbouring pixels when resampling the edges of tiles, avoiding
discrepancies and rendering artifacts over the borders of
raster tiles.
Fixes#30152
which doesn't require pre-allocation of a temporary QImage
The existing interface is very inefficient for the bilinear resampler,
because it requires allocation of a temporary QImage just to pass
the desired height and width to the resampler...
Allows raster nodata pixels to be colored in a specific (non-transparent) color.
Designed to match the "Display background value" option from ArcMap.
Sponsored by SLYR
Fixes#26087
CRS validation, regardless of the user's settings
This avoids hacks put in place in other parts of QGIS code or in plugins
to temporarily deactivate the CRS validation prompt, providing a supported,
stable method to indicate that when loading a particular layer no CRS
validation is required.
The extent reported by raster layers may be smaller than the area
which can be rendered.
Notably for WMS with symbology that takes more space than the data.
Fix#30251
Adds a new visitor pattern API for creation of visitors which visit
all the style entities (symbols, color ramps, text formats, and
label styles) associated with different objects. Can be used on a
renderer, map layer, or project wide level.
E.g. on a project wide level, allows collection of ALL the style
symbols/color ramps/text settings inside a project, including those
in layouts or annotations!
This reworks (on proj 6 builds only!) QgsCoordinateTransformContext
to use proj strings of proj coordinate operations to handle the
users' preferred list of operations when transforming coordinates
between two CRSes.
Previously, the context heavily utilised internal transform ID
numbers, which were QGIS specific and relied on matching entries
from the QGIS srs.db file. This approach was undesirable because
it meant QGIS had to maintain and carry it's own table of
possible transform pathways between CRS pairs (which was difficult
to update, impossible to track, and most likely severely out of
date).
Now we can utilse Proj 6's (wonderful!) logic for determining the
best coordinate operation to utilise between two CRSes. All the
old API has been deprecated and no longer works under proj 6, but
that's unavoidable (and unlikely to be in use by plugins anyway,
it's VERY low level stuff).
A further bonus of this work is that QgsCoordinateTransform no
longer relies on proj strings of the source/dest CRS to build
the transform -- the issue with that approach was that proj
strings are lossy (and not always possible to generate), so
now by default we are generating better pathways between CRS
pairs.
This resolves issues with transforms which rely on pivot datums,
such as GDA94 - GDA2020 conversions.
Sponsored by ICSM
For the c++ api dox this expands to "\c nullptr" (the
\c directive indicates a code literal value), and for sipify/Python
it expands to ``None`` (`` is sphinx annotation for literal values)
Makes for nicer dox for both c++ and Python!
flag in a single call
This is much more efficient then making two calls, since the
QgsRasterBlock::isNoData() check internally calls QgsRasterBlock::value().
So by requiring API users to make the two separate calls individually,
we double the time this process takes...
actually fetching the raster block data
This allows for efficient iteration over a "reference" layer, where
you require the block extent/origin/pixel size/etc (but not the
reference layer block data itself!), in order to fetch a block from
a DIFFERENT set of rasters (but keeping these pixel-aligned to the
reference raster).
