Add parameter for data access method (https, local path, S3, ....) in the request

[MartinePaepen]

Could the API spec include an additional parameter to handle different data access methods? Our catalog includes data products which can be accessed in different ways, e.g. HTTPS / S3 / Local paths). All depends on where the catalogue API is called from. Applications running on our platform can use the products directly and the response includes local paths to access the files. If the request is launched outside the platform, the response has to include HTTPS urls pointing to the data.

We have implemented a STAC API (https://services.terrascope.be/stac/) on top of our opensearcch API (see https://docs.terrascope.be/#/Developers/WebServices/TerraCatalogue/OpenSearch for info)
in the opensearch API the default access method is HTTPS download however An application that runs on the Terrascope MEP, can access the products directly and request for direct access links instead of download URLs (https://services.terrascope.be/catalogue/products?collection=urn%3Aeop%3AVITO%3ATERRASCOPE_S2_TOC_V2&start=2022-01-01T00%3A00%3A00&end=2022-01-31T23%3A59%3A59&accessedFrom=MEP) And currently, we also added the S3 access method.
Using this parameter, makes it easy for the client to access the data directly on the preferred location.

[MartinePaepen]

We are aware of the alternate-assets extension however we believe that this will enlarge the responses and the DB enormously and the client needs to extract the right access paths. There is also an extension to include/exclude fields in the results but this makes it also more complex for the clients which need to incorporate this fields in the request.

We could also configure 3 STAC IO instances but than we have to maintain all of them.

[philvarner]

I think there are a lot of users with this use case. I've implemented a STAC API with similar behavior -- when a parameter was passed, the S3 urls would be converted to signed HTTPS urls. The main challenge here is specifying something that will work generally. Something like asset-href-mode and endpoint (like the queryables endpoint) /asset-href-modes to discover what options are available and what they mean.

[m-mohr]

Is there anything similar planned for OGC APIs, which we could adopt? cc @cportele @pvretano

Would you need this /asset-href-modes endpoint globally only or also per collection?

[cportele]

@m-mohr I am not aware of a discussion about such a capability in the OGC API context. It mainly seems to be relevant for APIs that catalogue resources, so in my view, it would mainly be relevant for OGC API Records. @pvretano @tomkralidis

[tomkralidis]

I could see this as valuable for others API as well (perhaps OAProc outputs/references for external/internal pipelines). Could this be implemented as a vendor specific parameter (https://docs.opengeospatial.org/is/17-069r4/17-069r4.html#query_parameters)?

[philvarner]

Closing this in favor of:

• Add parameter for data access method (https, local path, S3, ....) in the request  stac-api-extensions/incubator#5

Since this would likely be implemented as an extension

[MartinePaepen]

Hi @philvarner, it seems that I don't have access to the incubator github repository. Is this a public repository?

[philvarner]

Hi @philvarner, it seems that I don't have access to the incubator github repository. Is this a public repository?

@MartinePaepen Thanks for mentioning this -- it's public now.