Since these expressions were only evaluated immediately, it led to
confusing behavior for users who were expecting that the expression
would be applied per-feature.
Given that expressions can be directly entered into spin boxes, we already
have a way of users evaluating simple calculations for numeric
parameters at least.
I don't think there's a strong enough use case for needing to
calculate string results to leave the confusing expression builder
option in place.
This should be re-evaluated when we add UI support for dynamic
parameters (which are already supported in the backend), where
expressions are evaluated per-feature.
Fixes#17267
...by moving extra arguments to new LayerOptions structs. This allows
us to more easily add new layer constructor options without making
the API cumbersome to use.
Initially only flag available is whether to sort drivers by
recommended order. The recommended order puts GPKG first and
SHP second, then leaves the rest alphabetical.
This fixes a few instances in the QGIS gui where these recommended formats
are not listed first.
* A new createopt textbox has been added to the parameters dialog for algorithms which exports to raster files.
* A new metaopt textbox has also been added to the Algorithm parameters dialog.
* Raster file format is detected from output filename extension.
* GdalUtils has been improved to correctly detect raster formats supported for creation.
* QFileDialog for output rasters now display only file filters for supported output raster file formats.
- Improve GRASS detection for all OS.
- Use GRASS --exec command.
- Unified GRASS batch job method for all OS (easier to maintain).
- Handle MS-Windows codepages (for data only, if you have a username with special characters, it will not work).
- Better support for filepath normalization.
- add -m option to r.out.gdal.
