Skip to content

Commit c397767

Browse files
committed
best practices: some clarifications #1108
1 parent 89923bf commit c397767

File tree

2 files changed

+13
-9
lines changed

2 files changed

+13
-9
lines changed

best-practices.md

Lines changed: 12 additions & 8 deletions
Original file line numberDiff line numberDiff line change
@@ -9,7 +9,8 @@
99
- [Deploying STAC Browser](#deploying-stac-browser)
1010
- [Requester Pays](#requester-pays)
1111
- **[Item Best Practices](#item-practices)**
12-
- [Field and ID formatting](#field-and-id-formatting)
12+
- [Field and ID formatting](#item-ids)
13+
- [Searchable Identifiers](#searchable-identifiers)
1314
- [Field selection and Metadata Linking](#field-selection-and-metadata-linking)
1415
- [Datetime selection](#datetime-selection)
1516
- [Unlocated Items](#unlocated-items)
@@ -147,19 +148,22 @@ For data providers using STAC with requester pays buckets, there are two main re
147148

148149
## Item Practices
149150

150-
### Field and ID formatting
151+
### Item IDs
151152

152153
When defining one's STAC properties and fields there are many choices to make on how to name various aspects of one's
153154
data. One of the key properties is the ID. The specification is quite flexible on ID's, primarily so that existing
154155
providers can easily use their same ID when they translate their data into STAC - they just need to be sure it is globally
155-
unique, so may need a prefix. But the use of URI reserved characters such as `:` or `/` is discouraged since this will
156+
unique, so may need a prefix. But the use of URI or file path reserved characters such as `:` or `/` is discouraged since this will
156157
result in [percented encoded](https://tools.ietf.org/html/rfc3986#section-2) [STAC API](https://github.com/radiantearth/stac-api-spec)
157-
endpoints. This isn't a blocker, it just makes the ID's served through API's a bit less parsable.
158+
endpoints and also the [IDs can't be used as file names](#catalog-layout).
158159

159-
When defining unique fields for search, like constellation or platform, it is recommended that
160-
the value consist of only lowercase characters, numbers, `_`, and `-`. Examples include `sentinel-1a` (Sentinel-1),
161-
`landsat-8` (Landsat-8) and `envisat` (Envisat). This is to provide consistency for search across Collections, so that
162-
people can just search for 'landsat-8', instead of thinking through all the ways providers might have chosen to name it.
160+
### Searchable Identifiers
161+
162+
When coming up with values for fields that contain searchable identifiers of some sort, like `constellation` or `platform`,
163+
it is recommended that the identifiers consist of only lowercase characters, numbers, `_`, and `-`.
164+
Examples include `sentinel-1a` (Sentinel-1), `landsat-8` (Landsat-8) and `envisat` (Envisat).
165+
This is to provide consistency for search across Collections, so that people can just search for `landsat-8`,
166+
instead of thinking through all the ways providers might have chosen to name it.
163167

164168
### Field selection and Metadata Linking
165169

item-spec/item-spec.md

Lines changed: 1 addition & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -90,7 +90,7 @@ As most geospatial assets are already uniquely defined by some
9090
identification scheme from the data provider it is recommended to simply use that ID.
9191
Data providers are advised to include sufficient information to make their IDs globally unique,
9292
including things like unique satellite IDs.
93-
See the [id section of best practices](../best-practices.md#field-and-id-formatting) for additional recommendations.
93+
See the [id section of best practices](../best-practices.md#item-ids) for additional recommendations.
9494

9595
#### assets
9696

0 commit comments

Comments
 (0)