I limited the renaming to things that are not in the public API and
are not setting names. This is probably more than we strictly need to
do, but at least this will help doing potential future similar 'grep'
exercises.
Filters must be configurable for each individual expansion level,
as we can't achieve the same results by a single top-level filter.
For instance, this prevents filtering children from the expansion
to return just the most recent observation.
This allows us to control the sort order and limit for each expansion,
and gives us more flexibility in future to eg handle per expansion
filter strings
This change allows SensorThings entities to be expanded to contain
their related child feature attributes, exposing the relational
SensorThings model as a traditional "flat" GIS-friendly table
structure.
Eg when selecting Location entities, you can now opt to expand
to "Things > Datastreams > Observations". This would result in
multiple "stacked" point location features, one corresponding
to each observation, with the attributes for each point feature
containing the location, thing, datastream and observation
attributes.
(Best used combined with some extent, feature limit, or custom
filter option, as this can otherwise result in very heavy
requests to the backend service!)
Fixes#56805
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.
Allows users to set an extent limit for the layer, so that
features are only ever loaded within this extent
The extent can be set from the data source manager before adding
the layer initially, or modified from the layer properties, source
tab.
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.
Allows all layer types (including vector, mesh and point cloud)
providers to show custom metadata in the layer properties dialog.
Previously this was limited to raster/vector tile and tiled
scene layers only.
Also fix const for a lot of raster providers as a consequence.
