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

Часть 2 из 3

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

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

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

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

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

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

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

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

👥 @IFC_ru
👥 @IFC_club