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.
elevation related properties to their layers
And use this to ensure that wms tiles with maptiler terrain
or terrarium terrain interpretation are always included by
default in elevation profile plots.
Most specifically, this ensures that projects containing the
out-of-the-box "Mapzen Global Terrain" layer will be automatically
included in elevation plots.
* load layers in parallel threads when opening project
* parallel loading by default and settingsin advanced settings
* fix freezing when no layer supports parallel loading
* clean leftover
* fix unwanted remove and typo
* typo
* fix flake8
* load OGR metadata under global mutex
* Revert "load OGR metadata under global mutex"
This reverts commit adcaf9e66ca432ee35143c45af2b383108770a63.
* remove parallel loading capability for OGR
* start application in server test
* import start_app
* fix flake8
QgsAbstractDatabaseProviderConnection
When implemented by providers, will provide a method for
permanently setting field aliases/comments within a
database
Here we have no choice but to create a new Capability2
enum, as the original Capability has now consumed the
entire range of values for data types permitted by QFlag
Conversion between relative and absolute paths when reading/writing project files
has been inconveniently done in subclasses of QgsMapLayer in encodedSource() and
decodedSource() methods, with a lot of provider specific code.
This is a refactoring to finally fix this - there is a new pair of functions added
to QgsProviderMetadata and QgsProviderRegistry:
- absoluteToRelativeUri()
- relativeToAbsoluteUri()
This new pair of functions delegates the actual conversion between absolute and
relative path to provider code - where it belongs.
The existing code from encodedSource() and decodedSource() functions has been moved
to providers. Unit tests were added to confirm the existing behavior.
There should be no change of behavior apart from removal of old compatibility code
for WMS provider for projects from QGIS < 1.9 (10 years ago).
