Add a new Qgis::ProcessingAlgorithmDocumentationFlag flag, with
a virtual method in QgsProcessingAlgorithm to return documentation
flags. These flags are used to indicate algorithm behavior which
should be noted in the documentation.
Add initial flags for algorithms which drop and regenerate
primary keys/FIDs, and automatically add a note to the algorithm's
help panel to explain that this will occur
In future this flag could be extended with other helpful warnings,
eg
- Algorithm requires valid geometries
- Algorithm will segmentize curved geometries
- Algorithm will drop Z or M values
API allows to define a color model without a color space. If both are
set, consistency between defined color model and color space one is
checked (only in Qt version 6.8.0 or greater because it's not possible
to retrieve color model from color space before that)
Allows suppression of the standard user actions for managing
file based data items. Could be used in future to restrict
other browser actions for sources which the user does not
have permission to modify.
This is a new opt-in flag for map settings/render context/layouts.
If set, then when applying clipping paths for selective masking,
we always use global ("entire map") paths, instead of calculating
local clipping paths per rendered feature. This results in
considerably more complex vector exports in all current Qt versions,
but gives us a way to force this IF/when a future Qt version adds
optimisations which make global masks desirable.
Optimise the logic used when the new geometry backend for
selective masking is in effect:
Whenever its SAFE, instead of calculating an "entire map" clipping
path and then applying this for every feature being rendered,
we now defer the calculation of the clipping path until we
are rendering individual features. Then, we create a clipping path
which contains ONLY the mask paths which are within the area
being drawn over.
This avoids having the entire map clipping path being used for
EVERY feature being rendered, which results in huge PDF/SVG
exports when masks are in effect, and instead results in
clipping paths which are confined just to a sensible area
around each rendered feature.
In some complex test projects this reduces the PDF export
size by a factor of 0.01!! (and results in PDFs/SVGs which
open much quicker in viewers and editors, and don't grind
their operation to a halt).
For the "Around point" and "Cartographic" placement modes, this
adds a new optional setting for the maximum distance of the labels from
the feature. It's used together with the existing distance setting
to define a range of distances at which labels may be placed
from their corresponding point features.
This adds more flexibility to the placement for these layers,
ultimately allowing for more labels to be placed in busy maps.
When the layer is set to the "around point" mode, then label
candidates which are closer to the point will always be prefered
over those which are further away.
When the layer is set to the "cartographic" mode, then the default
behavior is also to prioritize closer labels. A new combo box
allows users to control the priority, with an option for
prefering position ordering. If this option is set, then candidates
at the corresponding positions (eg top left) are preferred regardless
of how far they are from the point, with the labelling falling
back to alternate positions only when no labels can be placed
up to the maximum label distance.
Sponsored by Rubicon Concierge Real Estate Services
This adds a new option for placement when labels are set to the
"cartographic" mode, for "O" = "over point". When a feature's
data defined placement priorities include this new 'O' option,
a label can be placed directly over the corresponding point.
Sponsored by Rubicon Concierge Real Estate Services
This adds support for the Multidatastream entity type, as
implemented in the SensorThings version 1.1 "MultiDatastream extension"
While the specification mandates that MultiDatastreams have an
optional polygon geometry, I've encountered numerous servers
which expose different geometry types for this entity or which
return errors when attempting to read the geometries from
MultiDatastreams. Accordingly we always expose an option to
load MultiDatastreams as geometryless layers alongside the
default option to load them as polygon layers, to handle a
wider range of connections.
This mode can be used when each band in the raster layer is associated
with a fixed time range, eg. NetCDF files.
The user can either manually populate a table with begin/end dates for
each band in the raster, or build the table using QGIS expressions
which return datetime values.
In this mode, the user can specify a QGIS expression for the
lower and upper value corresponding to raster bands, using
variables like @band, @band_name and @band_description.
E.g
@band * 100
Can be used when each band represents a 100 m vertical slice
of data.
The expression will be evaluated when required to determine
the actual elevation range corresponding to each band.
This differs from the existing "Fixed Elevation Range Per Band"
mode in that "Fixed Elevation Range Per Band" requires users
to manually enter an elevation for each band separately,
and these values are then treated as constants. That mode works
best for rasters with non-regular steps in the band
elevation values, while this new mode is better for regular
band elevation steps
In this mode, each band in the raster can have a fixed elevation
range associated with it. This is designed for data sources which
expose elevation related data in bands, eg netcdf files, such
as a raster with temperate data at different ocean depths.
This introduces a new option for specifying how raster layers
have associated elevation. It permits a fixed elevation range
to be set for the layer. It can be used when the layer has
a single fixed elevation, or a range (slice) of elevation values.
Users can set the lower and upper elevation range for the layer,
and whether the lower or upper limits are inclusive or
exclusive.
When enabled, the layer will only be visible in elevation
filtered 2d maps when the layer's range is included in the map's
z range.
Similar to the existing setting for temporal filtering of 2d layout
maps, this setting allows users to set a specific elevation/z range
for a layout map item. When set, map layers with support for 2d
z range filtering (currently point clouds and raster DEMs) will
be filtered to show only content within this range.
The z range can be data-defined, allowing differing z range
for different atlas or report features.
These flags reflect that retrieval of the provider's 2D or 3D extent
retrieval via QgsDataProvider::extent()/extent3D() are ALWAYS guaranteed
to be trivial/fast to calculate and involve absolutely no extra work.
