Creates a URI for use with QgsVectorLayerExporter corresponding to given destination
table options for the backend. The URI format and extra options which
need to be passed to QgsVectorLayerExporter differ from provider to
provider, so this new method gives us a consistent, generic method we
can call to safely generate the right URI and options in a
cross-provider way.
Implemented for all database connection providers.
These don't exist on the backend, so just hide them from the builder
dialog to avoid user confusion.
(Note that it's impossible to show the actual non-proxy fields
here, as we can ONLY show fields with types compatible with native
QGIS field types in this dialog)
Fixes#59528
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.
