
Всё про IFC
Новости и полезности по IFC.
Главное IFC-сообщество: @ifc_club
Для связи: @AlexanderShilo
Главное IFC-сообщество: @ifc_club
Для связи: @AlexanderShilo
TGlist रेटिंग
0
0
प्रकारसार्वजनिक
सत्यापन
असत्यापितविश्वसनीयता
अविश्वसनीयस्थानРосія
भाषाअन्य
चैनल निर्माण की तिथिГруд 23, 2023
TGlist में जोड़ा गया
Лист 26, 2024संलग्न समूह
समूह "Всё про IFC" में नवीनतम पोस्ट
15.04.202505:51
ИИ-классификация элементов на основе геометрии в Qonic
BIM-платформа Qonic анонсировала разработку ИИ-помощника, который будет предлагать подходящий класс IFC для неклассифицированных элементов в моделях. По заверениям разработчиков определять класс он будет на основе анализа геометрии элемента и контекста (то есть его места в структуре модели).
Кроме того, Qonic умеет редактировать геометрию, исправлять классы, добавлять/править свойства элементов и сохранять в IFC.
👥 @IFC_ru
👥 @IFC_club
BIM-платформа Qonic анонсировала разработку ИИ-помощника, который будет предлагать подходящий класс IFC для неклассифицированных элементов в моделях. По заверениям разработчиков определять класс он будет на основе анализа геометрии элемента и контекста (то есть его места в структуре модели).
Кроме того, Qonic умеет редактировать геометрию, исправлять классы, добавлять/править свойства элементов и сохранять в 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


03.04.202508:57
Что нового в Revit 2026 в части IFC
1️⃣ Теперь можно выбирать способ координационной привязки для связанных IFC-файлов. Они могут располагаться по внутреннему началу, базовой точке проекта или точке съемки.
2️⃣ На этом всё )
UPD. Остальные мелкие улучшения в комментах.
👥 @IFC_ru
👥 @IFC_club
1️⃣ Теперь можно выбирать способ координационной привязки для связанных IFC-файлов. Они могут располагаться по внутреннему началу, базовой точке проекта или точке съемки.
2️⃣ На этом всё )
UPD. Остальные мелкие улучшения в комментах.
👥 @IFC_ru
👥 @IFC_club


02.04.202509:11
Проект приказа Минстроя о составе ЦИМ в IDS!
На публичное обсуждение размещен проект приказа Минстроя России об утверждении состава ЦИМ на этапе проектирования.
И многие уже успели его обсудить. Но мы решили на этом не останавливаться и сделали по этому проекту IDS-требования (по таблице 1).
Помимо того, что проект приказа требует изменений в формулировках, также нужны уточнения в самих таблицах.
Так, для элементов инженерных систем введены слишком обобщенные понятия (например, «Оборудование»). В результате не совсем понятно, что конкретно в них входит.
С точки зрения целей применимости ЦИМ на этапе проектирования к проекту приказа есть вопросы, но в техническом плане он вполне выполним (после ряда доработок).
👥 @IFC_ru
👥 @IFC_club
На публичное обсуждение размещен проект приказа Минстроя России об утверждении состава ЦИМ на этапе проектирования.
И многие уже успели его обсудить. Но мы решили на этом не останавливаться и сделали по этому проекту IDS-требования (по таблице 1).
Помимо того, что проект приказа требует изменений в формулировках, также нужны уточнения в самих таблицах.
Так, для элементов инженерных систем введены слишком обобщенные понятия (например, «Оборудование»). В результате не совсем понятно, что конкретно в них входит.
С точки зрения целей применимости ЦИМ на этапе проектирования к проекту приказа есть вопросы, но в техническом плане он вполне выполним (после ряда доработок).
👥 @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


28.03.202511:52
Провели встречу с замечательным человеком, BIM-лидером отрасли в части инфраструктуры Аллой Землянской (Tangl).
Обсудили перспективы открытых стандартов передачи данных в отечественных ПО.
🔹 В части цифровых требований пришли к общему мнению, что это молодое направление еще предстоит освоить как вендорам, так и заказчикам. И начинать здесь надо с малого, с IDS :) то есть с цифровизации требований заказчика.
IDS пока не может формализовать сложные проверки на техрегламенты, но на данном этапе развития технологии этого и не требуется, потому что перепрыгнуть через кучу подводных камней и перейти к полной автоматизации нормативных проверок вряд ли удастся в ближайшей перспективе. Стандартизация должна предшествовать автоматизации.
🔹Также поговорили о передаче отчетов о коллизиях в BCF. Востребованность формата пока по большей части ограничивается госсектором и органами экспертиз. Но при обмене замечаниями через BCF-сервер, популярность его будет только расти. И такие разработки в России уже ведутся.
🔹И затронули перспективу перехода к IFC4x3, как более проработанному и развитому в части описания инфраструктурных объектов.
👥 @IFC_ru
👥 @IFC_club
Обсудили перспективы открытых стандартов передачи данных в отечественных ПО.
🔹 В части цифровых требований пришли к общему мнению, что это молодое направление еще предстоит освоить как вендорам, так и заказчикам. И начинать здесь надо с малого, с IDS :) то есть с цифровизации требований заказчика.
IDS пока не может формализовать сложные проверки на техрегламенты, но на данном этапе развития технологии этого и не требуется, потому что перепрыгнуть через кучу подводных камней и перейти к полной автоматизации нормативных проверок вряд ли удастся в ближайшей перспективе. Стандартизация должна предшествовать автоматизации.
🔹Также поговорили о передаче отчетов о коллизиях в BCF. Востребованность формата пока по большей части ограничивается госсектором и органами экспертиз. Но при обмене замечаниями через BCF-сервер, популярность его будет только расти. И такие разработки в России уже ведутся.
🔹И затронули перспективу перехода к IFC4x3, как более проработанному и развитому в части описания инфраструктурных объектов.
👥 @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


20.03.202514:36
Интероперабельность. Роль заказчика и разработчика ПО
Добавим немного мыслей к цитатам из поста Дмитрия Чубрика об интероперабельности.
Это осознали только те, кто давно работает с BIM. Сегодня заказчики, особенно государственные - это наиболее "просевшее" звено. И связано это с тем, что они до сих пор не могут сформулировать свои потребности, исходя из которых формулировались бы требования.
Заказчик должен играть ключевую роль в установлении требований к данным. Однако сегодня мы имеем немного другую ситуацию:
- BIM-стандарты и ТЗ на модель зачастую пишут сами проектировщики;
- требования к форматам и классификации - в постановлениях Правительства;
- а проверки на коллизии - дело экспертизы.
Заказчик в этом процессе как-то затерялся.
+1.
При этом разработчики ПО, не развивая интероперабельность на базе OpenBIM-стандартов, делают хуже не только пользователю, но и себе, так как потребность в стандартизации данных будет расти и дальше. А плохая поддержка открытых стандартов уже давно воспринимается как большой недостаток такого ПО.
По итогу мы имеем конфликт интересов.
Разработчики - хотят оставить пользователя в своей экосистеме.
Заказчики (если они уже работают с BIM) - хотят иметь долгосрочный доступ к данным и на перспективу не зависеть от одного ПО.
Проектировщики - хотят минимизировать трудозатраты с жесткими дедлайнами.
Разрешить этот конфликт можно целым комплексом мер, в частности, усилением регуляторного давления и крупных заказчиков с целью качественного использования открытых стандартов передачи данных (например, путем сертификации ПО).
👥 @IFC_ru
👥 @IFC_club
Добавим немного мыслей к цитатам из поста Дмитрия Чубрика об интероперабельности.
Важность открытых форматов большинство заказчиков осознало несколько лет назад, когда Autodesk ушел
Это осознали только те, кто давно работает с BIM. Сегодня заказчики, особенно государственные - это наиболее "просевшее" звено. И связано это с тем, что они до сих пор не могут сформулировать свои потребности, исходя из которых формулировались бы требования.
Заказчик должен играть ключевую роль в установлении требований к данным. Однако сегодня мы имеем немного другую ситуацию:
- BIM-стандарты и ТЗ на модель зачастую пишут сами проектировщики;
- требования к форматам и классификации - в постановлениях Правительства;
- а проверки на коллизии - дело экспертизы.
Заказчик в этом процессе как-то затерялся.
интероперабельность данных очень важна. Но она базируется на стандартах, а стандарты часто идут вразрез с интересами разработчиков ПО.
+1.
При этом разработчики ПО, не развивая интероперабельность на базе OpenBIM-стандартов, делают хуже не только пользователю, но и себе, так как потребность в стандартизации данных будет расти и дальше. А плохая поддержка открытых стандартов уже давно воспринимается как большой недостаток такого ПО.
По итогу мы имеем конфликт интересов.
Разработчики - хотят оставить пользователя в своей экосистеме.
Заказчики (если они уже работают с BIM) - хотят иметь долгосрочный доступ к данным и на перспективу не зависеть от одного ПО.
Проектировщики - хотят минимизировать трудозатраты с жесткими дедлайнами.
Разрешить этот конфликт можно целым комплексом мер, в частности, усилением регуляторного давления и крупных заказчиков с целью качественного использования открытых стандартов передачи данных (например, путем сертификации ПО).
👥 @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


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
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
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


20.02.202505:36
Проверка IFC моделей по требованиям IDS
На Хабре вышла хорошая обзорная статья от Ильи Савельева по работе с IDS-требованиями, с полезными ссылками и практическими кейсами на Python и библиотеки ifcopenshell.
Добавляем в закладки.
👥 @IFC_ru
👥 @IFC_club
На Хабре вышла хорошая обзорная статья от Ильи Савельева по работе с IDS-требованиями, с полезными ссылками и практическими кейсами на Python и библиотеки ifcopenshell.
Добавляем в закладки.
👥 @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.
रिकॉर्ड
14.04.202523:59
896सदस्य04.03.202523:59
100उद्धरण सूचकांक03.04.202517:44
1.8Kप्रति पोस्ट औसत दृश्य03.04.202517:44
1.8Kप्रति विज्ञापन पोस्ट औसत दृश्य07.03.202503:41
10.92%ER03.04.202509:50
203.57%ERRअधिक कार्यक्षमता अनलॉक करने के लिए लॉगिन करें।