Архітектура GEOINT-платформи: приймання, обробка та надання геопросторової розвідки у масштабі

Геопросторова розвідка — це дисципліна, що відповідає на питання: що відбувається, де і коли? GEOINT-платформа — це програмна інфраструктура, яка дозволяє відповідати на це питання у масштабі: приймає супутникові знімки від кількох сенсорів і вікон повторного відвідування, поєднує їх із відео з БпЛА, даними про висоти та векторними шарами, обробляє необроблені пікселі в придатні для дій продукти і доставляє ці продукти аналітикам за робочими станціями та солдатам із планшетами Android у полі. Інженерна проблема полягає в тому, що кожен крок у цьому ланцюжку працює з різними обсягами даних, обмеженнями затримки та форматними конвенціями, які ніколи не розроблялись для сумісності.

У цій статті описується архітектура виробничої GEOINT-платформи від прийому до споживання. Вона охоплює типи даних, що живлять систему, конвеєр перетворення форматів і тайлінгу, архітектуру зберігання необроблених і оброблених знімків, конвеєр обробки для виявлення змін і розпізнавання об'єктів, рівень обслуговування для аналітиків і пристроїв TAK, модель офлайн-розповсюдження для середовищ з обмеженою пропускною здатністю, інтеграцію робочих станцій аналітиків та засоби контролю класифікації й можливості розкриття, що керують потоком даних між анклавами.

Типи даних GEOINT: що платформа повинна приймати

Повноцінна GEOINT-платформа приймає дані з п'яти категорій джерел, кожна з яких має унікальні форматні конвенції та операційні характеристики.

Супутникові знімки — електрооптичні (EO) та SAR. Електрооптичні знімки є найбільш знайомими: зображення у видимому діапазоні та ближньому інфрачервоному, отримані сенсорами WorldView, Sentinel-2 та Planet SkySat. EO-знімки надають багатий візуальний деталь, необхідний для розпізнавання об'єктів і виявлення змін, але погіршуються при хмарному покриві та обмежені денним придбанням для панхроматичних сенсорів. Знімки синтетичної апертурної радіолокації (SAR) отримуються сенсорами Sentinel-1, ICEYE та Capella Space; вони проникають крізь хмарний покрив і функціонують вдень і вночі, за рахунок складнішої моделі інтерпретації — SAR-знімки представляють радіолокаційне розсіювання, а не візуальний вигляд. Продукти EO та SAR зазвичай постачаються у форматі NITF (National Imagery Transmission Format) або GeoTIFF із пов'язаними метаданими геометрії RPC (Rational Polynomial Coefficient) для ортовипрямлення.

Повнорухоме відео (FMV) з БпЛА. Тактичні БпЛА виробляють безперервні відеопотоки — зазвичай у кодеку H.264 або H.265 — анотовані метаданими MISB (Motion Imagery Standards Board) KLV, що містять положення сенсора, орієнтацію платформи, похилу відстань і поле зору сенсора. Потік KLV дозволяє платформі геолоцирувати кожен кадр відео як чотирикутний відбиток на землі. Кадри з високою цінністю можна витягувати як статичні зображення та подавати до конвеєра знімків для аналізу. Архіви FMV зберігаються окремо від знімків через їхній обсяг; платформа підтримує просторовий і часовий індекс, щоб аналітики могли запитувати відеосегменти, що охоплюють задану зону та часове вікно.

Моделі рельєфу. Цифрові моделі місцевості (DTM) і цифрові моделі рельєфу (DEM) забезпечують третій вимір, якого бракує знімкам. DTED (Digital Terrain Elevation Data) — стандартний формат NATO на рівнях 0 (крок 900 м), 1 (90 м) і 2 (30 м). SRTM (Shuttle Radar Topography Mission) забезпечує майже глобальне покриття 30 м. Похідні з вищою роздільною здатністю отримуються зі стереопарних EO-знімків або SAR-інтерферометрії. Дані висот необхідні для ортовипрямлення знімків, 3D-аналізу видимості, маскування місцевості для планування сенсорів та геолокації спостережень сенсорів із БпЛА та літаків.

Векторні шари. Бази даних іменованих об'єктів, адміністративні межі, дорожні мережі, гідрографія та дані об'єктів розповсюджуються як векторні набори даних у форматах Esri File Geodatabase, GeoPackage, Shapefile та GeoJSON. Класифіковані векторні шари, наприклад бази даних цілей і шари бойового порядку, управляються в межах архітектури класифікації і ніколи не змішуються з некласифікованими шарами на рівні бази даних.

Краудсорсинговий OSINT. Витяги OpenStreetMap, дані місцеположення з соціальних мереж і комерційно агреговані звіти про зміни надають оновлення майже в реальному часі, яких не може відповідати повторне відвідування супутника. Потоки OSINT приймаються як GeoJSON або власні схеми JSON і розглядаються як шари з низьким рівнем достовірності та без класифікації, що інформують рішення щодо завдань — спрямовуючи збір із супутника до зон, де OSINT сигналізує про активність, — а не слугують основними продуктами розвідки.

Конвеєр прийому: приймання NITF, перетворення COG та піраміди тайлів

Необроблені знімки надходять до рівня прийому в різнорідних форматах і проєкціях. Конвеєр прийому нормалізує їх у послідовний формат зберігання до того, як запускається будь-який крок обробки.

Приймання NITF та GeoTIFF. Файли NITF аналізуються за допомогою драйвера NITF бібліотеки GDAL, який витягує смуги зображення, коефіцієнти RPC та поля заголовка безпеки. Поля безпеки заповнюють атрибути класифікації та можливості розкриття запису метаданих каталогу. Для багатосегментних контейнерів NITF (великі зображення, розбиті на кілька сегментів), GDAL прозоро обробляє повторне збирання. Приймання GeoTIFF простіше: GDAL читає вбудовані метадані GeoTransform або RPC і дані зображення безпосередньо.

Ортовипрямлення. Перед будь-якою просторовою операцією необроблені знімки повинні бути ортовипрямлені — скориговані за геометрією сенсора та зміщенням рельєфу — щоб отримати послідовний проєктований на землю продукт. Функція GDAL gdalwarp із корекцією RPC та вхідними даними DEM виконує цей крок. На виході — проєктований GeoTIFF у WGS84 або локальній зоні UTM із залишковою похибкою, що зазвичай менше одного пікселя на вихідній роздільній здатності.

Перетворення у Cloud-Optimised GeoTIFF. Кожне ортовипрямлене зображення негайно перетворюється у формат COG за допомогою gdal_translate із драйвером -of COG. COG організовує дані зображення як взаємозаплетені плитки з вбудованими рівнями огляду (піраміди) зі зменшеними роздільними здатностями, кратними двійковому степеню. Отриманий файл підтримує ефективний доступ через HTTP-запити діапазону: тайловий сервер або клієнт із прямим доступом можуть отримати будь-яку просторову підмножину на будь-якому рівні масштабу, не читаючи весь файл. Перетворення COG, як правило, подвоює обсяг зберігання порівняно з вихідним зображенням через рівні піраміди; це прийнятний компроміс за усунення окремої інфраструктури генерації тайлів.

Генерація піраміди тайлів. Для шарів, що потребують швидшого кешованого обслуговування тайлів, ніж можуть забезпечити HTTP-запити діапазону COG — базові карти з високим трафіком, часто запитувані результати виявлення змін — явний крок тайлінгу генерує піраміду тайлів за допомогою MapTiler або gdal2tiles.py від GDAL. На виході — структура каталогів XYZ або один контейнер MBTiles, записаний в об'єктне сховище та проіндексований у каталозі кешу тайлів. Вибір між обслуговуванням COG на вимогу та заздалегідь згенерованими пірамідами тайлів визначається частотою запитів: новий прохід супутника, прийнятий для негайного доступу аналітика, обслуговується як COG; базова карта, що використовується тисячами одночасних пристроїв TAK, попередньо тайлується.

Архітектура зберігання: об'єктне сховище, PostGIS та контейнери тайлів

GEOINT-платформа управляє трьома окремими рівнями зберігання, кожен із яких оптимізований для різного шаблону доступу.

Об'єктне сховище для необроблених і оброблених знімків. Всі растрові дані — необроблені прийоми, ортовипрямлені COG, похідні продукти — зберігаються в об'єктному сховищі: MinIO для ізольованих локальних розгортань, S3-сумісні сховища для хмарно-підключених середовищ. Об'єктне сховище забезпечує практично необмежену горизонтальну ємність, адресацію вмісту за URI та нативну підтримку HTTP-запитів діапазону, на яких базується COG. Політики життєвого циклу архівують холодні знімки (до яких не зверталися протягом 90 днів) на рівні з нижчою вартістю; гарячі знімки (у поточному операційному вікні) зберігаються у високопродуктивному сховищі на SSD.

PostGIS для векторних об'єктів і метаданих знімків. Каталог знімків, векторні шари, анотації аналітиків і результати виявлення змін — усе це зберігається в PostGIS. Таблиця каталогу знімків зберігає один рядок на сцену зі стовпцями для часу отримання, сенсора, рівня класифікації, хмарного покриву та стовпця geometry(POLYGON, 4326) для відбитка сцени. Просторовий індекс GiST на цьому стовпці робить запити на перетин обмежувальних прямокутників — «знайти всі сцени, що охоплюють цю зону» — субмілісекундними навіть за мільйонів записів у каталозі. Таблиці векторних шарів слідують тому ж шаблону: кожен об'єкт має стовпець геометрії та набір стовпців атрибутів; просторова індексація забезпечує швидкі запити на рівні тайлів карти. Щодо повних компромісів у індексуванні, дивіться Геопросторова індексація для оборони.

MBTiles та PMTiles для офлайн-розповсюдження. Контейнери тайлів, упаковані для офлайн-використання, зберігаються поряд із обробленими знімками в об'єктному сховищі, але також копіюються у виділене сховище офлайн-розповсюдження — мережеву папку або фізично ізольований диск — звідки пристрої TAK і ноутбуки аналітиків завантажують пакети. Файли MBTiles — це бази даних SQLite: проста схема з таблицею tiles з ключами за масштабом, стовпцем і рядком робить їх тривіально переносними та читабельними будь-яким пристроєм із підтримкою SQLite. PMTiles, нова альтернатива, зберігає тайли у плоскому двійковому файлі з індексом на основі заголовка, що дозволяє прямий доступ через HTTP-запити діапазону зі статичного веб-сервера без процесу проксі тайлів.

Конвеєр обробки: виявлення змін, розпізнавання об'єктів, когерентність SAR

Конвеєр обробки перетворює необроблені знімки в готові для аналітиків продукти. Три основні режими обробки охоплюють більшість операційних вимог.

Попіксельне виявлення змін. Найпростіший підхід до виявлення змін віднімає базове зображення від нового зображення тієї ж ділянки, застосовує поріг до абсолютної різниці та виробляє двійкову маску змін. Це обчислювально недороге — пара пікселів 10 000 × 10 000 завершується за секунди на одному ядрі CPU — і не потребує навчальних даних. Його режими збоїв добре вивчені: сезонна зміна рослинності, відмінності в куті освітлення та дрейф калібрування сенсора — усе це генерує хибнопозитивні результати. Для тактичних застосувань, де швидкість важливіша за частоту хибнопозитивних, попіксельне порівняння є правильним стандартом.

Виявлення змін на основі ML. Згорткова нейронна мережа, навчена на розмічених парах зображень до/після, виробляє карту ймовірності змін, а не двійкову маску. Навчені моделі узагальнюються за умовами освітлення та сезонними варіаціями, оскільки вони навчаються ознак на рівні сцени, а не на рівні пікселів. Компроміс — це вартість виведення — прискорене GPU виведення для великої сцени займає десятки секунд — і вимога розмічених навчальних даних, що представляють операційне середовище. У виробництві попіксельне порівняння виступає швидким початковим фільтром: лише регіони, позначені попіксельним порівнянням, підлягають виведенню ML, знижуючи навантаження на GPU на порядок для сцен із рідкісними змінами.

Виявлення об'єктів на знімках. Моделі виявлення об'єктів — зазвичай архітектури класу YOLO, налаштовані на аерофотознімки — ідентифікують транспортні засоби, літаки, судна, об'єкти та будівельну діяльність на EO-знімках. Модель виводить обмежувальні прямокутники з мітками класів і оцінками впевненості; обмежувальні прямокутники геолоцируються з використанням метаданих ортовипрямлення сцени та записуються в PostGIS як точкові або полігональні об'єкти з прикріпленими метаданими виявлення. Виявлені об'єкти входять у ширший конвеєр злиття як спостереження, отримані з GEOINT: виявлений у продукті знімка конвой військових транспортних засобів може бути співвіднесений із радіолокаційним треком або пеленгом SIGINT у шарі злиття кількох сенсорів.

Аналіз когерентності SAR. Когерентність обчислюється з двох спільно зареєстрованих SAR-знімків Single Look Complex (SLC), отриманих над однією ділянкою в різний час. Попіксельне значення когерентності — нормована взаємна кореляція комплексних значень пікселів — варіюється від 0 (повна декореляція, що вказує на зміну поверхні) до 1 (ідеальна когерентність, що вказує на відсутність змін). Карти втрати когерентності, отримані з пар знімків Sentinel-1 або ICEYE, виділяють порушення ґрунту з чутливістю, що перевищує попіксельне порівняння на рослинних або малоконтрастних ділянках. Обробка потребує доступу до даних рівня SLC (а не продуктів інтенсивності з виявленням наземних об'єктів, що зазвичай розповсюджуються загальним користувачам) і спеціалізованого програмного забезпечення для інтерферометричної обробки SAR — SNAP, ISCE або власних реалізацій CUDA для потреб реального часу.

Рівень обслуговування: кінцеві точки OGC, векторні тайли та інтеграція TAK

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

Кінцеві точки OGC WMS та WMTS. Стандарт OGC Web Map Service визначає протокол для запиту картографічних зображень із сервера за заданим обмежувальним прямокутником, системою координат, розміром зображення та іменем шару. WMS — це універсальний стандарт сумісності: кожен інструмент ГІС — QGIS, ArcGIS, Global Mapper, ATAK — може споживати кінцеву точку WMS. Його слабкість — затримка: кожен запит ініціює рендеринг на стороні сервера. WMTS усуває це за допомогою попередньо відрендерених кешів тайлів на фіксованих рівнях масштабу; кінцева точка WMTS може обслуговувати тисячі одночасних запитів тайлів із кешу без звернення до сервера зображень. MapServer, GeoServer та більш легкий TiTiler (хмарно-нативний тайловий сервер COG) підтримують обидва стандарти.

OGC WFS для векторних об'єктів. WFS надає векторні об'єкти — результати виявлення змін, виявлені об'єкти, анотації аналітиків — як відповіді GeoJSON або GML на просторові та атрибутні фільтрові запити. Клієнти WFS отримують об'єкти для редагування й аналізу, а не для відображення; повернуті геометрії несуть повні корисні навантаження атрибутів. Для читального доступу з високою пропускною здатністю, OGC API Features (наступний стандарт) надає інтерфейс REST/JSON, простіший для кешування та краще пристосований для веб-застосунків.

Векторні тайли Mapbox. MVT є де-факто стандартом для обслуговування векторних тайлів із високою продуктивністю. Векторні дані — дорожні мережі, іменовані об'єкти, шари аналітиків — нарізаються на тайли на кожному рівні масштабу та кодуються як двійковий Protocol Buffer; клієнти виконують рендеринг на стороні клієнта за допомогою WebGL, забезпечуючи плавне масштабування та панорамування без звернень до сервера. GEOINT-платформа генерує архіви MVT з PostGIS за допомогою tippecanoe або функції PostGIS ST_AsMVT, зберігає їх як MBTiles або PMTiles і обслуговує через тайловий сервер, що споживають ATAK-веб-клієнт і браузерні панелі аналітиків.

Інтеграція ATAK та CloudTAK. Пристрої ATAK підключаються до TAK-сервера — еталонна реалізація — TAK Server (Java), з FreeTAKServer як більш легкою альтернативою — який розповсюджує XML-повідомлення CoT (Cursor on Target) із позиціями об'єктів у реальному часі, треками та сповіщеннями. GEOINT-платформа інтегрується як виробник CoT: коли конвеєр обробки виявляє новий об'єкт або значну зміну, він публікує подію CoT на TAK-сервер, який ретранслює її на всі підписані пристрої ATAK. Шари карт — оброблені знімки, шари виявлення змін — розповсюджуються як пакети MBTiles, які TAK-сервер робить доступними для завантаження на пристрій через локальну мережу.

Офлайн-розповсюдження: пакування MBTiles, дельта-синхронізація та фізична передача даних

Польові оператори регулярно працюють у середовищах, де з'єднання з бекендом GEOINT-платформи переривчасте або відсутнє. Офлайн-розповсюдження — не граничний випадок; це основний шлях доставки.

Пакування MBTiles для пристроїв TAK. Робочий процес офлайн-пакунка починається з визначення користувачем — аналітиком або офіцером розвідки — зони інтересу та набору шарів (базова карта, останні знімки, шар виявлення змін, векторні об'єкти) і запиту пакунка. Платформа запитує PostGIS для отримання відповідних тайлів, збирає їх в один SQLite-файл MBTiles за допомогою сценарію тайлінгу та стискає файл для передачі. Розмір пакунка управляється діапазоном рівнів масштабу: зона 10 км × 10 км на рівнях масштабу 0–17 зазвичай виробляє пакунок 200–500 МБ, який вміщується на USB-накопичувач або передається за хвилини через локальну мережу Wi-Fi.

Дельта-синхронізація для середовищ із обмеженою пропускною здатністю. Коли доступні періодичні вікна зв'язку — супутниковий канал, ретрансляційний літак над головою — платформа підтримує дельта-синхронізацію, а не повторну доставку повного пакунка. Сховище тайлів веде журнал змін: кожен запис тайла фіксується з міткою часу та ключем тайла. Коли пристрій переп'єднується, він повідомляє свою останню мітку часу синхронізації; платформа обчислює набір змінених тайлів з того часу та передає лише різницю. Для тактичної зони з помірними темпами змін дельта-синхронізація за 24 години оновлень може передавати десятки мегабайт, на відміну від сотень при повному оновленні пакунка.

Передача через QR-коди. Для екстремального обмеження пропускної здатності — без радіо, без Wi-Fi, фізична ізоляція — невеликі продукти розвідки (один результат виявлення змін, сітка цілі, векторний шар із кількома об'єктами) можуть бути закодовані як QR-коди та передані візуально. Платформа генерує QR-код із корисного навантаження GeoJSON у кодуванні Base64 із стисненням; приймаючий пристрій із плагіном ATAK або власним застосунком сканує код та імпортує об'єкт. Цей підхід обмежений ємністю даних QR-коду — приблизно 3 КБ на код — але охоплює критичну проблему «останнього метра» доставки конкретної сітки цілі або повідомлення про транспортний засіб на пристрій без іншого підключення.

Робоча станція аналітика: інтеграція QGIS, анотація та експорт

Робоча станція аналітика — це основне середовище аналізу. Більшість аналітиків оборонних знімків працюють у QGIS, доповненому спеціалізованими інструментами аналізу для конкретних типів продуктів.

Інтеграція плагіна QGIS. Плагін QGIS для GEOINT-платформи надає прикріплену панель, що аутентифікується через API платформи, запитує каталог знімків за зоною та часовим діапазоном і завантажує вибрані сцени як шари COG WMS безпосередньо на полотно QGIS. Плагін автоматично обробляє оновлення токенів, конвенції іменування шарів і вирівнювання системи координат. Аналітики можуть накладати кілька сцен, перемикати шари виявлення змін і переглядати атрибути виявлених об'єктів, не виходячи зі середовища QGIS. Для власних інтеграцій QGIS дивіться також PostGIS для геопросторових оборонних даних — про шар бази даних, що підтримує каталог.

Робочий процес анотації. Аналітики анотують об'єкти — ідентифікацію цілей, мітки активності, примітки аналізу — безпосередньо на знімках у QGIS за допомогою стандартної панелі оцифровування, а плагін записує анотації до шару анотацій PostGIS через API платформи. Анотації несуть ідентичність аналітика, рівень класифікації та посилання на UUID вихідного знімка, створюючи повний ланцюг походження від необробленого зображення до готового продукту розвідки. Події анотацій публікуються на шину повідомлень, щоб споживачі нижче за потоком — рівень інтеграції TAK, механізм аналізу шаблону діяльності — отримували оновлення майже в реальному часі.

Експорт у NITF, KMZ та GeoJSON. Готові продукти повинні покидати платформу у форматах, яких очікують споживачі розвідки нижче за потоком. Експорт NITF упаковує оброблене зображення з відповідними полями заголовка безпеки, заповненими з метаданих класифікації продукту. Експорт KMZ упаковує векторні об'єкти як накладення Google Earth — стандартний формат доставки для багатьох партнерських організацій. Експорт GeoJSON задовольняє сучасних споживачів веб-застосунків. Усі експорти реєструються як події походження, а запит на експорт фіксує ідентичність запитувача та призначеного одержувача — необхідно для обліку класифікації та вимог журналу аудиту.

Класифікація та можливість розкриття: маркування метаданих, CDS та спільний доступ у коаліції

Засоби контролю класифікації — це не шар, доданий поверх GEOINT-платформи, — вони структурні. Кожен об'єкт даних у системі несе метадані класифікації та можливості розкриття з моменту прийому, і ці метадані керують кожним рішенням щодо доступу, обробки та розповсюдження.

Маркування метаданих. Файли NITF несуть класифікацію у стандартизованих полях заголовка безпеки (FSCLAS, FSCLSY, FSREL, FSDCTP та суміжних полях). При прийомі платформа зчитує ці поля та зберігає їх у базі даних каталогу як структуровані атрибути, а не рядки вільного тексту. Кожен похідний продукт успадковує найвищу класифікацію своїх вихідних вхідних даних, якщо не було застосовано явний робочий процес зниження класифікації. Схема маркування відповідає національним або союзницьким стандартам класифікації (NATO, національні еквіваленти) і застосовується на рівні моделі даних — запис продукту без допустимого значення класифікації не проходить валідацію схеми і не допускається до каталогу.

Інтеграція рішення між доменами. Пристрої CDS — апаратні або програмні засоби захисту, сертифіковані для передачі даних між доменами — розміщуються між анклавами класифікації та застосовують політику на основі вмісту до даних, що переходять із середовищ із вищим рівнем секретності до нижчого. GEOINT-платформа розглядає CDS як зовнішню систему, яку платформа живить через виділений інтерфейс експорту. Продукти з вищим рівнем секретності, призначені для розкриття, повинні пройти через робочий процес експорту CDS, який перевіряє метадані класифікації, застосовує будь-яку необхідну редакцію або деградацію і генерує аудиторський запис на обох сторонах межі домену. Платформа не реалізує логіку CDS внутрішньо — це межа сертифікації постачальника CDS — але вона надає структуровані метадані, яких потребують механізми політики CDS.

Автоматичне зниження класифікації для спільного доступу в коаліції. Коаліційні операції вимагають ділитися продуктами розвідки з партнерськими країнами, які можуть не мати доступу до найвищого рівня класифікації. Автоматичні робочі процеси зниження класифікації працюють у двох вимірах: просторовому та спектральному. Просторове зниження видаляє або пікселізує об'єкти в чутливих районах — конкретні розташування об'єктів, ідентифікатори цілей із високою цінністю — з продукту до того, як він перетинає межі класифікації. Спектральне зниження деградує роздільну здатність знімка до рівня, відповідного застереженню щодо розкриття. Операції зниження параметризуються тегами розкриття продукту та допуском призначеного одержувача; платформа автоматично виконує відповідне перетворення зниження та фіксує параметри перетворення як частину походження продукту. Продукти, розповсюджені в коаліції, позначаються застереженням одержувача та можуть бути розповсюджені лише в межах повноважень розповсюдження цього застереження.

Пов'язане читання

Архітектура GEOINT-платформи знаходиться на перетині геопросторової інженерії даних, обробки розвідки та оборонного проєктування програмного забезпечення. Статті нижче детально охоплюють пов'язані теми.

Геопросторова інженерія даних: PostGIS для геопросторових оборонних даних, Геопросторова індексація для оборони, Аналіз шаблону діяльності для військової розвідки.

Злиття та multi-INT: Архітектура злиття кількох сенсорів, Повний посібник із злиття оборонних даних, Модель злиття даних JDL.

Інженерія конвеєрів даних: Черги повідомлень для оборонних конвеєрів даних, Подія-джерело для аудиторських журналів оборони, Побудова оборонного конвеєра злиття: джерела та схеми.

C2 та COP: Загальна оперативна картина: як вона будується, Повний посібник із систем C2.