1. Информационный хаос в геопространственной сфере

Задумывались ли вы, как в эпоху, когда мы можем мгновенно найти любую информацию в интернете, поиск спутникового снимка конкретного поля, леса или города за определённую дату до сих пор напоминает квест? Всего несколько лет назад мир геопространственных данных представлял собой хаотичный ландшафт изолированных архивов, каждый со своим уникальным форматом данных, структурой папок, проприетарным API и системой метаданных. Чтобы проанализировать один и тот же регион по данным разных спутников, учёным и инженерам приходилось тратить до 80% времени не на сам анализ, а на "добычу" и приведение данных к единому виду. Эта проблема интероперабельности (совместимости) была главным тормозом для развития целых направлений: от оперативного мониторинга чрезвычайных ситуаций до долгосрочного изучения климата.

Именно из этой "боли" родилась идея SpatioTemporal Asset Catalog (STAC) — Каталога пространственно-временных активов. Изначально это была не инициатива госорганов или крупных корпораций, а практический ответ сообщества разработчиков и аналитиков на ежедневные сложности.

Оглавление

Информационный хаос в геопространственной сфере
"Партизанский" подход к стандартизации
STAC против устоявшихся альтернатив: эволюция вместо революции
Успешное внедрение от научных проектов до глобальных платформ
Как устроена база данных STAC, архитектура и производительность
STAC как основа каталогизации всех результатов космической деятельности (РКД)
Целесообразность STAC для геоинформатики
P.S. Требуется помощь! Ищем владельцев доменов cosmomayak.com и cosmomayak.ru
Цикл статей про STAC

2. "Партизанский" подход к стандартизации

Успех STAC — это история о том, как правильно выстроенный технологический и социальный процесс может привести к революции. STAC следовал так называемому "Партизанскому руководству по созданию стандартов" (Guerilla Standards Playbook).

Что такое "Guerilla Standards Playbook"?

Скрытый текст

«Guerilla Standards Playbook» — это методология разработки открытых технических спецификаций, основанная на гибкости и активном участии сообщества практиков.

Основные концепции

Этот подход противопоставляется «традиционным стандартам» (таким как ISO или IEEE) и характеризуется следующими чертами:

Сначала спецификация, потом стандарт: Группа сначала создает работающее решение (спецификацию), которое доказывает свою полезность на практике, и только потом оно может получить статус официального стандарта.
Bottom-up (Снизу вверх): Разработка ведется разработчиками для разработчиков, исходя из реальных потребностей внедрения, а не по указанию «сверху».
Минимализм: Спецификации создаются максимально простыми («minimal by design»), чтобы их было легко внедрить и поддерживать.
Быстрота и гибкость: В отличие от многолетнего процесса согласования в крупных организациях, «партизанские» стандарты эволюционируют быстро через итерации.

Примеры использования

Термин был популяризирован в контексте геопространственных данных и картографии. Успешными примерами реализации этого «плейбука» являются:

STAC (SpatioTemporal Asset Catalog): Спецификация для поиска и обмена данными дистанционного зондирования Земли.
GeoJSON: Открытый стандарт формата данных для хранения географических структур.
COG (Cloud Optimized GeoTIFF): Формат растровых данных, оптимизированный для облачного использования.

Происхождение термина

Название было предложено Говардом Батлером (Howard Butler) для описания agile-паттернов, которые возникали в процессе создания STAC. Оно подчеркивает «партизанский» характер работы — небольшие, неформальные группы достигают больших результатов за счет креативности и скорости, не обладая ресурсами и бюрократией крупных институтов.

В отличие от традиционных формальных стандартов (как ISO или IEEE), которые разрабатываются сверху вниз, медленно и стремятся к идеальной полноте, "партизанские" спецификации:

создаются сообществом практиков "снизу вверх";
нацелены на немедленную полезность, а не на теоретическую корректность;
итерируются быстро, выпуская рабочие версии, которые сразу можно применять;
обретают авторитет благодаря полезности, а не официальному декрету.

Различия формального и "партизанского" подхода можно изложить в виде сравнительной таблицы:

Атрибут	Формальные стандарты (ISO, OGC)	"Партизанские" спецификации (STAC)
Разработчик	Официальные органы по стандартизации	Сообщество практиков
Процесс	Медленный, тщательный, консенсус "сверху вниз"	Быстрый, итеративный, движимый реализацией
Фокус	Долгосрочная стабильность, корректность	Немедленная полезность, внедрение
Авторитет	Присваивается формальным декретом	Зарабатывается полезностью и поддержкой сообщества

В итоге STAC стартовал в 2017 году не как готовая спецификация, а как серия коротких интенсивных спринтов, где разработчики из разных компаний и институтов вместе решали конкретные задачи. Уже к концу первого спринта у них был рабочий прототип сервера. Такой подход создал беспрецедентную динамику: STAC прошел путь от идеи до широкого промышленного внедрения всего за 3-4 года.

3. STAC против устоявшихся альтернатив: эволюция вместо революции

Чтобы понять взлёт STAC, нужно увидеть его на фоне существовавших решений. А таких популярных решений или стандартов для каталогизации метаданных космической съемки на самом деле не так и много. Популярные, это значит, что ими пользуется как минимум две и более системы. Рассмотрим основные два из них.

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

ISO 19115 и его российский аналог ГОСТ Р 52657.2-2019 — это всеобъемлющие стандарты пространственных данных и метаданных. Они описывают геоданные с исчерпывающей детализацией, что критически важно для долгосрочного архивирования и юридического соответствия. Однако их сложность, ориентация на XML и необходимость создания национальных или отраслевых профилей (упрощённых подмножеств) делают их тяжёлыми для быстрой разработки, машинной обработки и создания гибких API.

STAC не отменяет и не заменяет эти стандарты. Он занимает другую, недостающую нишу. Если ISO 19115 — это "конституция" геоданных, то STAC — это "разговорный язык" для ежедневного общения машин и разработчиков в веб-среде.

Почему STAC выигрывает в современных реалиях:

Веб-нативный дизайн: STAC использует JSON (основной язык данных для веба) и GeoJSON (стандарт для геометрий в вебе). Это родной язык для современных программистов и cloud-сервисов.
Принцип минимального ядра: STAC определяет лишь небольшой обязательный набор полей (id, geometry, datetime, assets). Всё остальное добавляется через расширения (например, eo для оптических данных, sar для радара), что обеспечивает гибкость без усложнения ядра.
Двойная реализация: STAC может работать как набор статических JSON-файлов на веб-сервере (просто и дёшево для публикации) или через динамический STAC API для сложных запросов (быстро и мощно для больших каталогов).
Облачная оптимизация: STAC создавался в эпоху облаков. Он идеально сочетается с Cloud Optimized GeoTIFF (COG) и другими облачными форматами, позволяя обрабатывать терабайты данных, не скачивая их целиком.

Вместо того чтобы пытаться "упаковать" сложность ISO 19115 в JSON, STAC предложил новую, более простую и прагматичную модель, которая решила 80% повседневных задач за 20% усилий. Это и стало ключом к его массовому принятию.

4. Успешное внедрение от научных проектов до глобальных платформ

STAC — не теоретическая конструкция. Его триумф подтверждён внедрением в ведущих мировых проектах.

Microsoft Planetary Computer — это глобальная платформа для анализа данных об окружающей среде. В её основе лежит GeoCatalog — управляемый облачный ресурс в Azure, полностью построенный на спецификации STAC.

Microsoft использует STAC для организации и предоставления доступа к петабайтам данных: от спутниковых архивов Landsat и Sentinel до климатических моделей и данных о биоразнообразии.

Это демонстрация промышленной зрелости STAC. Платформа показывает, как единый каталог может стать основой для масштабируемых, cloud-нативных аналитических рабочих процессов, доступных исследователям по всему миру.

STAC в новой структуре Microsoft Planetary Computer Pro — STAC в новой структуре **Microsoft Planetary Computer** **Pro**

Eurac Research и инициатива OGC Testbed-20. Этот европейский исследовательский центр участвовал в тестовых инициативах OGC, где отрабатывались передовые концепции. В Testbed-20 они использовали STAC для решения задачи прослеживаемости происхождения данных (data provenance).

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

Этот пример показывает, как гибкость STAC через расширения позволяет решать сложные научные и инженерные задачи, такие как обеспечение воспроизводимости исследований и доверия к данным.

STAC в структуре Eurac Research — STAC в структуре **Eurac Research**

Copernicus Data Space Ecosystem (CDSE) — новая инфраструктура Европейского Союза для доступа к данным программы Copernicus. Её ядром стал STAC API, заменивший старые, менее гибкие интерфейсы.

Пользователи могут выполнять сложные запросы (по времени, географии, облачности и т.д.) и получать результаты за секунды. Использование расширения Fields позволяет "запрашивать" только нужные поля метаданных, что ускоряет ответ API в разы.

Это пример успешной миграции огромного государственного архива на современный стандарт, что кардинально улучшило пользовательский опыт для сотен тысяч ученых, компаний и госорганов.

5. Как устроена база данных STAC, архитектура и производительность

Сердце эффективности STAC — его гибкая архитектура, которая может адаптироваться под разные масштабы и задачи.

Две фундаментальные модели реализации

Статический каталог (Static Catalog)

Принцип: Весь каталог — это просто папка на веб-сервере (например, Amazon S3, Azure Blob Storage), наполненная взаимосвязанными JSON-файлами (корневой catalog.json, collection.json, файлы для каждого item).

Преимущества: Чрезвычайно прост в публикации, масштабируется горизонтально, дёшев в обслуживании, кэшируется любым CDN.

Недостатки: Поиск возможен только через навигацию по ссылкам, нет сложных запросов (например, "найти все снимки с облачностью <10% за лето").

Использование: Идеален для публикации фиксированных архивов, дата-сетов, как способ быстрого старта.

Динамический каталог / STAC API

Принцип: Серверное приложение (API), которое выполняет запросы к базе данных, где проиндексированы все метаданные STAC;

Преимущества: Мгновенный полнотекстовый и атрибутивный поиск по всем полям, пространственные запросы, пагинация результатов;

Недостатки: Требует серверной инфраструктуры и администрирования;

Использование: Все крупные облачные платформы (Planetary Computer, CDSE) используют эту модель.

Подходы к архитектуре базы данных STAC

Для реализации STAC API не существует единой "официальной" базы данных. Сообщество использует проверенные инструменты, наиболее подходящие для работы с пространственными данными и быстрым поиском:

Технология	Преимущества для STAC	Типичное использование
PostgreSQL + PostGIS	Надёжная реляционная СУБД с лучшей в отрасли поддержкой пространственных операций. Идеальна для сложных геозапросов и транзакционной целостности.	Основная база для хранения и индексации миллионов элементов. Используется в бэкенде многих продакшн-развёртываний.
Elasticsearch	Высокоскоростная поисковая и аналитическая система. Превосходна для полнотекстового поиска, агрегаций и работы с неструктурированными данными.	Часто используется как поисковый движок поверх PostgreSQL для ускорения сложных запросов или как основное хранилище для очень динамичных каталогов.
SQLite	Встраиваемая, лёгкая реляционная СУБД. Не требует отдельного сервера.	Идеален для прототипирования, небольших каталогов или edge-устройств.

Комбинированные архитектуры для максимальной скорости

Передовые платформы часто используют гибридный подход, объединяя сильные стороны разных технологий. Например, архитектура может выглядеть так:

Copernicus Data Space Ecosystem (CDSE) использует подобную комбинированную архитектуру. При запросе через Python-библиотеку pystac-client пользователь может задать геометрию, временной диапазон и фильтр по облачности. STAC API, работая с оптимизированной базой данных, выполняет запрос за миллисекунды и возвращает только ссылки на нужные снимки в облачном хранилище. Критически важную роль здесь играет расширение Fields, позволяющее указать в запросе только нужные поля метаданных (например, id, geometry, cloud_cover). Это сокращает объём передаваемых данных в десятки раз и ускоряет ответ.

6. STAC как основа каталогизации всех результатов космической деятельности (РКД)

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

Представьте федеральный каталог, который объединяет:

оптические и радиолокационные снимки ДЗЗ (Ресурс-П, Канопус, будущие аппараты);
научные данные с космических обсерваторий (астрофизика, солнечная физика);
телеметрию с космических аппаратов и МКС;
цифровые модели рельефа Луны, Марса и других планет;
результаты экспериментов в условиях микрогравитации;
техпроцессы производства и обработки продуктов.

Для каждого типа данных можно создать специфичное расширение STAC (например, radio-astronomy, spacecraft-telemetry), которое добавит необходимые профессиональные поля. При этом ядро останется общим, что позволит:

искать разрозненные данные через единый интерфейс ("показать все данные, полученные над Байкалом в 2025 году" — и получить и снимки, и данные атмосферного зондирования);
строить междисциплинарные приложения, например, для оценки влияния космической погоды на качество снимков ДЗЗ;
обеспечивать долгосрочную сохранность и доступность данных, отделяя метаданные (лёгкие JSON) от самих "тяжёлых" данных.

7. Целесообразность STAC для геоинформатики

Для научной среды, стремящейся к технологическому суверенитету и эффективному использованию своей космической группировки, принятие STAC выглядит стратегически оправданным. Внедрение STAC как единого слоя метаданных поверх существующих разрозненных систем (ЕТРИС ДЗЗ, ЕК ББП, Росгидромет и НИЦ "Планета", Цифровая Земля, заболоченные архивы институтов) позволит:

гармонизировать доступ к данным без ломки существующих архивов;
стимулировать инновации в отечественном геосервисном секторе, предоставив бизнесу и науке удобный API;
обеспечить соответствие уже принятому ГОСТ Р 70672-2023, который прямо рекомендует использование STAC;
интегрироваться в глобальную исследовательскую экосистему на равных, так как STAC является официальным стандартом сообщества OGC.

STAC — это не просто очередной формат. Это прагматичная философия работы с данными, рождённая в облачную эпоху. Она превращает информацию из мёртвого архива в живой, взаимосвязанный ресурс, которым легко может воспользоваться следующее поколение исследователей, инженеров и предпринимателей — те, кто будет создавать устойчивое будущее на основе данных РКД.

В следующей части я постараюсь рассмотреть базовые структуры элементов каталога STAC — item, catalog, collection, и озвучить некоторые проблемы, с которыми мы столкнулись при разработке расширений для метаданных радиолокационной съемки и технологических процессов обработки данных уровня L3/L4 (да, как оказалось, техпроцессы обработки ДЗЗ также можно эффективно записывать в STAC и как предоставлять пользователям так и автоматизированным системам обработки данных).

P.S.

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

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

Требуется помощь!

В 2017 году мы с командой убежденных единомышленников запустили с космодрома Байконур первый и до сих пор единственный в России полностью частный космический аппарат формата cubesat - "Маяк", разработанный исключительно на средства, собранные путем нескольких краудфандинговых компаний. Целью проекта была - популяризация космонавтики и космических исследований в России, а также повышение привлекательности научно-технического образования в среде молодежи.

Проект состоялся, Маяк был запущен, и спустя четыре года уже даже сошел с орбиты.

К сожалению, за прошедшие годы судьба развела членов команды Маяка по разным другим проектам, и поддержка двух основных интернет-ресурсов cosmomayak.com и cosmomayak.ru была заброшена...

В 2025 г., после торжественной передачи второго рабочего экземпляра спутника Маяк в Музей космонавтики мы решили вновь объединить усилия и реанимировать наши два сайта для истории. А может быть и для возобновлении работы)

К сожалению, пока не удается найти контакты текущих владельцев доменов (а их кто-то регулярно оплачивает). Предполагаем, это кто-то из старой команды Алекандра Панова, нашего PR-директора. Англоязычный сайт еще работает, а вот русскоязычный закрылся парковочной страницей какого-то интернет-магазина.

Будем признательны любой информации и контактам, чтобы выйти на текущих владельцев доменов, с целью выкупа и реанимации ресурсов и контента. Также очень интересуют действующие архивы русского и английского сайтов Маяка, если таковые у кого-то из старых веб-мастеров остались.

Заранее спасибо, друзья!

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

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