QEP 331: STAC layers and data providers

[02JanDal]

This QEP documents a proposed addition to the STAC support - adding STAC endpoints as layers.

There are some points here were I'd appreciate input, especially regarding the contents of the STAC layers subheader. From the PoV of this specific feature it would be beneficial to be able to restrict what the user can change about a layer (instead letting the data source control it). This could technically be solved relatively easily (for example by passing through a "read-only" flag from the data source which the layer properties dialog uses to hide pages), but I can image that this might violate some unspoken architectural rule. Or maybe not?

Provided that this QEP is accepted we'll be to implement at least the first part (adding a layer showing the extents of the STAC items) with the funding we've currently got, hopefully also preview of raster and/or point clouds.

[nyalldawson]

I have some concerns here.

Can you include links to the stac vector features specification, and describe how this relates to WFS/OAPIF? Creating a new data provider should be a last resort, so if the stac specifications are closely aligned with WFS/OAPIF then I think making a separate provider is a mis-step.

Similarly, creating QgsStacRasterDataProvider is a red-flag to me. The GDAL library and data provider are already mature and written to handle optimised reading of remote data sources, and it would be a massive undertaking and large technical debt to reimplement all that just for stac resources. Besides, GDAL itself already handles stac resources well, so I fail to see why we'd need a dedicated provider in the first place.

"thus be a good idea to have either separate layer classes for STAC"

No, this is not a good idea - creating a new layer class just for a single data provider breaks a lot of the assumptions and designs of QGIS API. The better approach is to add the missing bits to the API for the existing layer classes.

Was this proposal created in partnership/consultation with Lutra, who did the original stac implementation?

[nyalldawson]

@02JanDal following https://github.com/qgis/QGIS-Enhancement-Proposals?tab=readme-ov-file#process-and-policies, can you please announce this also to QGIS-psc lists?

[sweco-sedalh]

(EDIT: posted from the wrong account, I'm the same as @02JanDal)

can you please announce this also to QGIS-psc lists?

Done, that is however currently not documented on the linked page (only QGIS-developers and potentially QGIS-users)?

Can you include links to the stac vector features specification, and describe how this relates to WFS/OAPIF? Creating a new data provider should be a last resort, so if the stac specifications are closely aligned with WFS/OAPIF then I think making a separate provider is a mis-step.

There is a bit of historical cruft involved here, as STAC was developed along-side OAPIF, rather than based on it. But basically while STAC borrows a lot of ideas from OAPIF (and vice-versa) and a lot of STAC endpoints implement OAPIF, there is no guarantee for this to be the case.

Specification wise STAC has split of OAPIF-compability into a separate part: https://github.com/radiantearth/stac-api-spec/tree/v1.0.0/ogcapi-features

The /search endpoint, specified in STAC API - Item Search, which would be quite central to the implementation of this feature, has a lot of overlap with OAPIF endpoints (such as both returning GeoJSON FeatureCollections, and using the same name for many parameters) but I'd say still is distinct from it.

So basically we could solve parts of this using the existing OAPIF data provider, but likely not in a way that supports Item Search and it would not be guaranteed to work with all STAC endpoints.

Similarly, creating QgsStacRasterDataProvider is a red-flag to me. The GDAL library and data provider are already mature and written to handle optimised reading of remote data sources, and it would be a massive undertaking and large technical debt to reimplement all that just for stac resources. Besides, GDAL itself already handles stac resources well, so I fail to see why we'd need a dedicated provider in the first place.

That's a good point. Based on what I can tell the STACIT driver could be sufficient here. That would leave the questions of how to handle the temporal controller (probably would make sense to add support to it to the GDAL data provider/the STACIT driver) and authentication (AFAICT the GDAL driver does not support OAuth2 right now, right?).

Regarding authentication; I got an interesting tip based on https://lists.osgeo.org/pipermail/qgis-developer/2025-February/067392.html that PDAL is considering to move to GDAL's VSI. A possible solution to both PDAL algorithms and authentication here could then be to register a custom GDAL VSI (something like /vsiqgis/) which would send requests through QGIS' network plumbing for authentication, logging, proxying, etc.

"thus be a good idea to have either separate layer classes for STAC"

No, this is not a good idea - creating a new layer class just for a single data provider breaks a lot of the assumptions and designs of QGIS API. The better approach is to add the missing bits to the API for the existing layer classes.

I suspected as much. The other option (I can think of) would then be to let the data provider provide flags on stuff that the user may change, with the default being "everything" for backwards compatibility. For this use-case it'd probably be about leaving Information and Symbology/Labels/Masks/3D View/Diagrams editable. UI wise I think graying out the tabs, making the fields readonly and displaying some sort of "managed by data provider" message would be the best option?

Actions and initial styling can be set when adding the layer from the STAC tree, so as long as actions aren't overridable it should be fine (symbology I think should be possible to override, it should just have some sensible default).

Was this proposal created in partnership/consultation with Lutra, who did the original stac implementation?

I messaged @uclaros specifically when I sent the announcement to QGIS-Developer. I haven't had any further contact, but I hope they'll give their input here.