You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
| 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). |
30
30
| processing:lineage| string | Lineage Information provided as free text information about the how observations were processed or models that were used to create the resource being described [NASA ISO](https://wiki.earthdata.nasa.gov/display/NASAISO/Lineage+Information). For example, `GRD Post Processing` for "GRD" product of Sentinel-1 satellites. [CommonMark 0.29](https://commonmark.org/) syntax MAY be used for rich text representation. |
31
31
| processing:level| string | The name commonly used to refer to the processing level to make it easier to search for product level across collections or items. The short name must be used (only `L`, not `Level`). See the [list of suggested processing levels](#suggested-processing-levels). |
32
32
| 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. |
33
-
| 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. |
33
+
| processing:datetime| string | Processing date and time of the corresponding data formatted according to [RFC 3339, section 5.6](https://tools.ietf.org/html/rfc3339#section-5.6), in UTC. |
34
+
| processing:version| string | The version of the primary processing software or processing chain that produced the data. For example, this could be the processing baseline for the Sentinel missions. |
35
+
| processing:software| Map<string, string> | A dictionary with name/version for key/value describing one or more applications or libraries that were involved during the production of the data for provenance purposes. |
34
36
35
-
These fields can be used in a variety of places:
37
+
The fields in the table above can be used in these parts of STAC documents:
-[x] Item Properties (incl. Summaries in Collections)
42
+
-[x] Assets (for both Collections and Items, incl. Item Asset Definitions in Collections)
43
+
-[ ] Links
44
+
45
+
In more detail, the following restrictions apply:
36
46
37
47
1. Items:
38
-
- The fields are placed in the properties. At least one field is required to be present.
48
+
- The fields are usually placed in the properties. At least one field is required to be present.
39
49
- Additionally, STAC allows all fields to be used in the Asset Object.
40
50
41
51
2. Collections:
42
52
- The fields are usually placed in the [Provider Objects](https://github.com/radiantearth/stac-spec/blob/master/collection-spec/collection-spec.md#provider-object)
43
53
for the `providers` that have the role `producer` or `processor` assigned.
44
54
They don't need to be provided for all providers of the respective role.
45
55
- The fields can also be used in `summaries`, Collection `assets` or Item asset definitions (`item_assets`).
56
+
Please note that the JSON Schema is not be able to validate the values of Collection summaries.
46
57
47
-
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.
48
-
Please note that the JSON Schema is not be able to validate the values of Collection summaries.
58
+
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.
49
59
50
60
### Processing Date Time
51
61
52
-
The time of the processing is directly specified via the `created` properties of the target asset as specified in the [STAC Common metadata](https://github.com/radiantearth/stac-spec/blob/master/item-spec/common-metadata.md#date-and-time)
62
+
The time of the processing can be specified as a global field in `processing:datetime`,
63
+
but it can also be specified directly and individually via the `created` properties of the target asset
64
+
as specified in the [STAC Common metadata](https://github.com/radiantearth/stac-spec/blob/master/item-spec/common-metadata.md#date-and-time).
65
+
66
+
`created` in Item properties describes the STAC metadata creation and in Assets it describes the creation of the data files.
67
+
Thus the timestamps provided in Item Properties for `created` and `processing:datetime` may differ.
68
+
As Item properties are easier to be indexed and used for filtering purposes, `processing:datetime` exists.
69
+
`created` and `processing:datetime` should usually be the same value in Assets and as such `processing:datetime`
70
+
can usually be omitted.
71
+
72
+
### Version Numbers
73
+
74
+
Three fields exist for version numbers:
75
+
-`processing:software`
76
+
-`processing:version`
77
+
-`version` (in the [Version extension](https://github.com/stac-extensions/version))
78
+
79
+
The different fields exist to give data providers more flexibility depending on their needs.
80
+
81
+
In Item Properties:
82
+
-`processing:version` is useful if a single version number is available for the metadata or data that users should be able to filter on.
83
+
A popular example for this is the processing baseline in Sentinel missions.
84
+
-`processing:software` is used if the software libraries/tools are important to know, but it's not important to filter on them.
85
+
They are mostly informative and important to be complete for reporducibility purposes.
86
+
Thus, the values in the object can not just be version numbers, but also be e.g. tag names, commit hashes or similar.
87
+
For example, you could expose a simplified version of the `Pipfile.lock` (Python) or `package-lock.json` (NodeJS).
88
+
If you need more information, you could also link to such files via the relation type `processing-software`.
89
+
-`version` is usually not used in the context of processing and describes the version of the metadata.
53
90
54
91
### Linking the Items
55
92
56
-
In Items that declare this `processing` extension, it is recommended to add one or more [Links](https://github.com/radiantearth/stac-spec/blob/master/item-spec/item-spec.md#relation-types) with `derived_from` or `via` relationships to the eventual source metadata & data used in the processing. They could be used to trace back the processing history of the dataset.
93
+
In Items that declare this `processing` extension, it is recommended to add one or more [Links](https://github.com/radiantearth/stac-spec/blob/master/item-spec/item-spec.md#relation-types) with `derived_from` or `via` relationships to the eventual source metadata & data used in the processing.
94
+
They could be used to trace back the processing history of the dataset.
57
95
58
96
### Suggested Processing Levels
59
97
@@ -99,6 +137,7 @@ The following types should be used as applicable `rel` types in the
99
137
| derived_from | URL to a STAC Item that was used as input data in the creation of this Item. |
100
138
| processing-expression | A processing chain (or script) that describes how the data has been processed. |
101
139
| processing-execution | URL to any resource representing the processing execution (e.g. OGC Process API). |
140
+
| processing-software | URL to any resource that identifies the software and versions used for processing the data, e.g. a `Pipfile.lock` (Python) or `package-lock.json` (NodeJS). |
0 commit comments