ЦИМ АГР и IFC-модель: структура пакета, атрибуты и ошибки в GeoJSON
Вы подготовили полный пакет для подачи на АГР: ЦИМ АГР в формате IFC и модели НПМ/ВПМ. Геометрия везде выверена, площади и высоты посчитаны, здание точно соответствует проекту. Пакет уходит на согласование и возвращается с отказом. В замечаниях ни слова о форме здания: ошибка в кадастровом номере, незаполненное поле, несоответствие в метаданных.
Специалист, который несколько недель выверял именно геометрию моделей, видит в этом придирку не по делу: модели ведь построены правильно. Но пакет для АГР это не только сами модели. Вместе с ними подаются сопроводительные данные: атрибуты внутри самой IFC-модели и отдельный файл GeoJSON, который идет с моделями НПМ и ВПМ. Проблему чаще находят именно там где ошибка никак не связана с тем, насколько точно построено здание.
Внимание при подготовке пакета почти всегда уходит на геометрию: ее видно, ее можно проверить самому, открыв файл в Revit. Сопроводительные данные остаются на втором плане, ровно до того момента, когда из-за одного незаполненного поля приходится проходить всю процедуру заново.
Что такое ЦИМ АГР и как это соотносится с IFC-моделью
Разобраться в этом отказе стоит с самого начала: с того, что вообще такое ЦИМ АГР. ЦИМ расшифровывается как цифровая информационная модель, а применительно к АГР это открытая IFC-модель объекта: тот же по смыслу файл, что используется в обычном BIM-проектировании, только собранный и заполненный под требования конкретной процедуры согласования. ЦИМ АГР и IFC-модель для АГР по сути один и тот же файл, названный по-разному: один раз по назначению, другой раз по формату.
Это отдельный трек требований, отличный от низкополигональной и высокополигональной моделей, НПМ и ВПМ, которые тоже входят в пакет АГР. НПМ и ВПМ собираются в формате FBX и регулируются отдельным документом, а ЦИМ АГР в формате IFC по отдельному регламенту. Разные форматы и разные регламенты: смешивать требования одного трека с требованиями другого не стоит уже на этапе планирования работы над проектом.
Формально IFC является открытым, платформонезависимым форматом и на бумаге не привязывает разработчика к конкретной программе. На практике официальный плагин под атрибуты набора RUS_SET_AGR пока выпущен только для Revit. В других профессиональных платформах, например в Renga, ArchiCAD или Tekla, экспорт в IFC тоже есть, но недостающие атрибуты приходится проставлять вручную: готового инструмента именно под эту задачу там пока нет. Важна и версия самой схемы — регламент требует IFC4, вид Reference View, а не любую версию IFC. Прежде чем начинать работу в непривычной платформе, стоит заранее уточнить у ее разработчика, поддерживает ли она эту схему и как в ней добавить атрибуты RUS_ вручную.
Дальше в этой статье разбираем то, что скрыто внутри этой IFC-модели и вокруг нее, а не то, как в принципе экспортировать IFC из Revit. Общая механика экспорта уже разобрана в отдельном материале «Экспорт IFC из Revit без ошибок».
Из чего состоит пакет: IFC-модель, структура атрибутов, GeoJSON
Пакет для АГР состоит из двух самостоятельных слоёв данных, и у каждого свой набор требований: атрибуты внутри самой IFC-модели, и отдельный файл метаданных, который сопровождает архив с моделями НПМ и ВПМ. Спутать их легко, потому что оба слоя описывают, по сути, один и тот же объект. Заполняются они по разным правилам и проверяются по разным документам.
У IFC-модели атрибуты группируются в именованные наборы с префиксом RusSet_ (например, Rus_set_AGR), а сами атрибуты внутри них получают префикс RUS_: например, RUS_Zone для категории площади (значения вроде «СПП в ГНС» или «Общая площадь»), RUS_Object для привязки к корпусу, RUS_FNO для функционального назначения. Этот трек регулируется отдельным распоряжением Департамента градостроительной политики и ДИТ от 16 января 2026 года. На момент подготовки статьи полный текст этого документа в открытом доступе найти не удалось, названия атрибутов и наборов известны только по пересказам на профильных ресурсах, а не по самому регламенту. Здесь их стоит воспринимать как ориентир, а не как точную цитату документа.
Со вторым слоем ситуация обратная: он подробно описан в официальном регламенте, в Приложении 3 к распоряжению, которое целиком посвящено требованиям к НПМ и ВПМ. Файл называется GeoJSON и сопровождает архив именно с моделями НПМ/ВПМ, а не саму IFC-модель. Вот его структура полностью, с официальными названиями полей и примерами значений из документа:
| # | Поле | Описание | Пример значения |
|---|---|---|---|
| 1 | address | Улица, владение, корпус/строение. | Полярная ул., вл.4 |
| 2 | okrug | Округ. Ограничение до 50 символов. | СВАО |
| 3 | rajon | Район. Ограничение до 50 символов. | Южное Медведково |
| 4 | name | Наименование объекта. | Многоквартирный жилой дом |
| 5 | developer | Наименование организации застройщика. Ограничение до 255 символов. | Фонд реновации |
| 6 | designer | Наименование проектной организации. Ограничение до 255 символов. | АО МСУ-1 |
| 7 | cadNum | Кадастровый(ые) номер(а), по маске для участков или кварталов. | Участок: 77:02:0006003:95; квартал: 77:02:0006003 |
| 8 | FNO_code | Код функционального назначения объекта по 306-ПП. | 010 001 001, или не заполнять |
| 9 | FNO_name | Функциональное назначение объекта по 306-ПП, текстом. | Многоэтажный многоквартирный дом |
| 10 | ZU_area | Площадь участка, га. | 0.5191 |
| 11 | h_relief | Нулевая отметка, м. | 147.90 |
| 12 | h_otn | Относительная высота объекта, м. | 46.92 |
| 13 | h_abs | Абсолютная высота объекта, м. | 194.82 |
| 14 | s_obsh | Общая площадь объекта, м². | 17088.71 |
| 15 | s_naz | Наземная площадь объекта, м². | 13983.62 |
| 16 | s_podz | Подземная площадь объекта, м². | 3105.13 |
| 17 | spp_gns | Суммарная поэтажная площадь в габаритах наружных стен, м². | 16454.34 |
| 18 | act_AGR | Номер САГР, действующего на момент подачи заявления. | 811-2-21, или не заполнять |
| 19 | imageBase64 | Изображение объекта для поиска, base64, исходник 256×256 px jpg. | /9j/1as564fd1a… |
| 20 | other | Дополнительная информация. | — |
| 21 | coordinates | Координаты точки вставки модели в МСК-77, точность 3 знака. | [1000.374, 324.817] |
| 22 | Glasses | Массив свойств стеклянных материалов, группы M_Address_MainGlass_1..7. | — |
| 22.1 | color_RGB | Цвет стекла в RGB, 0-255. | R=135, G=136, B=146 |
| 22.2 | transparency | Прозрачность стекла, 0-1. | 0.379 |
| 22.3 | refraction | Коэффициент преломления, 1-3. | 1.13 |
| 22.4 | roughness | Шероховатость, 0-1. | 0.057 |
| 22.5 | metallicity | Металличность, 0-1. | 0.84 |
Если в проекте вообще нет остекления, массив Glasses остается пустым, но не убирается из структуры файла целиком: это тоже часть регламента, а не самодеятельность разработчика.
Какие из этих полей на практике заполняют неверно или не заполняют вовсе — отдельный разговор.
Типичные ошибки атрибутирования и заполнения GeoJSON
Ошибки в пакете для АГР распределены неравномерно между двумя треками, но случаются в обоих. Про атрибуты самой IFC-модели независимых источников меньше, но один конкретный пример встречается в профильных материалах. Про GeoJSON, который идет с моделями НПМ и ВПМ, подтверждений заметно больше.
На стороне IFC-модели один из таких примеров: элементы, которые при экспорте попадают в универсальный класс IfcBuildingElementProxy вместо своего корректного IFC-класса. Регламент, по данным профильных материалов, использование этого универсального класса прямо запрещает, но без настройки маппинга параметров при экспорте из некоторых САПР система по умолчанию относит к нему все элементы, которые не смогла точно распознать. Модель при этом может выглядеть безупречно: проблема не видна на глаз, только при открытии самого IFC-файла или при автоматической проверке.
Разработчики одного из бесплатных инструментов для проверки моделей перед подачей на АГР отмечают, что значительная часть ошибок связана именно с некорректным заполнением GeoJSON. Такой инструмент закрывает автоматической проверкой 70-80 пунктов из примерно 200, и даже при таком охвате остальные пункты по-прежнему требуют ручного контроля.
Хороший пример конкретной, не абстрактной ошибки: поле cadNum, кадастровый номер, в самом GeoJSON. Регламент задает точную маску: для земельного участка это АА:ББ:ВВВВВВВ:ГГ, для квартала — без последних двух цифр, то есть АА:ББ:ВВВВВВВ. Перепутать эти два формата, вписать номер квартала вместо номера участка или оставить лишние цифры достаточно просто, а визуальный контроль модели такую ошибку не поймает: геометрия остается прежней, но в архив уходит файл с форматным сбоем.
Второй частый источник путаницы: поля, обязательные для одного типа файла и запрещенные для другого. Например, h_otn, относительная высота объекта, заполняется для основного объекта, но должна остаться пустой для файла благоустройства. При копировании структуры файла с прошлого проекта это условие легко упустить, и тогда отказ приходит там, где сама модель безупречна.
Ошибка такого рода не видна, пока не откроешь сам файл метаданных, и именно поэтому ее пропускают чаще, чем неточность в самой модели.
К чему это приводит на практике
Неточность в атрибуте ЦИМ АГР или в поле GeoJSON не останавливает проект насовсем, но запускает цикл, который отнимает больше времени, чем кажется на старте. Комиссия рассматривает пакет, находит несоответствие не в геометрии, а в сопроводительных данных, и возвращает его с замечаниями. Специалист исправляет конкретное поле или атрибут, но подать исправленный пакет с той же скоростью, что и в первый раз, уже не получается: процедура согласования начинается заново, а не продолжается с того места, где остановилась.
От этого не застрахованы даже опытные команды: разовая ошибка в атрибуте или в поле GeoJSON случается независимо от опыта специалиста. Это не признак небрежности — это системный риск самой процедуры: слишком много мелких полей, чтобы не упустить ни одного при сборке пакета.
Что делать дальше
Проблему в сопроводительных данных, о которой шла речь выше, проще не искать в готовом пакете перед самой подачей, а закрыть на этапе разработки когда над атрибутами IFC-модели и структурой GeoJSON для НПМ/ВПМ работает одна команда, а не два отдельных исполнителя, у каждого из которых свой трек требований.
Услуга Tiver Group «3D-модели АГР» покрывает именно эту связку: разработку ЦИМ АГР, то есть IFC BIM-модели для согласования, и моделей НПМ/ВПМ в формате FBX оба трека одного пакета. Если вы собираете пакет для АГР и хотите, чтобы его не вернули из-за незаполненного поля или неверного атрибута, а не из-за формы здания, с этим можно обратиться уже сейчас.
