IfcBuildingElementProxy: как классифицировать "нестандартные" элементы и расширить классификацию IFC?

Часть 3 из 3

Итак, задача сводится к тому, чтобы в рамках схемы IFC описать объекты так, чтобы они обрели «смысл». Но слишком частое обновление IFC-схемы ради одного нового класса невозможно. Разработчики ПО не будут успевать ее соблюдать. Поэтому введены «обходные пути» в виде IfcBuildingElementProxy. А стандарт обновляется примерно раз в 5 лет.

И если элемент не вписывается в IFC-классификацию, есть несколько основных способов это поправить:

1️⃣ Использование IfcClassification - стандартный и наиболее корректный способ добавления своей классификации. Придает гибкости без нарушения стандарта, применяя любые системы: КСИ, Uniformat, МССК и другие. Но и в них может не быть подходящего класса.

2️⃣ Использование PredefinedType. Предусмотрен для «мягкого» расширения в рамках схемы. Если нужный IFC-класс и его подтип отсутствует, вводится свое значение.

PredefinedType: USERDEFINED
ObjectType: <пользовательский тип>.

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

3️⃣ Слои из CAD тоже выгружаются в IFC и могут служить для классификации.

Есть и другие, менее популярные способы, например, через стандартный атрибут Name или стандартное свойство Reference (в наборе Pset_[Entity]Common).

И немного рекомендаций:
🔹 Следует использовать IfcBuildingElementProxy в исключительных случаях и применять доп.классификацию к нему.
🔹 Договаривайтесь о принципах классификации заранее и прописывайте их в ТЗ.
🔹 И не допускайте ошибок в написании стандартных IFC-классов. Некоторые САПР имеют «защитный механизм» и автоматически экспортируют некорректный класс в IfcBuildingElementProxy. Но его все равно придется кому-то уточнять.

👥 @IFC_ru
👥 @IFC_club

IfcBuildingElementProxy: причины (зло)употребления

Часть 2 из 3

Порассуждаем, с чем связано излишнее использование данного IFC-класса в проектах.

1️⃣ IfcProxy был введен в качестве "корзины" для любых объектов, которых нет в стандарте IFC, с возможностью их семантической идентификации через атрибут Name.

IfcBuildingElementProxy стал его эволюцией, но с уточнением, что это элемент здания. То есть он обеспечивает более строгую семантику, чем IfcProxy, поскольку четкая связь со зданием сужает его использование. (Но и этого, как правило, бывает недостаточно на практике).

Тем не менее, устоялось ошибочное представление, что IfcBuildingElementProxy - это любой объект, который не описан стандартом, но это не так.

2️⃣ Всегда проще не искать нужный класс, а экспортировать "как есть" вместо настройки сопоставлений.
Часто это происходит из-за непроработанного ТЗ на модель либо его поверхностного исполнения.

Если ТЗ не содержит конкретных указаний, какую классификацию следует применять, то результат предсказуем.

3️⃣ Некоторые ПО просто не умеют выгружать ни во что другое (например, старый экспортер из Civil). То есть синтаксически файл IFC корректен, но семантически это не соответствует стандарту, и данные в модели теряют смысл. Для переопределения классов приходится использовать специализированные инструменты вроде Bonsai или FreeCAD.

Что делать? - об этом в третьей части.

👥 @IFC_ru
👥 @IFC_club

IfcBuildingElementProxy: удобный костыль или скрытая проблема?

Часть 1 из 3

Давно хотелось написать про IfcBuildingElementProxy (а также IfcProxy для версий до IFC4x1). Он часто используется, когда в IFC-стандарте не удается найти подходящий класс. Но загвоздка в том, что его бесконтрольное применение может создать больше проблем, чем решить их.

Чем грозит такое использование IfcBuildingElementProxy для классификации элемента?

➡️ Потеря семантики - элемент становится "черным ящиком". Он лишается своего назначения, если proxy-класс применяется без дополнительной классификации. А это нарушает принципы информационного моделирования и не совсем вписывается логику онтологии IFC.

➡️ Проблемы для коллег. То есть по сути перекладывание задачи классификации на кого-то позднее, кто будет вынужден вручную разбираться, что же скрывается за такими Proxy-элементами.

Оставлять Proxy-элементы в таком виде - плохая практика.

Но почему так происходит и что делать? - разберемся в следующих частях.

👥 @IFC_ru
👥 @IFC_club

ИИ-классификация элементов на основе геометрии в Qonic

BIM-платформа Qonic анонсировала разработку ИИ-помощника, который будет предлагать подходящий класс IFC для неклассифицированных элементов в моделях. По заверениям разработчиков определять класс он будет на основе анализа геометрии элемента и контекста (то есть его места в структуре модели).

Кроме того, Qonic умеет редактировать геометрию, исправлять классы, добавлять/править свойства элементов и сохранять в IFC.

👥 @IFC_ru
👥 @IFC_club

Сегодня завершился десятый (!) курс по технологиям информационного моделирования.

Спасибо всем, кто был с нами: «Росатому» и другим организациям за неудобные вопросы, споры и за то, что делились своим опытом. Для нас курс стал еще одной ступенькой в развитии.

Мы старались сделать курс максимально честным и детальным: разобрали BIM-подходы в мировом контексте, в российской практике, в экспертизе и даже в узких отраслевых нюансах. От Градкодекса до коллизий в IFC.

С 2021 года курс прилично «прокачался»:
🔹 добавили больше материала про работу с IFC и создание цифровых требований;
🔹 сместились акценты в сторону работы с заказчиком и правильному составлению ТЗ на модель.

Особая благодарность Ольге Кутузовой (@Kutuzova_O, NSR-Specification) и Николаю Самопалу (@NS_BIM, Wizardsoft) - на ваших лекциях мы тоже учимся.

👥 @IFC_ru
👥 @IFC_club

Начинаем новую рубрику:
Проверь себя в 🌐IFC

🕙 Один вопрос каждую пятницу в 10:00

✈️ Запись эфира "Без права на ошибку: Транспортная инфраструктура в IFC"

✈️ Гость: Филипп Сергеев, руководитель MARKS DIGITAL, заместитель генерального директора по цифровым технологиям MARKS GROUP

📹Youtube | 📺Rutube | ✈️ Telegram

👥 @IFC_ru
👥 @IFC_club

Что нового в Revit 2026 в части IFC

1️⃣ Теперь можно выбирать способ координационной привязки для связанных IFC-файлов. Они могут располагаться по внутреннему началу, базовой точке проекта или точке съемки.

2️⃣ На этом всё )

UPD. Остальные мелкие улучшения в комментах.

👥 @IFC_ru
👥 @IFC_club

Проект приказа Минстроя о составе ЦИМ в IDS!

На публичное обсуждение размещен проект приказа Минстроя России об утверждении состава ЦИМ на этапе проектирования.

И многие уже успели его обсудить. Но мы решили на этом не останавливаться и сделали по этому проекту IDS-требования (по таблице 1).

Помимо того, что проект приказа требует изменений в формулировках, также нужны уточнения в самих таблицах.

Так, для элементов инженерных систем введены слишком обобщенные понятия (например, «Оборудование»). В результате не совсем понятно, что конкретно в них входит.

С точки зрения целей применимости ЦИМ на этапе проектирования к проекту приказа есть вопросы, но в техническом плане он вполне выполним (после ряда доработок).

👥 @IFC_ru
👥 @IFC_club

Ежемесячный подкаст "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