Storage Extension Specification

• Title: Storage
• Identifier: https://stac-extensions.github.io/storage/v2.0.0/schema.json
• Field Name Prefix: storage
• Scope: Item, Catalog, Collection
• Extension Maturity Classification: Pilot
• Owner: @matthewhanson @m-mohr

This document explains the Storage Extension to the SpatioTemporal Asset Catalog (STAC) specification. It allows adding details related to cloud object storage access and costs to be associated with STAC Assets. This extension does not cover NFS solutions provided by PaaS cloud companies.

• Examples:
  • NAIP Item with Alternate Assets: Shows a mixture of storage providers, including custom S3 hosts and the alternate assets extension.
  • Catalog with Link: Shows the usage of the extension on a link in a STAC Catalog.
  • Collection with Auth: Shows the usage of the extension in a STAC Collecion in combination with the authentication extension.
• JSON Schema
• Changelog

Fields

The fields in the table below can be used in these parts of STAC documents:

• Catalogs
• Collections
• Item Properties (incl. Summaries in Collections)
• Assets (for both Collections and Items, incl. Item Asset Definitions in Collections)
• Links

Field Name	Type	Description
storage:schemes	Map<string, Storage Scheme Object>	REQUIRED. A property that contains all of the storage schemes used by Assets and Links in the STAC Item, Catalog or Collection.

---

The fields in the table below can be used in these parts of STAC documents:

• Catalogs
• Collections
• Item Properties (incl. Summaries in Collections)
• Assets (for both Collections and Items, incl. Item Asset Definitions in Collections)
• Links
• Alternate Assets Object

Field Name	Type	Description
storage:refs	[string]	A property that specifies which schemes in storage:schemes may be used to access an Asset or Link. Each value must be one of the keys defined in storage:schemes.

Storage Scheme Object

Field Name	Type	Description
type	string	REQUIRED. Type identifier for the platform, see below.
platform	string	REQUIRED. The cloud provider where data is stored as URI or URI template to the API.
region	string	The region where the data is stored. Relevant to speed of access and inter region egress costs (as defined by PaaS provider).
requester_pays	boolean	Is the data "requester pays" (true) or is it "data manager/cloud provider pays" (false). Defaults to false.
...	...	Additional properties as defined in the URL template or in the platform specific documents.

The properties title and description as defined in Common Metadata should be used as well.

platform

The platform field identifies the cloud provider where the data is stored as URI or URI template to the API of the service.

If a URI template is provided, all variables must be defined in the Storage Scheme Object as a property with the same name. For example, the URI template https://{bucket}.{region}.example.com must have at least the properties bucket and region defined:

{
  "type": "example",
  "platform": "https://{bucket}.{region}.example.com",
  "region": "eu-fr",
  "bucket": "john-doe-stac",
  "requester_pays": true
}

In case an href contains a non-HTTP URL that is not directly resolvable, the platform property must identify the host so that the URL can be resolved without further information. For example, this is especially useful to provide the endpoint URL for custom S3 providers. In this case the platform could effectively provide the endpoint URL.

type

We try to collect pre-defined templates and best pratices for as many providers as possible in this repository, but be aware that these are not part of the official extension releases. This extension just provides the framework, the provider best pratices may change at any time without a new version of this extension being released.

The following providers have defined best pratices at this point:

type	Provider and Documentation
aws-s3	AWS S3
custom-s3	Generic S3 (non-AWS)
ms-azure	Microsoft Azure

Feel encouraged to submit additional platform specifications via Pull Requests.

The type fields can be any value chosen by the implementor, but the types defined in the table above should be used as defined in the best practices. This ensures proper schema validation.

Contributing

See the Contributor documentation for details.