Интеллектуальная поддержка анализа градостроительных проектов на основе онтологии

Современные требования к качеству городской среды определяют необходимость изменения принципов градостроительной политики и внедрение новых технологий планирования и проектирования [1]. Проектирование городской среды включает ряд задач, связанных с разработкой концепции города, проектов зданий, сооружений, обеспечивающей инфраструк- туры и логистических систем, реализуемых в соответствии с регламентами нормативноправового регулирования [2].

Существующие подходы к поддержке принятия решений (ППР) в процессе градостроительного проектирования не позволяют учесть все факторы, влияющие на качество городской среды [3-5]. Особую сложность представляют экспертизы проектов, которые включают трудоёмкие процедуры проверки на соответствие нормативным документам. На этапе экспертизы проекта могут выявляться противоречия и ошибки, которые приводят к необходимости существенной переработки проекта. Цифровизация строительства и внедрение цифрового моделирования привели к необходимости интеграции разнородных данных, формируемых на различных этапах проектирования, и согласования проектных решений.

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

1    Онтологический подход в градостроительной деятельности

Применение онтологического подхода в градостроительстве обладает значительными возможностями для формализации процессов [6-9].

• ■    Онтологии позволяют интегрировать различные типы данных (географические, социальные, экономические и экологические), формировать единое информационное пространство для ППР в проектировании.

• ■    Онтологические модели (ОМ) совместно с цифровыми моделями объектов могут использоваться для оценки вариантов проектных решений.

• ■    Онтологии могут использоваться для создания интерфейсов между различными информационными системами, что обеспечивает более эффективное взаимодействие и обмен данными между участниками градостроительной деятельности.

• ■    Использование онтологии может обеспечить проактивное решение задач, связанных с выявлением возможных конфликтов, противоречий и недостатков в градостроительных решениях.

• ■    Онтологии являются основой для разработки баз знаний и структуры базы данных цифрового двойника градостроительного объекта. Потребители информации могут получать данные из онтологий, в т.ч. через сеть Интернет.

Известны онтологии, которые используются для формализации и структурирования знаний о городском пространстве.

CityGML 1 – это открытый стандарт для обмена трёхмерной географической информацией о городах и ландшафтах, который включает ОМ для описания геометрии, топологии, семантики и атрибутов городского пространства на основе формата JSON .

Linked Building Data ² ( LBD ) – решение для создания ОМ зданий и их компонентов с использованием принципов связанных данных.

Urban System Ontology 3 – это онтология, которая включает территориальное планирование, социальные вопросы, транспорт и окружающую среду. Одним из проектов включения онтологии в процессы проектирования градостроительных объектов является Towntology , который позволяет градостроителям работать с онтологией для анализа вариантов проектных решений [10].

В [11] рассматриваются вопросы формального представления знаний и использования построенных моделей для анализа городских систем. Приведены примеры применения ОМ для поддержки решений в оперативном управлении городскими системами и городском планировании.

Подход к интеграции данных и извлечению знаний для построения онтологии в сфере городского планирования представлен в [12]. Построенные ОМ применяются для ППР в задачах анализа эффективности использования территорий, исследования рынка недвижимости и планирования жилой застройки.

В [13] описывается подход, направленный на поддержку ранних этапах процесса городского проектирования. Основное внимание уделяется аспектам формализации знаний, которая является основой для моделирования городского пространства.

Потенциальные выгоды от использования онтологии в городском проектировании могут быть получены на разных этапах жизненного цикла градостроительного объекта, а эффективность полученных решений зависит от полноты используемых знаний [14].

Одним из ключевых преимуществ применения онтологий в градостроительстве является возможность объединения разнородных данных в единую систему. Это позволяет создавать комплексные решения для анализа и проектирования градостроительных объектов. Несмотря на достижения в сфере интеллектуализации строительного проектирования, для адаптации моделей знаний к конкретным проектам и регионам нужны новые решения и инструменты, в т.ч. позволяющие реализовать совместное использование с информационными системами моделирования зданий ( BIM -системами, от англ. Building Information Model).

2    Модели знаний для поддержки анализа градостроительных проектов 2.1    Градостроительное проектирование с использованием цифровых моделей

Градостроительное проектирование в современных условиях связано с разработкой и утверждением цифровой модели и документации, основанных на нормативах и правилах, в которых отражены знания о том, как организовать строительство с соблюдением всех существующих требований [15].

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

Рисунок 1 - Этапы процесса градостроительного проектирования с использованием цифровых моделей

1) Создание файла проекта включает подключение/создание библиотеки семейств, содержащей все необходимые для проекта элементы строительства/градостроительства (окна, двери, материалы, ограды, транспортно-телекоммуникационная инфраструктура, объекты городской среды и т.д.), библиотеку шаблонов -набор предварительно созданных типовых элементов, компонентов и конструкций. На основе технического задания, определяющие требования и условия для выполнения проектных работ, формируется план выполнения BIM проекта ( BEP, BIM Execution Plan ), определяющий координацию, планирование и организацию совместной работы всех участников проектной группы на всех этапах BIM -проекта.

• 2)    Интеграция данных – слияние информации о проектируемом объекте строительства из множества источников в унифицированное и стандартизированное отображение. Базовая модель представляет собой упрощённое представление объекта строительства и включает основные элементы здания (стены, перекрытия, инженерные системы и др.). Эта модель служит основой для более детализированной модели.

• 3)    Редактирование модели – на данном этапе дорабатывается базовая модель, наполняется характеристиками и значениями всех её составляющих из сформированной базы данных BIM модели.

• 4)    Экспертиза модели представляет собой проверку и оценку модели на соответствие определённым критериям, стандартам и требованиям. Если модель не проходит проверку, то она отправляется на доработку.

• 5)    Если модель проходит экспертизу, то на её основе готовят рабочую документацию, по которой выполняются строительные работы.

• 2.2    Формализация знаний для анализа градостроительных проектов

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

Например, в сфере градостроительства могут возникать противоречия между требованиями к плотности застройки и минимальными расстояниями между зданиями. Согласно одному нормативному документу, плотность жилой застройки в конкретной зоне может быть установлена на уровне 40%, что подразумевает максимальное использование территории под строительство (СП 42.13330. 2016 5 приложение Б.1). Другой нормативный акт (например, СП 476.1325800.2020 6 ) содержит требование выдерживать минимальные расстояния между зданиями.

Неоднозначность терминологии также создаёт сложности для проектировщиков и застройщиков. Например, понятие «прилегающая территория» может трактоваться по-разному: в одних документах оно относится только к участкам, непосредственно примыкающим к зданию, а в других — ко всей территории, находящейся в пределах красных линий улиц.

В предметной области рассмотрены типы строительных объектов, своды правил (СП), санитарные правила и нормы (СанПиН), ГОСТы и другие нормативные документы, определены концепты и связи между ними. На рисунке 2 показаны основные концепты, которые использовались для построения онтологии, а на рисунке 3 представлен фрагмент структуры классов разработанной онтологии.

Для формализации знаний и анализа соответствия проектов требованиям нормативных документов использовался язык SWRL ( Semantic Web Rule Language ) [16], который представляет собой язык для формулирования правил вывода, расширяющий возможности онтологии. SWRL -правила состоят из антецедента и консеквента, которые формируются на основе атомов, переменных и констант.

• ■    Атомы - это базовые составляющие правила, которые могут быть двух типов: классовые, например класс Road (?r), где Road является классом, и переменные, где ?r – экземпляр класса Road .

• ■    Переменные, которые обозначаются с помощью префикса ? (например, ?x, ?y) и используются для связывания различных атомов в одном правиле.

• ■    Стандартные логические операторы конъюнкции и импликации.

• ■    Антецедент — это часть правила, описывающая условия, при которых правило применяется.

• ■    Консеквент — это часть правила, описывающая следствие, которое должно быть выполнено, если условия

антецедента истинны.

• 4    В соответствии с Постановление Правительства Российской Федерации от 17.05.2024 № 614 предъявляются новые требования к составу сведений, документов и материалов, включаемых в информационную модель объекта капитального строительства.

• ⁵    СП 42.13330. 2016. Свод правил. Градостроительство. Планировка и застройка городских и сельских поселений. Актуализированная редакция СНиП 2.07.01-89.

• 6    СП 476.1325800.2020. Свод правил. Территории городских и сельских поселений. Правила планировки, застройки и благоустройства жилых микрорайонов" (утв. и введён в действие Приказом Минстроя России от 24.01.2020 N 33/пр).

  

  га t.'poa в

  Норма^-/

  засро/- г

  треоо=аь/-

  зонирование

  социальные

  IpOMWLJ-

  cG-j-ap'-.c

  нормы и

  правила

  Рисунок 2 – Концептуальная модель знаний для анализа градостроительных проектов в нотации IDEF5 (фрагмент)

  
  

• 2.3 Метод анализа градостроительных проектов

Пример формального представления правила:

A1 ∧ A2 ∧ ... ∧ An → B1 ∧ B2 ∧ ... ∧ Bm, где A1, A2,...,An — атомы в антецеденте (условия правила); B1, B2,...,Bm — атомы в консеквенте (следствия правила); n≥1, m≥1 — количество атомов в антецеденте и консеквенте.

Формализация правил позволяет автоматизировать процесс анализа модели и сопутствующей проектной документации т.к. появляется возможность напрямую работать с OWL классами, свойствами и индивидами и определять более сложные отношения и ограничения.

Для этого используются механизмы логического вывода, которые позволяют оценивать сложные условия и взаимосвязи между различными элементами модели. Например, если изменение проекта влияет на другие его части, система эти взаимосвязи учитываются при проверке. В работе сформировано 125 правил по различным нормативам и стандартам. Примеры правил представлены в таблице 1.

Использование ОМ позволяет автоматизировать процессы, связанные с проверкой качества создаваемой цифровой модели и сопутствующей проектной документации. Экспертиза строительных проектов трудоёмкая, дорогостоящая и ответственная процедура, выполняемая специа-

• ▼ ф ИЕИ

УЧ ЖилыеДома j |.....ф ВысотныеДома ■ Н"ф Дома Повышен ной Этажности ;  ......Ф СреднеэтажныеДома

У-ф КлиматическиеПояса

• ......ф ПравилаПостройки

• ▼    ф Территория

уф Двор

• ▼    ф ДорожноТропиночнаяСеть

• ►    ( АвтомобильныеДороги ф Пандусы ф ПешеходныеПути

• • ф Проезды ф Озеленение

1 ОриетацияПоСторонамСвета

• ▼ 4 Парковка

| [.....( ДвороваяПарковка

| 1.....ф ПодземнаяПарковка а а V ф Площадки

У-Ч Детская Площадка

I г.....ф Дошкол ьногоВозра ста

| L.....ф ШкольногоВозраста

[.....ф Контейнерная Площадка i.....ф ПлощадкаТихогоОтдыха

|.....( Спортивная Площадка

• ¹.....4 ХозяйственнаяПлощадка

; ▼ ф Инфраструктура г.....4 ДетскийСад г.....4 Магазин

[.....ф ОбшественныйТранспорт

).....ф Парк

1.....ф Школа

УЧ ЭлементыДома

Рисунок 3 – Иерархия классов онтологии (фрагмент)

листами высокой квалификации. Однако практика показывает, что ошибки могут обнаруживаться в процессе строительства и даже в эксплуатации. Высокий риск ошибок проектирова-

ния обусловлен:

■ сложностью городской среды, состоящей из большого числа взаимосвязанных элементов;

■ большим количеством нормативной документации и противоречиями в ней;

■ постоянными изменениями в законодательстве;

■ недостатком квалифицированных специалистов и др.

Таблица 1 – Примеры SWRL -правил

Раздел СП	Требование по СП	SWRL -правило
СП 42.13330.2016 п.7	Расстояние между домами свыше 9 этажей должно быть больше 25 м	MultiStoreyBuildings(?b1) ^ MultiStoreyBuildings(?b2) ^ hasFloors(?b1, ?f1) ^ hasFloors(?b2, ?f2) ^ swrlb:greaterThan(?f1, 9) ^ swrlb:greaterThanOrEqual(?f2, 9) ^ Distance(?d) ^ connects(?d, ?b1) ^ connects(?d, ?b2) ^ dis-tanceBetween(?d, ?dist) ^ swrlb:lessThan(?dist, 25) -> In-validDistance(?b1, ?b2)
СП 42.13330.2016 п.9	Площадь озеленённой территории микрорайона многоквартирной застройки жилой зоны должна составлять не менее 25% площади территории квартала.	Microdistrict(?d) ^ hasArea(?d, ?a) ^ hasGreenArea(?d, ?g) ^ swrlb:divide(?p, ?g, ?a) ^ swrlb:multiply(?p, ?p, 100) ^ swrlb:lessThan(?p, 25) -> has-InsufficientGreenery(?d, true)
СП 42.13330.2016 п.11.11	Расстояние между магистральной трассой и жилым домом, должно быть больше 50 м	TrunkRoad(?road) ^ ResidentialBuilding(?building) ^ hasDis-tanceTo(?road, ?building) ^ distanceBetween(?road, ?dis-tance) ^ swrlb:lessThan (?distance, 50) -> Invalid-Distance(?road, ? building)

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

Предлагаемый метод анализа градостроительных проектов включает следующие этапы:

• 1)    загрузка информационной модели, созданной в программе градостроительного проектирования Rhinoceros ⁷, и создание файла проекта формата XML ;

• 2)    передача параметров и данных модели через программный интерфейс ( Application Programming Interface, API ) и создание их списка – структурированного представления данных модели, которое включает ключевые характеристики и их значения; для извлечения параметров используются функции Rhinoceros API ;

• 3)    преобразование SWRL -правил в JSON -файл с помощью OWL API и создание массива для хранения правил;

• 4)    чтение JSON -файла через API среды информационного моделирования;

• 5)    интерпретация JSON -файла в список правил;

• 6)    проверка соответствия параметров модели правилам онтологии.

В таблице 2 представлены элементы XML-файла и интерпретированные правила из JSON. Элементы Building содержат атрибуты id, Name, Floors, Height, Location и AdjacentBuildings, которые описывают характеристики здания и его расположение относительно других зданий. В начале процесса экспертизы интерпретируются SWRL-правила, описанные в JSON структуре. Каждое правило содержит ключи ruleName, description, antecedent, consequent и condition. Антецедент в правиле указывает, что необходимо проверить, являют- ся ли две сущности соседними зданиями и какое расстояние между ними. Эти условия связаны с элементами XML файла Building, AdjacentBuildings и атрибутом distanceToBuilding, описанным в JSON. После извлечения данных применяются логические условия, указанные в condition JSON структуры. Если условие выполняется, то применяется консеквент. В результате формируется список всех несоответствий с указанием на нормативные документы.

Таблица 2 – Проверка соответствия параметров модели правилам онтологии

Элемент XML -файла	Правила из JSON -файла
id="Building1" Residential Tower A 12 40m 25m 30m id="Building2" Residential Building B 8 25m 25m 20m	"swrlRules": [ { "ruleName":"BuildingSpacingRule" "antecedent": [ "?b1 rdf:type :Building", "?b2 rdf:type :Building", "?b1 :hasAdjacentBuilding ?b2", "?b1 :distanceToBuilding ?d"], "consequent": [ "?b1 :meetsBuildingSpacingRequirement true" ], "condition": "?d > 25" }]

Диаграмма компонентов системы анализа градостроительных проектов в виде совокупности модулей показана на рисунке 4.

Рисунок 4 – Диаграмма компонентов системы анализа градостроительных проектов

• ■    Интерфейс Rhinoceros 3D предназначен для взаимодействия пользователя с информационной моделью и получения предупреждения о несоответствиях, если таковые имеются.

• ■    Плагин взаимодействует с интерфейсом через RhinoCommon API и состоит из следующих модулей:

• ■    Менеджер загрузки модели с помощью языка программирования C# обрабатывает данные информационной модели и формирует список её элементов.

• ■    Модуль извлечения данных получает значения характеристик информационной модели и формирует её структуру.

• ■    Модуль взаимодействия с онтологией обеспечивает связь между характеристиками информационной модели Rhino и онтологией. Этот модуль использует OWL API для аннотации объектов модели семантическими метаданными и установления связей между ними.

• ■    OWL API является инструментом для работы с онтологией и предоставляет доступ к семантическим данным и регулирующим правилам.

• ■    Модуль логического вывода осуществляет применение логических правил и выводов на основе данных модели и онтологии.

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

• 1)    анализ несоответствий (какие параметры не соответствуют требованиям и почему);

• 2)    пересмотр параметров модели (изменение размеров, выбор других материалов и др.);

• 3)  проверка модели (цикл повторяется до тех пор, пока все несоответствия не будут устранены);

• 4)    если ошибки не выявлены, то принимается решение о формировании проектной документации.

3 Пример анализа градостроительного проекта

Рассматривается соответствие проектных решений своду правил СП 42.13330.2016 при проектировании жилого квартала. Проверка реализуется в виде запросов к модели проекта на языке SPARQL , что позволяет извлекать необходимые данные и анализировать их на соответствие семантическим связям, заданным в онтологии. Результаты проверки возвращаются в формате таблицы, где отображаются соответствия установленным правилам и возможные противоречия. Модель проекта представляет собой набор конкретных данных, таких как параметры зданий, характеристики участков или другие атрибуты, которые могут соответствовать правилам либо противоречить им. SPARQL -запросы используют онтологию как основу для проверки данных модели проекта, выявляя несоответствия или ошибки [16, 17]. Созданные запросы хранятся в файле и могут повторно использоваться. Примеры запросов и используемых при этом SWRL -правил представлены в таблице 3.

Таблица 3 – Примеры SPARQL -запросов и результаты проверки

SPARQL-запросы Результаты проверки SELECT ?house1 ?property ?house2 ?value WHERE { ?house1 a ?class. FILTER(regex(str(?class),        “MultiStoreyBuildings$”,        “i”)).        ?house1 < asDistance> ?house2. ?house1 <     > ?value } Расстояние между домами свыше 9-ти этажей должно быть больше 25 м согласно СП 42.13330.2016. SELECT ?district ?area ?greenArea ?greenPercentage WHERE { ?district a ?class . FILTER(regex(str(?class),           "Microdistrict$",           "i"))           .           < > ?area. ?district                                                                                         < > ?greenArea . BIND((?greenArea / ?area) * 100 AS ?greenPercentage) } Площадь озеленённой территории микрорайона многоквартирной застройки должна составлять не менее 25% площади территории микрорайона согласно СП 42.13330.2016. SELECT ?road ?property ?relatedRoad ?value WHERE {?road a ?class. FILTER(regex(str(?class), “TrunkRoad$”, “i”)) ?road <  > ?relat-edRoad. ?road ?property ? value. } Расстояние между магистральной трассой и жилым домом должно быть больше 50 м согласно СП 42.13330.2016.

Визуальное представление результатов проверки информационной модели в среде проектирования Rhinoceros , показаны на рисунке 5.

Рисунок 5 – Визуальное представление результатов анализа проекта в среде проектирования Rhinoceros

Заключение

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

Предложен метод анализа градостроительных проектов с использованием ОМ, позволяющий автоматизировать процессы, связанные с проверкой создаваемой цифровой модели и сопутствующей проектной документацией. Программное решение в виде модуля среды Rhinoceros для анализа градостроительных объектов позволяет интегрировать разработанную онтологию с BIM -моделями, организовать обмен информацией между цифровыми моделями, внешними программами и проектировщиками, снизить трудоёмкость экспертизы.