Свойства в IFC

Пользователи САПР привычно называют "параметрами" все характеристики, которые привязаны к элементу. Эти "параметры" обычно подразделяют на системные и пользовательские. Проектировщикам этих знаний может быть вполне достаточно. Но для BIM-специалистов, не замкнутых на одном программном продукте и желающих разобраться в структуре IFC, этого не хватит.

В стандарте IFC история с характеристиками объектов представлена несколько иначе. Существуют три вида характеристик:

🛑 атрибут (attribute) - это "встроенные" характеристики объекта (сущности), такие как GlobalID, Name, Tag, PredefinedType и т.д. Их количество строго ограничено схемой IFC.

🛑 свойство (property) - это приписываемые характеристики, которые могут быть присущи конкретному экземпляру или типу элемента. Они позволяют нам наполнять модель дополнительными данными, так как их количество может быть не ограничено. Группируются в наборы (Pset’ы).

🛑 количественный показатель (quantity) - здесь записываются показатели, индивидуальные для каждого элемента и вычисляемые в САПР, например, длина, площадь, объем и так далее. Также группируются в наборы (Qset’ы).

Атрибуты в свою очередь подразделяются на:
🛑 прямые (явные) атрибуты (direct attribute) - их мы обычно видим в просмотрщике в диспетчере свойств вместе со всеми остальными свойствами. В структуре файла IFC для них всегда отведено место;
🛑 обратные (инверсные) атрибуты (inverse attribute) - эти атрибуты в файл IFC не выгружаются, на них пока останавливаться не будем;
🛑 производные (вычисляемые) атрибуты (derived attribute) - вычисляются по значениям из других атрибутов и зависимые от них.

Если погрузиться поглубже, то свойства и количественные показатели тоже задаются в виде атрибутов у специальных классов, отвечающих за их хранение и связь с ''физическими'' элементами. Об этом можно почитать в свежей статье на bimcorner.com, где сделан достаточно подробный анализ различных типов свойств.

https://bimcorner.com/properties-in-ifc/

#База

👥 @IFC_ru
👥 @IFC_club

По просьбам трудящихся подключаем комментарии 📝
P.S. Предыдущие посты откомментировать нельзя

Спешим сообщить, что у нас появился канал на 📹Youtube!

Теперь все подкасты можно посмотреть в плейлисте "BIM-среда".

#1= Поворот в сторону IFC? (А. Высоцкий, О. Коршунова)
#2= Open Design Alliance - от DWG до IFC (А. Боровиков)
#3= Открытые ТИМ-стандарты в теории и на практике (В.А. Семёнов, часть 1)
#4= Открытые ТИМ-стандарты в теории и на практике (В.А. Семёнов, часть 2)
#5= bSDD - что это и зачем? (Илья Усов)
#6= Раскрывая возможности IFC (Д. Чилин, В. Хоцанович)
#7= IFC на всём жизненном цикле объекта (В. Золотов)

Подписывайтесь, чтобы ничего не пропустить!

👥 @IFC_ru
👥 @IFC_club

🌐 IFC: панацея или суррогат?

С таким заголовком вышел журнал "Информационное моделирование" (от компании CSoft) с двумя статьями, посвященными плюсам и минусам применения IFC.

🆙 Начнем с аргументов "ЗА" от заместителя генерального директора Renga Software Максима Нечипоренко. Выделим ключевые моменты из его статьи:

✅открытость спецификации IFC;
✅огромная история и проработанность;
✅сформированное сообщество в лице нескольких сотен ПО;
✅возможность раcширения схемы IFC;
✅закреплен в качестве национального стандарта (ГОСТ Р 10.0.02-2019/ИСО 16739-1:2018);
✅гибкость и разные способы настройки модельных представлений (MVD);
✅вариативность (возможность представления в различных нотациях)

🆙 Аргументы "ПРОТИВ" готовил Александр Волков, директор ГК CSoft Дальний Восток. Главные недостатки применения IFC по его мнению:

❔сложности обмена данными из-за использования разработчиками разных графических ядер для своих приложений;
❔сложности с прямым редактированием модели в IFC;
❔зависимость новых версий IFC от финансирования со стороны крупных игроков строительного рынка;
❔санкционные ограничения не дают возможности использовать будущие редакции стандарта IFC в юридическом плане;
❔использование IFC не решает проблемы применения пиратского ПО;
❔в IFC не учтена национальная специфика строительной отрасли.

P.S. Стоит отметить, что пункты "ПРОТИВ" следует прокомментировать отдельно, так как каждый из них по большому счету является нерешённым вопросом, сложностью.
Комментарии последуют далее 👉

#Мифология

Прокомментируем перечисленные выше недостатки IFC.

⬜️ Сложности обмена данными из-за использования разработчиками разных графических ядер для своих приложений.

Комментарий:
Суть вопроса сводится к интероперабельности на семантическом и програмно-техническом уровне. Очевидно, что сделать формат, идеально подходящий под все имеющиеся в мире программные решения с их графическими ядрами, невозможно, так как все ПО разные и их внутренняя структура организации данных тоже разные. Проблема здесь не в IFC, а в том, что большинство ПО изначально не учитывали принципы организации данных согласно этому стандарту. Из этого проистекают проблемы. Решение здесь только одно: разработчикам необходимо добросовестно подойти к поддержке IFC. И такие примеры есть, в том числе в отечественной практике.

⬜️ Сложности с прямым редактированием модели в IFC.

Комментарий:
Отметим, IFC изначально создавался не для этого, а для формирования единого языка взаимодействия и передачи данных между программными решениями.

Но если и говорить о "нативном" и редактируемом IFC, то это возможно и этому есть практические примеры. Правда до недавнего времени этой задачей мало кто из разработчиков занимался. Однако сегодня существует ряд решений, поддерживающих редактирование IFC файлов, например 7d моделер, ACCA usBIM.editor, BlenderBIM, некоторые утилиты от BIMVision и другие.
Кроме того, в России разрабатываются два независимых друг от друга IT-стартапа по генерации моделей зданий в IFC.

#Мифология

Продолжение:

⬜️ Зависимость новых версий IFC от финансирования со стороны крупных игроков строительного рынка.

Комментарий:
Любая серьезная разработка зависит от финансирования. На голом энтузиазме они не делаются. И разработчики САПР поступают точно так же.

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

И если крупный представитель может предлагать и влиять на развитие стандарта в позитивном ключе - это скорее плюс, чем минус.

Конечно, есть альтернатива не вкладываться в развитие IFC, а подчиниться монополистам вроде Autodesk с его закрытыми форматами, и тогда никаких открытых стандартов не будет в принципе. Но у такого монопольного подхода совсем другие риски.

⬜️ Санкционные ограничения не дают возможности использовать будущие редакции стандарта IFC в юридическом плане.

Комментарий:
1) IFC - открытой стандарт. Он описывается на языке EXPRESS, закрепленном стандартами ISO 10303, которые переведены на русский язык в качестве национальных стандартов ГОСТ Р.

2) Принятие актуальной версии IFC4x3 в качестве стандарта ISO 16739, планируемое в апреле 2024 года, позволит применять его без каких-либо юридических препятствий и угроз национальной безопасности. Более того, это только поспособствует утверждению его национальным стандартом.

#Мифология

Завершение:

⬜️ Использование IFC не решает проблемы применения пиратского ПО;

Комментарий:
Встречный вопрос: а какой формат это решает? Это проблема из другой плоскости и решение ее не связано с форматами данных. По этой логике XML-формат предоставления смет (.gge) способствует пиратству сметных программ?
Наоборот, открытые форматы позволяют как развиваться бесплатным openSource проектам, так и договариваться различным разработчикам между собой (пример, объединение АРСИТИМ с форматом. TIMML).

⬜️ В IFC не учтена национальная специфика строительной отрасли.

Комментарий:
Во-первых, в статье не приводится примера, а в каком формате решены все вопросы национальной специфики, и в чем она заключается.

Во-вторых, в IFC присутствует возможность его использования с учетом различных специфик и целей. В этом его сила. Реализуется это разными способами (альтернативной классификацией, расширением предопределенных типов, введением дополнительных наборов свойств, использованием bSDD и так далее).

И в завершение отметим, что за 30 лет существования IFC у представителей отечественной стройотрасли и разработчиков САПР, как и у всего мира, всегда была возможность повлиять на развитие IFC и внести свои предложения. На наш взгляд, это лишь вопрос IT-зрелости как отдельных организаций, так и отечественной отрасли в целом.

#Мифология

👥 @IFC_ru
👥 @IFC_club

Что означают цвета в описании классов IFC

В технической спецификации стандарта IFC различные сущности помечены разными цветами. Расшифруем, что они значат:

🛑Черным обозначается любая сущность, экземпляр которой может быть создан. При этом не важно наличие или отсутствие геометрии.

🛑Серым обозначается "верхнеуровневая" абстрактная сущность, на базе которой экземпляры не могут быть созданы.

🛑Красным - классы, которые будут удалены в следующих версиях схемы IFC и больше не будут использоваться.

Изменяются ли эти классы от версии к версии схемы?

Да, изменяются, так как со временем приходит новое понимание классификационной иерархии.

Пример: В схеме IFC4 сущность IfcBuildingElement, обобщающий строительные классы здания, является абстрактным. Но в схеме IFC4x3 он переименован в IfcBuiltElement и стал определенным. Теперь этот строительный класс относится не только к зданиям. И он может быть назначен элементам, которые не конкретизированы в классификационной системе IFC.

#База

👥 @IFC_ru
👥 @IFC_club

Как описываются “пустоты” в IFC?

Зачастую в САПР есть довольно ограниченный инструментарий для создания элементов, отвечающих за создание пространств, зон, помещений, отверстий. Так, например, проектировщики чаще всего моделируют отверстия с помощью «окон». А для группировки помещений необходимо добавлять к ним свойства, определяющие принадлежность к той или иной группе, что является достаточно примитивным способом.

В IFC для таких задач выделены отдельные сущности. (см. шпаргалку).

Можно условно выделить два типа таких элементов:

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

🛑 "вырезающие", то есть зависимые от физических элементов и вычитающие их объем.

Для группировки "самостоятельных" пространств предусмотрена отдельная сущность IfcZone, которая не содержит собственной геометрии. Эта сущность, например, хорошо подойдет для объединения помещений в квартиры.

#База

Ежемесячный подкаст "BIM-среда" в IFC Клубе!

🗓️ Среда, 6 марта, в 16-00 МСК

🔊 Тема: "Основные принципы IFC и их реализация в Renga"

Спикер:
🇷🇺 Евгений Кирьян, ведущий менеджер по продукту Renga Software

Поговорим о:
🛑 базовой структуре IFC;
🛑 типах геометрических представлений;
🛑 возможностях Renga по работе с IFC.

Присоединяйтесь!
Встреча будет проходить в группе в формате видео-чата.

👥@IFC_ru
👥@IFC_club

✈️ Запись вчерашнего подкаста "BIM-среда" доступна на Youtube-канале 📹 (звук исправлен)

✈️ Тема: Основные принципы IFC и их реализация в Renga
✈️ Спикер - Евгений Кирьян @EugeneKiryan, ведущий менеджер по продукту Renga Software

✈️ Сcылка на доску Miro с презентацией: https://miro.com/app/board/uXjVNrq-5ms=/

✈️ Дополнение:
Статьи Евгения Кирьяна по теории и практике работы с IFC:
- Тюнинг IFC-моделей. Добавляем Зоны (IfcZone). Часть 1.
- Тюнинг IFC-моделей. Добавляем Зоны (IfcZone). Часть 2.
- Тюнинг IFC-моделей. Вращаем объекты. Теория.
- Тюнинг IFC-моделей. Вращаем объекты. Практика.

@IFC_ru
@IFC_club

IFC Toolbox - бесплатный помощник по работе с IFC

Чем поможет:
🛑IFC Optimizer – уменьшает размер файлов.

🛑IFC Converter – преобразует IFC в форматы OBJ, Collada, STEP, IGES, XML и SVG.

🛑IFC Splitter – делит файлы по участкам/зданиям/уровням или по выбранным объектам в иерархии IFC-модели.

🛑IFC Relocator – работает с мировыми координатами IFC и координатами проекта.

🛑IFC Anonymizer – удаляет информацию об авторе, программном продукте, организации и т.д.

🛑IFC Validator – проверяет на наличие свойств согласно классификации IFC.

Github | Microsoft Store

Протестируем?

#Tools

В ожидании нового ПП РФ 1431

В преддверии нового постановления Правительства (ех. ПП РФ 1431) о составе и правилах формирования и ведения информационной модели ОКС важно отметить потенциальные проблемы формулировок в части форматов представления ЦИМ. Утратившее силу ПП РФ 1431 и текущий проект нового ПП до введения официальной XML-схемы предлагает представлять трехмерные модели (ЦИМ) в следующих форматах:

г) LandXML или иной формат данных с открытой спецификацией - для цифровой модели местности;
д) IFC или иной формат данных с открытой спецификацией - для трехмерной модели.

Разберемся, какие подводные камни могут быть от такой формулировки:

1️⃣ Указание IFC без версии стандарта (IFC 2.0, IFC 2x3, IFC4, IFC4x3 и т.д.) принесет в процесс больше путаницы, чем пользы.

2️⃣ Для проектирования требуется совмещение как модели ОКС, так и модели изысканий, что означает необходимость поддержки обоих форматов (IFC и LandXML) в одном ПО. А как следствие необходимости серьезной доработки ПО и лишним трудозатратам.
Отметим, что LandXML не закреплен стандартом РФ.

3️⃣ Отдельный «дьявол» скрыт в фразе «иной формат с открытой спецификацией». Поскольку открытых форматов масса, и разработчик любого САПР или вьювера может свободно опубликовать свой формат.

Поэтому крайне важно избежать рисков несовместимости форматов и издержки на доработку информационных систем и САПР.

Видится логичным:
🛑обозначить единый формат для ЦИМ и для так называемых цифровых моделей местности, которые по сути являются разновидностью ЦИМ в части результатов инженерных изысканий.
🛑использовать для этого стандарт IFC, спецификация которого утверждена ГОСТ Р 10.0.02-2019 (будет лучше, если он будет обновлен до версии IFC4х3).
🛑объединить подпункты «г» и «д», изложив их в следующей редакции:

«г) IFC в версии, спецификация которой утверждена национальным стандартом – для цифровых информационных моделей объекта капитального строительства и результатов инженерных изысканий».

#Стандартизация

👥 @IFC_ru
👥 @IFC_club