1. Предисловие

Продолжаем знакомить читателей, молодых и немолодых специалистов в области наук о Земле, с новым перспективным стандартом работы с метаданными космической съемки, данными дистанционного зондирования Земли (ДЗЗ) и другими результатами космической деятельности (РКД).

В предыдущей статье мы рассмотрели предпосылки для рождения нового стандарта и причины его стремительного развития. Привели примеры наиболее успешного внедрения STAC в таких глобальных каталогах космических продуктов и сервисов как Microsoft Planetary Computer, Eurac Research и Copernicus Data Space Ecosystem.

Продолжим погружаться в принципы взаимодействия со STAC и его структурами данных.

В наши дни спутники ежедневно делают сотни терабайтов снимков Земли. Эти данные хранятся в десятках разных архивов по всему миру, и найти среди них нужный кадр — задача не из простых. Часть архивов платные даже на уровне метаданных, часть бесплатные, материалы в них низкого качества, почти каждый архив имеет свою структуру данных и API для машинного взаимодействия. Что если бы все эти архивы «говорили» на одном языке? Именно эту проблему решает STAC — открытый стандарт, который превращает разрозненные коллекции снимков в единый, легко доступный цифровой каталог.

SpatioTemporal Asset Catalog (STAC) — это не конкретная программа, а набор правил (спецификация) для описания геопространственных данных. Его цель — стандартизировать то, как мы структурируем и ищем информацию о любых файлах, связанных с определённым местом и временем: от спутниковых снимков до цифровых моделей рельефа и даже разметки для машинного обучения.

Изначально созданный для работы со спутниковыми сценами, сегодня STAC охватывает огромный спектр данных: аэрофотосъёмку, радиолокационные (SAR) снимки, лидарные облака точек, видео и производные продукты, такие как карты вегетационного индекса (NDVI) и многие другие. Всё это многообразие объединяет простой принцип: каждому набору данных присваивается чёткое описание в формате JSON, которое одинаково понимают как люди, так и компьютеры.

Оглавление

1. Предисловие

2. Зачем нужен STAC?

3. Спецификация STAC (введение)

   1. Из чего состоит STAC: основные элементы и их структура

   2. Описание структуры объектов STAC

4. Расширения STAC: ключ к адаптации стандарта под любые задачи

5. Расширения STAC: пример создания и использования

6. На что следует обращать внимание при работе с расширениями STAC

7. P.S. Требуется помощь! Ищем владельцев доменов cosmomayak.com и cosmomayak.ru

8. Цикл статей про STAC

2. Зачем нужен STAC?

Представьте, что вы хотите найти все спутниковые снимки Санкт-Петербурга за последний год. Без общего стандарта вам пришлось бы по отдельности изучать интерфейсы архивов Роскосмоса, NASA, коммерческих компаний — каждый со своим уникальным форматом запросов и ответов.

STAC решает эту проблему, предлагая общий язык для метаданных.

В результате поставщикам данных (например, операторам спутников) не нужно разрабатывать собственные сложные форматы и API — они могут использовать готовый, хорошо продуманный стандарт. А потребителям данных (учёным, разработчикам, аналитикам) не нужно писать новый код под каждый архив. Они могут использовать единые библиотеки и инструменты для поиска и доступа к информации.

3. Спецификация STAC (введение)

Спецификация STAC определяет связанные JSON-объекты, которые образуют «проходимый» интерфейс в стиле HATEOAS, а также RESTful API для расширенного поиска. Это означает, что каталог можно реализовать даже статически — как набор взаимосвязанных JSON-файлов на сервере, что идеально подходит для простой публикации данных.

{
  "orderId": 123,
  "status": "Pending",
  "customerId": 456
}
// Клиент должен знать, что для отмены заказа нужно использовать: POST /orders/123/cancel

{
  "orderId": 123,
  "status": "Pending",
  "customerId": 456,
  "_links": {
    "self": { "href": "/orders/123" },
    "cancel": { "href": "/orders/123/cancel", "method": "POST" }, // Доступна отмена
    "customer": { "href": "/customers/456" }
  }
}
// Клиент видит ссылку 'cancel' и понимает, что может отменить заказ.

3.1 Из чего состоит STAC: основные элементы и их структура

Каталог STAC строится на трёх основных типах объектов: Каталог (Catalog), Коллекция (Collection) и Элемент (Item). Они образуют логическую иерархию и описываются в формате JSON. Также можно в отдельную сущность выделить Объекты (Assets) - структуры внутри Элементов (Item), в которых, как правило, хранятся ссылки на сами данные (файлы или сервисы), но об этом поговорим чуть позже.

На рисунке 1 представлена иерархия структур STAC.

По сути, STAC — это система организации данных в виде папок и JSON-файлов. Каждый каталог, коллекция или отдельный снимок (Item) описывается своим .json-файлом. Почему JSON? Потому что это де-факто текущий стандарт для веба. Он понятен и человеку (можно открыть в любом редакторе и комфортно читать глазами), и машине (обрабатывается любой современной библиотекой), и идеально ложится на REST API — то есть ваши данные сразу готовы к работе через HTTP-запросы.

Каждый JSON заполняется полями, как форма. Есть обязательные базовые поля: например, id, название и описание на всех уровнях. У коллекций появляются более специфичные свойства вроде списка ключевых слов, контактов поставщика и лицензии. Но вся мощь STAC — в расширениях (extensions). Это как модули или плагины, которые добавляют нужные вам поля. Нужно описать параметры съемки со спутника — берете готовое расширение eo. Работаете с радарными данными — есть расширение sar. Это гарантирует, что разные команды говорят на одном языке.

При этом система не загоняет вас в жесткие рамки. Если готовых расширений не хватает, вы можете создать свое, добавив в JSON свои уникальные поля. Главное — сохранить общую логику и обязательный минимум, чтобы ваш каталог оставался совместимым с другими. Это и есть баланс STAC: единый стандарт для совместной работы и полная свобода кастомизации под внутренние задачи, как коридор возможностей с достаточно широкими стенами.

На практике это означает, что вы можете быстро развернуть каталог данных, который будет одновременно и человекочитаемым (просто файлы в файловой системе), и машиночитаемым (готовый API), и при этом гибко описывать что угодно — от архивных снимков до результатов нейросетевой обработки. Наглядно увидеть, какие поля и на каком уровне обычно используются для данных ДЗЗ, можно на рисунке 2.

3.2 Описание структуры объектов STAC

Более подробно разберем структуры объектов STAC.

1. Элемент (Item)

Item — это атомарная единица в STAC, представляющая один пространственно-временной актив (например, отдельную спутниковую сцену). По сути, это объект GeoJSON Feature с дополнительными обязательными полями.

Обязательные поля элемента:

• id — уникальный идентификатор;

• type — всегда "Feature";

• bbox — ограничивающий прямоугольник (bounding box);

• properties — метаданные, включая ключевое поле datetime;

• assets — ссылки на сами файлы данных (например, GeoTIFF);

• links — ссылки на родительскую коллекцию, корневой каталог и т.д.;

• stac_version — версия спецификации STAC.

Пример JSON элемента (упрощённо):

json

{
    "stac_version": "1.0.0",
    "type": "Feature",
    "id": "20201211_223832_CS2",
    "bbox": [172.911, 1.343, 172.954, 1.369],
    "geometry": {
        "type": "Polygon",
        "coordinates": [...]
    },
    "properties": {
        "datetime": "2020-12-11T22:38:32.125Z"
    },
    "collection": "simple-collection",
    "links": [{
            "rel": "collection",
            "href": "./collection.json",
            "type": "application/json"
        }
    ],
    "assets": {
        "visual": {
            "href": "https://example.com/image.tif",
            "type": "image/tiff; application=geotiff",
            "roles": ["visual"]
        }
    }
}

2. Коллекция (Collection)

Collection описывает группу элементов (Items), объединённых общими характеристиками: например, данные с одного спутника (Landsat 8) или одного типа съёмки (радар SAR). Коллекция также является валидным каталогом (Catalog).

Обязательные поля коллекции (помимо полей каталога):

• license — лицензия на данные;

• extent — пространственные и временные границы всех элементов коллекции.

Содержит spatial.bbox и temporal.interval.

Пример JSON коллекции (фрагмент):

json

{
    "stac_version": "1.0.0",
    "type": "Collection",
    "id": "sentinel-2-l2a",
    "description": "Sentinel-2 Level-2A поверхностные отражения",
    "license": "CC-BY-4.0",
    "extent": {
        "spatial": {
            "bbox": [[-180, -90, 180, 90]]
        },
        "temporal": {
            "interval": [["2015-06-01T00:00:00Z", null]]
        }
    },
    "links": [...],
    "summaries": {
        "eo:bands": [...],
        "platform": ["sentinel-2a", "sentinel-2b"]
    }
}

3. Каталог (Catalog)

Catalog — это объект верхнего уровня, который логически группирует коллекции и элементы. Его основная задача — предоставлять ссылки (links) на дочерние коллекции и каталоги, формируя навигационную структуру.

Обязательные поля каталога:

• id — идентификатор;

• type — всегда "Catalog";

• description — описание;

• links — массив ссылок на дочерние ресурсы.

Пример структуры корневого каталога:

json

{
    "stac_version": "1.1.0",
    "type": "Catalog",
    "id": "root-catalog",
    "description": "Корневой каталог спутниковых данных",
    "links": [{
            "rel": "child",
            "href": "./collections/sentinel-2/collection.json",
            "type": "application/json",
            "title": "Данные Sentinel-2"
        }, {
            "rel": "child",
            "href": "./collections/landsat/collection.json",
            "type": "application/json",
            "title": "Данные Landsat"
        }, {
            "rel": "self",
            "href": "./catalog.json",
            "type": "application/json"
        }
    ]
}

4. Расширения STAC: ключ к адаптации стандарта под любые задачи

Базовое минимальное ядро STAC не может покрыть все возможные метаданные для разных типов данных. Но в спецификацию уже заложено универсальное решение — расширения (extensions).

Расширение — это JSON-схема, которая добавляет новые поля в объекты STAC (Item, Collection, Catalog). Чтобы использовать расширение, его идентификатор (URL схемы) добавляется в массив stac_extensions объекта, а сами данные помещаются в свойства объекта.

Как создаются собственные (пользовательские) расширения

1. Сообщество (или частный пользователь/разработчик) определяет потребность в новой группе метаданных (например, параметры съёмки для электроптических данных).

2. Разрабатывается JSON-схема, описывающая новые поля.

3. Схема публикуется, обычно в организации stac-extensions на GitHub.

4. Расширение проходит стадии (stages) зрелости: Proposal, Pilot, Candidate, Stable.

Расширение можно также опубликовать и на локальном сервере, если промышленная или публичная эксплуатация каталога это допускает. В этом случает п. 4 не выполняется.

Примеры популярных расширений

• eo (Electro-Optical) — описывает спектральные каналы, их ширину, облачность, солнечную геометрию. Имеет статус Stable;

• sar (Synthetic Aperture Radar) — добавляет параметры поляризации, частоты и режима работы радара.

• view (View Geometry) — содержит метаданные о геометрии съёмки (зенитный и азимутальный углы);

• projection — детали проекции растровых данных;

• label (Machine Learning Labels) — позволяет прикреплять к снимкам разметку для обучения нейросетей (маски объектов, классификацию пикселей).

Без расширения eo — Item описывает «просто снимок». С расширением eo он становится научным продуктом, где для каждого канала (bands) указана его центральная длина волны (center_wavelength), что позволяет автоматически строить точные индексы, например, NDVI.

Этот подход превращает STAC из жёсткого стандарта в живую, эволюционирующую экосистему. Новый тип датчика или научная методика? Сообщество просто разрабатывает для них новое расширение, не ломая существующие каталоги. Такой подход позволяет STAC оставаться простым в основе, но бесконечно адаптивным для специфических нужд различных миссий, инструментов и научных дисциплин.

5. Расширения STAC: пример создания и использования

В STAC ссылка на любое расширение (как официальное, так и ваше собственное) указывается в корневом поле stac_extensions. Это массив строк, где каждый элемент — это URL, ведущий на JSON-схему (JSON Schema) этого расширения.

Допустим, вы создали расширение custom_processing для хранения служебной информации о том, каким алгоритмом и когда был обработан снимок.

Условно, представим ваше расширение в виде следующего JSON-файла my_proc.json:

{
  "$schema": "https://json-schema.org/draft/2020-12/schema",
  "$id": "https://my-company.com/stac-extensions/custom_processing/v1.0.0/my_proc.json",
  "title": "Custom Processing Extension",
  "description": "Добавляет метаданные об алгоритмической обработке данных (например, классификация, фильтрация).",
  "type": "object",
  "allOf": [
    {
      "$ref": "https://schemas.stacspec.org/v1.0.0/item-spec/json-schema/item.json"
    }
  ],
  "properties": {
    "custom_processing:algorithm_version": {
      "type": "string",
      "pattern": "^\\d+\\.\\d+\\.\\d+$",
      "description": "Версия алгоритма обработки в формате семантического версионирования (например, 2.1.4)."
    },
    "custom_processing:processed_at": {
      "type": "string",
      "format": "date-time",
      "description": "Дата и время завершения обработки в формате ISO 8601."
    },
    "custom_processing:parameters": {
      "type": "object",
      "additionalProperties": true,
      "description": "Произвольный объект с параметрами, использованными при обработке (например, настройки фильтра)."
    }
  },
  "required": ["custom_processing:algorithm_version", "custom_processing:processed_at"]
}

Где:

• $id: Уникальный идентификатор схемы. Именно этот URL указывается в поле stac_extensions STAC-объекта.

• title и description: Человекочитаемые название и описание расширения.

• allOf: Ссылка на базовую схему STAC Item. Это значит, что наше расширение добавляет свойства к существующей структуре Item.

• properties: Определение новых полей. Обратите внимание, что имена полей уже содержат префикс custom_processing:.

• required: Список обязательных полей для этого расширения. В нашем случае algorithm_version и processed_at обязательны, а parameters — опционален.

Тогда ваш JSON-файл my_item.json будет выглядеть примерно так:

{
  // 1. СТАНДАРТНЫЕ ПОЛЯ STAC
  "type": "Feature",
  "stac_version": "1.0.0",
  "id": "image_2023_processed",
  "bbox": [ ... ],
  "geometry": { ... },
  "properties": {
    "datetime": "2023-10-26T10:20:00Z"
    // ... другие стандартные свойства
  },
  "assets": { ... },
  "links": [ ... ],

  // 2. **ВАЖНО: ПОДКЛЮЧЕНИЕ РАСШИРЕНИЙ**
  // Здесь объявляется, какие расширения использует этот объект.
  "stac_extensions": [
    "https://schemas.stacspec.org/v1.0.0/item-spec/json-schema/item.json", // (опционально, базовая схема)
    "https://schemas.stacspec.org/v1.0.0/extensions/eo/json-schema.json", // Официальное расширение, например, для оптики (eo)
    "https://my-company.com/stac-extensions/custom_processing/v1.0.0/my_proc.json" // Ваше пользовательское расширение
  ],

  // 3. **ИСПОЛЬЗОВАНИЕ ПОЛЕЙ ИЗ РАСШИРЕНИЙ**
  // После объявления в `stac_extensions` вы можете использовать поля, определенные в этих схемах.
  // Поля из официального расширения "eo" (для электромагнитных данных):
  "eo:cloud_cover": 5.2,

  // Поля из вашего пользовательского расширения "custom_processing":
  "custom_processing:algorithm_version": "2.1.4",
  "custom_processing:processed_at": "2023-10-27T14:00:00Z",
  "custom_processing:parameters": {
    "filter_type": "median",
    "kernel_size": 3
  }
}

6. На что следует обращать внимание при работе с расширениями STAC

Расширения указываются в корневом поле stac_extensions. Это правило едино для всех типов объектов STAC (Item, Collection, Catalog).

Указываются URL на JSON-схему (schema.json). Для официальных расширений STAC использует фиксированные URL на schemas.stacspec.org. Для своего расширения вы должны разместить схему на доступном в вашей сети URL (например, на сайте компании, в S3-бакете или в корне каталога данных).

После объявления расширения, вы можете добавлять в объект новые поля с соответствующим префиксом пространства имен. В примере выше префикс custom_processing: как раз и говорит о том, что поле принадлежит вашему расширению. Это предотвращает конфликты имен.

Файл schema.json по указанному URL — это и есть формальное определение вашего расширения. В нем описываются: какие поля (algorithm_version, processed_at) обязательны или опциональны, их тип (строка, число, объект) и описание. Без публичной схемы расширение не будет по-настоящему интероперабельным.

Если вы тестируете локально, в поле stac_extensions можно указать не URL, а относительный путь к файлу схемы, например: ["./custom_processing/schema.json"]. Но для публикации данных лучше использовать полный URL.

Чтобы не перегружать статью (а тем для обсуждения в экосистеме STAC еще очень много), прервемся пока на общем описании расширений STAC, и в следующей части я постараюсь более подробно остановиться на описании пользовательских расширений для машиночитаемого описания процессов обработки ДЗЗ и комплексных процессов производства и предоставления продуктов потребителям, которые мы реализовывали в двух новых геоинформационных системах.

А также затронем тему, почему Python стал де-факто основным языком разработки сервисов и систем обработки данных дистанционного зондирования Земли (ДЗЗ) и сознания на основе их комплексного использования информационно-аналитических продуктов (ИАП).
Кстати, основные библиотеки и для работы со STAC и построения на его основе современных геоинформационных систем также написаны на Python.

P.S.

Уважаемые читатели!

Мы ищем текущих владельцев русского и английского сайтов проекта Маяк, для реанимации и поддержки ресурсов. Нужна ваша помощь!

Цикл статей про STAC

1. Часть 1 STAC — знакомство: Новая эпоха в работе с данными о Земле

2. Часть 2. STAC — знакомство: Универсальный язык для геоинформационных систем и не только