support STAC specification

[tomkralidis]

Implement the STAC API specification to support search/discovery of geospatial assets. Notes for implementation based on initial discussions with @matthewhanson :

• add front end routes (/stac/search)
• update pygeoapi.api to address request handling
• implement STAC provider backend via plugin mechanism which will interrogate backend and return results as a Python dictionary for marshalling to JSON proper to the client
• add stubs for transactional capability
• populating a STAC backend could be via workflow beyond pygeoapi (i.e. implement a CLI within the backend, which is not hooked into pygeoapi tooling proper but can be run offline just the same)

[pvgenuchten]

I'm curious to see how stac, ogcapi-coverage and ogcapi-records operate together on a single endpoint, what aspects they can share and where are the challenges, would be good input for the upcoming sprint

[francbartoli]

Implement the STAC API specification to support search/discovery of geospatial assets. Notes for implementation based on initial discussions with @matthewhanson :

• add front end routes (/stac/search)
• update pygeoapi.api to address request handling
• implement STAC provider backend via plugin mechanism which will interrogate backend and return results as a Python dictionary for marshalling to JSON proper to the client

Are you considering external libraries for marshalling? Or we need to implement our own?

• add stubs for transactional capability
• populating a STAC backend could be via workflow beyond pygeoapi (i.e. implement a CLI within the backend, which is not hooked into pygeoapi tooling proper but can be run offline just the same)

[tomkralidis]

Are you considering external libraries for marshalling? Or we need to implement our own?

Good point. I'm guessing a STAC backend could provided via one of the sat-utils tools (for example) and a STAC backend's mission would be to provide Python dict's of JSON objects back to pygeoapi.api, but this remains to be seen/needs to be further tested.

[francbartoli]

Are you considering external libraries for marshalling? Or we need to implement our own?

Good point. I'm guessing a STAC backend could provided via one of the sat-utils tools (for example) and a STAC backend's mission would be to provide Python dict's of JSON objects back to pygeoapi.api, but this remains to be seen/needs to be further tested.

Ok that makes sense, thanks @tomkralidis.

[francbartoli]

@tomkralidis Should stac/search endpoint be optional in the configuration? I would say yes...

[tomkralidis]

Would this depend on how we describe in configuration? Like, is STAC a dataset in config? Other options?

[pvgenuchten]

Any guidance from the stac team? Is stac intended to run along side ogc api’s in a single ogc-api endpoint, or does it require it’s own endpoint, in that case maybe deploy a second instance of pygeoapi in a ‘stac’ modus?

[francbartoli]

@pvgenuchten I would consider its own endpoint as suggested in the bullet above from @tomkralidis (cc @matthewhanson)

[francbartoli]

Configuration could be something like:

catalogs:
    sat-api:
        provider:
            name: STAC
            data: https://sat-api-dev.developmentseed.org/stac

[lossyrob]

@francbartoli is the thought that STAC catalog providers would be their own provider architecture (i.e. separate from dataproviders), or that STAC would be a quality of existing data providers? If an elasticsearch backend, for instance, was loaded with STAC Items (perhaps marked in the dataset configuration), then some STAC-specific capabilities could be enabled.

To comment on the above comment:

Is stac intended to run along side ogc api’s in a single ogc-api endpoint, or does it require it’s own endpoint, in that case maybe deploy a second instance of pygeoapi in a ‘stac’ modus?

My understanding (which is a bit weaker, since I mostly work with static STACs) is that STAC API contains some additional endpoints:

• /stac - Simply gets the root catalog.
• /stac/search - Implemented so that STAC can do more advanced queries via extensions than what OAF currently supports

The idea would be that eventually, with the convergence of the Query/Filter extensions into OAF, the second endpoint would go away.

@matthewhanson could provide more info as I'm basically summarizing what I heard from him yesterday at the STAC sprint.

[matthewhanson]

There is currently a PR up to change those endpoints: radiantearth/stac-spec#632

The /stac endpoint would go away because it's redundant with the root endpoint / - it just returns a STAC catalog, which is the same thing that the root OAF endpoint returns with some additional fields.

/stac/search endpoint is proposed to be be renamed to /items and proposed to OAF as a general cross-collection search endpoint. However, this wouldn't go in until OAF 1.1.

[francbartoli]

Thanks @matthewhanson, so in the meantime, we could adopt /items but for users that might be a bit confusing to understand if it is not part yet of the OAF spec. And we don't know when it will land there