1. Предисловие
Продолжаем знакомить читателей, молодых и немолодых специалистов в области наук о Земле, с новым перспективным стандартом работы с метаданными космической съемки, данными дистанционного зондирования Земли (ДЗЗ) и другими результатами космической деятельности (РКД).
В предыдущей статье мы рассмотрели предпосылки для рождения нового стандарта и причины его стремительного развития. Привели примеры наиболее успешного внедрения STAC в таких глобальных каталогах космических продуктов и сервисов как Microsoft Planetary Computer, Eurac Research и Copernicus Data Space Ecosystem.
Продолжим погружаться в принципы взаимодействия со STAC и его структурами данных.
В наши дни спутники ежедневно делают сотни терабайтов снимков Земли. Эти данные хранятся в десятках разных архивов по всему миру, и найти среди них нужный кадр — задача не из простых. Часть архивов платные даже на уровне метаданных, часть бесплатные, материалы в них низкого качества, почти каждый архив имеет свою структуру данных и API для машинного взаимодействия. Что если бы все эти архивы «говорили» на одном языке? Именно эту проблему решает STAC — открытый стандарт, который превращает разрозненные коллекции снимков в единый, легко доступный цифровой каталог.
SpatioTemporal Asset Catalog (STAC) — это не конкретная программа, а набор правил (спецификация) для описания геопространственных данных. Его цель — стандартизировать то, как мы структурируем и ищем информацию о любых файлах, связанных с определённым местом и временем: от спутниковых снимков до цифровых моделей рельефа и даже разметки для машинного обучения.
Изначально созданный для работы со спутниковыми сценами, сегодня STAC охватывает огромный спектр данных: аэрофотосъёмку, радиолокационные (SAR) снимки, лидарные облака точек, видео и производные продукты, такие как карты вегетационного индекса (NDVI) и многие другие. Всё это многообразие объединяет простой принцип: каждому набору данных присваивается чёткое описание в формате JSON, которое одинаково понимают как люди, так и компьютеры.
Оглавление
Расширения STAC: ключ к адаптации стандарта под любые задачи
На что следует обращать внимание при работе с расширениями STAC
P.S. Требуется помощь! Ищем владельцев доменов cosmomayak.com и cosmomayak.ru
2. Зачем нужен STAC?
Представьте, что вы хотите найти все спутниковые снимки Санкт-Петербурга за последний год. Без общего стандарта вам пришлось бы по отдельности изучать интерфейсы архивов Роскосмоса, NASA, коммерческих компаний — каждый со своим уникальным форматом запросов и ответов.
STAC решает эту проблему, предлагая общий язык для метаданных.
В результате поставщикам данных (например, операторам спутников) не нужно разрабатывать собственные сложные форматы и API — они могут использовать готовый, хорошо продуманный стандарт. А потребителям данных (учёным, разработчикам, аналитикам) не нужно писать новый код под каждый архив. Они могут использовать единые библиотеки и инструменты для поиска и доступа к информации.
3. Спецификация STAC (введение)
Спецификация STAC определяет связанные JSON-объекты, которые образуют «проходимый» интерфейс в стиле HATEOAS, а также RESTful API для расширенного поиска. Это означает, что каталог можно реализовать даже статически — как набор взаимосвязанных JSON-файлов на сервере, что идеально подходит для простой публикации данных.
Стиль HATEOAS
Стиль HATEOAS (Hypermedia As The Engine Of Application State) в REST API означает, что сервер возвращает не только данные, но и гиперссылки (действия/переходы) для дальнейшего взаимодействия, позволяя клиенту динамически перемещаться по API, как по веб-странице, без предварительного знания всех эндпоинтов, что делает API самодокументируемым и гибким. Это достигается включением в ответы ссылок типа _links, указывающих на доступные операции и связанные ресурсы, что соответствует третьему уровню зрелости REST.
Основные идеи HATEOAS
Гипермедиа: Ответы сервера содержат не только данные (JSON/XML), но и ссылки на другие ресурсы и возможные действия (URL), подобно ссылкам и кнопкам на веб-странице.
Двигатель состояния приложения: Ссылки определяют, какие действия можно совершить в текущем состоянии, направляя клиента по логике приложения.
Самодокументируемость: Клиенту не нужно знать жестко закодированные URL; он "исследует" API, переходя по ссылкам, предоставленным сервером.
Гибкость: API становится более устойчивым к изменениям, т��к как клиенту не нужно обновлять свои знания об URL при рефакторинге бэкенда.
Примеры
Без HATEOAS:
json
{ "orderId": 123, "status": "Pending", "customerId": 456 } // Клиент должен знать, что для отмены заказа нужно использовать: POST /orders/123/cancel
С HATEOAS:
json
{ "orderId": 123, "status": "Pending", "customerId": 456, "_links": { "self": { "href": "/orders/123" }, "cancel": { "href": "/orders/123/cancel", "method": "POST" }, // Доступна отмена "customer": { "href": "/customers/456" } } } // Клиент видит ссылку 'cancel' и понимает, что может отменить заказ.
Стиль HATEOAS рекомендован для публичных API, где важна легкость интеграции и эволюция без жесткой привязки клиента, и для сложных систем, где состояния и переходы между ними имеют значение (например, в системах управления заказами, рабочими процессами).
HATEOAS - ключевой, но редко полностью реализуемый элемент истинного REST, поднимающий API на максимальный, третий уровень зрелости.
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 объекта, а сами данные помещаются в свойства объекта.
Как создаются собственные (пользовательские) расширения
Сообщество (или частный пользователь/разработчик) определяет потребность в новой группе метаданных (например, параметры съёмки для электроптических данных).
Разрабатывается JSON-схема, описывающая новые поля.
Схема публикуется, обычно в организации stac-extensions на GitHub.
Расширение проходит стадии (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_extensionsSTAC-объекта.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.
Уважаемые читатели!
Мы ищем текущих владельцев русского и английского сайтов проекта Маяк, для реанимации и поддержки ресурсов. Нужна ваша помощь!
Требуется помощь!
В 2017 году мы с командой убежденных единомышленников запустили с космодрома Байконур первый и до сих пор единственный в России полностью частный космический аппарат формата cubesat - "Маяк", разработанный исключительно на средства, собранные путем нескольких краудфандинговых компаний. Целью проекта была - популяризация космонавтики и космических исследований в России, а также повышение привлекательности научно-технического образования в среде молодежи.
Проект состоялся, Маяк был запущен, и спустя четыре года уже даже сошел с орбиты.
К сожалению, за прошедшие годы судьба развела членов команды Маяка по разным другим проектам, и поддержка двух основных интернет-ресурсов cosmomayak.com и cosmomayak.ru была заброшена...
В 2025 г., после торжественной передачи второго рабочего экземпляра спутника Маяк в Музей космонавтики мы решили вновь объединить усилия и реанимировать наши два сайта для истории. А может быть и для возобновлении работы)
К сожалению, пока не удается найти контакты текущих владельцев доменов (а их кто-то регулярно оплачивает). Предполагаем, это кто-то из разработчиков, из старой команды Алекандра Панова, нашего PR-директора. Англоязычный сайт еще частично работает, а вот русскоязычный закрылся парковочной страницей какого-то интернет-магазина.
Будем признательны любой информации и контактам, чтобы выйти на текущих владельцев доменов, с целью выкупа и реанимации ресурсов и контента. Также очень интересуют действующие архивы русского и английского сайтов Маяка, если таковые у кого-то из старых веб-мастеров остались.
Заранее спасибо, друзья!
