This class (attached to a QgsProject object) provides a place to
store and retrieve settings related to project display behavior,
e.g. the numeric formats used for bearings and coordinates
QgsNumericFormat subclasses provide a means to format a numeric value
as a string, applying various formatting options. E.g. a default
string to value formatter (included here) includes settings for
controlling the number of decimal places, whether a thousands separator
should be shown, whether a leading + sign should be shown, whether
trailing zeros should be shown.
This PR also includes a formatter for bearings, allowing various
formats of numeric bearings to be applied (e.g. control over decimal
places, etc + control over whether direction E/W suffixes are shown,
or whether values should be limited to either the +/- 180 range or
0-360 degree range)
When formatting values, a QgsNumericFormatContext class is used
to provide context. Currently, this includes the thousands and
decimal separators to apply when formatting (which are taken by
default from the user's locale).
A registry of formatters is included to allow easy addition of
other formats in future (e.g. currencies, percentages, scientific
notation, etc...) and to allow plugin based formats.
The intention is to follow this up with gui configuration widgets
for the formats, and then expose them in various places through
the qgis ui (e.g. in the range editor widget for fields, in scalebar
numbers, as an option for formatting numeric labels, etc)
and background colors of matching conditional styles attached to the layer
When the new "Apply layer conditional styling colors" option is enabled in the
layout attribute table settings, any conditional styling rules present in the
layer will be applied inside the layout attribute table (foreground and
background colors only, for now!).
Refs #25712
Sponsored by City of Canning
and setup alias to avoid script/model breakage. This algorithm
uses GDAL utilities and fits better alongside the other GDAL based
algorithm rather than in the qgis provider.
GRASS GIS, in addition to importing data in its native formats via
`r.in.gdal`/`v.in.ogr` (and likewise `r.import`/v.import`),
also supports `r.external`/`v.external` which only link the data into
the GRASS DB.
Nevertheless, both `r.external` and `v.external` occasionally have problems,
especially on windows. E.g.:
- https://trac.osgeo.org/grass/ticket/3927
GRASS 7 Processing Plugin already has a setting that controls whether
`v.external` is used (disabled by default).
With this commit the complementary setting for `r.external` gets added too.
Usage of `r.external` is disabled by default. This is changing the existing
behavior, which was to use r`r.external`. The downsides of this change
should be the somewhat lower import speed + higher disk usage. Nevertheless
this way we have the same default value as `v.external` + we circumvent the
`r.import/v.import` shortcomings.
function during bulk index load from a feature iterator
Allows single-iteration of a source for dual purposes simultaneously,
e.g. doing other feature-based operations while still gaining the full
advantage of the bulk loaded spatial index without having to do multiple
feature iterations
Motivation :
Move the QgsRasterLayerProperties class to the GUI API.
So, this class could be used using the QGIS API, notably for standalone applications.
The instance of this class was dependent, since QGIS 3.8, from the QgisApp instance, when calling the askUserForDatumTransform(). As this method, defines a title and only call QgsDatumTransformDialog::run() method from the gui API, this PR purpose to :
