Intelligent support for the analysis of urban development projectsbased on ontology

А. G. Shcherbakov; Щербаков А. Г.; N. P. Sadovnikova; Садовникова Н. П.; D. S. Parygin; Парыгин Д. С.; N. M. Rashevskiy; Рашевский Н. М.; A. S. Gurtyakov; Гуртяков А. С.

doi:10.18287/2223-9537-2025-15-3-436-448

Intelligent support for the analysis of urban development projectsbased on ontology

Авторлар: Shcherbakov А.G.¹, Sadovnikova N.P.¹, Parygin D.S.¹, Rashevskiy N.M.¹, Gurtyakov A.S.¹
Мекемелер:
1. Volgograd State Technical University (VSTU)
Шығарылым: Том 15, № 3 (2025)
Беттер: 436-448
Бөлім: METHODS AND TECHNOLOGIES OF DECISION MAKING
URL: https://journal-vniispk.ru/2223-9537/article/view/312508
DOI: https://doi.org/10.18287/2223-9537-2025-15-3-436-448
ID: 312508

Дәйексөз келтіру

Толық мәтін

Аннотация
Толық мәтін
Авторлар туралы
Әдебиет тізімі
Қосымша файлдар
Статистика

Аннотация

The design of urban development projects relies on approaches that involve the creation of new methods for knowledge extraction and representation. These approaches enable the adaptation of digital models to changing conditions and facilitate the coordination of interdisciplinary requirements. This article addresses the formalization of knowledge related to building structure types, regulatory standards, operational conditions, and other data that must be considered in urban development processes. Based on an analysis of design workflows and regulatory and reference documentation, an ontology has been developed to support the evaluation of urban development projects. The article proposes a method for analyzing such projects that integrates data from informational, geometric, and ontological models to verify the compliance of digital models and design documentation with relevant norms and standards. The method is applicable across a wide range of urban development projects; its use depends on the completeness of the databases and rule sets involved. The software implementation of the proposed method reduces the labor intensity of project review and contributes to improving the overall quality of urban development outcomes.

Негізгі сөздер

decision support, knowledge representation model, urban development project, ontologies, design

Толық мәтін

Введение

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Атомы – это базовые составляющие правила, которые могут быть двух типов: классовые, например класс Road(?r), где Road является классом, и переменные, где ?r – экземпляр класса Road.
Переменные, которые обозначаются с помощью префикса ? (например, ?x, ?y) и используются для связывания различных атомов в одном правиле.
Стандартные логические операторы конъюнкции и импликации.
Антецедент — это часть правила, описывающая условия, при которых правило применяется.
Консеквент — это часть правила, описывающая следствие, которое должно быть выполнено, если условия антецедента истинны.

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

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

A1 ∧ A2 ∧ ... ∧ An → B1 ∧ B2 ∧ ... ∧ Bm,

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

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

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

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

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

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

Рисунок 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) ^ distanceBetween(?d, ?dist) ^ swrlb:lessThan(?dist, 25) -> InvalidDistance(?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) ^ hasDistanceTo(?road, ?building) ^ distanceBetween(?road, ?distance) ^ swrlb:lessThan (?distance, 50) -> InvalidDistance(?road, ? building)

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

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

загрузка информационной модели, созданной в программе градостроительного проектирования Rhinoceros ^[7], и создание файла проекта формата XML;
передача параметров и данных модели через программный интерфейс (Application Programming Interface, API) и создание их списка – структурированного представления данных модели, которое включает ключевые характеристики и их значения; для извлечения параметров используются функции Rhinoceros API;
преобразование SWRL-правил в JSON-файл с помощью OWL API и создание массива для хранения правил;
чтение JSON-файла через API среды информационного моделирования;
интерпретация JSON-файла в список правил;
проверка соответствия параметров модели правилам онтологии.

В таблице 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

</AdjacentBuildings>

</Building>

id="Building2"

<Name>Residential Building B</Name>

</AdjacentBuildings>

</Building>

"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 является инструментом для работы с онтологией и предоставляет доступ к семантическим данным и регулирующим правилам.
Модуль логического вывода осуществляет применение логических правил и выводов на основе данных модели и онтологии.

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

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

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 <http://www.semanticweb.org/gsher/ontologies/buildingFamily.owl#h asDistance> ?house2. ?house1 <http://www.semanticweb.org/gsher/ontologies/buildingFamily.owl#hasADistanceOf > ?value }	Расстояние между домами свыше 9-ти этажей должно быть больше 25 м согласно СП 42.13330.2016.
SELECT ?district ?area ?greenArea ?greenPercentage WHERE { ?district a ?class . FILTER(regex(str(?class), "Microdistrict$", "i")) . < http://www.semanticweb.org/gsher/ontologies/buildingFamily.owl#hasArea> ?area. ?district < http://www.semanticweb.org/gsher/ontologies/buildingFamily.owl#hasGreenArea> ?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 < http://www.semanticweb.org/gsher/ontologies/buildingFamily.owl#hasDistance > ?relatedRoad. ?road ?property ? value. }	Расстояние между магистральной трассой и жилым домом должно быть больше 50 м согласно СП 42.13330.2016.

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

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

Заключение

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

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

¹ CityGML - Open Geospatial Consortium. - https://www.ogc.org/standard/citygml/.

² LBD. - https://www.ugent.be/ea/architectuur/en/research/research-projects/all-research-projects/linked-building-data.

³ Urban System Ontology. - https://enterpriseintegrationlab.github.io/icity/UrbanSystem/doc/index-en.html.

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

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

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

⁷ Rhinoceros 3D. - https://www.rhino3d.com/.