Способы связки чертежей с моделями в IFC.

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

И раз уж решили идти по этому пути, то сразу надо подумать наперед о том, как:
1️⃣ обеспечить единовременную выгрузку модели и листов чертежей из САПР;
2️⃣ связать 2D-объекты на чертежах с элементами модели;
3️⃣ связать табличные данные (ведомости и спецификации) с элементами модели;
4️⃣ обеспечить возможность просмотра видов (разрезов, сечений) в пространстве модели вместе с аннотациями и штриховками чертежа.

🔍 Способ 1. Связь IFC и SVG
По этому пути двигается Bonsai (ex. BlenderBIM). Виды и аннотации создаются в редакторе, сохраняются в IFC. Сам лист чертежа оформляется и экспортируется в популярный векторный формат SVG с XML-разметкой, где 2D-объекты имеют IfcGUID для связи с элементами модели. И тут каждый SVG-файл - это отдельный лист чертежа. Из минусов: не решена проблемы 1 и 4.

🔍 Способ 2. Связь IFC и XPS
Формат XPS создавался как замена PDF, но с XML-разметкой, и в этом его главный плюс. Спецификация формата зарегистрирована как открытый международный стандарт. В отличие от SVG имеет постраничную структуру, как и PDF, и может содержать в одном файле множество листов чертежей. Связь между моделью и чертежом также реализуется с помощью IfcGUID. Старый формат DWFx от Autodesk был реализован на базе XPS.
Выгрузка чертежей в XPS есть у Renga, правда IfcGUIDов мне в нем найти не удалось.

У первых двух способов важно, чтобы САПР сохранял виды/разрезы в IFC. Не каждое ПО это умеет. Но почти каждое умеет работать с отчетами в BCF, а значит:

🔍 Способ 3. Связь IFC и BCF
Идея принадлежит Игорю Шерстенникову: настраиваются нужные виды с координатами камеры и ракурсом и выгружаются в BCF, который может содержать скриншот чертежа. Понадобится только автоматически наложить аннотации на каждом виде и смотреть их в пространстве модели. Но тут возникают доп вопросы, как будут созданы аннотации в IFC? Подход сейчас проходит апробацию и есть первые результаты. Этот способ подразумевает уход от оформления листов, а это рождает описанные ранее проблемы.

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

👥 @IFC_ru
👥 @IFC_club

BIM-форум: поговорим про чертежи и модели

Завтра приму участие в Круглом столе «ЦИМ как отказ от чертежей: все «за» и все «против».

Тема стара как мир, но вновь и вновь всплывает в BIM-среде. Для нее были поводы и у нас на канале:

🟡 XML-бомба, способная изменить всё!
🔵 BIM-среда: «Экспертиза без чертежей: ожидания и реальность» (гость: Сергей Сербин) и наше мнение о пилоте
🟣 Как совместить модель в IFC с чертежами
🔴 Связка IFC и чертежей: проблема целостности данных
🟢 Способы связки чертежей и модели в IFC

Завтра обсудим эту важную и сложную тему с разных сторон. До встречи!

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

На прошедшем XI BIM-Форуме команда Института системного программирования РАН представила технологический стек, меняющий подход к цифровой нормативной базе. Их цель - это полная автоматизация цепочки:

НОРМАТИВ (текст) ➡️ OWL-ОНТОЛОГИЯ ➡️ SPARQL/SWRL-ПРАВИЛА ➡️ IDS++ ➡️ АВТОПРОВЕРКА IFC

Текст нормативов предлагается сначала переводить в виде OWL-онтологии (машинопонятный "словарь"). Далее с помощью SPARQL (язык запросов) и SWRL (язык логических правил) они трансформируются в спецификации IDS/IDS++ для проверки IFC-моделей.

Таким образом, от пункта норматива появляется сквозная прослеживаемость к правилу SWRL, его формализованному представлению в IDS++ и далее (после валидации) к замечанию в BCF. Важно, что система будет проводить семантическую проверку, то есть "понимать" и обращаться не только к атрибутам модели, но и контексту, отношениям и геометрии.

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

👥 @IFC_ru
👥 @IFC_club

Предновогодний прогон всех постов канала через ИИ (+статистика от TGStat)

В дополнение к статистике от ТGStat пропустили через ИИ все посты нашего канала. И вот что он сказал:

В лидерах по темам в 2025 году оказались:
1. Цифровые требования (IDS) и их развитие – 14 постов
2. Критика и разбор нормативных документов – 11 постов и упоминаний
3. Разбор ТЗ на ЦИМ (серия постов) – 10 постов и упоминаний
4. Инструменты для работы с IFC – 9 постов и упоминаний
5. IFC-структура, классы и связи – 8 постов
6. Интеграция ИИ и IFC – 7 постов
7. OpenBIM и открытые стандарты – 6 постов
8. Связь чертежей и IFC-моделей – 5 постов и упоминаний
9. Обучение и курсы – 4 поста
10. Инфраструктурные объекты и IFC – 4 поста
11. Прочие темы – 5 постов

💻 Самый популярный пост 💻

Вывод от ИИ:

2025 год стал годом цифровых требований (IDS) и глубокого анализа нормативной базы. Канал активно продвигал переход от «бумажных» стандартов к машиночитаемым форматам, критиковал противоречия в документах Минстроя и показывал практические инструменты для работы с IFC.

Главный месседж канала 2025 года по версии DeepSeek:

«IFC — это не просто формат обмена геометрией, а онтология для управления данными на всём жизненном цикле. Цифровые требования (IDS) и открытые стандарты — основа цифровой зрелости отрасли.»

Всех с Наступающим!

🎄 @IFC_ru
🎄 @IFC_club

СОДЕРЖАНИЕ 2025

1. Проблемы излишней стандартизации имен файлов моделей
2. "Формат RVT - это де-факто стандарт отрасли"
3. Bonsai - еще не САПР, но больше, чем САПР
4. Как посмотреть структуру IFC-файла
5. DeepSeek и IFC. Пример запроса
6. Как подружить элементы и документы в IFC
7. Проверка IFC моделей по требованиям IDS (статья)
8. Связи BIM-стандартов ISO
9. Тестируем выгрузку стен из Revit
10. Обзор библиотек для просмотра IFC в веб-приложениях
11. Машинно-интерпретируемые требования: иллюзия или реальность?
12. Интероперабельность. Роль заказчика и разработчика ПО
13. Альтернативная классификация. Что делать, если не хватает классов IFC?
14. Встреча с Аллой Землянской. О цифровых требованиях IDS
15. Проект приказа Минстроя о составе ЦИМ в IDS
16. Что нового в Revit 2026 в части IFC
17. Завершился 10-ый курс по ТИМ
18. ИИ-классификация элементов на основе геометрии в Qonic
19. IfcBuildingElementProxy: удобный костыль или скрытая проблема?
20. IfcBuildingElementProxy: причины (зло)употребления
21. IfcBuildingElementProxy: как классифицировать элементы и расширить классификацию
22. 7D Modeler 1.5: новый релиз!
23. Список MVD для IFC4x3 дополнен
24. О новых типах объектов в IFC4x3
25. Открытый веб-валидатор IFC
26. 10 шагов по созданию корпоративного стандарта на базе IFC
27. О вариантах структуры IFC-проекта
28. Автоматизированный перевод IDS-требований в атрибуты ЦИМ
29. Топоматик 360 с крутыми возможностями!
30. Разбираем ТЗ на ЦИМ - 1. О классификации
31. Разбираем ТЗ на ЦИМ - 2. О делении модели на разделы
32. 1-ое место в ТИМ-лидерах!
33. О делении составных элементов на части
34. Разбираем ТЗ на ЦИМ - 3. Об информационном наполнении элементов
35. Разбираем ТЗ на ЦИМ - 4. О несоответствии атрибутивного состава целям моделирования
36. 1000 подписчиков!
37. Всё, что нужно знать про IFC5
38. Разбираем ТЗ на ЦИМ - 5. Проблема LOD
39. ПНСТ 909-2024 "Жилые здания" в IDS!
40. Разбираем ТЗ на ЦИМ - 6. О матрице коллизий
41. Цикл постов с разборами ТЗ на ЦИМ
42. Еще раз о проекте приказа Минстроя о составе ЦИМ (презентация)
43. Выгрузка в IFC из Revit. Без Revit
44. Структура в инфраструктуре
45. Атрибутивка из требований прямо в IFC - это реально. Без нативных форматов
46. Как совместить IFC-модель с чертежами
47. Связка IFC и чертежей: проблема целостности данных
48. IfcCheckingTool_Lite - инструмент проверки семантической и синтаксической корректности IFC
49. Способы связки чертежей с моделями в IFC
50. Ежегодный форум РосТИМ 2025
51. Перевод реестра требований в цифровой вид. Презентация ИСП РАН
52. Предновогодний анализ постов через ИИ

Проверь себя в IFC:
Вопрос №1
Вопрос №2
Вопрос №3
Вопрос №4
Вопрос №5
Вопрос №6
Вопрос №7
Вопрос №8
Вопрос №9
Вопрос №10
Вопрос №11
Вопрос №12
Вопрос №13
Вопрос №14

Подкасты "BIM-среда" на Youtube 📹 | Rutube 📺

👥 @IFC_ru
👥 @IFC_club

СОДЕРЖАНИЕ 2026 (обновляется)

1. Коллизии. Новый взгляд? + иерархия коллизий
2. Коллизии. Новый взгляд? Дополнение.
3.
4.
5.
6.
7.

Подкасты "BIM-среда" на Youtube 📹 | Rutube 📺

👥 @IFC_ru
👥 @IFC_club

Коллизии. Новый взгляд?

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

А во времена BIM-стандартов от вендоров предлагалось что-то странное: жесткие коллизии, мягкие, газообразные… Это аналогично 4D, 5D, 6D, 7D. Проблема в том, что пока не посмотришь, что это значит, не поймешь, о чем речь. В результате - недопонимание и проблемы в коммуникации.

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

🔍 В приложенном ниже файле я предложил структуру типов коллизий/дефектов, выявляемых в результате верификации и валидации. Коллизии представлены шире, чем только геометрические. На истину не претендую, просто предложение.

🔹 При верификации выявляются дефекты в синтаксисе и семантике набора данных (файла IFC, XML-документа и т.д.). Например, в IFC-файле обнаружен GUID, начинающий с буквы, хотя по правилам в IFC он должен начинаться с цифры.
🔹 При валидации проверяем данные на различные семантические требования (в том числе высокого уровня: нормативные требования).

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

👥 @IFC_ru
👥 @IFC_club