- code simplification (moving displayName() to the core class
prevents us having to create lists of DecorationItem alongside
lists of MapDecoration
- Proper translation support for decoration names
Provides warnings in Processing algorithms when running on layers
which don't have a spatial index present (e.g. geojson files) and
where performance will be severely hurt as a result
Fixes#30530
* Fix misalignment of rasters with RPC (fixes#35796)
By default GDAL would assume that the imagery has zero elevation - if that is not the case,
the image would not be shown in the correct location. Fortunately we can pass RPC_HEIGHT
to GDAL to use given value as the fixed elevation for the whole image.
We try to use HEIGHT_OFF coefficient ("Geodetic Height Offset") as an estimate for elevation
(it seems that ENVI software does that as well). In the future we may want to use also
RPC_DEM for an even more precise georeferencing.
https://gdal.org/development/rfc/rfc22_rpc.html
* Update code to use the new fuction GDALAutoCreateWarpedVRTEx()
This function will be available in GDAL >= 3.2 so we have a local
copy for the time being for older versions of GDAL.
We have to keep a local reference to the dialog, otherwise sip suddenly
"forgets" about the python subclass and treats the dialog as just
the parent c++ class. Really weird, thanks sip.
Fixes#36436
and preparation stage from the symbol layer rendering stage, and
ensure that QgsSymbolLayer::startFeatureRender and ::stopFeatureRender
is correctly called in the right sequence when rendering multi-layer
symbols
This fixes issues with symbol layers which rely on startFeatureRender
and stopFeatureRender to correctly render, e.g. the Random Marker Fill
symbol layer.
Before this fix, the logic looked like:
- for every symbol layer in the symbol, call startFeatureRender
- for each part in polygon, prepare the part geometry and then render each symbol layer
- for every symbol layer in the symbol, call stopFeatureRender
The issue with this approach is that symbol layers which defer
rendering to the stopFeatureRender stage are always rendered
after ALL other symbol layers in the symbol, regardless of the actual
order of the symbol layers. Ultimately this causes Random Marker Fill
layers to always render on the top of symbols.
The new logic is:
- for each part in polygon, prepare the geometry and store the result
- for each symbol layer in the symbol:
- call startFeatureRender
- render the layer using each of the previously prepared parts
- call stopFeatureRender
This results in correct stacking of the random marker fill in multi
layer symbols, because the stopFeatureRender call is correctly called
before the next layer's startFeatureRender and renderPolygon calls
Also, use QVector instead of QList for rings for improved efficiency
Spotted by cppcheck
Independently of this fix, it looks like the geometry building when
mixing linestrings and circularstrings would need some more love...
when colorramp argument was nullptr, which could occur when called from
QgsColorRampButton::setToNull()
The logic to detect if the colorramp was changed was convoluted and
wrong too.
Spotted by cppcheck
As base comment() implementation returns nullptr, and is virtual, it could
be possible in theory that subclasses return during the first call a non-nullptr
and then a nullptr...
cppcheck warned about potential null pointer dereference of rasterBlock and
zonesRasterBlock at line 242
```
if ( !rasterBlock->isValid() || rasterBlock->isEmpty() || !zonesRasterBlock->isValid() || zonesRasterBlock->isEmpty() )
```
It is likely that the logic about correctly prevented those null pointer from
arising, but this wasn't immediately obvious. Make it so
Fixes#35043, fixes#35671
The initial version of this class presupposed the possibility of constructing a rectangle by 3 points where each point had a Z. Very useful to make 3D plans, but this is not always what we want...
These don't correspond to standard CRSes, and by avoiding the identification
we shave a considerable time off QGIS startup (about 1/3rd on my machine!)
The identification can be time consuming, so in the rare cases that
we are SURE that the definition doesn't correspond to a known or
user CRS, we can optionally skip it to save some time.
