### Format/Pretty-Print Example Files

Source: https://github.com/radiantearth/stac-spec/blob/master/CONTRIBUTING.md

Run this command to automatically format or pretty-print the example files in the repository, ensuring consistent styling and readability across all examples.

```bash
npm run format-examples
```

--------------------------------

### Check Example Files Locally

Source: https://github.com/radiantearth/stac-spec/blob/master/CONTRIBUTING.md

This command allows you to specifically check only the example files within the STAC spec repository for correctness and adherence to standards.

```bash
npm run check-examples
```

--------------------------------

### STAC Consistent URI Resolution Examples

Source: https://github.com/radiantearth/stac-spec/blob/master/best-practices.md

Examples demonstrating how relative URIs are resolved against base URLs in STAC, highlighting the significance of trailing slashes and the behavior of path components during resolution.

```APIDOC
| # | Base URL                                  | Relative URL       | Resolved URL                                  |
| - | ----------------------------------------- | ------------------ | --------------------------------------------- |
| 1 | `https://example.com/folder/catalog.json` | `item.json`        | `https://example.com/folder/item.json`        |
| 2 | `https://example.com/folder`              | `item.json`        | `https://example.com/item.json`               |
| 3 | `https://example.com/folder/`             | `item.json`        | `https://example.com/folder/item.json`        |
| 4 | `https://example.com/folder`              | `folder/item.json` | `https://example.com/folder/item.json`        |
| 5 | `https://example.com/folder/`             | `folder/item.json` | `https://example.com/folder/folder/item.json` |
| 6 | `https://example.com/another/folder`      | `../item.json`     | `https://example.com/item.json`               |
| 7 | `https://example.com/another/folder/`     | `../item.json`     | `https://example.com/another/item.json`       |
| 8 | `https://example.com`                     | `folder/item.json` | `https://example.com/folder/item.json`        |
| 9 | `https://example.com/`                    | `folder/item.json` | `https://example.com/folder/item.json`        |
```

--------------------------------

### Install STAC Spec Dependencies with npm

Source: https://github.com/radiantearth/stac-spec/blob/master/CONTRIBUTING.md

This command installs all necessary dependencies for the STAC spec repository. It requires npm, which is part of a Node.js installation. Alternatively, yarn can be used by replacing 'npm' with 'yarn'.

```bash
npm install
```

--------------------------------

### STAC Static Catalog Versioning File Structure Example

Source: https://github.com/radiantearth/stac-spec/blob/master/best-practices.md

Illustrates the recommended file naming and linking convention for versioning STAC Items in a static catalog. When an item is created, a versioned copy is made. Upon update, the main item links to the previous version, and a new versioned copy is created.

```Filesystem
root / collections / example_collection / items / my_item / my_item.json
root / collections / example_collection / items / my_item / my_item_01.json

When my_item.json is updated:
root / collections / example_collection / items / my_item / my_item.json
root / collections / example_collection / items / my_item / my_item_01.json
root / collections / example_collection / items / my_item / my_item_02.json
```

--------------------------------

### Run All Local Checks for STAC Spec

Source: https://github.com/radiantearth/stac-spec/blob/master/CONTRIBUTING.md

Execute this command to run all local checks, including markdown and example file validations. This ensures that proposed changes will pass the continuous integration checks on pull requests.

```bash
npm test
```

--------------------------------

### STAC Asset Roles Usage

Source: https://github.com/radiantearth/stac-spec/blob/master/best-practices.md

Explains the purpose and recommended usage of asset roles in STAC to describe the function of assets, especially when multiple assets share the same media type. Provides examples of common role combinations.

```APIDOC
Asset Roles:
  Purpose: Describe what each asset is used for, especially when several assets have the same media type.
  Recommendation: Use at least one role for every asset. Multiple roles are often sensible.
  Examples:
    - data, reflectance: For main data processed to reflectance.
    - metadata, cloud: For a cloud mask asset.
    - metadata, cloud, cloud-shadow, snow-ice: For an asset representing several types of 'unusable data'.
  Guidance: If no clear role, pick a sensible name and consider adding to the list or an extension.
```

--------------------------------

### STAC Item Properties with Vendor and Community Prefixes

Source: https://github.com/radiantearth/stac-spec/blob/master/extensions/README.md

This example demonstrates the use of prefixes within STAC Item properties to clearly distinguish metadata fields originating from different sources, such as core STAC, community extensions (e.g., 'eo:' for Electro-Optical), and vendor-specific data (e.g., 'l8:' for Landsat 8). This approach helps in organizing and identifying the provenance of diverse metadata within a single STAC Item.

```js
  "properties": {
    "datetime":"2018-01-01T13:21:30Z",

    "start_datetime":"2018-01-01T13:21:30Z",
    "end_datetime":"2018-01-01T13:31:30Z",

    "view:off_nadir": -0.001,
    "eo:cloud_cover": 10.31,
    "view:sun_azimuth": 149.01607154,
    "view:sun_elevation": 59.21424700,
    "gsd": 30,

    "l8:data_type": "L1T",
    "l8:wrs_path": 153,
    "l8:wrs_row": 25,
    "l8:earth_sun_distance": 1.0141560,
    "l8:ground_control_points_verify": 114,
    "l8:geometric_rmse_model": 7.562,
    "l8:image_quality_tirs": 9,
    "l8:ground_control_points_model": 313,
    "l8:geometric_rmse_model_x": 5.96,
    "l8:geometric_rmse_model_y": 4.654,
    "l8:geometric_rmse_verify": 5.364,
    "l8:image_quality_oli": 9
  }
```

--------------------------------

### STAC Common Asset Roles Reference

Source: https://github.com/radiantearth/stac-spec/blob/master/best-practices.md

Defines a list of commonly used asset roles within the SpatioTemporal Asset Catalog (STAC) specification, providing descriptions for each role to guide their appropriate use and ensure consistency across STAC implementations.

```APIDOC
Role Name: data
  Description: The data itself, excluding the metadata.
Role Name: metadata
  Description: Metadata sidecar files describing the data, for example a Landsat-8 MTL file.
Role Name: thumbnail
  Description: An asset that represents a thumbnail of the Item or Collection, typically a RGB or grayscale image primarily for human consumption, low resolution, restricted spatial extent, and displayable in a web browser without scripts or extensions.
Role Name: overview
  Description: An asset that represents a more detailed overview of the Item or Collection, typically a RGB or grayscale image primarily for human consumption, medium resolution, full spatial extent, in a file format that's can be visualized easily (e.g., Cloud-Optimized GeoTiff).
Role Name: visual
  Description: An asset that represents a detailed overview of the Item or Collection, typically a RGB or grayscale image primarily for human consumption, high or native resolution (often sharpened), full spatial extent, in a file format that's can be visualized easily (e.g., Cloud-Optimized GeoTiff).
Role Name: date
  Description: An asset that provides per-pixel acquisition timestamps, typically serving as metadata to another asset
Role Name: graphic
  Description: Supporting plot, illustration, or graph associated with the Item
Role Name: data-mask
  Description: File indicating if corresponding pixels have Valid data and various types of invalid data
Role Name: snow-ice
  Description: Points to a file that indicates whether a pixel is assessed as being snow/ice or not.
Role Name: land-water
  Description: Points to a file that indicates whether a pixel is assessed as being land or water.
Role Name: water-mask
  Description: Points to a file that indicates whether a pixel is assessed as being water (e.g. flooding map).
Role Name: iso-19115
  Description: Points to an [ISO 19115](https://www.iso.org/standard/53798.html) metadata file
```

--------------------------------

### STAC Item Link to Collection

Source: https://github.com/radiantearth/stac-spec/blob/master/item-spec/item-spec.md

Example of a STAC Item link object demonstrating the `collection` relation type. This link is required when the `collection` field in the Item's properties is filled, pointing to the associated STAC Collection definition.

```json
"links": [
  { "rel": "collection", "href": "link/to/collection/record.json" }
]
```

--------------------------------

### STAC Asset Definition with Direct Band Properties (Without `bands` Array)

Source: https://github.com/radiantearth/stac-spec/blob/master/best-practices.md

Illustrates an alternative method for defining a single-band asset where the band-specific properties are directly included within the asset's definition, rather than being nested within a `bands` array. This simpler approach is suitable when the band does not require a specific `name` property (which is only available in the `bands` array) and is not part of a larger set of bands that needs to be summarized or combined. The example shows `data_type`, `eo:common_name`, and `raster:spatial_resolution` directly under the asset.

```json
{
  "assets": {
    "example": {
      "href": "example.tif",
      "data_type": "uint16",
      "eo:common_name": "red",
      "raster:spatial_resolution": 10
    }
  }
}
```

--------------------------------

### STAC Asset Definition with `bands` Array for Single Band

Source: https://github.com/radiantearth/stac-spec/blob/master/best-practices.md

Demonstrates how to define a single-band asset within a STAC Item's `assets` object by explicitly using the `bands` array. This approach is recommended when it's important to convey the band's presence, its specific name (which is only available in the `bands` array), or when the band is part of a set that needs to be summarized or combined across different assets. The example shows properties like `data_type`, `eo:common_name`, and `raster:spatial_resolution` defined within the band object.

```json
{
  "assets": {
    "example": {
      "href": "example.tif",
      "bands": [
        {
          "data_type": "uint16",
          "eo:common_name": "red",
          "raster:spatial_resolution": 10
        }
      ]
    }
  }
}
```

--------------------------------

### Recommendations for Unregistered STAC Media Types

Source: https://github.com/radiantearth/stac-spec/blob/master/best-practices.md

Provides guidance on handling media types not registered with IANA, recommending the use of custom content types with the `vnd.` prefix and encouraging IANA registration.

```APIDOC
Recommendations for Unregistered Media Types:
  - Use custom content types, typically with the `vnd.` prefix (RFC 6838 section-3.2).
  - Ideally, the format provider registers the media type with IANA.
  - Internal use may not require IANA registration.
  - IANA registration for `vnd` media types is relatively easy.
```

--------------------------------

### STAC Requester Pays Configuration Recommendations

Source: https://github.com/radiantearth/stac-spec/blob/master/best-practices.md

Recommendations for STAC data providers using 'requester pays' buckets, including separating STAC JSON metadata into a public bucket and using cloud-specific protocols for asset hrefs to enable proper client handling and billing.

```APIDOC
1. Put STAC JSON in a separate, public, non-requester pays bucket.
2. For Asset hrefs to requester pays buckets, use cloud provider-specific protocols (e.g., s3://, gs://) instead of https://.
```

--------------------------------

### STAC Common Media Types Reference

Source: https://github.com/radiantearth/stac-spec/blob/master/best-practices.md

Provides a comprehensive list of media types recognized and utilized within the STAC ecosystem, including their descriptions and status (e.g., unofficial, standardized).

```APIDOC
Media Type: image/tiff; application=geotiff
  Description: GeoTIFF with standardized georeferencing metadata

Media Type: image/tiff; application=geotiff; profile=cloud-optimized
  Description: Cloud Optimized GeoTIFF (unofficial). Once there is an official media type it will be added and the custom media type here will be deprecated.

Media Type: image/jp2
  Description: JPEG 2000

Media Type: image/png
  Description: Visual PNGs (e.g. thumbnails)

Media Type: image/jpeg
  Description: Visual JPEGs (e.g. thumbnails, oblique)

Media Type: text/xml or application/xml
  Description: XML metadata [RFC 7303]

Media Type: application/json
  Description: A JSON file (often metadata, or labels)

Media Type: text/plain
  Description: Plain text (often metadata)

Media Type: application/geo+json
  Description: GeoJSON

Media Type: application/geopackage+sqlite3
  Description: GeoPackage

Media Type: application/x-hdf5
  Description: Hierarchical Data Format version 5

Media Type: application/x-hdf
  Description: Hierarchical Data Format versions 4 and earlier.

Media Type: application/vnd.laszip+copc
  Description: COPC Cloud optimized PointCloud
```

--------------------------------

### Migrate STAC 1.0 eo:bands/raster:bands to STAC 1.1 Unified Bands

Source: https://github.com/radiantearth/stac-spec/blob/master/best-practices.md

Illustrates the migration process from STAC 1.0's separate eo:bands and raster:bands arrays to the unified bands array in STAC 1.1. It shows how to merge band objects, rename properties with extension prefixes, and deduplicate common values to the asset level, including handling overrides.

```json
{
  "assets": {
    "example": {
      "href": "example.tif",
      "eo:bands": [
        {
          "name": "r",
          "common_name": "red"
        },
        {
          "name": "g",
          "common_name": "green"
        },
        {
          "name": "b",
          "common_name": "blue"
        },
        {
          "name": "nir",
          "common_name": "nir"
        }
      ],
      "raster:bands": [
        {
          "data_type": "uint16",
          "spatial_resolution": 10,
          "sampling": "area"
        },
        {
          "data_type": "uint16",
          "spatial_resolution": 10,
          "sampling": "area"
        },
        {
          "data_type": "uint16",
          "spatial_resolution": 10,
          "sampling": "area"
        },
        {
          "data_type": "uint16",
          "spatial_resolution": 30,
          "sampling": "area"
        }
      ]
    }
  }
}
```

```json
{
  "assets": {
    "example": {
      "href": "example.tif",
      "data_type": "uint16",
      "raster:sampling": "area",
      "raster:spatial_resolution": 10,
      "bands": [
        {
          "name": "r",
          "eo:common_name": "red"
        },
        {
          "name": "g",
          "eo:common_name": "green"
        },
        {
          "name": "b",
          "eo:common_name": "blue"
        },
        {
          "name": "nir",
          "eo:common_name": "nir",
          "raster:spatial_resolution": 30
        }
      ]
    }
  }
}
```

--------------------------------

### STAC Registered Media Types

Source: https://github.com/radiantearth/stac-spec/blob/master/best-practices.md

Lists common media types used within STAC, linking to their respective specifications. Includes formats like GeoParquet, OGC 3D Tiles, and PMTiles.

```APIDOC
application/vnd.apache.parquet: Apache Geoparquet
application/3dtiles+json: OGC 3D Tiles
application/vnd.pmtiles: Protomaps PMTiles
```

--------------------------------

### STAC API Specification Overview

Source: https://github.com/radiantearth/stac-spec/blob/master/README.md

Details the STAC API specification, which provides API endpoints based on the OGC API - Features standard for searching Item objects.

```APIDOC
STAC API specification: Provides API endpoints, based on the OGC API - Features standard, that enable clients to search for Item objects that match their filtering criteria.
```

--------------------------------

### Optimize STAC Asset Band Properties by Deduplication

Source: https://github.com/radiantearth/stac-spec/blob/master/best-practices.md

Demonstrates how to optimize STAC asset definitions by moving common band properties (e.g., data_type, raster:spatial_resolution) from individual band objects to the asset level, reducing redundancy and making the bands array more lightweight.

```json
{
  "assets": {
    "example": {
      "href": "example.tif",
      "bands": [
        {
          "name": "r",
          "eo:common_name": "red",
          "data_type": "uint16",
          "raster:spatial_resolution": 10
        },
        {
          "name": "g",
          "eo:common_name": "green",
          "data_type": "uint16",
          "raster:spatial_resolution": 10
        },
        {
          "name": "b",
          "eo:common_name": "blue",
          "data_type": "uint16",
          "raster:spatial_resolution": 10
        }
      ]
    }
  }
}
```

```json
{
  "assets": {
    "example": {
      "href": "example.tif",
      "data_type": "uint16",
      "raster:spatial_resolution": 10,
      "bands": [
        {
          "name": "r",
          "eo:common_name": "red"
        },
        {
          "name": "g",
          "eo:common_name": "green"
        },
        {
          "name": "b",
          "eo:common_name": "blue"
        }
      ]
    }
  }
}
```

--------------------------------

### STAC Extensions Specification

Source: https://github.com/radiantearth/stac-spec/blob/master/README.md

Describes how STAC can use extensions to extend core functionality or add domain-specific fields. Extensions can be published anywhere, with a preferred location in the GitHub `stac-extensions` organization.

```APIDOC
STAC Extensions: Describe how STAC can use extensions that extend the functionality of the core spec or add fields for specific domains. Extensions can be published anywhere, although the preferred location for public extensions is in the GitHub `stac-extensions` organization.
```

--------------------------------

### Check Markdown Files Locally

Source: https://github.com/radiantearth/stac-spec/blob/master/CONTRIBUTING.md

Use this command to specifically check only the markdown files within the STAC spec repository for formatting and syntax errors.

```bash
npm run check-markdown
```

--------------------------------

### STAC Catalog Specification

Source: https://github.com/radiantearth/stac-spec/blob/master/README.md

Specifies a simple, flexible JSON file structure for linking various STAC Items, Catalogs, or Collections together for crawling or browsing.

```APIDOC
STAC Catalog: A simple, flexible JSON file of links to Items, Catalogs or Collections that can be used in a variety of ways to link various STAC Items together to be crawled or browsed.
```

--------------------------------

### STAC Commons Specification

Source: https://github.com/radiantearth/stac-spec/blob/master/README.md

Describes parts of the STAC specification that are shared across Item, Catalog, and Collection specifications, including assets, links, and common metadata.

```APIDOC
STAC Commons: Describes parts of the specification that are shared across the specifications listed above. This includes assets, links and common metadata.
```

--------------------------------

### STAC Item Fields API Reference

Source: https://github.com/radiantearth/stac-spec/blob/master/item-spec/item-spec.md

This snippet provides a detailed API reference for the fields that constitute a STAC Item. It includes field names, their data types, descriptions, and requirements (e.g., REQUIRED, conditional requirements). It also covers notes on `stac_version` and `stac_extensions`.

```APIDOC
STAC Item Fields:
  type: string (REQUIRED)
    Description: Type of the GeoJSON Object. MUST be set to `Feature`.
  stac_version: string (REQUIRED)
    Description: The STAC version the Item implements.
  stac_extensions: [string]
    Description: A list of extensions the Item implements. This list must only contain extensions that extend the Item specification itself.
  id: string (REQUIRED)
    Description: Provider identifier. The ID should be unique within the Collection that contains the Item.
  geometry: GeoJSON Geometry Object | null (REQUIRED)
    Description: Defines the full footprint of the asset represented by this item, formatted according to RFC 7946, section 3.1 if a geometry is provided or section 3.2 if no geometry is provided.
  bbox: [number] (REQUIRED if `geometry` is not `null`, prohibited if `geometry` is `null`)
    Description: Bounding Box of the asset represented by this Item, formatted according to RFC 7946, section 5.
  properties: Properties Object (REQUIRED)
    Description: A dictionary of additional metadata for the Item.
  links: [Link Object] (REQUIRED)
    Description: List of link objects to resources and related URLs.
  assets: Map<string, Asset Object> (REQUIRED)
    Description: Dictionary of asset objects that can be downloaded, each with a unique key.
  collection: string
    Description: The `id` of the STAC Collection this Item references to. This field is required if a link with a `collection` relation type is present and is not allowed otherwise.

STAC Versioning:
  In general, STAC versions can be mixed, but recommended best practices should be kept in mind.

STAC Extensions:
  A list of extensions the Item implements. The list consists of URLs to JSON Schema files that can be used for validation.
```

--------------------------------

### Determine STAC File Type using 'type' and 'stac_version' fields

Source: https://github.com/radiantearth/stac-spec/blob/master/best-practices.md

This snippet outlines the primary method for identifying STAC files (Item, Collection, Catalog) based on their 'type' field and, for Items, the presence of 'stac_version'. It provides a decision tree for classification.

```shell
if type is 'Collection'
  => Collection
else if type is 'Catalog'
  => Catalog
else if type is 'Feature' and stac_version is defined
  => Item
else
  => Invalid (JSON)
```

--------------------------------

### STAC Link Relation Types (IANA)

Source: https://github.com/radiantearth/stac-spec/blob/master/best-practices.md

This section details common IANA Link Relation Types recommended for use in STAC (SpatioTemporal Asset Catalog) implementations. These relations define the nature of a link between a STAC entity (Item, Collection, Catalog) and another resource, aiding clients in understanding the structure and content of related data. The table specifies each relation type and its specific application within the STAC context.

```APIDOC
alternate:
  Description: It is recommended that STAC Items are also available as HTML, and should use this rel with "type" : "text/html" to tell clients where they can get a version of the Item or Collection to view in a browser. See [STAC on the Web in Best Practices](#stac-on-the-web) for more information.
canonical:
  Description: The URL of the [canonical](https://en.wikipedia.org/wiki/Canonical_link_element) version of the Item or Collection. API responses and copies of catalogs should use this to inform users that they are direct copy of another STAC Item, using the canonical rel to refer back to the primary location.
via:
  Description: The URL of the source metadata that this STAC Item or Collection is created from. Used similarly to canonical, but refers back to a non-STAC record (Landsat MTL, Sentinel metadata XML, etc)
prev:
  Description: Indicates that the link's context is a part of a series, and that the previous in the series is the link target. Typically used in STAC by API's, to return smaller groups of Items or Catalogs/Collections.
next:
  Description: Indicates that the link's context is a part of a series, and that the next in the series is the link target. Typically used in STAC by API's, to return smaller groups of Items or Catalogs/Collections.
preview:
  Description: Refers to a resource that serves as a preview (see [RFC 6903, sec. 3](https://tools.ietf.org/html/rfc6903#section-3)), usually a lower resolution thumbnail. In STAC this would usually be the same URL as the [thumbnail](#list-of-asset-roles) asset, but adding it as a link in addition enables OGC API clients that can't read assets to make use of it. It also adds support for thumbnails to STAC Catalogs as they can't list assets.
derived_from:
  Description: URL to a STAC Entity that was used as input data in the creation of this Entity.
```

--------------------------------

### STAC Standard Media Types

Source: https://github.com/radiantearth/stac-spec/blob/master/commons/links.md

Lists recommended Media Types (formerly MIME types) to be used in the `type` field of STAC Link Objects and Asset Objects. These types help web clients determine how to render and display content from STAC catalogs.

```APIDOC
STAC Media Types:
  - media_type: "application/geo+json"
    description: "A STAC Item"
  - media_type: "application/json"
    description: "A STAC Catalog"
  - media_type: "application/json"
    description: "A STAC Collection"
```

--------------------------------

### STAC Asset Object Definition

Source: https://github.com/radiantearth/stac-spec/blob/master/commons/assets.md

Defines the structure and properties of a STAC Asset Object, including required and optional fields for linking to data, providing descriptive metadata, and specifying media types and semantic roles. Additional fields may be added in special cases.

```APIDOC
Asset Object:
  href:
    type: string
    description: REQUIRED. URI to the asset object. Relative and absolute URI are both allowed. Trailing slashes are significant.
  title:
    type: string
    description: The displayed title for clients and users.
  description:
    type: string
    description: A description of the Asset providing additional details, such as how it was processed or created. CommonMark 0.29 syntax MAY be used for rich text representation.
  type:
    type: string
    description: Media type of the asset. See the common media types in the best practice doc for commonly used asset types.
  roles:
    type: [string]
    description: The semantic roles of the asset, similar to the use of `rel` in links.
```

--------------------------------

### STAC Common Metadata: Basic Descriptive Fields

Source: https://github.com/radiantearth/stac-spec/blob/master/commons/common-metadata.md

Defines fundamental descriptive fields for STAC entities such as Catalogs, Collections, Items, and Assets, providing a human-readable title, a detailed description, and a list of keywords and semantic roles.

```APIDOC
Field Name  | Type      | Description
----------- | --------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------
title       | string    | A human readable title describing the STAC entity.
description | string    | Detailed multi-line description to fully explain the STAC entity. [CommonMark 0.29](https://commonmark.org/) syntax MAY be used for rich text representation.
keywords    | \[string] | List of keywords describing the STAC entity.
roles       | \[string] | The semantic roles of the entity, e.g. for assets, links, providers, bands, etc.
```

--------------------------------

### STAC Collection Object Field Reference

Source: https://github.com/radiantearth/stac-spec/blob/master/collection-spec/collection-spec.md

Defines the required and optional fields for a STAC Collection object, including their types and descriptions. This table specifies the structure for valid STAC Collections.

```APIDOC
Collection Fields:
  type:
    Type: string
    Description: REQUIRED. Must be set to 'Collection' to be a valid Collection.
  stac_version:
    Type: string
    Description: REQUIRED. The STAC version the Collection implements.
  stac_extensions:
    Type: [string]
    Description: A list of extension identifiers the Collection implements.
  id:
    Type: string
    Description: REQUIRED. Identifier for the Collection that is unique across all collections in the root catalog.
  title:
    Type: string
    Description: A short descriptive one-line title for the Collection.
  description:
    Type: string
    Description: REQUIRED. Detailed multi-line description to fully explain the Collection. CommonMark 0.29 syntax MAY be used for rich text representation.
  keywords:
    Type: [string]
    Description: List of keywords describing the Collection.
  license:
    Type: string
    Description: REQUIRED License(s) of the data collection as SPDX License identifier, SPDX License expression, or 'other' (see below).
  providers:
    Type: [Provider Object]
    Description: A list of providers, which may include all organizations capturing or processing the data or the hosting provider.
  extent:
    Type: Extent Object
    Description: REQUIRED. Spatial and temporal extents.
  summaries:
    Type: Map<string, [*]|Range Object|JSON Schema Object>
    Description: STRONGLY RECOMMENDED. A map of property summaries, either a set of values, a range of values or a JSON Schema.
  links:
    Type: [Link Object]
    Description: REQUIRED. A list of references to other documents.
  assets:
    Type: Map<string, Asset Object>
    Description: Dictionary of asset objects that can be downloaded, each with a unique key.
  item_assets:
    Type: Map<string, Item Asset Definition Object>
    Description: A dictionary of assets that can be found in member Items.
```

--------------------------------

### STAC Collection Specification

Source: https://github.com/radiantearth/stac-spec/blob/master/README.md

Provides additional information about a spatio-temporal collection of data, likely a related group of STAC Items. Includes spatial/temporal extent, license, keywords, enabling higher-level discovery.

```APIDOC
STAC Collection: Provides additional information about a spatio-temporal collection of data. In the context of STAC it is most likely a related group of STAC Items that is made available by a data provider. It includes things like the spatial and temporal extent of the data, the license, keywords, etc. It enables discovery at a higher level than individual Item objects.
```

--------------------------------

### STAC Catalog Core Fields and API Endpoint

Source: https://github.com/radiantearth/stac-spec/blob/master/catalog-spec/README.md

Details the 'type' field used to distinguish STAC Catalogs from Collections and describes the root endpoint for STAC API implementations.

```APIDOC
STAC Catalog/Collection Type Field:
  Field Name: type
  Description: Distinguishes between Catalog and Collection objects.
  Required: Yes
  Possible Values:
    - "Catalog"
    - "Collection"

STAC API Root Endpoint:
  Path: /
  Description: The standard entry point for STAC API implementations.
  Returns: A STAC Catalog object.
  Reference: Defined in the STAC API specification (OpenAPI).
```

--------------------------------

### STAC API Object: Provider Object

Source: https://github.com/radiantearth/stac-spec/blob/master/collection-spec/collection-spec.md

Defines the structure for a provider, which is any organization influencing the Collection's data, including those capturing, processing, or hosting the content.

```APIDOC
Provider Object:
  name: string (REQUIRED) - The name of the organization or the individual.
  description: string - Multi-line description to add further provider information such as processing details for processors and producers, hosting details for hosts or basic contact information. CommonMark 0.29 syntax MAY be used for rich text representation.
  roles: [string] - Roles of the provider. Any of 'licensor', 'producer', 'processor' or 'host'.
  url: string - Homepage on which the provider describes the dataset and publishes contact information.

Roles:
  licensor: The organization that is licensing the dataset under the license specified in the Collection's 'license' field.
  producer: The producer of the data is the provider that initially captured and processed the source data, e.g. ESA for Sentinel-2 data.
  processor: A processor is any provider who processed data to a derived product.
  host: The host is the actual provider offering the data on their storage. There should be no more than one host, specified as last element of the list.
```

--------------------------------

### STAC Item Date and Time Range Properties

Source: https://github.com/radiantearth/stac-spec/blob/master/commons/common-metadata.md

Defines properties for specifying a range of capture dates and times for a STAC entity. It clarifies that both `start_datetime` and `end_datetime` are required if one is used, or if the main `datetime` field is null. The fields represent inclusive bounds.

```APIDOC
Property: start_datetime
  Type: string
  Description: The first or start date and time for the resource, in UTC. It is formatted as `date-time` according to [RFC 3339, section 5.6](https://tools.ietf.org/html/rfc3339#section-5.6).
Property: end_datetime
  Type: string
  Description: The last or end date and time for the resource, in UTC. It is formatted as `date-time` according to [RFC 3339, section 5.6](https://tools.ietf.org/html/rfc3339#section-5.6).

Constraints:
  - Using one of the fields REQUIRES inclusion of the other field.
  - Both fields are REQUIRED if the `datetime` field is set to `null`.
  - `start_datetime` and `end_datetime` constitute inclusive bounds.
```

--------------------------------

### STAC Item Properties Object Specification

Source: https://github.com/radiantearth/stac-spec/blob/master/item-spec/item-spec.md

Defines the 'properties' object within a STAC Item, which allows for additional metadata fields. The only required field is 'datetime', but more fields are recommended. The 'datetime' field specifies the searchable date and time of assets in UTC, formatted according to RFC 3339.

```APIDOC
STAC Item Field: properties
  Type: object
  Description: Additional metadata fields for the GeoJSON Object Properties.
  Required Field:
    datetime:
      Type: string | null
      Description: REQUIRED. The searchable date and time of the assets, in UTC, formatted according to RFC 3339, section 5.6. Null allowed if 'start_datetime' and 'end_datetime' from common metadata are set.
```

--------------------------------

### STAC Link Relation Types Overview

Source: https://github.com/radiantearth/stac-spec/blob/master/commons/links.md

Explains the use of `rel` types within the STAC Link Object to precisely describe the nature of a link between a STAC object and the entity it points to. It recommends using official IANA Link Relation Types where applicable.

```APIDOC
Relation Types Overview:
  Purpose: "STAC Entities use a variety of 'rel' types in the Link Object to describe the exact nature of the link between the STAC object and the entity it is linking to."
  Recommendation: "It is recommended to use the official IANA Link Relation Types where possible."
  Hierarchical relations mentioned: ["self", "root", "parent", "child", "collection", "item"]
```

--------------------------------

### STAC Item Licensing Properties

Source: https://github.com/radiantearth/stac-spec/blob/master/commons/common-metadata.md

Describes the `license` field for STAC entities, which specifies the license(s) of the data. It details accepted values (SPDX identifiers/expressions, or 'other') and provides guidance on linking to license texts when SPDX identifiers are not used.

```APIDOC
Property: license
  Type: string
  Description: License(s) of the data as SPDX License identifier, SPDX License expression, or `other`.

Accepted Values for 'license':
  1. [SPDX License identifier](https://spdx.org/licenses/)
  2. [SPDX License expression](https://spdx.github.io/spdx-spec/v2.3/SPDX-license-expressions/)
  3. String with the value `other` if the license is not on the SPDX license list.

Deprecated Values: `various`, `proprietary`

Rules:
  - If the license is NOT an SPDX license identifier, links to the license texts SHOULD be added using the `license` link relation type.
  - If no public license URL is available, it is RECOMMENDED to supplement the STAC Item with the license text in a separate file and link to this file.
  - If no link to a license is included and the `license` field is set to `other`, the data is private.
```

--------------------------------

### STAC Item Provider Properties

Source: https://github.com/radiantearth/stac-spec/blob/master/commons/common-metadata.md

Outlines the `providers` field, which is a list of organizations involved in capturing, producing, processing, hosting, or publishing the data. Providers should be listed chronologically.

```APIDOC
Property: providers
  Type: [[Provider Object](#provider-object)]
  Description: A list of providers, which may include all organizations capturing or processing the data or the hosting provider. Providers should be listed in chronological order with the most recent provider being the last element of the list.
```

--------------------------------

### STAC Catalog Object Fields Definition

Source: https://github.com/radiantearth/stac-spec/blob/master/catalog-spec/catalog-spec.md

Defines the required and optional fields for a STAC Catalog object, including their types and detailed descriptions. These fields are fundamental for structuring and identifying STAC Catalogs and ensuring compliance with the STAC specification. This includes notes on versioning, extension handling, and linking to other STAC objects.

```APIDOC
STACCatalogObject:
  type: string (REQUIRED)
    Description: Set to `Catalog` if this Catalog only implements the Catalog spec.
  stac_version: string (REQUIRED)
    Description: The STAC version the Catalog implements. In general, STAC versions can be mixed, but please keep the recommended best practices in mind.
  stac_extensions: [string]
    Description: A list of extension identifiers the Catalog implements. The list consists of URLs to JSON Schema files that can be used for validation. This list must only contain extensions that extend the Catalog specification itself, see the 'Scope' for each of the extensions. This must NOT declare the extensions that are only implemented in child Collection objects or child Item objects.
  id: string (REQUIRED)
    Description: Identifier for the Catalog.
  title: string
    Description: A short descriptive one-line title for the Catalog.
  description: string (REQUIRED)
    Description: Detailed multi-line description to fully explain the Catalog. CommonMark 0.29 syntax MAY be used for rich text representation.
  links: [[Link Object]] (REQUIRED)
    Description: A list of references to other documents. Each link in the `links` array must be a [Link Object].
```

--------------------------------

### STAC Band Object Definition

Source: https://github.com/radiantearth/stac-spec/blob/master/commons/common-metadata.md

Defines the structure and properties of a Band Object within the STAC specification. It includes a unique 'name' identifier and allows for additional common metadata fields like 'description'.

```APIDOC
Band Object:
  name: string
    description: The name of the band (e.g., "B01", "B8", "band2", "red"), which should be unique across all bands defined in the list of bands. This is typically the name the data provider uses for the band.
  description: string
    description: Description to fully explain the band. CommonMark 0.29 syntax MAY be used for rich text representation.
```

--------------------------------

### STAC Collection Field: license

Source: https://github.com/radiantearth/stac-spec/blob/master/collection-spec/collection-spec.md

License(s) of the data provided by the STAC Collection and its children. License information should ideally be defined at the Collection level. It can be an SPDX License identifier, an SPDX License expression, or 'other'. If 'other', links to license texts should be added using the 'license' link relation type. If no public URL, it's recommended to supplement with a separate license file. If 'other' and no link, the Collection is private.

```APIDOC
license: string (SPDX identifier, SPDX expression, or 'other')
```

--------------------------------

### STAC Collection Field: providers

Source: https://github.com/radiantearth/stac-spec/blob/master/collection-spec/collection-spec.md

A list of organizations involved in capturing, processing, or hosting the data. Providers should be listed chronologically, with the most recent provider as the last element.

```APIDOC
providers: [Provider Object]
```

--------------------------------

### STAC Item Asset Definition Object Fields

Source: https://github.com/radiantearth/stac-spec/blob/master/collection-spec/collection-spec.md

Defines the standard fields for an Item Asset Definition Object within the STAC specification, detailing their type and purpose. These fields describe the datafiles associated with STAC Items and can be extended with custom fields.

```APIDOC
Item Asset Definition Object:
  title:
    type: string
    description: The displayed title for clients and users.
  description:
    type: string
    description: A description of the Asset providing additional details, such as how it was processed or created. CommonMark 0.29 syntax MAY be used for rich text representation.
  type:
    type: string
    description: Media type of the asset.
  roles:
    type: [string]
    description: The semantic roles of the asset, similar to the use of `rel` in links.
```

--------------------------------

### STAC Provider Object Definition

Source: https://github.com/radiantearth/stac-spec/blob/master/commons/common-metadata.md

Defines the structure and fields for a STAC Provider object, including details about organizations involved in data capture, processing, or hosting. It specifies required fields, data types, and the roles a provider can fulfill.

```APIDOC
Provider Object:
  description: Provides information about an organization that captures, processes, or hosts STAC assets.
  fields:
    name:
      type: string
      required: true
      description: The name of the organization or the individual.
    description:
      type: string
      description: Multi-line description to add further provider information such as processing details for processors and producers, hosting details for hosts or basic contact information. CommonMark 0.29 syntax MAY be used for rich text representation.
    roles:
      type: array<string>
      description: Roles of the provider.
      allowed_values:
        - licensor: The organization that is licensing the dataset under the license specified in the Collection's 'license' field.
        - producer: The producer of the data is the provider that initially captured and processed the source data, e.g. ESA for Sentinel-2 data.
        - processor: A processor is any provider who processed data to a derived product.
        - host: The host is the actual provider offering the data on their storage. There should be no more than one host, specified as the last element of the provider list.
    url:
      type: string
      description: Homepage on which the provider describes the dataset and publishes contact information.
```

--------------------------------

### STAC Link Object Definition

Source: https://github.com/radiantearth/stac-spec/blob/master/commons/links.md

Defines the structure of a STAC Link Object, detailing its fields, their types, and purpose for describing relationships with other entities. Data providers are encouraged to use links liberally to describe related items, catalogs, and hierarchical connections.

```APIDOC
Link Object:
  href:
    type: string
    description: "REQUIRED. The actual link in the format of an URL. Relative and absolute links are both allowed. Trailing slashes are significant."
  rel:
    type: string
    description: "REQUIRED. Relationship between the current document and the linked document. See chapter \"Relation types\" for more information."
  type:
    type: string
    description: "Media type of the referenced entity."
  title:
    type: string
    description: "A human readable title to be used in rendered displays of the link."
  method:
    type: string
    description: "The HTTP method that shall be used for the request to the target resource, in uppercase. GET by default."
  headers:
    type: Map<string, string | [string]>
    description: "The HTTP headers to be sent for the request to the target resource. Keys are header names, values are either a single string or an array of strings."
  body:
    type: any
    description: "The HTTP body to be sent to the target resource."
```

--------------------------------

### STAC Collection Summary JSON Schema Object Usage

Source: https://github.com/radiantearth/stac-spec/blob/master/collection-spec/collection-spec.md

Describes the use of a JSON Schema Object for providing fine-grained information about a summarized field in a STAC Collection. Each schema must be valid against all corresponding values for the property in sub-Items, and empty schemas are not allowed. JSON Schema draft-07 is the default version.

```APIDOC
JSONSchemaObject:
  Description: Extensible JSON Schema definition for fine-grained information about a summarized field.
  Constraints:
    - Must be valid against all corresponding values for the property in sub-Items.
    - Empty schemas are not allowed.
  Version:
    - Default: JSON Schema draft-07 (aligns with STAC).
    - Other versions allowed if explicitly expressed in '$schema' keyword, but tooling support may vary.
  Reference: Learn JSON Schema (https://json-schema.org/learn/)
```

--------------------------------

### Deprecated STAC GeoTiff Media Types

Source: https://github.com/radiantearth/stac-spec/blob/master/best-practices.md

Details the deprecated media types for GeoTiff and Cloud Optimized GeoTiffs, advising replacement with current standards.

```APIDOC
Deprecated GeoTiff Media Types:
  image/vnd.stac.geotiff
  image/vnd.stac.geotiff; profile=cloud-optimized
Note: Both are deprecated and should be replaced in new STAC implementations.
```

--------------------------------

### STAC Common Metadata: Date and Time Fields

Source: https://github.com/radiantearth/stac-spec/blob/master/commons/common-metadata.md

Specifies fields for temporal information within STAC entities, including creation and update timestamps, and a general datetime field. All timestamps must adhere to RFC 3339, section 5.6. The meaning of 'created' and 'updated' fields varies based on their context (metadata vs. actual data).

```APIDOC
Field Name | Type         | Description
---------- | ------------ | -----------------------------------------------------------------------------------------------
datetime   | string|null | See the [Item Specification Fields](../item-spec/item-spec.md#properties) for more information.
created    | string       | Creation date and time of the corresponding STAC entity or Asset (see below), in UTC.
updated    | string       | Date and time the corresponding STAC entity or Asset (see below) was updated last, in UTC.
```

--------------------------------

### STAC Spatial Extent Object Definition

Source: https://github.com/radiantearth/stac-spec/blob/master/collection-spec/collection-spec.md

Describes the spatial extents of a STAC Collection using bounding boxes (bbox). It supports 2D or 3D geometries and multiple bounding boxes for precise data clustering.

```APIDOC
Spatial Extent Object:
  description: The object describes the spatial extents of the Collection.
  properties:
    bbox:
      type: "[[number]]"
      description: "REQUIRED. Potential spatial extents covered by the Collection."
      details:
        - "Each outer array element can be a separate spatial extent describing the bounding boxes of the assets represented by this Collection using either 2D or 3D geometries."
        - "The first bounding box always describes the overall spatial extent of the data. All subsequent bounding boxes can be used to provide a more precise description of the extent and identify clusters of data."
        - "Clients only interested in the overall spatial extent will only need to access the first item in each array."
        - "It is recommended to only use multiple bounding boxes if a union of them would then include a large uncovered area (e.g. the union of Germany and Chile)."
        - "The length of the inner array must be 2*n where n is the number of dimensions."
        - "The array contains all axes of the southwesterly most extent followed by all axes of the northeasterly most extent specified in Longitude/Latitude or Longitude/Latitude/Elevation based on WGS 84 (http://www.opengis.net/def/crs/OGC/1.3/CRS84)."
        - "When using 3D geometries, the elevation of the southwesterly most extent is the minimum depth/height in meters and the elevation of the northeasterly most extent is the maximum."
        - "The coordinate reference system of the values is WGS 84 longitude/latitude."
      examples:
        - "Whole Earth (2D): [[-180.0, -90.0, 180.0, 90.0]]"
        - "Whole Earth with depth/height (3D): [[-180.0, -90.0, -100.0, 180.0, 90.0, 150.0]]"
```

--------------------------------

### STAC Link Relation Type: License

Source: https://github.com/radiantearth/stac-spec/blob/master/commons/common-metadata.md

Defines the `license` link relation type, which is used to specify URLs for license texts, particularly when the `license` field is not an SPDX identifier.

```APIDOC
Link Relation Type: license
  Type: license
  Description: The license URL(s) for the resource SHOULD be specified if the `license` field is NOT a SPDX license identifier.
```

--------------------------------

### STAC Item Specification

Source: https://github.com/radiantearth/stac-spec/blob/master/README.md

Defines a STAC Item as a GeoJSON Feature with additional fields for attributes like time and links to related entities and assets. It is the core entity describing discoverable data.

```APIDOC
STAC Item: A GeoJSON Feature with additional fields ("foreign members") for attributes like time and links to related entities and assets (including thumbnails). This is the core entity that describes the data to be discovered.
```