Всё про IFC
15.04.202505:51
ИИ-классификация элементов на основе геометрии в Qonic
BIM-платформа Qonic анонсировала разработку ИИ-помощника, который будет предлагать подходящий класс IFC для неклассифицированных элементов в моделях. По заверениям разработчиков определять класс он будет на основе анализа геометрии элемента и контекста (то есть его места в структуре модели).
Кроме того, Qonic умеет редактировать геометрию, исправлять классы, добавлять/править свойства элементов и сохранять в IFC.
👥 @IFC_ru
👥 @IFC_club
BIM-платформа Qonic анонсировала разработку ИИ-помощника, который будет предлагать подходящий класс IFC для неклассифицированных элементов в моделях. По заверениям разработчиков определять класс он будет на основе анализа геометрии элемента и контекста (то есть его места в структуре модели).
Кроме того, Qonic умеет редактировать геометрию, исправлять классы, добавлять/править свойства элементов и сохранять в IFC.
👥 @IFC_ru
👥 @IFC_club
02.04.202509:11
Проект приказа Минстроя о составе ЦИМ в IDS!
На публичное обсуждение размещен проект приказа Минстроя России об утверждении состава ЦИМ на этапе проектирования.
И многие уже успели его обсудить. Но мы решили на этом не останавливаться и сделали по этому проекту IDS-требования (по таблице 1).
Помимо того, что проект приказа требует изменений в формулировках, также нужны уточнения в самих таблицах.
Так, для элементов инженерных систем введены слишком обобщенные понятия (например, «Оборудование»). В результате не совсем понятно, что конкретно в них входит.
С точки зрения целей применимости ЦИМ на этапе проектирования к проекту приказа есть вопросы, но в техническом плане он вполне выполним (после ряда доработок).
👥 @IFC_ru
👥 @IFC_club
На публичное обсуждение размещен проект приказа Минстроя России об утверждении состава ЦИМ на этапе проектирования.
И многие уже успели его обсудить. Но мы решили на этом не останавливаться и сделали по этому проекту IDS-требования (по таблице 1).
Помимо того, что проект приказа требует изменений в формулировках, также нужны уточнения в самих таблицах.
Так, для элементов инженерных систем введены слишком обобщенные понятия (например, «Оборудование»). В результате не совсем понятно, что конкретно в них входит.
С точки зрения целей применимости ЦИМ на этапе проектирования к проекту приказа есть вопросы, но в техническом плане он вполне выполним (после ряда доработок).
👥 @IFC_ru
👥 @IFC_club
20.03.202514:36
Интероперабельность. Роль заказчика и разработчика ПО
Добавим немного мыслей к цитатам из поста Дмитрия Чубрика об интероперабельности.
Это осознали только те, кто давно работает с BIM. Сегодня заказчики, особенно государственные - это наиболее "просевшее" звено. И связано это с тем, что они до сих пор не могут сформулировать свои потребности, исходя из которых формулировались бы требования.
Заказчик должен играть ключевую роль в установлении требований к данным. Однако сегодня мы имеем немного другую ситуацию:
- BIM-стандарты и ТЗ на модель зачастую пишут сами проектировщики;
- требования к форматам и классификации - в постановлениях Правительства;
- а проверки на коллизии - дело экспертизы.
Заказчик в этом процессе как-то затерялся.
+1.
При этом разработчики ПО, не развивая интероперабельность на базе OpenBIM-стандартов, делают хуже не только пользователю, но и себе, так как потребность в стандартизации данных будет расти и дальше. А плохая поддержка открытых стандартов уже давно воспринимается как большой недостаток такого ПО.
По итогу мы имеем конфликт интересов.
Разработчики - хотят оставить пользователя в своей экосистеме.
Заказчики (если они уже работают с BIM) - хотят иметь долгосрочный доступ к данным и на перспективу не зависеть от одного ПО.
Проектировщики - хотят минимизировать трудозатраты с жесткими дедлайнами.
Разрешить этот конфликт можно целым комплексом мер, в частности, усилением регуляторного давления и крупных заказчиков с целью качественного использования открытых стандартов передачи данных (например, путем сертификации ПО).
👥 @IFC_ru
👥 @IFC_club
Добавим немного мыслей к цитатам из поста Дмитрия Чубрика об интероперабельности.
Важность открытых форматов большинство заказчиков осознало несколько лет назад, когда Autodesk ушел
Это осознали только те, кто давно работает с BIM. Сегодня заказчики, особенно государственные - это наиболее "просевшее" звено. И связано это с тем, что они до сих пор не могут сформулировать свои потребности, исходя из которых формулировались бы требования.
Заказчик должен играть ключевую роль в установлении требований к данным. Однако сегодня мы имеем немного другую ситуацию:
- BIM-стандарты и ТЗ на модель зачастую пишут сами проектировщики;
- требования к форматам и классификации - в постановлениях Правительства;
- а проверки на коллизии - дело экспертизы.
Заказчик в этом процессе как-то затерялся.
интероперабельность данных очень важна. Но она базируется на стандартах, а стандарты часто идут вразрез с интересами разработчиков ПО.
+1.
При этом разработчики ПО, не развивая интероперабельность на базе OpenBIM-стандартов, делают хуже не только пользователю, но и себе, так как потребность в стандартизации данных будет расти и дальше. А плохая поддержка открытых стандартов уже давно воспринимается как большой недостаток такого ПО.
По итогу мы имеем конфликт интересов.
Разработчики - хотят оставить пользователя в своей экосистеме.
Заказчики (если они уже работают с BIM) - хотят иметь долгосрочный доступ к данным и на перспективу не зависеть от одного ПО.
Проектировщики - хотят минимизировать трудозатраты с жесткими дедлайнами.
Разрешить этот конфликт можно целым комплексом мер, в частности, усилением регуляторного давления и крупных заказчиков с целью качественного использования открытых стандартов передачи данных (например, путем сертификации ПО).
👥 @IFC_ru
👥 @IFC_club
04.03.202515:12
Связи BIM-стандартов ISO
Комитет по моделированию и стандартам EC3 связал воедино все ISO-стандарты по информационным технологиям в строительстве.
Стандарты отбираются фильтрами. А при нажатии на кнопку Relationships отображаются все связи между этими стандартами.
Полезный и нужный труд.
https://ec-3.org/BIM-Standards-Landscape-Explorer.html
👥 @IFC_ru
👥 @IFC_club
Комитет по моделированию и стандартам EC3 связал воедино все ISO-стандарты по информационным технологиям в строительстве.
Стандарты отбираются фильтрами. А при нажатии на кнопку Relationships отображаются все связи между этими стандартами.
Полезный и нужный труд.
https://ec-3.org/BIM-Standards-Landscape-Explorer.html
👥 @IFC_ru
👥 @IFC_club
04.02.202511:56
Как посмотреть структуру IFC-файла
🛑 GeometryGym IFC Tree Viewer (скрин 1) - легкий и быстрый просмотрщик "дерева" IFC-файла с показом наименования атрибутов.
🛑 IfcQuickViewer (скрин 2) - еще один простой и надежный просмотрщик структуры IFC-файлов, которому уже более 20 лет. С его помощью можно отследить связи элемента с другими.
🛑 KITModelViewer (скрин 3) - мощный, но порой вылетающий, немецкий вьюер. Плюсом является то, что можно увидеть STEP-структуру элемента вместе с иерархией, геометрией, свойствами и связями.
🛑Open IFC Viewer (скрин 4) - недоступный без VPN вьюер от ODA с хорошим функционалом по просмотру структуры файла.
Ну и конечно же старый добрый Notepad++ с предварительной настройкой подсветки IFC-синтаксиса. Без подсветки совсем грустно.
Каждый из них по-своему хорош и бывает нужен для разных задач. Поэтому лучше установить их все.
👥 @IFC_ru
👥 @IFC_club
🛑 GeometryGym IFC Tree Viewer (скрин 1) - легкий и быстрый просмотрщик "дерева" IFC-файла с показом наименования атрибутов.
🛑 IfcQuickViewer (скрин 2) - еще один простой и надежный просмотрщик структуры IFC-файлов, которому уже более 20 лет. С его помощью можно отследить связи элемента с другими.
🛑 KITModelViewer (скрин 3) - мощный, но порой вылетающий, немецкий вьюер. Плюсом является то, что можно увидеть STEP-структуру элемента вместе с иерархией, геометрией, свойствами и связями.
🛑
Ну и конечно же старый добрый Notepad++ с предварительной настройкой подсветки IFC-синтаксиса. Без подсветки совсем грустно.
Каждый из них по-своему хорош и бывает нужен для разных задач. Поэтому лучше установить их все.
👥 @IFC_ru
👥 @IFC_club
15.01.202506:36
Проблемы излишней стандартизации имен файлов моделей
«Мода» стандартизовать имена файлов модели появилась давно, во времена BIM-стандартов от вендоров и PAS 1192. Затем ее подхватили девелоперы. Но в основную редакцию ISO 19650 правила именования файлов не вошли.
В России апогеем этой тенденции стал СП333 2020 года, доведя этот процесс до абсурда.
В результате использования такого подхода:
➖ "правильно" называть файл будет занимать больше времени, чем создание его содержимого.
➖ даже если файл назван правильно, его имя настолько сложное, что это сводит на нет любую эффективность.
➖ смещается фокус с самой сути проекта, что только добавляют сложности, но не решают проблем.
Сегодня открытые данные приобретают все большую значимость, и излишнее кодирование имен файлов теряет смысл.
Однако требования к именам все же необходимы, но они должны быть адекватными:
✅ Краткость и ясность. Имена должны иметь очень простой формат, интерпетируемый и понятный человеку, с минимальным делением на блоки.
✅ Использование метаданных. Добавление атрибутов ключ/значение в виде метаданных к файлу позволяет системе управления файлами с контролем версий работать эффективнее.
✅ Использование информации в IFC. Большая часть информации уже содержится в структуре файла (например, версия IFC, IfcPerson, IfcOrganization, IfcApplication и т.д.). Данные в IFC открыты, и извлечь их не составит труда.
✅ Стабильность имен. Имя файла не должно содержать полей, которые постоянно меняются. Это избавит от излишней рутины и необходимости гадать, какой файл является актуальным.
✅ Значимость блоков. Необходимо упорядочивать структуру имени, начиная с наиболее значимых блоков. Так в них легче ориентироваться.
🔍 Стандартизация имен файлов важна, но она не должна становиться самоцелью.
📢 @ifc_ru
👥 @ifc_club
«Мода» стандартизовать имена файлов модели появилась давно, во времена BIM-стандартов от вендоров и PAS 1192. Затем ее подхватили девелоперы. Но в основную редакцию ISO 19650 правила именования файлов не вошли.
В России апогеем этой тенденции стал СП333 2020 года, доведя этот процесс до абсурда.
В результате использования такого подхода:
➖ "правильно" называть файл будет занимать больше времени, чем создание его содержимого.
➖ даже если файл назван правильно, его имя настолько сложное, что это сводит на нет любую эффективность.
➖ смещается фокус с самой сути проекта, что только добавляют сложности, но не решают проблем.
Сегодня открытые данные приобретают все большую значимость, и излишнее кодирование имен файлов теряет смысл.
Однако требования к именам все же необходимы, но они должны быть адекватными:
✅ Краткость и ясность. Имена должны иметь очень простой формат, интерпетируемый и понятный человеку, с минимальным делением на блоки.
✅ Использование метаданных. Добавление атрибутов ключ/значение в виде метаданных к файлу позволяет системе управления файлами с контролем версий работать эффективнее.
✅ Использование информации в IFC. Большая часть информации уже содержится в структуре файла (например, версия IFC, IfcPerson, IfcOrganization, IfcApplication и т.д.). Данные в IFC открыты, и извлечь их не составит труда.
✅ Стабильность имен. Имя файла не должно содержать полей, которые постоянно меняются. Это избавит от излишней рутины и необходимости гадать, какой файл является актуальным.
✅ Значимость блоков. Необходимо упорядочивать структуру имени, начиная с наиболее значимых блоков. Так в них легче ориентироваться.
🔍 Стандартизация имен файлов важна, но она не должна становиться самоцелью.
📢 @ifc_ru
👥 @ifc_club
11.04.202516:29
Сегодня завершился десятый (!) курс по технологиям информационного моделирования.
Спасибо всем, кто был с нами: «Росатому» и другим организациям за неудобные вопросы, споры и за то, что делились своим опытом. Для нас курс стал еще одной ступенькой в развитии.
Мы старались сделать курс максимально честным и детальным: разобрали BIM-подходы в мировом контексте, в российской практике, в экспертизе и даже в узких отраслевых нюансах. От Градкодекса до коллизий в IFC.
С 2021 года курс прилично «прокачался»:
🔹 добавили больше материала про работу с IFC и создание цифровых требований;
🔹 сместились акценты в сторону работы с заказчиком и правильному составлению ТЗ на модель.
Особая благодарность Ольге Кутузовой (@Kutuzova_O, NSR-Specification) и Николаю Самопалу (@NS_BIM, Wizardsoft) - на ваших лекциях мы тоже учимся.
👥 @IFC_ru
👥 @IFC_club
Спасибо всем, кто был с нами: «Росатому» и другим организациям за неудобные вопросы, споры и за то, что делились своим опытом. Для нас курс стал еще одной ступенькой в развитии.
Мы старались сделать курс максимально честным и детальным: разобрали BIM-подходы в мировом контексте, в российской практике, в экспертизе и даже в узких отраслевых нюансах. От Градкодекса до коллизий в IFC.
С 2021 года курс прилично «прокачался»:
🔹 добавили больше материала про работу с IFC и создание цифровых требований;
🔹 сместились акценты в сторону работы с заказчиком и правильному составлению ТЗ на модель.
Особая благодарность Ольге Кутузовой (@Kutuzova_O, NSR-Specification) и Николаю Самопалу (@NS_BIM, Wizardsoft) - на ваших лекциях мы тоже учимся.
👥 @IFC_ru
👥 @IFC_club
31.03.202509:50
Ежемесячный подкаст "BIM-среда" в IFC Клубе!
В группе мы часто репостим классные кейсы с канала MARKS DIGITAL. Коллеги хорошо продвинулись в использовании разных ПО. В эту среду автор канала у нас в гостях!
🗓️ Среда, 2 апреля, в 16-00 МСК
🔊 Тема: "Без права на ошибку: Транспортная инфраструктура в IFC"
Гость:
👤 Филипп Сергеев, Руководитель MARKS DIGITAL, заместитель генерального директора по цифровым технологиям MARKS GROUP
Поговорим о:
🛑особенностях проектирования объектов инфраструктуры;
🛑опыте прохождения экспертиз с моделями в IFC 👀;
🛑экспорте в IFC из Rhino;
🛑применении Bonsai / BlenderBIM для решения нетривиальных задач по доработке IFC-файлов ⚡️;
🛑использовании BCF для обмена замечаниями;
🛑проверках модели по IDS-требованиям без bonsai;
🛑и много другом!
Присоединяйтесь!
Встреча будет проходить в группе в формате видео-чата.
👥 @IFC_ru
👥 @IFC_club
В группе мы часто репостим классные кейсы с канала MARKS DIGITAL. Коллеги хорошо продвинулись в использовании разных ПО. В эту среду автор канала у нас в гостях!
🗓️ Среда, 2 апреля, в 16-00 МСК
🔊 Тема: "Без права на ошибку: Транспортная инфраструктура в IFC"
Гость:
👤 Филипп Сергеев, Руководитель MARKS DIGITAL, заместитель генерального директора по цифровым технологиям MARKS GROUP
Поговорим о:
🛑особенностях проектирования объектов инфраструктуры;
🛑опыте прохождения экспертиз с моделями в IFC 👀;
🛑экспорте в IFC из Rhino;
🛑применении Bonsai / BlenderBIM для решения нетривиальных задач по доработке IFC-файлов ⚡️;
🛑использовании BCF для обмена замечаниями;
🛑проверках модели по IDS-требованиям без bonsai;
🛑и много другом!
Присоединяйтесь!
Встреча будет проходить в группе в формате видео-чата.
👥 @IFC_ru
👥 @IFC_club
17.03.202509:56
Машинно-интерпретируемые требования: иллюзия или реальность?
Рассмотрим схему:
1. Определили цифровые требования в IDS.
2. Создали модель в IFC.
3. Сформировали отчет об ошибках в BCF.
4. Отправили данные через openCDE.
Мы часто слышим о машинно-интерпретируемых требованиях, открытых стандартах и цифровой трансформации. Но что, если это лишь верхушка айсберга? Что, если за красивыми слайдами скрывается проблема, которую предпочитают игнорировать?
На этой картинке нас смущает пункт 3 и отсутствие еще одного важного шага между 2 и 3.
🔍 Отчет в BCF - это не проверка, а лишь отчет о проверке.
Это не check, а report. И в этом кроется ключевая ошибка. Где же сам механизм проверки? Где открытые алгоритмы, которые должны лежать в основе этой системы?
Что мы имеем на текущий момент:
🛑 IDS-стандарт и его дальнейшее развитие призвано формализовать требования к информации в машинном виде.
При этом алгоритмы проверки файла на соответствие IDS находится вне файла требований, а на стороне вьюверов и чекеров.
Вопрос "подкапотной обработки" модели на соответствие требованиям решают OpenSource-проекты, наиболее известный из них - IfcOpenShell.
🛑 В России формируется реестр требований, который к 2026 году планируют перевести в машинно-интерпретируемую форму, использовав для этого разметку на базе КСИ.
При этом мы не видим ни активного движения в сторону апробации формируемых требований, ни верификационных примеров, ни открытых алгоритмов, которые бы помогли другим разработчикам ЕДИНООБРАЗНО интерпретировать и проводить проверку.
Это значит, что разработка алгоритмов проверки - это отдельная, большая задача. И она требует не только технической экспертизы, но и гарантий правильности их работы.
🔍Реестр цифровых нормативных требований - это только начало.
Следующий шаг - это создание алгоритмов проверки. Ведь мы собираемся передать машине функции, которые раньше выполнял человек. А значит, должны быть на 100% уверены в корректности этих алгоритмов.
🔍Представьте масштаб работы:
Создателям реестра предстоит не только описать требования, но и разработать, протестировать и внедрить алгоритмы проверки. Это приличный пласт работы, требующий больших усилий.
🔍 Подытожим:
Без открытых алгоритмов проверки вся система машинно-интерпретируемых требований останется неполной, а значит - нерабочей.
✈️ Ну и вопрос "на засыпку", готовы ли мы к такому уровню цифровизации? Или нам еще рано говорить о полной автоматизации проверок?
📢 @IFC_ru
👥 @IFC_club
Рассмотрим схему:
1. Определили цифровые требования в IDS.
2. Создали модель в IFC.
3. Сформировали отчет об ошибках в BCF.
4. Отправили данные через openCDE.
Мы часто слышим о машинно-интерпретируемых требованиях, открытых стандартах и цифровой трансформации. Но что, если это лишь верхушка айсберга? Что, если за красивыми слайдами скрывается проблема, которую предпочитают игнорировать?
На этой картинке нас смущает пункт 3 и отсутствие еще одного важного шага между 2 и 3.
🔍 Отчет в BCF - это не проверка, а лишь отчет о проверке.
Это не check, а report. И в этом кроется ключевая ошибка. Где же сам механизм проверки? Где открытые алгоритмы, которые должны лежать в основе этой системы?
Что мы имеем на текущий момент:
🛑 IDS-стандарт и его дальнейшее развитие призвано формализовать требования к информации в машинном виде.
При этом алгоритмы проверки файла на соответствие IDS находится вне файла требований, а на стороне вьюверов и чекеров.
Вопрос "подкапотной обработки" модели на соответствие требованиям решают OpenSource-проекты, наиболее известный из них - IfcOpenShell.
🛑 В России формируется реестр требований, который к 2026 году планируют перевести в машинно-интерпретируемую форму, использовав для этого разметку на базе КСИ.
При этом мы не видим ни активного движения в сторону апробации формируемых требований, ни верификационных примеров, ни открытых алгоритмов, которые бы помогли другим разработчикам ЕДИНООБРАЗНО интерпретировать и проводить проверку.
Это значит, что разработка алгоритмов проверки - это отдельная, большая задача. И она требует не только технической экспертизы, но и гарантий правильности их работы.
🔍Реестр цифровых нормативных требований - это только начало.
Следующий шаг - это создание алгоритмов проверки. Ведь мы собираемся передать машине функции, которые раньше выполнял человек. А значит, должны быть на 100% уверены в корректности этих алгоритмов.
🔍Представьте масштаб работы:
Создателям реестра предстоит не только описать требования, но и разработать, протестировать и внедрить алгоритмы проверки. Это приличный пласт работы, требующий больших усилий.
🔍 Подытожим:
Без открытых алгоритмов проверки вся система машинно-интерпретируемых требований останется неполной, а значит - нерабочей.
✈️ Ну и вопрос "на засыпку", готовы ли мы к такому уровню цифровизации? Или нам еще рано говорить о полной автоматизации проверок?
📢 @IFC_ru
👥 @IFC_club
20.02.202505:36
Проверка IFC моделей по требованиям IDS
На Хабре вышла хорошая обзорная статья от Ильи Савельева по работе с IDS-требованиями, с полезными ссылками и практическими кейсами на Python и библиотеки ifcopenshell.
Добавляем в закладки.
👥 @IFC_ru
👥 @IFC_club
На Хабре вышла хорошая обзорная статья от Ильи Савельева по работе с IDS-требованиями, с полезными ссылками и практическими кейсами на Python и библиотеки ifcopenshell.
Добавляем в закладки.
👥 @IFC_ru
👥 @IFC_club
03.02.202509:31
Ежемесячный подкаст "BIM-среда" в IFC Клубе!
Помните крутой доклад на BIM-форуме про BIM-менеджмент и IDS? В эту среду мы поговорим подробнее, что к чему и почему.
🗓️ Среда, 5 февраля, в 16-00 МСК
🔊 Тема: "OpenSource, IFC и IDS в управлении проектами"
Гость:
👤 Антон Мотовилов, Руководитель отдела цифровизации и технологий информационного моделирования, ООО «Желдорпроект»
Поговорим о:
🛑управлении процессами по информационному моделированию с помощью инструментов на открытом исходном коде;
🛑управлении требованиями к IFC-моделям с использованием OpenSource-решений;
🛑разработках в части автоматизации проверок моделей;
🛑и перспективах применения такого подхода.
Присоединяйтесь!
Встреча будет проходить в группе в формате видео-чата.
👥 @IFC_ru
👥 @IFC_club
Помните крутой доклад на BIM-форуме про BIM-менеджмент и IDS? В эту среду мы поговорим подробнее, что к чему и почему.
🗓️ Среда, 5 февраля, в 16-00 МСК
🔊 Тема: "OpenSource, IFC и IDS в управлении проектами"
Гость:
👤 Антон Мотовилов, Руководитель отдела цифровизации и технологий информационного моделирования, ООО «Желдорпроект»
Поговорим о:
🛑управлении процессами по информационному моделированию с помощью инструментов на открытом исходном коде;
🛑управлении требованиями к IFC-моделям с использованием OpenSource-решений;
🛑разработках в части автоматизации проверок моделей;
🛑и перспективах применения такого подхода.
Присоединяйтесь!
Встреча будет проходить в группе в формате видео-чата.
👥 @IFC_ru
👥 @IFC_club
24.11.202415:30
Как выгрузить связанные файлы Revit в один IFC
Пользователи Revit часто задают вопрос, можно ли выгружать связанные файлы Revit в общий IFC-файл?
Ответ: можно, но есть нюанс.
1️⃣ Общий IFC-файл следует создавать, только если:
🔹 нужно экспортировать два и более объекта/здания/секции (IfcBuilding), расположенных на одном участке (IfcSite);
🔹 имеем два и более объекта на разных участках.
Это также могут быть здания окружающей застройки, смежные корпуса и так далее.
2️⃣ Создавать общий IFC-файл из связанных смежных разделов в рамках одного проекта не совсем корректно с точки зрения структуры IFC-проекта, хотя и возможно. Потому как в таком случае мы получаем несколько IfcBuilding, наполненных элементами разных дисциплин, но по факту здание всего одно.
👥 @IFC_ru
👥 @IFC_club
Пользователи Revit часто задают вопрос, можно ли выгружать связанные файлы Revit в общий IFC-файл?
Ответ: можно, но есть нюанс.
1️⃣ Общий IFC-файл следует создавать, только если:
🔹 нужно экспортировать два и более объекта/здания/секции (IfcBuilding), расположенных на одном участке (IfcSite);
🔹 имеем два и более объекта на разных участках.
Это также могут быть здания окружающей застройки, смежные корпуса и так далее.
2️⃣ Создавать общий IFC-файл из связанных смежных разделов в рамках одного проекта не совсем корректно с точки зрения структуры IFC-проекта, хотя и возможно. Потому как в таком случае мы получаем несколько IfcBuilding, наполненных элементами разных дисциплин, но по факту здание всего одно.
👥 @IFC_ru
👥 @IFC_club
28.03.202511:52
Провели встречу с замечательным человеком, BIM-лидером отрасли в части инфраструктуры Аллой Землянской (Tangl).
Обсудили перспективы открытых стандартов передачи данных в отечественных ПО.
🔹 В части цифровых требований пришли к общему мнению, что это молодое направление еще предстоит освоить как вендорам, так и заказчикам. И начинать здесь надо с малого, с IDS :) то есть с цифровизации требований заказчика.
IDS пока не может формализовать сложные проверки на техрегламенты, но на данном этапе развития технологии этого и не требуется, потому что перепрыгнуть через кучу подводных камней и перейти к полной автоматизации нормативных проверок вряд ли удастся в ближайшей перспективе. Стандартизация должна предшествовать автоматизации.
🔹Также поговорили о передаче отчетов о коллизиях в BCF. Востребованность формата пока по большей части ограничивается госсектором и органами экспертиз. Но при обмене замечаниями через BCF-сервер, популярность его будет только расти. И такие разработки в России уже ведутся.
🔹И затронули перспективу перехода к IFC4x3, как более проработанному и развитому в части описания инфраструктурных объектов.
👥 @IFC_ru
👥 @IFC_club
Обсудили перспективы открытых стандартов передачи данных в отечественных ПО.
🔹 В части цифровых требований пришли к общему мнению, что это молодое направление еще предстоит освоить как вендорам, так и заказчикам. И начинать здесь надо с малого, с IDS :) то есть с цифровизации требований заказчика.
IDS пока не может формализовать сложные проверки на техрегламенты, но на данном этапе развития технологии этого и не требуется, потому что перепрыгнуть через кучу подводных камней и перейти к полной автоматизации нормативных проверок вряд ли удастся в ближайшей перспективе. Стандартизация должна предшествовать автоматизации.
🔹Также поговорили о передаче отчетов о коллизиях в BCF. Востребованность формата пока по большей части ограничивается госсектором и органами экспертиз. Но при обмене замечаниями через BCF-сервер, популярность его будет только расти. И такие разработки в России уже ведутся.
🔹И затронули перспективу перехода к IFC4x3, как более проработанному и развитому в части описания инфраструктурных объектов.
👥 @IFC_ru
👥 @IFC_club
14.03.202515:37
Обзор библиотек для просмотра IFC в веб-приложениях
Если вы планируете создавать веб-приложения для работы с моделями, важно не ошибиться с подходящей библиотекой для отображения IFC-файлов.
Коллеги из MARKS DIGITAL сделали подробный разбор популярных решений:
🔹Ifc.js (в настоящий момент развивается как That Open Company);
🔹Xbim;
🔹Xeokit.
Каждая библиотека имеет свои особенности, выбор зависит от задач проекта.
Подробнее в статье: читать
👥 @IFC_ru
👥 @IFC_club
Если вы планируете создавать веб-приложения для работы с моделями, важно не ошибиться с подходящей библиотекой для отображения IFC-файлов.
Коллеги из MARKS DIGITAL сделали подробный разбор популярных решений:
🔹Ifc.js (в настоящий момент развивается как That Open Company);
🔹Xbim;
🔹Xeokit.
Каждая библиотека имеет свои особенности, выбор зависит от задач проекта.
Подробнее в статье: читать
👥 @IFC_ru
👥 @IFC_club
11.02.202511:25
DeepSeek и IFC. Пример запроса
Запрос:
Ответ:
Для сопоставления работы "Устройство железобетонных колонн в деревянной опалубке высотой: до 6 м, периметром более 4 м" со схемой данных стандарта IFC (Industry Foundation Classes) версии IFC4_3, необходимо определить соответствующие классы и атрибуты, которые описывают процесс строительства железобетонных колонн с использованием деревянной опалубки.
Шаги для сопоставления:
Описание колонны:
Железобетонная колонна может быть описана с использованием класса IfcColumn, который представляет собой вертикальный строительный элемент.
Атрибуты:
Name: "Железобетонная колонна".
PredefinedType: COLUMN.
Height: 6 м (может быть указано в IfcPropertySingleValue).
Perimeter: более 4 м (также может быть указано в IfcPropertySingleValue).
Материал колонны:
Железобетон может быть описан с использованием класса IfcMaterial с атрибутом Name = "Железобетон".
Для уточнения свойств материала (например, марка бетона, класс арматуры) можно использовать IfcMaterialProperties.
Опалубка:
Деревянная опалубка может быть описана с использованием класса IfcConstructionMaterialResource, который представляет собой ресурс, используемый в строительстве.
Атрибуты:
Name: "Деревянная опалубка".
PredefinedType: FORMWORK.
Процесс устройства колонн:
Процесс устройства колонн может быть описан с использованием класса IfcTask, который представляет собой задачу или процесс.
Атрибуты:
Name: "Устройство железобетонных колонн в деревянной опалубке".
OperatesOn: ссылки на колонну (IfcColumn) и опалубку (IfcConstructionMaterialResource).
➕
В схеме IFC нет стандартного «периметра» для колонны, поэтому DeepSeek предложил пользовательское свойство Perimeter.
В случае с высотой DeepSeek не определил стандартный количественный показатель (quantity) Length как высоту колонны и также предложил ввести свойство Height.
Запрос:
Сопоставь работу со схемой данных стандарта IFC.
Используй только данные с ресурса https://standards.buildingsmart.org/IFC/RELEASE/IFC4_3/
Устройство железобетонных колонн в деревянной опалубке высотой:до 6 м, периметром более 4 м
Ответ:
Для сопоставления работы "Устройство железобетонных колонн в деревянной опалубке высотой: до 6 м, периметром более 4 м" со схемой данных стандарта IFC (Industry Foundation Classes) версии IFC4_3, необходимо определить соответствующие классы и атрибуты, которые описывают процесс строительства железобетонных колонн с использованием деревянной опалубки.
Шаги для сопоставления:
Описание колонны:
Железобетонная колонна может быть описана с использованием класса IfcColumn, который представляет собой вертикальный строительный элемент.
Атрибуты:
Name: "Железобетонная колонна".
PredefinedType: COLUMN.
Height: 6 м (может быть указано в IfcPropertySingleValue).
Perimeter: более 4 м (также может быть указано в IfcPropertySingleValue).
Материал колонны:
Железобетон может быть описан с использованием класса IfcMaterial с атрибутом Name = "Железобетон".
Для уточнения свойств материала (например, марка бетона, класс арматуры) можно использовать IfcMaterialProperties.
Опалубка:
Деревянная опалубка может быть описана с использованием класса IfcConstructionMaterialResource, который представляет собой ресурс, используемый в строительстве.
Атрибуты:
Name: "Деревянная опалубка".
PredefinedType: FORMWORK.
Процесс устройства колонн:
Процесс устройства колонн может быть описан с использованием класса IfcTask, который представляет собой задачу или процесс.
Атрибуты:
Name: "Устройство железобетонных колонн в деревянной опалубке".
OperatesOn: ссылки на колонну (IfcColumn) и опалубку (IfcConstructionMaterialResource).
➕
В схеме IFC нет стандартного «периметра» для колонны, поэтому DeepSeek предложил пользовательское свойство Perimeter.
В случае с высотой DeepSeek не определил стандартный количественный показатель (quantity) Length как высоту колонны и также предложил ввести свойство Height.
28.01.202512:59
Bonsai - еще не САПР, но больше, чем САПР
В то время, как бесплатный ИИ-помощник DeepSeek уложил на лопатки IT-гигантов, вернемся в более приземленное русло.
Новые инструменты на основе принципов открытости могут заявить о себе очень быстро. И BIM-моделирование - не исключение.
У нас нет завышенных ожиданий по поводу Bonsai, однако считаем, что этот инструмент заслуживает в IFC Клубе отдельной ветки Bonsai | BlenderBIM.
➖Конечно, надстройку Bonsai на базе мощного бесплатного ПО Blender нельзя назвать полноценным САПР.
✅Вместе с тем его возможности выходят за рамки обычного IFC-вьюера и традиционных САПР.
Что в нем стоит обсудить:
🔹 Обнаружение коллизий и работа по их устранению на базе BCF
🔹 Создание новых IFC-моделей с нуля и редактирование существующих
🔹 Создание 2D-документации
🔹 Исправление некорректной координационной привязки файлов IFC
🔹 Создание календарных графиков и их визуализации
🔹 Интеграция c bSDD для подключения альтернативной классификации
🔹 Перевод моделей между различными версиями IFC (например, IFC4 в IFC4x3)
🔹 Использование библиотек IFC для повторного применения
🔹 Валидация моделей на соответствие цифровым требованиям IDS
🔹 Извлечение необходимых данных
🔹 Назначение наборов свойств (Psets) для объектов
🔹 и многое другое.
В то время, как бесплатный ИИ-помощник DeepSeek уложил на лопатки IT-гигантов, вернемся в более приземленное русло.
Новые инструменты на основе принципов открытости могут заявить о себе очень быстро. И BIM-моделирование - не исключение.
У нас нет завышенных ожиданий по поводу Bonsai, однако считаем, что этот инструмент заслуживает в IFC Клубе отдельной ветки Bonsai | BlenderBIM.
➖Конечно, надстройку Bonsai на базе мощного бесплатного ПО Blender нельзя назвать полноценным САПР.
✅Вместе с тем его возможности выходят за рамки обычного IFC-вьюера и традиционных САПР.
Что в нем стоит обсудить:
🔹 Обнаружение коллизий и работа по их устранению на базе BCF
🔹 Создание новых IFC-моделей с нуля и редактирование существующих
🔹 Создание 2D-документации
🔹 Исправление некорректной координационной привязки файлов IFC
🔹 Создание календарных графиков и их визуализации
🔹 Интеграция c bSDD для подключения альтернативной классификации
🔹 Перевод моделей между различными версиями IFC (например, IFC4 в IFC4x3)
🔹 Использование библиотек IFC для повторного применения
🔹 Валидация моделей на соответствие цифровым требованиям IDS
🔹 Извлечение необходимых данных
🔹 Назначение наборов свойств (Psets) для объектов
🔹 и многое другое.
03.04.202508:57
Что нового в Revit 2026 в части IFC
1️⃣ Теперь можно выбирать способ координационной привязки для связанных IFC-файлов. Они могут располагаться по внутреннему началу, базовой точке проекта или точке съемки.
2️⃣ На этом всё )
UPD. Остальные мелкие улучшения в комментах.
👥 @IFC_ru
👥 @IFC_club
1️⃣ Теперь можно выбирать способ координационной привязки для связанных IFC-файлов. Они могут располагаться по внутреннему началу, базовой точке проекта или точке съемки.
2️⃣ На этом всё )
UPD. Остальные мелкие улучшения в комментах.
👥 @IFC_ru
👥 @IFC_club
21.03.202509:22
Альтернативная классификация
Не хватает классов IFC?
🔍 Использование инструментов That Open Engine и JavaScript (для красоты) позволяет добавлять, редактировать и сохранять дополнительную классификацию к элементам, будь то КСИ, МССК, Uniformat, OmniClass или любую другую.
Классификационных систем в одном IFC-файле может быть несколько, в зависимости от задач.
Для кода и наименования классификатора предназначены специальные сущности IfcClassificationReference и IfcClassification. Это важно, чтобы классификатор всегда находился в одном месте, а не в произвольном параметре вроде "код по КСИ".
✈️ Напомним, что в редакторе IDS от ИСП РАН можно создавать требования с использованием альтернативной классификации (КСИ, РЖД, МССК).
👥 @IFC_ru
👥 @IFC_club
Не хватает классов IFC?
🔍 Использование инструментов That Open Engine и JavaScript (для красоты) позволяет добавлять, редактировать и сохранять дополнительную классификацию к элементам, будь то КСИ, МССК, Uniformat, OmniClass или любую другую.
Классификационных систем в одном IFC-файле может быть несколько, в зависимости от задач.
Для кода и наименования классификатора предназначены специальные сущности IfcClassificationReference и IfcClassification. Это важно, чтобы классификатор всегда находился в одном месте, а не в произвольном параметре вроде "код по КСИ".
✈️ Напомним, что в редакторе IDS от ИСП РАН можно создавать требования с использованием альтернативной классификации (КСИ, РЖД, МССК).
👥 @IFC_ru
👥 @IFC_club
12.03.202508:21
Тестируем выгрузку стен из Revit
Зачастую в проектах можно встретить два класса стен: IfcWall и IfcWallStandardCase. Обычно пользователь не назначает второй класс. Но он появляется "сам собой". Это связано с особенностями выгрузки из Revit в схему IFC2x3. Разберемся с этим.
Что говорит стандарт:
🔹 IfcWallStandardCase - класс для стен с набором слоев материала, представленных выдавливанием (SweptSolid) с постоянной толщиной вдоль траектории.
🔹 IfcWall - класс для стен с переменной толщиной, сложными сечениями или геометрией, которые не могут быть просто выдавлены.
Начиная с IFC4 сущность IfcWallStandardCase убрали, и всем стенам назначается IfcWall.
Как с этим справляется Revit?
Наш тест показал, что Revit 2021 и 2024 выгружает в IFC2x3 CoordanationView2.0 с особенностями и ошибками геометрии в обеих версиях ревита и назначением классов IfcWall только для стен, имеющих нестандартную геометрию (с врезками плит, с наклоном и т.д) .
При этом выгрузка в IFC4 ReferenceView постепенно улучшается. 24-ый ревит справился с выгрузкой без ошибок, при этом 21 версия имеет проблемы с геометрией наклонных стен.
Ранее мы писали мнение о IFC 2x3.
Наш вердикт:
Выгружаем стены в IFC4 и выше, используем новый ревит со свежим экспортером.
👥 @IFC_ru
👥 @IFC_club
Зачастую в проектах можно встретить два класса стен: IfcWall и IfcWallStandardCase. Обычно пользователь не назначает второй класс. Но он появляется "сам собой". Это связано с особенностями выгрузки из Revit в схему IFC2x3. Разберемся с этим.
Что говорит стандарт:
🔹 IfcWallStandardCase - класс для стен с набором слоев материала, представленных выдавливанием (SweptSolid) с постоянной толщиной вдоль траектории.
🔹 IfcWall - класс для стен с переменной толщиной, сложными сечениями или геометрией, которые не могут быть просто выдавлены.
Начиная с IFC4 сущность IfcWallStandardCase убрали, и всем стенам назначается IfcWall.
Как с этим справляется Revit?
Наш тест показал, что Revit 2021 и 2024 выгружает в IFC2x3 CoordanationView2.0 с особенностями и ошибками геометрии в обеих версиях ревита и назначением классов IfcWall только для стен, имеющих нестандартную геометрию (с врезками плит, с наклоном и т.д) .
При этом выгрузка в IFC4 ReferenceView постепенно улучшается. 24-ый ревит справился с выгрузкой без ошибок, при этом 21 версия имеет проблемы с геометрией наклонных стен.
Ранее мы писали мнение о IFC 2x3.
Наш вердикт:
Выгружаем стены в IFC4 и выше, используем новый ревит со свежим экспортером.
👥 @IFC_ru
👥 @IFC_club
09.02.202512:26
✈️ Запись эфира "OpenSource, IFC и IDS в управлении проектами"
✈️ Гость: Антон Мотовилов, руководитель отдела цифровизации и технологий информационного моделирования, ООО «Желдорпроект»
📹Youtube | 📺Rutube | ✈️Презентация
👥 @IFC_ru
👥 @IFC_club
✈️ Гость: Антон Мотовилов, руководитель отдела цифровизации и технологий информационного моделирования, ООО «Желдорпроект»
📹Youtube | 📺Rutube | ✈️Презентация
👥 @IFC_ru
👥 @IFC_club
17.01.202507:12
"Формат RVT - это де-факто стандарт отрасли"
Многие считают формат САПР, в котором они привыкли работать, стандартом отрасли, особенно если вкладывают средства в его использование.
❓ Но может ли проприетарный формат стать полноценным стандартом в части организации данных? Что для этого нужно и почему?
1️⃣ Проблемы специализации.
Строительная отрасль обширна и включает множество типов объектов: здания, мосты, тоннели и другие. Это требует специфических инструментов для работы.
Даже "универсальные" САПР не всегда подходят для узких задач. К примеру, проектирование бревенчатых и каркасных домов в Revit может потребовать скриптов, плагинов или библиотечных элементов. Специализированные программы, вроде Cadwork, SEMA или К3-Коттедж часто эффективнее.
2️⃣ Применение нескольких программ.
В рамках одного проекта часто требуется несколько инструментов. Например, для раздела ГП могут потребоваться другие ПО с собственными форматами. САПР не могут полностью заменить программы для расчётов, смет или проектирования инфраструктуры, что создаёт необходимость интеграции данных из разных источников.
3️⃣ Риск зависимости от проприетарных форматов.
Любой проприетарный формат САПР - это частная закрытая разработка компании. На этом построен ее бизнес. В современном мире это нормально, но пользователь должен понимать все риски такого подхода.
4️⃣ Проблемы с хранением и версионностью.
Проприетарные форматы зачастую могут создавать проблемы долгосрочного хранения данных, и доступ к старым или новым версиям формата может быть затруднён.
5️⃣ Ограничения в схеме данных.
Схема данных в форматах САПР оптимизирована для работы ПО, а не для отражения иерархической структуры объекта. Это может усложнить стандартизацию данных. В открытых стандартах, таких как IFC, предлагается представлять данные в виде онтологии, описывающей логическую иерархию с учетом различных сценариев и задач.
Касаемо схемы есть еще ряд моментов:
➖ Ограниченная классификация элементов.
САПР имеют очень ограниченный набор категорий (например, отделку вынуждены создавать "стеной", а сваю - "колонной"), без возможности их расширения. Это заставляет пользователей применять дополнительную классификацию, записывая коды в параметры.
➖ Ограничения на создание наборов свойств и связей.
Некоторые САПР не позволяют создавать наборы свойств или управлять связями. Приходится создавать условные разделители, вроде этого:
Знакомо?
🔍 Чтобы стать стандартом данных, спецификация формата должна покрывать широкий спектр задач и представлять собой онтологию. При этом она должна быть написана, опубликована и утверждена.
🔍 Проприетарные форматы САПР, включая RVT, не обеспечивают полноценной стандартизации данных (хотя они удобны в работе проектировщика). Для этого требуются дополнительные действия: классификация элементов, маппинг свойств и настройка экспорта.
И открытые стандарты, такие как IFC, здесь играют ключевую роль.
📢 @IFC_ru
👥 @IFC_club
Многие считают формат САПР, в котором они привыкли работать, стандартом отрасли, особенно если вкладывают средства в его использование.
❓ Но может ли проприетарный формат стать полноценным стандартом в части организации данных? Что для этого нужно и почему?
1️⃣ Проблемы специализации.
Строительная отрасль обширна и включает множество типов объектов: здания, мосты, тоннели и другие. Это требует специфических инструментов для работы.
Даже "универсальные" САПР не всегда подходят для узких задач. К примеру, проектирование бревенчатых и каркасных домов в Revit может потребовать скриптов, плагинов или библиотечных элементов. Специализированные программы, вроде Cadwork, SEMA или К3-Коттедж часто эффективнее.
2️⃣ Применение нескольких программ.
В рамках одного проекта часто требуется несколько инструментов. Например, для раздела ГП могут потребоваться другие ПО с собственными форматами. САПР не могут полностью заменить программы для расчётов, смет или проектирования инфраструктуры, что создаёт необходимость интеграции данных из разных источников.
3️⃣ Риск зависимости от проприетарных форматов.
Любой проприетарный формат САПР - это частная закрытая разработка компании. На этом построен ее бизнес. В современном мире это нормально, но пользователь должен понимать все риски такого подхода.
4️⃣ Проблемы с хранением и версионностью.
Проприетарные форматы зачастую могут создавать проблемы долгосрочного хранения данных, и доступ к старым или новым версиям формата может быть затруднён.
5️⃣ Ограничения в схеме данных.
Схема данных в форматах САПР оптимизирована для работы ПО, а не для отражения иерархической структуры объекта. Это может усложнить стандартизацию данных. В открытых стандартах, таких как IFC, предлагается представлять данные в виде онтологии, описывающей логическую иерархию с учетом различных сценариев и задач.
Касаемо схемы есть еще ряд моментов:
➖ Ограниченная классификация элементов.
САПР имеют очень ограниченный набор категорий (например, отделку вынуждены создавать "стеной", а сваю - "колонной"), без возможности их расширения. Это заставляет пользователей применять дополнительную классификацию, записывая коды в параметры.
➖ Ограничения на создание наборов свойств и связей.
Некоторые САПР не позволяют создавать наборы свойств или управлять связями. Приходится создавать условные разделители, вроде этого:
___Параметры квартиры_____
Знакомо?
🔍 Чтобы стать стандартом данных, спецификация формата должна покрывать широкий спектр задач и представлять собой онтологию. При этом она должна быть написана, опубликована и утверждена.
🔍 Проприетарные форматы САПР, включая RVT, не обеспечивают полноценной стандартизации данных (хотя они удобны в работе проектировщика). Для этого требуются дополнительные действия: классификация элементов, маппинг свойств и настройка экспорта.
И открытые стандарты, такие как IFC, здесь играют ключевую роль.
📢 @IFC_ru
👥 @IFC_club
Показано 1 - 22 із 22
Увійдіть, щоб розблокувати більше функціональності.