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