Геометрия Столицы


Гео и язык канала: Россия, Русский
Категория: Технологии


BIM/ТИМ в России без иллюзий.
ЦИМ, экспертиза, IFC, данные, цифровизация и реальные кейсы.
Личный канал Алексея Григорьева.
ТИМ-менеджер | Основатель «Геометрии Столицы»
@elvax

Связанные каналы

Гео и язык канала
Россия, Русский
Категория
Технологии
Статистика
Фильтр публикаций


💰 Изменили модель. Кто пересчитает деньги?

Первый расчет стоимости по модели — вообще не самая сложная часть 5D. Самое интересное начинается после первой нормальной корректировки проекта.

Передвинули стену, изменили толщину перекрытия, поменяли материал, добавили проем, конструктор пересчитал решение. ЦИМ обновилась. А стоимость?


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

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

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

Настоящий смысл появляется тогда, когда можно проследить: изменился элемент - изменился объем - изменилась работа - изменилась стоимость.

Причем недостаточно увидеть новую итоговую цифру. Было 300 м3 бетона, стало 327. Хорошо. Откуда появились еще 27?

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

Связать модель со сметой один раз относительно легко. Сделать так, чтобы эта связь пережила десятки изменений проекта, — совсем другая история.


И главный вопрос: кто после изменения модели должен пересчитать деньги? Проектировщик? ТИМ-менеджер? Сметчик? Или в идеальной цифровой цепочке система вообще не должна ждать, пока кто-то об этом вспомнит?


Спасибо всем, кто поучаствовал в опросе.

По результатам видно, что задача работы с ВОР на основе данных ЦИМ действительно актуальна, причем у части коллег она стоит уже сейчас.

Значит, продолжаю подготовку нового формата работы. Скоро расскажу подробнее.


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


⭕️⭕️⭕️
Сделали свой IFC Anonymizer. Зачем, если аналоги уже существуют?

На рынке уже есть инструменты для обезличивания IFC. Например, IFC Toolbox умеет анонимизировать пользовательские и часть служебных данных, а BIMcamel очищает авторов, организации, контакты и сведения о происхождении файла.


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

Простой пример.

У вас есть IFC реального объекта. Внутри могут находиться название проекта, адрес, заказчик, проектировщик, ФИО авторов, исходные GUID, геопривязка и другие данные. При этом вам нужно передать модель на внешний анализ и сохранить стены, перекрытия, материалы, классификацию, площади, объемы и свойства элементов.


Руками проверить десятки тысяч IFC-сущностей практически нереально.

⭕️Наш IFC Anonymizer:⭕️

- работает локально на компьютере;
- не изменяет исходный IFC;
- удаляет адреса, людей, организации и служебные данные;
- позволяет указать конкретные названия, шифры и другие идентификаторы проекта для поиска;
- удаляет геопривязку;
- генерирует новые GlobalId;
- сохраняет геометрию и инженерные данные;
- после обработки формирует отдельный Privacy Report.

Именно отчет нам нравится больше всего.

Мы получаем не просто файл со словами «вроде обезличили», а паспорт обработки: что было очищено, сколько записей изменено, удалена ли геопривязка, сколько GUID заменено и остались ли находки уровня Critical, Review или Info.

На тестовой модели инструмент заменил более 80 тысяч GlobalId, очистил сведения об авторах, организациях, адресах и проекте, удалил геопривязку и при этом сохранил геометрию и структуру модели.

Чем наш подход отличается от похожих решений?

Не самим фактом анонимизации. Такое ПО уже существует.

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

В основе инструмента используется открытая библиотека IfcOpenShell, которая позволяет программно читать, изменять и сохранять IFC.

⭕️⭕️
Пока оставляем инструмент для внутренней работы «Геометрии Столицы». Посмотрим, как он покажет себя на разных моделях. Если окажется действительно полезным, возможно, позже поделимся им с вами.


Если конечно вам такое интересно 🤔


IDS в Москве. Что изменилось?

Москва уже публикует часть требований к ЦИМ в машиночитаемом формате.

На официальной странице МГЭ вместе с МССК опубликована версия классификатора в формате .ids.

И это интереснее, чем просто еще один формат файла.


IDS позволяет описать требования так, чтобы их мог проверять не только человек, но и программа.

Нужный IFC-класс, обязательное свойство, допустимое значение, классификация, материал — такие требования можно формализовать и проверять автоматически.

Но IDS не проверит, правильно ли запроектировано здание или хорошее ли принято техническое решение. Детали геометрии IDS также не определяет.

Он работает там, где требование можно превратить в однозначное машинное правило.

И вот здесь самое интересное.

Мы много говорим про автоматическую проверку ЦИМ. Но сначала сами требования должны быть написаны так, чтобы машина могла понять, что именно от нее хотят.

Если требование нельзя нормально формализовать, возможно, проблема уже не в отсутствии автоматизации.

Возможно, проблема в самом требовании.


Пятница начинается с актуального «ЮМОРА» 😀


🙋 Кто отвечает за объем, который посчитала модель?

Автоматизация должна была закрыть простой вопрос: сколько здесь бетона, стен, перекрытий или оборудования. Нажали кнопку — получили 128,37 м3. Красиво.


А теперь представим, что цифра неправильная.
Проектировщик скажет: геометрия построена правильно.
ТИМ-менеджер — правило расчета настроено.
Сметчик — объем пришел из модели.
Разработчик — программа посчитала то, что ей передали.

И внезапно за итоговые 128,37 м3 как будто не отвечает никто.


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

Сам IFC умеет хранить количественные характеристики: длину, площадь, объем, массу и другие величины. Для отдельных элементов предусмотрены стандартные наборы количеств. Например, для стены отдельно определяются GrossVolume, NetVolume, GrossSideArea и другие показатели. Но наличие параметра еще не отвечает на вопрос, какой именно объем нужен для конкретной работы.

И чем глубже мы связываем ЦИМ с ВОР и стоимостью, тем важнее становится уже не вопрос: «Может ли программа это посчитать?» Может.

❓ Главный вопрос другой: кто проверил, что именно она посчитала, и кто готов отвечать за эту цифру?

Вот здесь автоматизация становится немного интереснее кнопки «Рассчитать»)))

175 1 0 22 20

Почему прораб до сих пор открывает PDF, а не ЦИМ?

Потому что прорабу обычно не нужна модель сама по себе. Ему нужен быстрый ответ на конкретный вопрос: что строить, где строить, из чего и по какой актуальной версии.

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


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

ЦИМ станет действительно рабочим инструментом стройки не тогда, когда прораба обяжут ее открывать, а когда она быстрее PDF ответит на его вопросы: что изменилось, какой элемент строить сегодня, какое решение актуально и где посмотреть связанные документы.

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

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


🤖 ИИ для стройки вышел за пределы Москвы

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


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

Сейчас размещенные на платформе решения работают в том числе с фотографиями, а дальнейшее развитие предполагает работу с ЦИМ, чертежами, облаками точек и другими данными строительной отрасли.

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

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

Получается забавно: развитие ИИ снова возвращает нас к тем самым «скучным» вопросам последних лет — классификации, структуре данных, требованиям к ЦИМ, качеству IFC и единым правилам передачи информации.

ИИ плохие данные не отменяет. Он просто делает цену плохих данных еще заметнее.


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


С Днем строителя!

Спасибо всем, кто не просто рисует проекты, а создает города, дороги, школы, дома и будущее.

Пусть объектов будет больше, ошибок — меньше, а каждый проект приносит гордость за свою работу.

С праздником! ⭐️

Ребята, извиняюсь, что на фото сижу с чертежами, а не с ноутбуком. Просто на стройке пока что так проще. 🙂


⭕️⭕️⭕️
Москва теперь видит стройку на большом экране

Сегодня на 2-й Брестской улице открыли Ситуационный центр градостроительной политики города Москвы.

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


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

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

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

Ну и уровень открытия соответствующий — сегодня новый центр посетил наш дорогой мэр Москвы Сергей Семёнович Собянин. ⭕️

К сожалению, показать центр изнутри пока не могу — в день открытия доступ туда был ограничен. Но, думаю, ещё успеем заглянуть внутрь и подробно всё рассмотреть.


В модели есть стена. А где работы по ее возведению?
В модели есть стена. У нее указаны материал, объем, площадь, толщина, этаж и код. Кажется, осталось нажать кнопку — и получить готовую смету.


Но модель в первую очередь описывает, что должно быть построено. Смета и стройка отвечают уже на другой вопрос: как именно это построить.

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

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

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


Главная сложность 5D сегодня не в том, чтобы найти стену и посчитать ее объем. Главная сложность — правильно объяснить системе, как эту стену будут строить


49% застройщиков применяют ТИМ. Почему стройка быстрее не стала?
49% — красивая цифра. По данным ЕИСЖС, во втором квартале 2026 года ТИМ применяли 49% застройщиков, а самым распространенным этапом оставалось проектирование. Но сама по себе эта статистика не отвечает на главный вопрос: какой эффект получила стройка?


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

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

Пока мы считаем сам факт применения ТИМ, а не полученный эффект, цифра 49% больше говорит о распространении технологии, чем о ее реальной пользе.

Возможно, пора спрашивать не «сколько компаний внедрили ТИМ?», а «что конкретно после этого изменилось на их объектах?» 🤔


Видео недоступно для предпросмотра
Смотреть в Telegram
Всем хороших выходных! Сегодня без юмора: начался последний месяц лета, которого мы так долго ждали. Успейте прожить его по-настоящему… 🙏


К моему сожалению, с форматом glTF я столкнулся совсем недавно. Увидел рядом два файла — .gltf и .bin — и сначала не до конца понял, зачем они нужны и чем отличаются от привычного IFC. Тут моя фантазия разошлась: а сколько ещё форматов передачи данных в BIM я до сих пор не знаю? Начал разбираться — так и родился этот пост)))

Один объект — несколько форматов. Что мы вообще передаём?

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


glTF и GLB — для быстрой визуализации. Основа glTF — JSON-описание трёхмерной сцены, при этом геометрия может храниться отдельно в .bin, а текстуры — в других файлах. GLB позволяет собрать всё в один бинарный файл. Такой формат удобен для браузерных просмотрщиков, мобильных приложений, презентаций и передачи лёгкой 3D-модели, но он не предназначен для полноценной передачи всей BIM-семантики исходного проекта.

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

XML — для структурированных данных. Это не отдельный формат BIM-модели, а универсальный текстовый способ описания информации. В XML можно передать объёмы, параметры, классификаторы, сметные данные, статусы или результаты проверок. Поэтому кнопка «Выгрузить в XML» без пояснений говорит мало: важно понимать структуру файла, состав полей и систему, которая будет его принимать. Два XML-файла могут иметь совершенно разное содержание и назначение.

На этом список не заканчивается. BCF нужен для обмена замечаниями по модели: описаниями проблем, статусами, точками обзора и привязками к элементам. То есть IFC передаёт сам объект, а BCF — обсуждение того, что с ним не так.

COBie ориентирован на передачу структурированных данных об оборудовании и активах при переходе к эксплуатации. gbXML используется для передачи информации из авторских BIM-систем в программы энергетического и инженерного анализа. CityGML работает уже в масштабе города и территории, позволяя хранить и передавать виртуальные трёхмерные городские модели.

Получается, одна модель вполне может иметь несколько правильных выгрузок: glTF — для просмотра, IFC — для межпрограммного обмена, XML — для интеграции информационных систем, BCF — для замечаний, COBie — для эксплуатации, gbXML — для расчётов, CityGML — для городского масштаба.


Это не дублирование. Просто каждый формат отвечает на свой вопрос.

Поэтому спрашивать «Какой формат лучше?» не совсем правильно. Сначала нужно понять, кто получит информацию, что с ней будут делать, какие данные необходимо сохранить и как потом проверить результат передачи. Иначе экспорт легко превращается в формальность: файл сформировали, отправили, галочку поставили — а что именно дошло до следующего участника процесса, уже никто не знает)))


Коллеги, хочу провести небольшое исследование.

Какая повторяющаяся задача в проектировании, BIM, сметах или строительстве сильнее всего отнимает у вас время?


Интересует не глобальное «всё автоматизировать», а конкретный процесс:

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

Например:
получили несколько файлов 🔽
сверили 🔽
пересчитали 🔽
собрали таблицу 🔽
подготовили отчёт.

Пишите в комментариях. Можно написать мне лично, если не хочется раскрывать внутренние процессы. Самые частые и жизнеспособные задачи разберём отдельно — возможно, одну из них действительно превратим в нормальный рабочий продукт. @elvax


Небольшое напоминание для тех, кто работает с АГР по московской программе реновации.

С 3 августа 2026 года заканчивается переходный период: ЦИМ АГР в формате IFC станет обязательной и для объектов реновации. Для остальных объектов это требование действует ещё со 2 апреля.


Информация появилась ещё в начале июня, но дата уже близко, поэтому стоит напомнить.

Одного буклета и визуализаций теперь недостаточно. Потребуется IFC-модель с необходимой структурой и атрибутами, а показатели должны совпадать в модели, XML и буклете АГР.

Следующее важное изменение запланировано на 30 сентября 2026 года. В Москве начнёт действовать новый порядок согласования АГР через Архитектурную комиссию. После одобрения материалов свидетельство будет формироваться автоматически, без подачи отдельного заявления.

Если подготовка IFC для АГР ещё не началась, времени осталось немного.


Видео недоступно для предпросмотра
Смотреть в Telegram
Уже было такое?)) 🍻


СУИД — зачем он вообще нужен?

Последнее время всё чаще слышу про СУИД, но, кажется, многие до сих пор не понимают, для чего он нужен.

Если совсем просто, идея СУИД — собрать информацию об объекте в одном месте и обеспечить её сопровождение на протяжении всего жизненного цикла. Чтобы участники работали не с десятками разрозненных файлов, а с единым источником актуальных данных.


Звучит логично. Но возникает другой вопрос.

А что будет, если сами данные изначально плохие?

Если информационная модель заполнена формально, параметры отсутствуют, классификаторы используются как попало, а IFC экспортируется только ради прохождения проверки — никакая система не сможет превратить это в качественную информацию.

СУИД не создаёт данные. Он лишь помогает ими управлять.

Поэтому, как мне кажется, главная задача отрасли сегодня — не внедрить очередную информационную систему.

Главная задача — научиться создавать модели, которым действительно можно доверять.

Иначе получится цифровизация ради цифровизации.


💰 Почему 5D в России всё ещё не работает нормально?

5D в России звучит красиво уже много лет: модель, объёмы, смета, деньги, контроль изменений. Казалось бы, вот оно будущее. Но на практике всё часто выглядит иначе: ТИМ отдельно, смета отдельно, Excel где-то рядом, а сметчик всё равно пересчитывает объёмы вручную.


❓ Почему так? Потому что 5D начинается не в сметной программе. 5D начинается в модели.

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

И проблема не только в софте. Проблема в самом процессе. Проектировщик делает модель «чтобы сдать», ТИМ-специалист пытается привести её в порядок, сметчик не доверяет данным, а заказчик хочет кнопку «Посчитать всё». Но кнопка не заработает, если модель изначально не готова.

⭕️ Именно поэтому мы уделяем особое внимание проектированию. Наши специалисты создают информационные модели с нуля, а не просто переводят готовые DWG-чертежи в 3D. Такой подход позволяет сразу заложить правильную структуру, параметры и данные.

⭕️ Когда модель создаётся правильно с самого начала, она становится не просто красивой картинкой, а полноценным источником информации. А значит, появляется реальная возможность построить настоящий 5D.

И, кажется, совсем скоро мы сможем показать это на практике.

Показано 20 последних публикаций.