Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add more example expression objects #31

Open
Tracked by #7 ...
fmigneault opened this issue Apr 4, 2024 · 2 comments · May be fixed by #33
Open
Tracked by #7 ...

Add more example expression objects #31

fmigneault opened this issue Apr 4, 2024 · 2 comments · May be fixed by #33

Comments

@fmigneault
Copy link

fmigneault commented Apr 4, 2024

I think that (at least) 3 common definitions should be provided for https://github.com/stac-extensions/processing#expression-object to better guide users.

  • a generic "python script entry points" similar to what setup(entry_point=...) or poetry.scripts expect
    (e.g.: my_package.my_module:some_function or my_package.my_module:SomeClass.a_method)

  • a URI based reference to a script or executable
    (somewhat relates to Add a Software object #29 about the href requirement)
    (for this, I would suggest that "expression": {"href": "<uri>", "type"; "<media-type>"} is used, since expression allows anything)

  • some docker container or similar, using an expression like ghcr.io/NAMESPACE/IMAGE_NAME:latest (or a more explicit docker run call)

@emmanuelmathot
Copy link
Member

The processing extension initially aims at tracing the processing lineage of the item. I understand you want to specify possible processing on the item? The expression object is left free to add any data structure that would represent the processing applied. If you want to provide with more processing format and related convention, feel free to provide them with examples.

@fmigneault
Copy link
Author

I agree. If the above suggestions are valid, I can open a PR to add the examples.
Users are always free to define whichever format that suits their needs, but if we push them toward a common strategy with good examples, it can help "standardizing" some work later on.

Also related, once the Machine Learning Model (MLM) extension will be released, I plan to suggest another example similar to the following for STAC Items representing a derived product resulting from model predictions (eg: land-cover).

{
  "processing:level": "L4",
  "processing:expression": {
    "format": "stac-mlm",
    "expression": {
      "href": "<URI-to-MLM-STAC-Item>",
      "type": "application/geo+json"
    }
  }
}

As described in https://github.com/crim-ca/dlm-extension/blob/validate/best-practices.md#processing-extension

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 a pull request may close this issue.

3 participants