Обновить

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

Время на прочтение13 мин
Охват и читатели9.9K
Всего голосов 3: ↑3 и ↓0+4
Комментарии11

Комментарии 11

Мм, ещё один стандарт...

А как в нём CRS указывается? (не заметил при беглом просмотре)

STAC - Новая эпоха ... ==> это очень молодая спецификация, открытый, постоянно обновляемый и развивающийся стандарт. И при этом уже вставший на вооружение у ведущих хранителей космических снимков  Microsoft Planetary ComputerEurac Research и Copernicus Data Space Ecosystem.

Тот же Р 1323565.1.058-2024 ... ==> в действующем ГОСТ Р 70672— 2023 о требованиях к сервису обработки и анализа данных дистанционного зондирования Земли из космоса напрямую указано требование использовать в таких сервисах STAC. В периметре Роскосмоса STAC уже используется, не в массе, но в нескольких публичных ГИС.

Почему не RDF\ OWL и не JSON-LD? ==> тут я могу выразить собственное мнение:

STAC сознательно построен на обычном JSON, а не на RDF/OWL или даже JSON‑LD — это решение продиктовано, как мне кажется, ключевыми целями проекта: практичностью, простотой внедрения и максимальной совместимостью с существующими геоинформационными инструментами и веб‑API. STAC пошёл по пути прагматичной простоты, выбрав JSON как формат, который максимально соответствует его цели – быстрому каталогированию и поиску геопространственных активов.

RDF/OWL/JSON‑LD, безусловно, мощнее в плане семантической интеграции, но их сложность и меньшая распространённость в гео‑инструментарии перевешивают потенциальные выгоды для основной задачи STAC.

При этом STAC не запрещает использование семантических технологий на верхнем уровне: вы можете преобразовывать STAC‑JSON в RDF с помощью сторонних инструментов (например, stacIndexer) или добавлять JSON‑LD‑разметку для улучшения SEO. Однако ядро спецификации скорее всего остаётся в рамках обычного JSON – это компромисс, который обеспечивает широкое внедрение и удобство работы для большинства пользователей.

Пространственные данные и Linked Open Data? ==> Семантическая паутина - это вообще отдельная и интереснейшая тема)) Она была частью моего диссертационного исследования, при разработке новых моделей метаданных. Однако, это вообще отдельный мир! К сожалению, мне не известен ни один по настоящему успешный проект, в котором бы хотя бы на 90% была реализована концепция Тима Бернерсона-Ли... разве что на очень малом объеме тестовых данных... В 2006 г. сам Тим Бернерс-Ли подтверждал в своей статье «Semantic Web Revisited» («Семантическая паутина: пересмотр») нереализуемость концепта, по крайней мере в настоящее время. Основные проблемы - с бесконечным количеством создаваемых классов по мере увеличения объема описываемых данных, и человеческий фактор, чтобы все это поддерживать.

Однако, это вообще отдельный мир! К сожалению, мне не известен ни один по настоящему успешный проект, в котором бы хотя бы на 90% была реализована концепция Тима Бернерсона-Ли... разве что на очень малом объеме тестовых данных... 

Хотя бы на малом объеме - это какие?
В целом, конечно с миром LD печальная картинка, например, в соседней статье (медицина) тоже свой не семантический велосипед изобретают.

>> Хотя бы на малом объеме - это какие?
За последние 20 лет было произведено несколько вполне рабочих решений в части применения семантической паутины и онтологических моделей, часть из них в виде проектов и концепций.

  1. Семантическая электронная библиотека LibMeta - был разработан вполне рабочий прототип в 2014 г., а двумя годами позднее опубликована Информационная модель семантической библиотеки.

  2. Платформа Semantic MDM (2014), проект ИЦ «Сколково». Позволяет унифицировать терминологию предметной области и создавать каталоги промышленной продукции с семантическими связями между объектами. Используется, в частности, для развёртывания электронного каталога отечественного металлообрабатывающего оборудования. Коммерческий продукт, прошедший экспертизу Сколково, работает в реальных заказных проектах (каталог «Станкоинструмент»). Является примером успешного внедрения семантических технологий в промышленный каталог.

  3. Есть молодой проект 2025 г. Система организации знаний для научного информационного пространства России - пока только проект.

  4. Есть концепция Концепция «Единого российского электронного пространства знаний» (ЕРЭПЗ), законодательно закреплена в Федеральном законе «О библиотечном деле» (с 2014 г.). В концепции прямо указана необходимость семантической взаимосвязи информации и использования онтологий для интеграции разнородных ресурсов.

  5. Платформа построения онтологических моделей «ОНТО» - инструментальная платформа для создания и редактирования онтологий. Предназначена для разработчиков, которые хотят строить семантические модели данных в своих системах. Включена в реестр отечественного ПО, что свидетельствует о её готовности к использованию в государственных и корпоративных проектах.

Semantic MDM и LibMeta из перечисленных пожалуй самые работоспособные.

Всю жизнь использовали GeoJSON в своих проектах, со своими расширениями конечно, но тем не менее.

Честно статью просмотрел не до конца... Но это сурово, еще один стандарт представления гео данных... Пока хватает shape и GeoJson. И я совсем не понимаю выгоды использования STAC, есть ли сравнения этих форматов?

Развернутый ответ наверно займет еще одну статью на тему STAC-браузера, который является неотъемлемой частью экосистемы STAC, и почему любой STAC-браузер любого разработчика должен одинаково хорошо читать любой STAC-каталог любого другого разработчика. Эту статью я обязательно выложу)

Сейчас отвечу кратко. STAC это не стандарт представления данных, это скорее спецификация, как экосистема каталогизации метаданных, т.е. данных о данных.

В вашем контексте вы скорее всего имели в виду shape и GeoJson как контейнеры для пространственных данных , географических структур данных. Как я писал ранее, STAC-item, это и есть объект GeoJSON Feature с дополнительными полями, полученными за счет расширений STAC. Другими словами STAC-item наследует GeoJSON Feature или является его производной.

Теперь, если вы будете каталогизировать в STAC пространственные данные, то в STAC-item могут храниться непосредственно сами данные в формате GeoJSON, а в разделе assets может, например, появиться ссылка на эти же данные (геометрию) в формате shape.

Но если вы каталогизируете в STAC космические снимки, но данными является сам космический снимок, размещенный, например, в хранилище S3. STAC-item в этом случае будет содержать метаданные этого снимка, т.е. данные о данных снимка. В assets тогда окажется ссылка на TIFF снимка в S3, ссылка на превью в формате PNG.

А если вы каталогизируете более сложный объект, например абстрактный объект наблюдений, то в STAC-item будет опять же содержать метаданные ваших наблюдений, а в assets может оказаться множество ссылок на данные (снимки), в виде таймсерии, несколько геометрий в разных форматах shape, wkt и пр., и множество других данных, например производных - построенные индексы, облака точек, датасеты и т.д.

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

И отдельной статьи также требует тема "математики на метаданных", которая также становиться крайне популярна последнее время и напрямую связана с концепцией STAC.

Стало яснее! Благодарю вас и ознакомлюсь более внимательно!

Жду тогда новых статей!

Зарегистрируйтесь на Хабре, чтобы оставить комментарий

Публикации