От хаоса к переменам: что нам несут GML-подосновы от МГГТ

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

Те из вас, кто был знаком с МГГТ или их подосновами (ГБУ МосГорГеоТрест), в курсе того хаоса, который традиционно связан с форматом выдачи подоснов в DWG. Есть 2 слова, которые хорошо отражают их формат "графическая расчлененка".

Примерно вот в таком виде данные - все блоки, все линии и другие объекты представляют собой набор примитивов

Насколько я слышал глубину вопроса, странный формат выдачи связан не с желанием усложнить жизнь пользователям, а с архитектурой базы данных/представления, где эти данные размещаются. В общем, не будем ворошить проблемные места, а плавно перейдем к теме статьи.

1. О новом формате

Не вдаваясь в подробности, через кого, но мы в TBS познакомились со специалистом из ГБУ "МГГТ", который направил нам пояснения к новой схеме представления данных в формате GML. На этот счет было как минимум 2 официальных приказа в открытой печати:

• Распоряжение Правительства Москвы №1113 от 02.06.2022 (https://www.mos.ru/mka/documents/dokumenty-moskomarkhitektury/view/270474220/)
• Распоряжение Правительства Москвы №133 от 19.01.2023 (https://www.mos.ru/mka/documents/dokumenty-moskomarkhitektury/view/281364220/)

Первый приказ утверждал схему, а второй вносил в неё изменения.

В качестве новой формы представления теперь выступает открытая спецификация GML с особой (специфичной) структурой файла и атрибутивным наполнением утвержденным МосГорГеоТрестом. Спасибо им за то, что основной была выбрана не логика XML как в Росреестре, а нормальная спецификация, файлы которой можно читать с использованием программных библиотек GDAL.

2. Состав материалов

Среди утвержденных к применению есть 3 типа схем:

• Геодезия (GML_TerritoryDigitalInformationModel);
• Геология (DigitalInformationGeologicalModel);
• Экология (GML_DigitalInformationEcologicalModel);

В числе демо-материалов, которые прилагались к схемам, были примеры для схем по геодезии и геологии. Из интересного, обе схемы в файлах имели в заголовке версию 03, то есть работа по их изменению идет постоянно.

2.1 Схема с инженерно-геодезическими данными

На мой взгляд, самая подробная и геометрически-сложная. Сложная оттого, что в составе предоставляемых данных может быть тип "поверхность". Здесь стоит отметить, что традиционно в ГИС мы привыкли иметь дело с простыми геометрическими типами -- точками, полилиниями и полигонами (или их группами). Здесь же добавляется новый тип - триангулированная поверхность, а если быть конкретным, то представление gml:TriangulatedSurface из набора граней gml:Triangle.

Если говорить о спецификации геометрии OGR, то триангулированная поверхность является подтипом OGRPolyhedralSurface

Несмотря на то, что OGRPolyhedralSurface в общем виде может описывать сетчатую оболочку, а не только поверхность триангуляции, этот тип данных был выбран для представления поверхности. Нелишним будет отметить, что структурно форма описания поверхности совпадает с видом OGRMultiPolygon, и например в движке QGIS им и заменяется.

Другие элементы геометрии -- это знакомые всем типы "точка", "линия", "полигон".

Кстати, именно ради полного импорта GML-файла от МГГТ мы и реализовали в модуле TBS-GIS поддержку поверхностей.

3. Как это выглядит на практике

Итак, подхожу к главному: в нашей надстройке TBS GIS был реализован импорт GML от МГГТ с особыми правилами: геометрическая сторона и атрибуты импортируются как гласит спецификация GML, но вот дальше данные претерпевают изменения:

• типы геометрии становятся примитивами платформы nanoCAD. а поверхность - набором 3D-граней;
• атрибутика вместо кодов приобретает конкретные значения (ищется расшифровка значения свойства для каждого имени, предусматривающего код в XSD-схемах);

В нашем модулем предусмотрена отдельная кнопка на импорт подосновы от МГГТ (всех поддерживаемых типов)

Вне зависимости от условий импорта у файлов отображается система координат МГГТ (при желании, например, импортировать с пересчетом в документ). Там же в деревообразном виде видны слои файла

Если импортировать файл через стандартный импорт OGR-форматов (драйверов) то в значениях свойств будут одни коды, как забито в GML-файле.

Реализация нашего импортера предусматривает расшифровку кодов

3.1 Как выглядит инженерно-геодезическая схема

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

Из классного, там есть даже структурные линии рельефа!

Вот так выглядит в полном виде

3.2 Как выглядят данные по геологии

В примере файла, который был, геология представлена информацией по точкам зондирования скважин, линиям каждого ИГЭ-слоя и двумя не-объектными слоями (возможно, потом им дадут геометрию - они помечены типом геометрии Other)

Красным слева выделен тип данных - 3D-полилиния для конкретного слоя ИГЭ скважины. В модели прямоугольников выделены точки зондирования скважины.

Конечно, не хватает для полной мощи картины поверхностей одинаковых ИГЭ, но это будет наверное следующий запрос. Так-то, атрибутика и геометрия есть, алгоритм построения поверхностей есть - реализовать можно

4. Преимущества реализации

Продемонстрированный функционал реализован на платформе nanoCAD, данные вставляются в примитивы (то есть этот DWG может быть свободно открыт и в AutoCAD\Civil 3D при необходимости). Вся атрибутивная часть в нашей надстройке сохраняет значения по свойствам, группа свойств и значениям с привязкой к объектам (по их Handle) в локальный XML-файл, который может быть легко программно преобразован, например, в набор характеристик Civil 3D или какого-либо другого ПО:

Вид нашего XML-файла с атрибутикой

Само собой, всё это черновая реализация, требующая отладки и уточнений в МГГТ, но по предварительной задумке наша надстройка TBS-GIS будет иметь кнопку с импортом подосновы от МГГТ не требующей приобретения лицензии на надстройку.

Кроме того, мы планируем позже, как AutoCAD переедет на среду .NET 8(?) реализовать минимальный адаптер и над этой средой, вернее, над Civil 3D 2025, так как логическое ядро TBS-GIS написано на C++/CLI под NRX под .NET 6 (а проекты C++/CLI в отличие от C# не могут быть собраны под .NET Framework).

Остается надеяться, что другие регионы и\или ведомства возьмут за основу спецификацию GML вместо политики Росреестра со своими XML своего сочинения, но это мечты-мечты ...