Sensor things Data Provider, pt 1 (Request in QGIS)

[qgis-bot]

Request for documentation

From pull request qgis/QGIS#55840
Author: @nyalldawson
QGIS version: 3.36

Sensor things Data Provider, pt 1

PR Description:

This is part 1 of a native data provider implementation for the OGC SensorThings API.

See qgis/QGIS-Enhancement-Proposals#257 for technical details

Introduced in this PR are:

Connection handling for SensorThings connections

These are exposed via data source manager and browser. Like other connection types (eg WMS) users can populate a set of frequently used connections for rapid access. I've used the modern approach we use for eg XYZ connections here, where the stored connection prepopulates all the connection settings BUT where users can easily modify these (or add ad-hoc connections) on a case by case basis:

Source widget implementation for configuring existing layer connections

I've added a source widget, so that users can modify the properties of an existing SensorThings layer in their projects WITHOUT having to add a new layer:

This is especially important for SensorThings layers as they tend towards an interactive source, where users will frequently modify filter configuration and other related settings.

Optimised data provider

The SensorThings data provider has been designed to provide the best possible user experience given what is available from the OGC SensorThings API standard. Some interesting things here are:

• We always lazy fetch features and store in an session wide cache. (This was modelled off the existing ArcGIS REST feature server implementation)
• Care was taken to ensure that constructing a data provider only fires off two VERY CHEAP requests to the server. (One to get the endpoints, the other to retrieve the layer's feature count). This ensures good performance when adding layers or reloading projects containing sensor things providers.
• A local spatial index is used to store cached features, so that we can quickly query for rectangle based searches. There's a lot of (I think!) smart things at play here. Eg, we keep track of a unioned extent polygon for all previous spatial rect requests we've successfully fetched and if a new request falls within this polygon then we know we can safely just return cached features only. If part of the request falls outside the previously fetched extent, then we FIRST return all the locally cached features before requesting the remainder from the service (this ensures that panning the map is nice and responsive -- the features previously visible are all immediately drawn, and the newly visible ones are drawn as the requests are complete)

Future work

More work is coming, but this is the minimal PR I can submit which brings up the data provider in a functional way. Eg:

• Further optimisations regarding geometry type filtering and layer extent calculations
• Automatic integration with temporal controller
• Filtering
• Ability to "flatten" relationships in the layer, so that the relational SensorThings model is exposed in a more traditional flat row based table. (For easy use with eg temporal animations or with data analysis tools)

Commits tagged with [need-docs] or [FEATURE]

[pvgenuchten]

From the usage perspective it would be nice to have documented:

• how to access a set of sensors and sensor observations related to a selected location or feature-of-interest
• how to style a location based on (recently) measured values in the related /sensor/observation