Skip to content

Proposal: Define processing:expression with format: results - #44

Open
fmigneault wants to merge 4 commits into
stac-extensions:mainfrom
crim-ca:processing-result
Open

fmigneault wants to merge 4 commits into
stac-extensions:mainfrom
crim-ca:processing-result

Conversation

@fmigneault

Copy link
Copy Markdown

If a processing-expression or processing-execution reference (eg: an openEO Process, OGC API Processes, gdal-calc etc.) produced results to be annotated in a STAC Collection/Item for provenance, but that those results contained a mixture of file references (easily integrated as Assets) and data literals (eg: a threshold value or a predicted datetime), the processing extension does not offer an explicit method to indicate the data values.

If the values are simply placed in the Collection fields or Item properties, there is a risk to clash with actual fields that have semantic meaning for STAC (eg: predicted datetime will conflict with the datetime of STAC).

Therefore, there should be a way to provide such values, since creating an Asset file for small literal data is not practical. One approach would be to leverage the processing:expression free-form object. While this works, it makes it not reusable since anyone can come up with their own thing.

This PR indicates this strategy clearly such that it insensitive reuse and guide against anti-patterns.

This branch has not been deployed

No deployments
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant