Skip to content

Processing properties are not required on providers #8 #13

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.

Sign up for GitHub

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

Merged
merged 2 commits into from
Jan 3, 2022
Merged

Processing properties are not required on providers #8 #13

Changes from all commits
Commits
Show all changes
2 commits
Select commit Hold shift + click to select a range
0200271
Processing properties are not required on providers #8
m-mohr Nov 27, 2021
fddc07a
Update README.md
m-mohr Nov 27, 2021
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
18 changes: 13 additions & 5 deletions README.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -24,10 +24,6 @@ and therefore are shared across all items, it is recommended adding the fields t

## Item Properties and Collection Provider Fields

- For Items, the fields are placed in the properties. Additionally, STAC allows all Item properties to be used in the Asset Object.
- For Collections, the fields are placed in the [Provider Objects](https://github.com/radiantearth/stac-spec/blob/master/collection-spec/collection-spec.md#provider-object)
for the `providers` that have the role `producer` or `processor` assigned.

| Field Name | Type | Description |
| ----------------------- | ------------------- | ----------- |
| processing:expression | [Expression Object](#expression-object) | An expression or processing chain that describes how the data has been processed. Alternatively, you can also link to a processing chain with the relation type `processing-expression` (see below). |
Expand All @@ -36,7 +32,19 @@ for the `providers` that have the role `producer` or `processor` assigned.
| processing:facility | string | The name of the facility that produced the data. For example, `Copernicus S1 Core Ground Segment - DPA` for product of Sentinel-1 satellites. |
| processing:software | Map<string, string> | A dictionary with name/version for key/value describing one or more softwares that produced the data. For example, `"Sentinel-1 IPF":"002.71"` for the software that produces Sentinel-1 satellites data. |

*At least one of the fields must be specified.*
These fields can be used in a variety of places:

For Items:
- The fields are placed in the properties.
- Additionally, STAC allows all fields to be used in the Asset Object.

For Collections:
- The fields are usually placed in the [Provider Objects](https://github.com/radiantearth/stac-spec/blob/master/collection-spec/collection-spec.md#provider-object)
for the `providers` that have the role `producer` or `processor` assigned. They don't need to be provided for all providers of the respective role.
- The fields can also be used in summaries, assets or Item asset definitions.

If the extension is given in the `stac_extensions` list, at least one of the fields must be specified in any of the given places listed above.
Please note that the JSON Schema might not be able to validate this requirement in all cases due to limitations in JSON Schema.
Copy link
Contributor

@l0b0 l0b0 Nov 28, 2021

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Could we make sure which exact places this requirement is validated in, or at least which places it should be validated in? Then we could add tests to make sure it works that way. Otherwise users of the extension have to be JSON Schema experts to work out whether their use case is even validated.

Copy link
Contributor Author

@m-mohr m-mohr Dec 11, 2021 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Sure, but I don't have the time for it. A proposal would be welcome.

Copy link
Contributor

@l0b0 l0b0 Dec 14, 2021

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Working on some tests which illustrate the existing (buggy) behaviour.

Copy link
Contributor

@l0b0 l0b0 Dec 14, 2021 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

See #16.

Copy link
Contributor

@l0b0 l0b0 Dec 14, 2021 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think I've fixed the main issues in #9. Except for some remaining weird behaviour it should now be possible to conclusively say where these fields can be used, and how.

Copy link
Contributor Author

@m-mohr m-mohr Dec 22, 2021

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I assumed you'd want some text to be added to this PR which makes requirements clear by just reading the text. Otherwise, we could just merge this now.

Copy link
Contributor

@l0b0 l0b0 Dec 22, 2021

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Theistext doesn't tell the user exactly where these properties can be used such that they will be validated, but the tests in #9 do. Maybe we could use the tests as a template for updating the documentation, so that it's precise and complete?

Copy link
Contributor Author

@m-mohr m-mohr Dec 22, 2021

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

And I assumed you'd provide the text as you had worked on #9 ;-)

Copy link
Contributor

@l0b0 l0b0 Dec 22, 2021

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can do.


### Processing Date Time

Expand Down