Подготовка IFC-модели для АГР: экспорт, атрибуты и проверка перед подачей

Из чего состоит цифровой пакет: НПМ, ВПМ и файлы IFC

Прежде чем говорить про экспорт, стоит зафиксировать, что именно город ждёт на входе. Пакет цифровых материалов АГР состоит не из одного файла и не из одной модели. Подробно про саму суть ЦИМ, дату вступления требования в силу и разницу между низкополигональной и высокополигональной моделью мы уже разбирали в статье ЦИМ модель для АГР, здесь коротко напомним структуру и сразу перейдём к практике.

Минимум два самостоятельных IFC-файла: модель архитектурных решений объекта капитального строительства и отдельная модель проектной ситуации, куда входят благоустройство территории и озеленение участка. Их держат раздельно, каждый файл собой представляет два разных предмета проверки с разным набором обязательных данных.

Низкополигональная и высокополигональная модель

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

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

Кто в проекте готовит эти файлы

На практике задача обычно распределена между BIM-координатором или ГИПом, который отвечает за общую структуру и своевременность модели, и архитектором, который держит в актуальном состоянии саму геометрию. Разметка атрибутов RUS_SET_AGR при этом требует отдельного внимания: это формальная процедура со своими правилами, и на крупных проектах её иногда выделяют в отдельную задачу одному специалисту, чтобы не размазывать ответственность между несколькими исполнителями и не терять атрибуты на стыке между их частями модели.

Из какой программы экспортировать: Revit, Renga, ArchiCAD и другие BIM-системы

Формат IFC (Industry Foundation Classes) это открытый формат обмена данными между BIM-системами, работает поверх любой из них и определён профильным стандартом ГОСТ Р 10.0.02-2019, он же международный ИСО 16739-1:2018. Экспорт в IFC умеет практически любая современная BIM-система. Разница между программами именно в том, насколько удобно и без ручной доводки в файл попадут атрибуты набора RUS_SET_AGR, который требует город: сам экспорт в IFC умеет практически любая современная система.

Revit: официальный плагин

У Департамента градостроительной политики есть официальный плагин под требования к ЦИМ АГР, и выпущен он пока только для Revit. Плагин подтягивает нужный набор атрибутов через файл маппинга и экспортирует модель уже в структуре, которую ждёт входной контроль. Это самый короткий путь, если проект и так ведётся в Revit: меньше ручной работы, меньше риска опечататься в имени параметра.

Renga, ArchiCAD, Tekla и другие системы

Для остальных BIM-систем готового плагина под требования ДГП пока нет. Это не значит, что модель оттуда нельзя подать: встроенный IFC-экспортер есть в Renga, ArchiCAD, Tekla Structures и в большинстве других профессиональных систем. Разница в том, что атрибуты набора RUS_SET_AGR в этом случае элементам нужно проставить вручную, до экспорта, через пользовательские параметры или общий набор свойств, а затем проверить, что при выгрузке в IFC они не потерялись и не переименовались автоматически самой программой.

Что делать, если проект собран в нескольких программах

На практике архитектурную часть нередко ведут в одной системе, а генплан и благоустройство в другой. Здесь работает то же правило, что и с двумя обязательными файлами модели: не пытайтесь склеить всё в один IFC вручную через сторонние конвертеры, это почти гарантированно ломает структуру данных. Каждую модель выгружайте из своей программы отдельным файлом и проверяйте по отдельности.

Что проверить в самом IFC-файле после экспорта

Экспорт из любой программы стоит открыть контрольным взглядом до отправки в проверку на портал. Большинство бесплатных IFC-вьюеров показывают дерево классов элементов и позволяют выбрать конкретное помещение или конструкцию, чтобы посмотреть список его свойств. Стоит выборочно раскрыть несколько квартир на разных этажах и убедиться, что атрибуты RUS_Zone, RUS_Group_Number и RUS_Number у них заполнены и не совпадают между разными квартирами там, где должны различаться. Это быстрая проверка на глаз, она не заменяет автоматическую валидацию, но ловит грубые сбои экспорта раньше, чем на них будет потрачено время полноценной проверки на портале.

Смена BIM-системы посреди проекта

Иногда проект начинают в одной системе, а к моменту подготовки материалов АГР часть команды уже переходит на другую. Полный перенос модели между системами через IFC как промежуточный формат теоретически возможен, но на практике почти всегда требует повторной разметки атрибутов: при конвертации пользовательские параметры одной системы редко переносятся в другую один в один, особенно когда перенос идёт обходным путём через сторонний конвертер вместо штатного импорта производителя. Разумнее закладывать выбор основной BIM-системы для конкретного проекта заранее, зная, что именно из неё в итоге будет собираться пакет для АГР.

Требования к геометрии: этажи, статусы уровней и подсчёт площадей

Геометрия модели интересует город прежде всего как основа для автоматического подсчёта технико-экономических показателей. Отсюда главное практическое требование: каждый уровень здания должен быть назван и промаркирован так, чтобы система понимала, участвует он в подсчёте или нет.

Статус «основной» и «вспомогательный»

Уровни, которые относятся к этажам здания и данные по которым должны быть проверены при подсчёте площадей, помечают статусом «основной». Уровни, которые в подсчёт не входят напрямую, технические пространства, дополнительные отметки внутри одного этажа, помечают статусом «вспомогательный» или «дополнительный». Разработчик официального плагина приводит характерный пример именования уровней: С00_1_Этаж_основной_0,000, С01_П2_Подземный_этаж_основной_-6,600, П05_0_Цокольный_этаж_вспомогательный_-1,200, С03_9_Крыша_основной_+29,700. Схема читается так: номер секции, номер или код этажа, название уровня, статус, отметка по высоте.

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

Подвалы, кровля, технические этажи

В модель включают все уровни здания целиком: подземные этажи, надземные этажи, технические этажи и кровлю, с корректными отметками по высоте для каждого. Пропуск подземного или технического уровня в модели, даже если он есть в проекте, ведёт к расхождению объёмных показателей.

Секции и корпуса

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

Геометрия благоустройства и озеленения

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

Точки, где статус чаще всего путают

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

Атрибуты набора RUS_SET_AGR: что и как заполнять

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

Атрибуты для квартир и помещений

• RUS_Group_Type. Тип группы помещений, для жилых объектов значение задаётся как «Квартира».
• RUS_Group_Number. Основной идентификатор квартиры: все помещения одной квартиры обязаны иметь одинаковый номер группы, иначе система не соберёт их в единый объект при подсчёте.
• RUS_Number. Обязателен к заполнению у каждого помещения для отнесения его к нужной группе, без этого атрибута помещение выпадает из подсчёта квартиры целиком.
• RUS_Zone. Параметр для элементов, определяющих площадь: значения вписывают в терминах суммарной приведённой площади (СПП) в границах наружных стен (ГНС) и общей площади: именно этими категориями считает город, произвольные подписи назначения помещений в расчёт не идут.

Атрибуты для корпуса, секции и дополнительных функций

• RUS_Object. Номер корпуса, к которому относится элемент.
• RUS_Object_Sub. Номер секции внутри корпуса.
• RUS_GPZU_Zone. Дополнительный параметр к IfcSpace, нужен, когда в ГПЗУ или ГЗК для здания указана дополнительная функция, которую требуется отдельно отразить в суммарной приведённой площади или общей площади здания.

Как считаются комнаты

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

Детализация низко- и высокополигональной модели

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

Низкополигональная модель: только объём

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

Высокополигональная модель: атрибуты важнее визуальной детализации

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

Сколько закладывать по времени

На практике подготовка обеих версий модели по уже существующему проекту здания занимает от нескольких дней до трёх недель, в зависимости от того, велась ли модель изначально с прицелом на эти требования или её нужно доразмечать задним числом. Модель, которую строили без учёта будущей выгрузки в IFC для АГР, почти всегда требует больше времени на разметку атрибутов, чем на саму геометрию.

Чем ВПМ отличается от рабочей документации

Путаница часто возникает именно здесь: заказчику кажется, что раз модель называется «высокополигональной», в неё нужно перенести всю глубину проработки, характерную для рабочей документации, вплоть до узлов и деталей. На деле для целей АГР этого не требуется. Высокополигональная модель должна корректно передавать архитектурный объём, оконные и дверные проёмы, основные конструктивные членения фасада и, самое главное, нести полный набор атрибутов RUS_SET_AGR. Уровень проработки рабочей документации, армирование, узлы примыканий, спецификации оборудования, к предмету цифровой модели для АГР не относится и только удлиняет подготовку без пользы для прохождения контроля.

Чек-лист перед экспортом в IFC

Прежде чем нажать «экспорт», стоит пройти по короткому списку. Он не заменяет автоматическую проверку на портале, но убирает большинство очевидных промахов ещё до неё и экономит время на повторных заходах.

• Версия плагина и файла маппинга актуальна. Проверьте дату обновления плагина или шаблона маппинга атрибутов, требования обновляются, и старый шаблон может экспортировать часть данных с устаревшими именами параметров.
• У каждого уровня есть статус. Ни один этаж, подвал или технический уровень не должен остаться без пометки «основной» или «вспомогательный».
• У каждой квартиры один RUS_Group_Number на все помещения. Особенно после копирования типовых этажей: проверьте, что номер группы не «прилип» от исходного этажа.
• RUS_Number заполнен у каждого помещения без исключений. Пустое значение выбрасывает помещение из группы целиком.
• Площади размечены как СПП в ГНС и общая площадь. Именно в этих терминах: произвольные подписи назначения помещений тут не считаются.
• Корпус и секция проставлены у всех элементов объекта. Особенно на стыках между секциями, где элементы иногда остаются без привязки ни к одной из них.
• Комнаты промаркированы верным кодом функционального назначения. Жилая комната, спальня, детская, гостиная, иначе автоматический подсчёт комнат занизит их число.
• Модель здания и модель проектной ситуации выгружены отдельными файлами. Не единым файлом со всей сценой сразу.
• Имена атрибутов без лишних пробелов и посторонних символов. Опечатка в имени параметра для системы проверки равносильна отсутствию этого атрибута вовсе.

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

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

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

Из-за чего модель возвращают: разбор по данным ДГП

Руководитель Департамента градостроительной политики Владислав Овчинский приводил статистику по первому полугодию 2026 года: новые цифровые требования применены более чем в 100 проектах силами свыше 40 проектных компаний, а по массиву свыше 300 заявок собрана статистика причин замечаний.

54% замечаний, атрибуты

Больше половины всех возвратов связаны именно с атрибутами модели: пустые обязательные поля, неверно заполненные булевы параметры, ошибки в написании имён атрибутов вроде лишних пробелов или посторонних символов, старые версии программ или экспортёров, отставшие от текущего набора RUS_SET_AGR. Это самая частая и одновременно самая обидная причина возврата: геометрия здания при этом чаще всего в порядке, страдает именно машиночитаемая разметка.

27% замечаний, нехватка обязательных файлов

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

19% замечаний, отсутствие модели вовсе

Оставшаяся часть возвратов, это случаи, когда цифровая модель не была представлена вместе с пакетом материалов, хотя с 2 апреля 2026 года пакет без неё считается неполным. Такие заявки возвращают на доработку без содержательного рассмотрения альбома АГР.

Как отличить ошибку атрибута от ошибки геометрии

На практике замечание об атрибуте и замечание о геометрии выглядят по-разному уже в самом отчёте проверки: замечание об атрибуте указывает конкретный класс элемента и конкретное имя параметра, замечание о геометрии, как правило, касается объёмных характеристик или расположения элемента в пространстве. Если отчёт указывает на атрибут, чинить нужно именно разметку, геометрию трогать не требуется, и наоборот. Смешивать эти два вида правок в одной итерации не стоит: легче закрыть все замечания по атрибутам разом, затем отдельно разобрать замечания по геометрии, если они есть.

Почему доля атрибутивных ошибок так высока

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

Как проверить модель через портал «СтроимПросто» перед подачей

Департамент градостроительной политики прямо рекомендует проверять модель перед подачей заявления на архитектурную комиссию через сервис на портале «СтроимПросто»: «проведите проверку вашей информационной модели перед подачей заявления на архитектурную комиссию, результат проверки нужно обязательно приложить к заявлению».

Что делает проверка

Сервис на портале сверяет структуру загруженного IFC-файла с требованиями по IDS-файлам, набором правил, которые описывают, какие атрибуты, у каких классов элементов и в каком формате должны присутствовать. Проверка находит именно те технические проблемы, которые дают основную массу отказов: незаполненные атрибуты, некорректные значения, элементы без нужной привязки к группе или секции.

Как встроить проверку в рабочий процесс

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

Порядок работы с сервисом на практике

В личном кабинете на портале «СтроимПросто» готовый IFC-файл загружают в раздел проверки моделей, указав, какой это файл, архитектурные решения или проектная ситуация. Сервис обрабатывает файл и выдаёт отчёт с перечнем найденных замечаний по каждому классу элементов. Отчёт стоит сохранить в исходном виде: именно его прикладывают к заявлению вместе с самой моделью, пересказ замечаний своими словами тут не подходит.

Что делать с замечаниями внутри отчёта проверки

Отчёт сервиса группирует замечания по классам элементов вместо одного сплошного списка без структуры. Удобно закрывать замечания именно по группам: сначала все замечания к одному классу элементов, например ко всем IfcSpace квартир, затем к другому, например к элементам корпуса или секции. Так меньше риска пропустить однотипную ошибку у соседнего элемента того же класса, если отчёт указал её только у части экземпляров.

Что делать, если модель вернули с замечаниями

Если несмотря на предварительную проверку модель всё же вернули с замечаниями, порядок действий простой и линейный.

Разберите каждое замечание по отдельности

Замечания к цифровой модели почти всегда точечные: конкретный атрибут у конкретного класса элементов, конкретный уровень без статуса. Не пытайтесь чинить модель «в целом», выпишите список конкретных исправлений и закрывайте их по одному, сверяясь с чек-листом выше.

Проверьте, не тянется ли ошибка из шаблона

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

Повторно прогоните модель через проверку

После исправлений обязательно повторите проверку на портале «СтроимПросто», прежде чем подавать доработанный пакет заново. Это тот же принцип, что и на этапе первой подготовки: дешевле поймать оставшиеся ошибки самостоятельно, чем повторно ждать рассмотрения архитектурной комиссией.

Общий порядок рассмотрения материалов, сроки и то, что делать при содержательных замечаниях к самому архитектурному решению, разбираем в статье про новый порядок согласования АГР.

Сроки на доработку

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

Когда стоит привлекать специалиста со стороны

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

Коротко: главное о подготовке IFC-модели

• Из чего состоит пакет. Минимум два IFC-файла: архитектурные решения объекта и проектная ситуация с благоустройством, каждый в низко- и высокополигональной версии.
• Из какой программы готовить. Официальный плагин ДГП пока выпущен только для Revit, в Renga, ArchiCAD и других системах атрибуты проставляют вручную и экспортируют через встроенный IFC-экспортер.
• Геометрия и уровни. Каждому этажу присваивают статус «основной» или «вспомогательный», от этого зависит подсчёт площадей и технико-экономических показателей.
• Атрибуты RUS_SET_AGR. RUS_Zone, RUS_Group_Type, RUS_Group_Number, RUS_Number для помещений; RUS_Object и RUS_Object_Sub для корпуса и секции; RUS_GPZU_Zone для дополнительных функций здания.
• Детализация. В низкополигональной модели важен объём и силуэт, в высокополигональной полнота атрибутов важнее визуальной точности геометрии.
• Основные причины возврата. 54% замечаний это ошибки в атрибутах, 27% нехватка обязательных файлов, 19% отсутствие модели вовсе, по статистике ДГП за первое полугодие 2026 года.
• Проверка перед подачей. Сервис на портале «СтроимПросто» проверяет структуру IFC по IDS-файлам, результат проверки обязателен в составе заявления на архитектурную комиссию.
• Если вернули с замечаниями. Разбирают каждое отдельно, проверяют, не тянется ли ошибка из шаблона, и повторно прогоняют модель через проверку перед новой подачей.
• Кто готовит модель. Обычно BIM-координатор отвечает за структуру пакета, архитектор за геометрию, разметку атрибутов на крупных проектах разумно выделять отдельной задачей.