Instead of just setting the whole widget as disabled, implement proper
read-only state for these widgets. This fixes an annoying UI issue where
the list / key value widgets can't be scrolled when opening read-only
attribute forms, preventing users from viewing all the entries in
the widget.
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 widget will call a callback function to generate
a new QgsExpressionContext as the previewed object changes. This
can be used to provide custom preview values for different objects
(i.e. for objects which aren't vector layer features), such as raster
bands or other custom objects.
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
Use the processing context's ellipsoid instead of a hardcoded
WGS84 ellipsoid for distance calculations during network
analysis, so that the lengths used will exactly match other
measurement tools used on the same features in the same
project.
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.
Allows forcing the widget to have a specific fixed range width,
so that interactions with the lower or upper slider automatically
force the other slider to move to keep a constant width
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.
Attempts to set the input band for the renderer.
Returns TRUE if the band was successfully set, or FALSE if the
band could not be set.
This was implemented in various raster renderer subclasses,
but it was necessary to down cast and then call the individual
methods (which don't have consistent names!).
Instead, add a top level virtual method so that it's easy to
change the input band for the renderers.
This is messy, as there's no way we can possibly make the current,
stable API of this class safe. We have to resort to an opt-in
"safe" mode which exposes a non-dangerous API.
This should hopefully fix issues where the qt event loop causes
destruction of the detected connection before listener slot is
called and is able to take ownership of the signal argument...
And hookup for point cloud identification. We actually already
correctly handled z range filtering for point cloud identify,
because that method is using the canvas' render context and
filtering by the corresponding z range. But this new approach
makes things more flexible and usable for different layer types.
