specific numeric format objects
E.g. this allows users to set a specific thousand grouping character
to use for a particular scalebar number labels. Useful in the case of
creating maps for users outside of the current locale. Default is
always to use the QGIS locale character (this is an advanced setting!)
Gives users control over all the formatting properties for the numbers
in scalebars, including whether they want thousand separators, decimal
places, scientific notation, etc
Fixes#21341
and profile options
The Settings - Options - Map Tools tab contains a new setting for
controlling the default format to use for displaying angular bearings for
newly created projects. Whenever a new project is created, it will
inherit this default settings.
The Project Properties dialog also has a new setting for the project-specific
bearing format.
The intention is that whenever angular bearings are shown in QGIS,
they will be formatted using the current project's bearing format
settings.
This class contains a variety of default setting values. These values are local, profile
specific settings which may have been configured or tweaked by the user (as opposed to
global, fixed default settings).
The values encapsulated here should be inherited when creating new objects such as new
QGIS projects.
Typically, the QgsSettings backend is used to store and retrieve these local settings.
The intention here is to provide stable, structured and easily discoverable
methods for setting and retrieve these settings, rather than forcing raw QSetting
handling.
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
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
settings and logic
The previous approach of a single fixed value which applied to ALL line and ALL polygon
features was... not ideal. It meant that all line features would be assigned the same
number of candidates, regardless of length. So a road of length 1 cm on the rendered
map would have an identical number of candidates as a 30cm road covering the length of the
whole map!! This resulted in both a lot of wasted calculations (generating a ridiculous
number of candidates for small lines at barely discernable distances from each other)
AND an insufficient number of candidates for lengthy features (resulting in worse label
placement for these features).
(The situation was similar, but even worse for polygons)
Now, the setting is reworked to "Number of line candidates per cm" and "number of
polygon candidates per cm2". This means that small features get much less candidates,
and large features get much more features! Both a win for map rendering speed in many
circumstances AND good cartography... now that's a nice Christmas gift for QGIS :)
Fix dependency inconsistency to project from QgsRelationManager
by forcing 'QgsRelation::createFromXml' to rely on project passed
to 'QgsRelationManager' instead of using 'QgisProject::instance()'
[FEATURE] [MESH] add new 3d stacked mesh averaging methods (top, bottom, sigma, depth, height, elevation)
see https://fvwiki.tuflow.com/index.php?title=Depth_Averaging_Results for description of the methods. method can be selected for 3d stacked mesh dataset in the new widget added for QGIS 3.12 in the mesh layer styling dialog
These should NOT be used, and auth:code or WKT definitions used instead.
Unfortunately some use of these methods are very heavily entangled around
other code, so we can't deprecate all of them until 4.0
Constructing CRS using Postgis srids is highly discouraged,
and instead CRSes should always be constructed using auth:id
codes or WKT strings.
QGIS 4.0: The logic should be isolated into the postgres
provider alone, and not exposed to stable API
