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
running GDAL algorithms
If a subset string is set, we must export the subset of the layer
for use by the GDAL command*
Fixes#35981
* well, we probably **should** just build the gdal command to include
the SQL definition of the subset filter, but that's non-trivial, so
this fix is a good simple solution for now
- alias WKT_2018* to new WKT_2019* values, since the spec is actually
2019, not 2018
- add WKT_PREFERRED value which currently aliases to WKT2_2019, but
can be changed if/when future bumps to the WKT spec happen
- add WKT_PREFERRED_GDAL which should be used whenever a CRS is
exported to WKT for use with GDAL API. Aliases to WKT2_2019 currently,
but can be changed if/when a new spec is released and GDAL supports it
This allows defered setting of parameter values, e.g. if you add an algorithm, fill in
half the parameter values, then realise you need to add a new input to the model, you
don't have to lose all your filled in values...
This change "dims" the results from the SAGA provider when a search
is made in the toolbox, to visually push users towards picking alternative
algorithms instead.
The Processing implementation of SAGA algorithms are a constant source
of critical bugs for users, causing incorrect analysis results. There's
zero community interest in actively maintaining this provider, so we
need to take steps to push users to stop picking these algorithms
wherever alternative (QGIS/GRASS/GDAL based) equivalents exist.
And for 4.0, seriously re-consider dropping this provider from the
out of the box install. We are causing more harm then good by offering
it to users.
