❓IfcBuildingElementProxy – это плохо?
Не так давно, решая задачу привязки элементов одного корпоративного классификатора к классам IFC, столкнулся с мнением, что IfcBuildingElementProxy это «мусорный» класс, использование которого недопустимо и априори является ошибочным. Я с этим мнением не согласился, и решил написать об этом пост.
☝🏻Чтобы понять пригоден ли для нас IfcBuildingElementProxy, нужно ответить себе на простой вопрос – зачем мы используем модели в IFC? В базе его используют как средство обмена геометрией, чтобы координироваться со смежниками, работающими в разных софтах. Со временем IFC стал восприниматься многими как нечто большее, чем просто инструмент обмена – как некий единый цифровой стандарт, на основе которого накапливаются данные об объектах строительства. Иногда его воспринимают и вовсе как своего рода классификатор элементов ЦИМ, что тоже имеет место. А некоторым IFC нужен чтобы просто пройти экспертизу (или АГР 😊).
🔃Исторически IFC создавался как инструмент интероперабельности, т.е. чтобы разные САПРы могли воспринимать нативные данные иного софта как свои собственные. IFC – это модель данных, где каждый класс элементов имеет свое четкое место в иерархии и выполняет свою соответствующую функцию. Это нужно, например, для того, чтобы импортировав оборудование в САПР, он воспринял этот элемент так, как будто его моделировали прямо здесь, инструментами этого САПР. Чтобы его можно было изменить и использовать в дальнейшем.
💁🏻♂️Например, чтобы рассчитать технологическую систему, у элемента оборудования должны быть соответствующие коннекторы (интерфейсы). Оборудование, включая коннекторы, должно иметь соответствующие атрибуты, и желательно такие, которые программой будут восприняты как системные, чтобы они попали туда куда нужно сразу, без дополнительных манипуляций. И поэтому в этом случае использование соответствующих классов IFC архиважно.
👌🏻Но для объектов, которые в целом не влияют на поведение модели как системы, не используются для параметризации геометрии и расчетов различных систем, имеют признаки идентификации (имя, марку, и т.п.), то IfcBuildingElementProxy вполне пригодный класс. Всякая бутафория, МАФы, объекты визуализации и чего только еще. Во-первых, для большинства таких объектов просто не существует соответствующего класса IFC. Во-вторых - да он и не нужен.
🌐Языком IFC вы объясняете программе «что можно делать с этим объектом». Когда вам нужно, чтобы программа просто восприняла его геометрию и местоположение – этого класса более чем достаточно. В отдельных случаях вообще нет задачи сохранять модель как информационную и нужна только геометрия. Это, конечно, как сейчас модно выражаться, кринж, но вполне себе аргумент вообще все элементы ЦИМ с геометрией представить через класс IfcBuildingElementProxy.
❗️Поэтому, отвечаю на вопрос в заголовке – IfcBuildingElementProxy – это плохо, когда вы используете его бездумно, но вполне нормально и допустимо, когда вы понимаете целесообразность и осознаете последствия.
#информационнаясреда
@bimspoint
* изображение сгенерировано ИИ
Не так давно, решая задачу привязки элементов одного корпоративного классификатора к классам IFC, столкнулся с мнением, что IfcBuildingElementProxy это «мусорный» класс, использование которого недопустимо и априори является ошибочным. Я с этим мнением не согласился, и решил написать об этом пост.
☝🏻Чтобы понять пригоден ли для нас IfcBuildingElementProxy, нужно ответить себе на простой вопрос – зачем мы используем модели в IFC? В базе его используют как средство обмена геометрией, чтобы координироваться со смежниками, работающими в разных софтах. Со временем IFC стал восприниматься многими как нечто большее, чем просто инструмент обмена – как некий единый цифровой стандарт, на основе которого накапливаются данные об объектах строительства. Иногда его воспринимают и вовсе как своего рода классификатор элементов ЦИМ, что тоже имеет место. А некоторым IFC нужен чтобы просто пройти экспертизу (или АГР 😊).
🔃Исторически IFC создавался как инструмент интероперабельности, т.е. чтобы разные САПРы могли воспринимать нативные данные иного софта как свои собственные. IFC – это модель данных, где каждый класс элементов имеет свое четкое место в иерархии и выполняет свою соответствующую функцию. Это нужно, например, для того, чтобы импортировав оборудование в САПР, он воспринял этот элемент так, как будто его моделировали прямо здесь, инструментами этого САПР. Чтобы его можно было изменить и использовать в дальнейшем.
💁🏻♂️Например, чтобы рассчитать технологическую систему, у элемента оборудования должны быть соответствующие коннекторы (интерфейсы). Оборудование, включая коннекторы, должно иметь соответствующие атрибуты, и желательно такие, которые программой будут восприняты как системные, чтобы они попали туда куда нужно сразу, без дополнительных манипуляций. И поэтому в этом случае использование соответствующих классов IFC архиважно.
👌🏻Но для объектов, которые в целом не влияют на поведение модели как системы, не используются для параметризации геометрии и расчетов различных систем, имеют признаки идентификации (имя, марку, и т.п.), то IfcBuildingElementProxy вполне пригодный класс. Всякая бутафория, МАФы, объекты визуализации и чего только еще. Во-первых, для большинства таких объектов просто не существует соответствующего класса IFC. Во-вторых - да он и не нужен.
🌐Языком IFC вы объясняете программе «что можно делать с этим объектом». Когда вам нужно, чтобы программа просто восприняла его геометрию и местоположение – этого класса более чем достаточно. В отдельных случаях вообще нет задачи сохранять модель как информационную и нужна только геометрия. Это, конечно, как сейчас модно выражаться, кринж, но вполне себе аргумент вообще все элементы ЦИМ с геометрией представить через класс IfcBuildingElementProxy.
❗️Поэтому, отвечаю на вопрос в заголовке – IfcBuildingElementProxy – это плохо, когда вы используете его бездумно, но вполне нормально и допустимо, когда вы понимаете целесообразность и осознаете последствия.
#информационнаясреда
@bimspoint
* изображение сгенерировано ИИ