Even when the model execution fails, store the child inputs and
results for all steps which successfully completed in the context.
This gives more debugging information to a user when a model fails,
because these values will now be reflected in the model designer
view for all steps which completed.
We now always call QgsProcessingAlgorithm::postProcess, even when
the algorithm fails for some reason (eg it raises an exception).
This ensures that the context cleanup logic in postProcess is
always run. Note that we still ONLY call an algorithm's specific
postProcessAlgorithm implementation for successful executions,
so the public facing API and behavior remains unchanged.
This is intented to provide a consistent handling of the cleanup
logic in postProcess, specifically to make sure that that the
context thread handling logic is triggered in all cases.
Eg server layer title, abstract, etc, and deprecate the related
methods at the QgsMapLayer level
This should avoid accidental creep of these specifically server-related
properties into wider use, and help disambiguate them from the
standard layer metadata properties
If the project crs() is a compound CRS, then the CRS returned
by QgsProject::verticalCrs() be the vertical component of
QgsProject::crs(). Otherwise it will be the value explicitly
set by a call to setVerticalCrs().
The vertical crs is a persistent property of a project, which
is saved/restored to xml.
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.
